Meia-noite, o seu novo protocolo de agregação de liquidez de repente enfrenta liquidações anormais. Num piscar de olhos, os ativos dos utilizadores desaparecem e a comunidade explode de surpresa, mas o relatório de auditoria afirma que o seu código de contrato é «sem mácula». Como é isso possível?

Muitas vezes, o problema não está no seu código — mas na fonte de dados que integrou.

Isto não é alarmismo. Os desenvolvedores de DeFi não são apenas criadores, mas também a primeira linha de defesa dos ativos dos utilizadores. Ao decidir integrar um serviço de oráculo na sua aplicação, você não está apenas trazendo dados de preços, mas assumindo uma responsabilidade de «partilha de riscos» a longo prazo.

**Integrar não é sinónimo de abandonar**

Muitos desenvolvedores assumem automaticamente: ao usar um grande serviço de oráculo, a responsabilidade pelos dados é transferida. Errado. A sua responsabilidade começa no momento em que os dados entram no contrato.

Você compreende realmente o mecanismo de atualização dessa fonte de dados? Como são tratados os valores atípicos? O contrato tem tolerância a atrasos e verificações de anomalias? Quando a rede fica congestionada e os dados atrasam, o seu mecanismo de liquidação pode desencadear uma cadeia de explosões?

**Lições sangrentas**

Um protocolo de empréstimos já sofreu com isso. Eles não configuraram tolerância a atrasos de preços. Como resultado, durante uma breve latência na rede do oráculo, bots de arbitragem aproveitaram a oportunidade para fazer liquidações em massa com preços desatualizados e baixa garantia. Milhões de dólares evaporaram num instante, e a confiança dos utilizadores desmoronou completamente.

O serviço de oráculo é uma ferramenta útil, mas como usá-lo, até que ponto, depende, no final, de si mesmo.