ERC-7683 em 2026: como funcionam os resolvers e solvers cross-chain

Uma operação entre redes blockchain precisa coordenar ações executadas em sistemas distintos. Nos modelos baseados em intents, o usuário expressa o resultado que deseja obter e outros participantes se encarregam de executar a ordem sob suas condições.ERC-7683busca facilitar que esses sistemas compartilhem uma representação compreensível das ordens.

A especificação mantém o status Draft e utiliza uma arquitetura centrada em resolvers, contratos que interpretam as ordens, diferente do modelo inicial de interfaces rígidas de 2024. Essa evolução importa ao comparar implementações: uma representação comum pode facilitar a integração, mas a aplicação deve continuar explicando como cada operação é executada e quando é considerada concluída.

Por que é necessária uma representação comum das ordens

Um intent expressa o resultado que o usuário deseja, por exemplo, entregar um ativo em uma blockchain e receber outro em uma rede distinta, sem impor todas as etapas de execução. O problema surge quando cada protocolo codifica essa ordem, suas restrições e seus pagamentos de forma diferente. Um solver precisaria manter uma integração específica para descobrir e avaliar cada mercado.

O ERC-7683 coloca uma camada de tradução entre os dois lados. A ordem original pode ser um payload opaco próprio do protocolo. Um resolver a interpreta e devolve uma representação comum que outros sistemas podem consultar sem conhecer de antemão todos os detalhes desse formato privado.

Resolver e solver não são a mesma coisa

O resolver é o adaptador: transforma a ordem em etapas, variáveis e pagamentos normalizados. O solver é o agente econômico que analisa essa saída, estima custos e riscos e decide se consegue concluir a execução com lucro. Separar os dois papéis permite que um protocolo preserve sua lógica própria e, ao mesmo tempo, exponha oportunidades a um conjunto mais amplo de executores.

A representação comum descreve quais ações devem ocorrer, quais valores podem variar e quais pagamentos remuneram o executor. Os endereços interoperáveis se apoiam no ERC-7930 para identificar contas ou ativos além do formato de uma única blockchain.

Fluxo simplificado de uma ordem

Primeiro, o usuário assina ou envia uma ordem ao protocolo de origem. Segundo, um resolver decodifica esse payload e devolve a representação comum por meio de uma consulta. Terceiro, um ou mais solvers comparam a oportunidade com sua liquidez, inventário, latência e custo de capital. Por fim, o solver escolhido executa as etapas e o mecanismo do protocolo verifica o resultado antes de liberar o pagamento.

O que padroniza e o que deixa de fora

A proposta padroniza a forma como uma oportunidade é resolvida e apresentada aos solvers. Por si só, não define uma bridge universal, um sistema de mensageria, uma rede de liquidez nem um mecanismo único de disputa. Duas implementações compatíveis podem oferecer garantias muito diferentes, porque sua segurança depende de como verificam e liquidam a execução.

Riscos e decisões de integração

Uma equipe deve fixar a versão exata do draft, auditar o resolver, validar que pagamentos e variáveis não permitam ambiguidades, limitar replays e expirações e estudar o que acontece se uma parte da operação for executada e outra falhar. Também deve avaliar a concentração de solvers: um formato aberto melhora o acesso, mas não cria competição nem liquidez por si só.

Um exemplo para revisar as premissas do solver

Suponha uma ordem que exige entregar um ativo em outra rede antes de um prazo e receber depois o pagamento correspondente. O solver precisa de mais do que o endereço de destino: deve saber qual evidência libera o recebimento, quando pode considerá-la suficiente e quais condições poderiam impedi-lo depois de ter comprometido capital.

Na arquitetura descrita pelo draft, o resolver EVM pode ser consultado via eth_call. Sua resposta inclui instruções e premissas que o solver deve avaliar. A consulta, por si só, não executa a ordem nem garante que as dependências externas mantenham o estado observado.

A revisão técnica deveria simular uma expiração durante o percurso, uma mudança de permissões e uma prova de execução que não seja aceita pelo sistema de liquidação. O objetivo é localizar onde o capital fica retido e qual procedimento permite concluir ou encerrar a operação. Uma representação comum facilita a leitura das instruções; a segurança depende de que essas instruções e suas premissas estejam corretas.

Por que pode importar mesmo ainda em Draft

A tese do ERC-7683 é que a interoperabilidade não precisa obrigar todos os protocolos a compartilhar uma única lógica interna. Ela pode padronizar o ponto de encontro em que os executores leem e comparam ordens. Se o draft convergir e for adotado, reduz o custo de integrar novos mercados de intents; enquanto isso, convém tratá-lo como uma interface em evolução, não como uma garantia de compatibilidade definitiva.