O ERC-7683 está mudando, e muitas explicações ainda descrevem uma versão anterior do padrão. A versão atual do rascunho do ERC-7683 é mais centrada no resolver. Em vez de forçar todos os protocolos de intenção cross-chain a usar um único contrato de custódia compartilhado, um único sistema de leilão, um único mecanismo de liquidação, um único modelo de autorização ou uma única função de preenchimento de destino, os protocolos podem manter sua própria arquitetura de execução, enquanto expõem pedidos aos solvers por meio de uma camada de resolução comum. Essa distinção é importante. Um pedido ERC-7683 é essencialmente uma oferta de pagamento em troca da satisfação de um conjunto definido de requisitos. Solvers, também chamados de preenchedores, avaliam esses requisitos, determinam qual execução é necessária, comprometem capital ou gás e esperam pagamento se cumprirem corretamente o pedido. O design atual permite que um protocolo expõe uma carga útil opaca e específica do protocolo juntamente com um contrato resolver. Esse resolver traduz a carga útil em uma representação comum contendo: • etapas de execução • variáveis • pagamentos • suposições explícitas Isso fornece aos solvers programáveis uma maneira padronizada de entender o que um pedido realmente exige, sem que cada solver precise implementar lógica totalmente personalizada para cada protocolo de intenção. O modelo de execução resolvido pode expor requisitos de gasto de tokens, requisitos de gás, restrições de tempo, dependências e comportamento de revert. Variáveis podem representar endereços de pagamento do solver, cadeias de pagamento, saídas de execução, chamadores de etapas, testemunhas fora-da-cadeia, consultas de contrato e consultas de evento. O ERC-7683 também incorpora representações interoperáveis de endereços por meio do ERC-7930, vinculando o contexto da cadeia ao endereço em vez de depender apenas de um endereço EVM convencional de 20 bytes. Mas há um limite de segurança importante. A padronização do ERC-7683 não torna automaticamente o protocolo de intenção subjacente seguro. Contratos de liquidação, pontes, sistemas de troca de mensagens, tokens, mecanismos de leilão, serviços fora-da-cadeia, oráculos, bloqueios de recursos, proteção contra replay, lógica de cancelamento, comportamento de reembolso e preenchimento parcial permanecem como riscos específicos do protocolo, a menos que sejam explicitamente representados por meio dos requisitos ou suposições resolvidos. A segurança do resolver é, portanto, crítica. Um resolver deve validar corretamente sua carga útil específica do protocolo e expor uma representação que permita a um solver agindo adequadamente compreender o que deve acontecer e sob quais suposições o pagamento se tornará disponível. Um resolver correto não pode tornar seguro um sistema de liquidação inseguro. E um formato de pedido compatível não remove o risco do solver. Um preenchedor fica economicamente exposto desde o momento em que compromete aprovações, gás, capital ou transações até que seu pagamento esperado se torne final e utilizável. Para os usuários, os pontos-chave de verificação permanecem práticos: • cadeia de origem • ativo de entrada • cadeia de destino • destinatário • saída esperada • prazo final • escopo de autorização • transação ou dados tipados sendo assinados O ERC-7683 também se encaixa naturalmente dentro de sistemas mais amplos de intenção, como o Open Intents Framework, mas os dois não são intercambiáveis. O ERC-7683 é principalmente uma camada de padronização para resolução de pedidos voltada para solvers. O OIF é um framework infraestrutural mais amplo que abrange originação de intenção, solução, cumprimento, liquidação, agregação e componentes relacionados. Nossa mais recente pesquisa do TokenToolHub detalha o design atual do ERC-7683, como ele difere das versões anteriores, o ciclo de vida do pedido, solvers, segurança do resolver, etapas de execução, pagamentos, suposições, endereços interoperáveis e os riscos do solver que permanecem fora do próprio padrão. Análise completa: https://t.co/VK5Yb4wvJ3