Intenções e redes de solvers: como funciona a ponte por intenção

2026-08-24

Uma intenção é uma ordem que diz qual resultado você quer obter, e não quais transações precisam ser enviadas. Você a assina, um conjunto de solvers disputa a entrega desse resultado e uma camada de liquidação paga quem entregou. Roteamento, gas e espera entre redes saem do usuário e vão para uma contraparte profissional, e surge outro conjunto de perguntas: quem pode dar lance, com que régua isso é medido, o que sustenta a promessa e o que acontece com o seu dinheiro quando ninguém dá lance.

Ordens declarativas: o que é de fato uma intenção

Uma transação comum é imperativa. Ela nomeia o contrato, a função, os argumentos e o gas, e assiná-la autoriza exatamente um caminho de computação sobre um estado dado. Tudo fica decidido antes da assinatura, e tudo o que não foi previsto é problema seu.

Uma intenção é declarativa. É um conjunto assinado de restrições que descreve o resultado que você aceita, e admite qualquer caminho de execução que as satisfaça. A transação diz “faça A e depois B, pague exatamente C e receba X”; a intenção diz “quero X e estou disposto a pagar no máximo C”. Vista assim, a transação é o caso particular de uma intenção que admite apenas uma transição de estado.

A consequência prática é que, ao assinar e distribuir uma intenção, você concede a um terceiro permissão para escolher o caminho de computação no seu lugar. É daí que vem a comodidade, e é daí que vem também todo risco descrito aqui.

Nada disso é novo em espécie. Ordens limitadas, pagar a taxa com um token que você já tem, agregadores que prometem a melhor rota entre vários mercados: tudo isso tem formato de intenção, com o usuário definindo a condição e outra pessoa escolhendo a execução. O que é novo é que isso vem sendo construído como infraestrutura geral e que uma mesma ordem pode atravessar várias redes.

Os quatro papéis de um sistema de intenções

Escrito como ciclo de vida, o padrão tem quatro partes. Um usuário expressa uma intenção a um aplicativo; o aplicativo a transforma em uma ordem de um protocolo específico; a ordem entra em um fluxo de ordens onde os solvers a enxergam; um solver a avalia, executa os passos exigidos, e um processo de liquidação paga o solver.

Vale aprender o vocabulário, porque ele já está escrito em um padrão. Uma ordem é uma oferta de pagamento em troca do cumprimento de um conjunto de requisitos. Um solver, também chamado de filler, é quem cumpre esses requisitos. O pagamento fecha o circuito: o solver trabalha primeiro e só recebe na liquidação.

O padrão em questão é o ERC-7683, intenções entre redes (Cross Chain Intents). É um ERC da trilha Standards Track, criado em abril de 2024, e, no momento em que este texto é escrito, segue no estado Draft, ou seja, rascunho. Ele também foi bastante reformulado: um rascunho anterior padronizava a codificação das ordens, um fluxo de ordens na rede, a custódia e a função de execução, enquanto o texto atual padroniza apenas a interface pela qual um solver lê uma ordem, deixando cada protocolo livre na criação de ordens, na autorização, no preço e na liquidação. Ele se apoia no ERC-7930, o formato de endereços interoperáveis, que está no estado Review.

O estado de rascunho pesa mais aqui do que em outros lugares, porque não é a única proposta da área: o ERC-7521 trata de intenções gerais para carteiras de contrato inteligente e também segue como rascunho. Não trate nada disso como resolvido. O campo de estado de cada ERC aparece no início da página dele no repositório de ERCs do Ethereum, e a discussão viva está na thread do Ethereum Magicians que o próprio texto indica, então confira você mesmo o estágio atual.

Por que é o solver que adianta o dinheiro

Sob as intenções entre redes existe um fato incômodo: duas redes não liquidam de forma atômica, alguém precisa se mover primeiro. No desenho mais comum, os fundos do usuário ficam travados em um contrato da rede de origem no momento em que a ordem é criada, para que o solver tenha certeza de que o dinheiro existe antes de comprometer capital próprio do outro lado.

Depois o solver entrega o resultado com o próprio estoque: ele tem o ativo na rede de destino, envia para você e só mais tarde é reembolsado a partir dos fundos travados, pelo processo de liquidação. Em um desenho já em produção as execuções são agrupadas em lotes e reembolsadas em um ciclo medido em horas, não em segundos, e por isso um solver precisa de capital de giro e não apenas de um robô rápido.

As transações também são enviadas pelo solver, ou seja, o gas é pago por ele. Esse é o mecanismo por trás dos fluxos de intenção anunciados como sem gas: o custo não sumiu, foi transferido para o preço que o solver cota para você.

Esse intervalo entre gastar e receber é exatamente onde mora o risco do solver. A seção de segurança do próprio padrão diz sem rodeios: o solver fica exposto desde o instante em que compromete capital, aprovações ou transações até que o pagamento esperado seja definitivo e utilizável. Tudo o que pode dar errado nessa janela, de uma reorganização da rede à entrega de mensagens ou a um protocolo que muda de estado, já está embutido no preço que você vê.

Como a competição define o preço que você recebe

Como o usuário deixou de indicar a rota, o preço precisa ser produzido pela competição. Os desenhos diferem no método: alguns usam leilões holandeses em que a marca a ser batida se move com o tempo, outros tiram o preço de um oráculo, outros fixam a taxa e deixam os solvers competirem só em velocidade.

Os leilões em lote são a versão mais explícita. As ordens são recolhidas em uma janela curta, os solvers enviam soluções completas, cada solução é pontuada aproximadamente pelo excedente que gera para os usuários do lote, e vence a de maior pontuação. Os vencedores são pagos por uma regra de segundo preço, então a recompensa depende da margem sobre o próximo melhor lance e não do que o vencedor alegou.

A competição só ajuda se houver uma referência. Um conjunto de regras publicado exige que os preços de um solver não sejam piores do que o usuário obteria em uma lista definida de fontes de liquidez de referência, e exige preços de liquidação uniformes: duas ordens do mesmo par e no mesmo sentido precisam receber o mesmo preço. Sem algo assim, a melhor execução é o que o solver vencedor disser que é.

Essa é também a resposta honesta sobre por que intenções podem vencer o roteamento manual. Um solver pode casar a sua ordem com a ordem contrária de outro usuário, empacotar várias execuções em uma só transação e escolher para o reembolso a rede que lhe custa menos. A economia é real, mas chega até você na medida em que a competição e a regra de pontuação obrigam.

O que de fato sustenta a promessa do solver

Assinar uma intenção é dar margem a outra pessoa. O que trava o abuso não é a assinatura, e sim a camada de prestação de contas construída em volta do conjunto de solvers, e essa camada é diferente em cada sistema, que é justamente o que quase toda explicação pula.

O primeiro controle costuma ser a entrada. Em um conjunto de regras publicado, um solver precisa estar em uma lista branca antes de sequer enviar uma liquidação; os operadores mantêm um monitoramento que inspeciona cada liquidação na rede e sinaliza as suspeitas; o descumprimento sistemático pode ser punido, até o slashing.

O segundo controle é a verificação com janela de contestação. Em vez de provar cada execução na rede, um desenho de liquidação deixa um participante propor um lote de resultados junto com uma garantia, e o lote é aceito se ninguém o contestar dentro de um prazo fixo. O usuário recebe a velocidade primeiro; a prova vem depois.

O terceiro controle é a própria fronteira de confiança, e o padrão é incomumente direto sobre onde ela termina. O ERC-7683 padroniza como uma ordem é descrita aos solvers; ele não padroniza nem garante a segurança do protocolo que acaba liquidando a ordem. Espera-se que os solvers auditem por conta própria o contrato que traduz ordens para eles e validem as premissas que esse contrato não consegue conferir. Ao usuário, o padrão não promete nada sobre o sistema de liquidação que está embaixo.

Como funciona a ponte por intenção: o usuário assina um resultado, os solvers dão lances e adiantam capital, e a liquidação os reembolsa

Concentração, censura e o caminho de volta do seu dinheiro

O risco estrutural do modelo de intenções é o conjunto de quem vê e pode executar a sua ordem ficar pequeno. Se o acesso ao fluxo de intenções for permissionado e a lista for escolhida sem cuidado, o fluxo de ordens se concentra, e quem controla uma fatia grande passa a poder cobrar renda e, no limite, censurar.

A propagação aberta não resolve isso sozinha. Um nó capaz de executar uma intenção com lucro não tem incentivo para repassá-la aos concorrentes, e um pool de intenções totalmente público expõe as ordens à mesma extração de um mempool público. É por isso que tantos sistemas param em desenhos permissionados ou híbridos, e por isso a pergunta prática não é se aquilo é descentralizado, e sim quem está na lista e quem decide.

O custo associado é a opacidade. Na pior versão, você assina algo, aquilo some e reaparece como uma transação sem que se veja quem a montou nem quais alternativas foram descartadas. Qualidade de execução que você não consegue auditar é qualidade de execução aceita na confiança.

Depois vem a falha mais banal, mais comum do que as exóticas: ninguém dá lance. As ordens carregam um prazo de execução. Se ele passa sem execução e sem execução parcial, a ordem expira e os fundos travados voltam, em geral para o endereço indicado na ordem e, por padrão, na rede de origem. As causas são prosaicas: um valor grande demais, um par de tokens incomum ou solvers fora do ar por um tempo.

O que esse reembolso não é, é imediato. Como o dinheiro volta pelo mesmo processo de liquidação em lote que paga os solvers, uma execução normal leva segundos e uma expiração pode levar horas para se desfazer. Quando você dimensiona uma ordem ou constrói um produto em cima, o prazo de execução e o caminho de reembolso são os dois parâmetros que valem mais a leitura do que a taxa.

Em resumo

As intenções transferem o trabalho de execução do usuário para quem dá lance: você assina o resultado desejado, os solvers competem para entregá-lo, adiantam capital e gas, e uma camada de liquidação paga quem cumpriu. O ganho de eficiência é real e a troca também, porque você entrega a um terceiro a discricionariedade sobre como a sua ordem é executada, e o que protege você não é a assinatura, e sim as regras do leilão, a referência contra a qual esses lances são pontuados, as condições de entrada e o monitoramento em volta do conjunto de solvers, e o prazo que devolve o seu dinheiro quando ninguém dá lance. O padrão de ordens entre redes, o ERC-7683, ainda é um rascunho e já foi redesenhado uma vez, então trate qualquer descrição dele, inclusive esta, como uma foto de um momento, e confira o campo de estado antes de construir em cima.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- Modelos de ponte: travar, queimar e emissão nativa

- O que é Hyperlane? Interoperabilidade sem permissão

- Pontes de stablecoins: movendo dólares entre redes

Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em agosto de 2026; consulte as informações oficiais mais recentes.