Um pedal de freio e um acelerador não devem seguir a mesma lógica de permissão.

Isso pode parecer óbvio, mas acho que as finanças automatizadas muitas vezes tratam as ações de forma excessivamente uniforme. Uma transação chega, o sistema verifica uma política e o resultado vira aprovar ou rejeitar.

O processo parece limpo.

O risco por trás de cada ação não é.

Uma estratégia orientada por IA que aumenta a alavancagem faz algo fundamentalmente diferente do que a mesma estratégia ao encerrar uma posição. Mover fundos para um novo contraparte cria uma exposição diferente de devolver capital a um cofre aprovado. Comprar um ativo desconhecido não necessariamente deve enfrentar o mesmo caminho de autorização que reduzir a concentração em uma posição existente.

É aqui que eu acho que @NewtonProtocol se torna mais interessante do que uma simples narrativa de automação.

O Newton’s Mainnet Beta e o VaultKit focam na autorização antes da liquidação: verificar uma ação em relação a regras definidas antes de ela se liquidar e, então, produzir uma atestação assinada que pode mostrar que a avaliação ocorreu.

Eu vejo um valor real nesse design.

Mas eu acho que a versão mais forte da ideia vai além de perguntar se uma transação se encaixa em uma política.

Ele pergunta quanto de autorização aquela ação específica merece.

Considere um cofre automatizado durante um mercado volátil.

Uma ação aumenta a alavancagem porque a estratégia enxerga uma oportunidade.

Outra ação reduz a exposição porque as condições do colateral estão se deteriorando.

Se ambas as transações passarem exatamente pelo mesmo processo de aprovação, o sistema pode ser tecnicamente consistente enquanto permanece financeiramente insensível.

A primeira ação aumenta a perda potencial.

A segunda pode impedir isso.

Essa diferença deve importar.

Para mim, é aqui que a autorização proporcional ao risco se torna importante. Uma ação que expande a exposição pode precisar de condições mais rígidas: dados de mercado mais recentes, limites mais apertados, verificações de contraparte mais fortes ou uma janela de execução mais estreita.

Uma ação que reduz risco claramente pode precisar de um caminho mais rápido, especialmente quando o atraso em si poderia piorar a posição.

Eu não estou argumentando que transações que reduzem risco devam burlar a autorização.

Estou defendendo que a autorização deve entender direção.

Um sistema que só sabe “permitido” e “não permitido” pode perder o significado econômico do que o agente está tentando fazer.

Isso se torna ainda mais importante com agentes de IA porque sistemas automatizados não pausam e interpretam o contexto naturalmente do jeito que um trader humano poderia.

Uma pessoa pode olhar para o mercado e pensar:

“Este trade normalmente viola minha rota preferida, mas eu preciso reduzir a exposição imediatamente.”

Uma política rígida engne pode só ver que a rota não foi aprovada.

O resultado poderia ser uma contradição estranha: a camada de autorização bloqueia uma ação projetada para tornar a carteira mais segura porque a transação não se encaixa em uma regra escrita para condições normais.

Isso não significaria que a regra falhou.

Isso significaria que a política não tinha consciência de risco.

Esta é a parte do NEWT que eu acho que vale a pena acompanhar de perto. Newton está tentando trazer permissões executáveis para as finanças onchain automatizadas. O desafio mais difícil é tornar essas permissões expressivas o bastante para distinguir entre ações que criam risco e ações que o removem.

Uma atestação assinada poderia se tornar mais útil quando comunica essa distinção.

Em vez de eu querer apenas provar que uma transação passou por uma regra, eu gostaria que a lógica da política ao redor deixasse claro por que aquele nível de autorização foi aplicado.

A estratégia estava aumentando a alavancagem?

Ela estava reduzindo a exposição?

Ela estava interagindo com um ativo previamente aprovado?

Ela estava entrando em um novo mercado?

Foi usando uma condição de saída de emergência?

Esses detalhes podem mudar como deveria ser um processo de autorização sensato.

Eu também acho que isso poderia melhorar a compreensão do usuário.

A maioria das pessoas não quer estudar cada módulo interno de política antes de usar uma estratégia automatizada. Elas querem confiança de que o sistema fica mais cauteloso quando a ação se torna mais perigosa.

Isso é mais fácil de entender do que uma longa lista técnica de controles.

O princípio é simples:

Mais risco deve exigir permissões mais fortes.

Menos risco não deve ser adiado sem um bom motivo.

Claro, implementar esse princípio é difícil.

O primeiro problema é definir o que exatamente significa “reduzir risco”.

Fechar parte de uma posição pode reduzir a exposição ao mercado, mas criar custos de liquidez. Mover-se para um ativo estável pode reduzir a volatilidade, mas introduzir risco de contraparte ou de desancoragem. Sair de um cofre pode reduzir a exposição a smart contracts enquanto cria risco de liquidação ou de bridge em outro lugar.

Ações financeiras raramente movem risco em apenas uma direção.

Isso significa que a política não pode depender de um rótulo simples.

Pode ser necessário considerar várias dimensões ao mesmo tempo: alavancagem, liquidez, qualidade do colateral, concentração, exposição à contraparte e a confiabilidade dos dados que estão sendo usados.

O segundo desafio é prevenir abusos.

Se uma aplicação oferecer autorização mais rápida para ações que reduzem risco, uma estratégia mal projetada pode tentar classificar comportamento agressivo como defensivo. A definição deve ser executável, não apenas descritiva.

O terceiro desafio é a transparência.

Um usuário deve conseguir entender por que uma ação exigiu uma aprovação mais forte enquanto outra seguiu um caminho mais rápido. Se a lógica ficar escondida, a autorização sensível a risco pode começar a parecer arbitrária.

É aqui que atestações verificáveis poderiam se tornar especialmente significativas.

Um recibo não deve ser tratado como garantia de que cada julgamento financeiro estava correto. Mas ele pode fornecer evidências de que a ação foi avaliada sob uma política definida e de que o caminho de autorização exigido foi seguido.

Para mim, isso é mais útil do que simplesmente ver que uma transação foi executada.

Eu quero saber se o sistema reconheceu o tipo de risco que estava criando.

Eu também acho que diferentes aplicações vão precisar de diferentes perfis de autorização.

Um cofre institucional conservador pode exigir verificações rigorosas para quase todo movimento de capital.

Uma ferramenta de rebalanceamento para varejo pode usar limites mais simples.

Um agente de IA que gerencia um conjunto estreito de ativos aprovados pode precisar de menos atrito do que um que opera em múltiplas cadeias, contrapartes e mercados de empréstimo.

Essa flexibilidade é importante porque um único modelo universal de risco provavelmente se tornaria ou frouxo demais para capital sério ou restritivo demais para uso prático.

A infraestrutura específica do Newton se torna valiosa apenas quando desenvolvedores conseguem traduzir essas diferenças em regras executáveis sem tornar a experiência do usuário impossível de entender.

Esse é o equilíbrio que eu observaria com o Newt.

Pouco controle demais, e a automação se torna perigosa.

Controle rígido demais, e a automação perde a capacidade de responder quando os mercados se movem rapidamente.

A melhor camada de autorização não deve apenas bloquear ações proibidas. Ela deve reconhecer que algumas ações merecem uma análise mais profunda do que outras.

Para mim, este é o padrão real para finanças de IA controladas.

Eu não quero apenas um agente que siga regras.

Eu quero um agente cujo sistema de permissões fique mais rígido conforme as consequências se tornem maiores.

Porque, em mercados automatizados, tratar todas as transações com igualdade nem sempre cria justiça ou segurança.

Às vezes, isso só significa que o sistema não entendeu a diferença entre assumir risco e escapar dele.

$NEWT @NewtonProtocol #Newt

NEWT
NEWT
--
--