Certa vez em troquei meu número de telefone e o banco exigiu verificação por uma pergunta de segurança. Respondi tudo corretamente, mas ainda assim fui recusado, porque o sistema faz correspondência com os dados inseridos há dez anos; naquela época eu digitei errado, por engano, uma única letra, e não me lembrava. O conteúdo estava certo, mas o formato estava errado, e o sistema não distingue esses dois tipos de erro.
DeFi também tem um tipo de confusão exatamente igual — um endereço de carteira escrito em maiúsculas e minúsculas pode variar, um número arredondado pode diferir dos dígitos decimais, e ambos podem fazer com que uma condição que é verdadeira em essência seja considerada não correspondida, apenas porque a comparação é feita por correspondência absoluta de strings, em vez de entender o significado.
@NewtonProtocol se um policy engine compreendesse o significado das condições em vez de fazer apenas correspondência rígida, reduziria muitos casos de recusa injusta como esse.
Auto-reflexão: mas quanto mais você deixa o sistema “flexível para entender o significado”, mais camadas complexas de padronização de dados são necessárias, e cada camada adicionada vira também um lugar onde pode surgir um erro novo — padronizar demais pode fazer com que dois valores realmente diferentes sejam tratados como iguais, criando um risco inverso ainda mais perigoso: aceitar o erro porque parece certo.
A dificuldade do @NewtonProtocol não é tornar o sistema mais inteligente, e sim encontrar o limite exato dessa flexibilidade — o suficiente para não recusar injustamente diferenças inofensivas de formato, mas sem apagar também as diferenças realmente importantes.
$NEWT então deve ser avaliado pela capacidade de encontrar onde está esse limite, e não apenas por ter ou não aplicado tecnologia de compreensão semântica.

#newt $LAB $SAROS