Aquele instituto de dados estatístico informa que, atualmente, existem 3.500 vaults na rede, controlando US$ 89,3 bilhões. Isso, em 80%, ainda depende de uma única chave de manager para controlar diretamente; a confiança fica totalmente concentrada em uma única pessoa, o curator. Recentemente, usei o VaultKit na prática para montar um vault de rendimento de stablecoin e atravessei todo o fluxo de design — vou explicar os pontos que encontrei e a lógica subjacente.
A diferença do VaultKit em relação aos multisigs tradicionais não está na quantidade de assinaturas, e sim no pré-requisito. Ele troca “confiança na pessoa” por “confiança no código”. As regras são escritas no código; antes de executar, passa por uma verificação de estratégia. Se passar, então ele emite uma atestação criptográfica (cryptographic attestation) que pode ser auditada na cadeia; se não passar, os fundos nem sequer conseguem se mover. Esse tipo de mecanismo, dentro do @NewtonProtocol, é chamado de “camada de autorização para finanças on-chain”, e a lógica é basicamente alinhada à de uma rede de autorização de pagamentos do tipo Visa.
O cenário prático que eu trabalhei foi o seguinte. Gerenciar um vault de rendimento de stablecoin, com meta de TVL de US$ 50 milhões, aceitando depósitos de LP externos. O curator quer ajustar a taxa de empréstimo em Morpho ou obter rendimento via Aave; em todas as operações, é necessário passar primeiro pelo VaultKit.
Primeiro passo: definição de policy. Eu escrevi um policy pack em Rego — uma linguagem declarativa de políticas do Open Policy Agent. As regras se dividem em quatro partes. A camada de conformidade integra Chainalysis com Hexagate, fazendo a verificação automática de listas de sanções da OFAC e endereços de moedas roubadas; a camada de identidade executa KYC para o status de investidores qualificados; a camada de segurança faz varredura em tempo real de carteiras marcadas; e a camada de risco puxa a saúde do APY da RedStone e, com Credora, calcula a credibilidade do contraparte, além de impor um limite de no máximo 0,5% de drawdown por transação. Todo o conjunto, com algumas centenas de linhas de Rego, pode ser integrado em uma única etapa ao SDK do VaultKit.
Segundo passo: interceptação on-chain. Sempre que o curator envia uma ação de gerenciamento, o nó da Newton primeiro executa essa policy para avaliação. Se a camada de conformidade encontrar algo, o fluxo de fundos é interrompido; se a camada de risco exceder o limiar de drawdown, a operação é bloqueada diretamente. Se a avaliação passar, a rede de verifiers (na prática, os detentores de token que executam nós) assina uma attestation que pode ser verificada on-chain.
Terceiro passo: modelo econômico do verifier. O rendimento de staking do número
$NEWT não é uma recompensa passiva; é compensação de gas para o verifier rodar a avaliação, além de direitos de voto na governança. Se um nó agir de forma maliciosa, ele é penalizado (slash); os NEWT liberados pelo slash vão para o tesouro. Todo esse mecanismo é amarrado à segurança como no PoS — não é um incentivo “fraco”.
Comparando com o design tradicional de vaults, o que falta é “interceptação durante a execução vs auditoria após o fato”. Ficar com auditores monitorando essa lógica não é viável para LPs de pequenas instituições; o bloqueio via código é o que funciona.
O Mainnet Beta foi lançado em 23 de junho na TokenizeThisNYC, rodando no Ethereum com Base (na Base há mais agentes de IA do lado deles). A documentação está em docs.newton.xyz. Se você exige transparência on-chain para governança dos seus LPs, esta é uma opção que vale a pena adicionar à sua lista de conformidade.
#Newt #NewtonProtocol #VaultKit #DeFi