O que é o Delegation Toolkit e o que você pode criar com ele?

O controle de contas no Ethereum sempre foi rígido. As Externally Owned Accounts (EOAs) são simples e amplamente utilizadas, mas têm limitações no que podem fazer. As Smart Contract Accounts (SCAs) oferecem muito mais flexibilidade, mas até recentemente não conseguiam operar de forma independente. Ainda era necessário uma EOA para iniciar e pagar por cada transação.

Isso mudou com o ERC-4337, pois as SCAs agora suportam nativamente recursos como patrocínio de gas, agrupamento de transações (combinando múltiplas transações em uma só), session keys e abstração de chain, resultando em maior segurança, flexibilidade e controle para o usuário.

Ainda assim, as EOAs não desapareceram. E com razão: nem todo usuário considera útil ter uma conta que suporte lógica de verificação arbitrária. Qual seria o sentido de migrar para uma SCA agora?

Mas como garantir que, quando estiverem prontos para fazer a migração — ou mesmo para aproveitar temporariamente um ou mais recursos de conta ERC-4337 — eles não sejam obrigados a criar um novo tipo de conta do zero? Como permitir que as EOAs acessem os recursos de uma SCA para transações específicas sem abrir mão da configuração familiar?

É aqui que entra o EIP-7702 (Set-EOA-account-code).

Como parte da próxima atualização Pectra, o EIP-7702 permitirá que as EOAs se comportem temporariamente como SCAs, delegando o controle a um código de contrato inteligente que é executado diretamente a partir de seus endereços. Isso significa que os usuários não precisarão migrar para novas contas para aproveitar esses recursos avançados. A medida garante compatibilidade retroativa enquanto impulsiona o Ethereum para frente.

Apesar dessas melhorias, ainda há um aspecto importante de UX que precisa ser desbloqueado para alcançar plenamente uma experiência semelhante à web2. Trata-se de permissões granulares e flexíveis, nas quais o usuário pode facilmente compartilhar o poder de realizar uma ação específica em seu nome com outro usuário. Isso é feito de forma controlada, com restrições rígidas e a capacidade de revogar permissões quando necessário.

Esse é o desafio para o qual o Delegation Toolkit foi criado. Mas antes de mergulhar no que é e como funciona, vamos dar uma olhada mais detalhada nos dois ERCs que impulsionam esta próxima fase da UX de contas no Ethereum.

ERC 7710: Delegação de contratos inteligentes

O ERC-7710 é uma proposta para padronizar como as smart contract accounts delegam permissões específicas a outras contas Ethereum. Ele introduz uma interface comum para que os delegadores concedam autoridade a delegados com regras claras e aplicáveis.

Com o ERC-7710, os desenvolvedores podem criar sistemas nos quais uma conta permite com segurança que outra aja em seu nome sob determinadas condições, como limites de gastos, restrições de tempo ou permissões específicas para determinadas tarefas. Tudo isso é gerenciado por meio de um fluxo de delegação seguro e previsível.

Então, o que significa "delegação" neste contexto?

Em linhas gerais, trata-se de separar a propriedade da conta de sua execução. Um delegador ainda possui os ativos ou a lógica, mas pode transferir poderes específicos para outra pessoa temporária ou permanentemente, sem abrir mão do controle total.

Do ponto de vista da rede, o ERC-7710 traz clareza e composabilidade para a forma como as permissões são transferidas entre contas. Em vez de cada aplicativo desenvolver sua própria lógica de delegação, agora temos uma base compartilhada sobre a qual contratos e ferramentas podem ser construídos.

ERC 7715: Conceder permissões de carteiras

O ERC-7715 é uma proposta para simplificar como os dapps solicitam permissões das carteiras dos usuários. Ele introduz um modelo de permissões que permite aos dapps solicitar acesso pré-aprovado e com escopo bem definido à conta de um usuário, sem precisar de confirmações repetidas a cada interação.

Hoje, o fluxo de interação típico é complicado: um dapp solicita o envio de uma transação ou a interação com um contrato, e a carteira pede aprovação do usuário a cada vez. Não há como especificar limites, durações ou restringir o escopo do que um dapp pode fazer, nem uma forma padronizada para os usuários visualizarem ou revogarem essas aprovações posteriormente.

O ERC-7715 muda isso. Ele introduz um novo método, wallet_grantPermissions, que permite a um dapp solicitar capacidades específicas com antecedência. Por exemplo, ele pode solicitar permissão para gastar até 10 USDC na próxima hora ou interagir com um único contrato inteligente nas próximas sessões. O usuário revisa isso antecipadamente e aprova ou rejeita com total clareza.

Do ponto de vista do dapp, isso torna o onboarding mais fluido e permite experiências baseadas em sessão ou automatizadas que não interrompem constantemente o usuário. Para as carteiras, isso introduz uma estrutura limpa e auditável para gerenciar permissões e controlar o que foi concedido. Para os usuários, oferece melhor visibilidade, mais controle e menos pop-ups irritantes, tudo isso sem comprometer a segurança.

Então, o que os desenvolvedores podem criar com esses padrões?

Aqui estão alguns recursos que podem ser desbloqueados combinando ERC-7710 e ERC-7715:

• Defina limites diários de gastos a partir de uma carteira segura usando o ERC-7710 para delegar uma quantia fixa a uma carteira de uso mais frequente, mantendo a maior parte dos fundos com segurança offline.

• Simplifique o onboarding permitindo que os usuários realizem ações como mint ou resgate de recompensas sem configuração prévia de carteira ou aprovações de transações, usando delegações pré-definidas que concedem permissões limitadas automaticamente.

• Deixe agentes de IA negociarem em seu nome atribuindo permissões de execução limitadas via ERC-7710, com o ERC-7715 facilitando a aprovação dessas permissões pela sua carteira.

• Deixe um dapp cobrir as taxas de gas dos usuários atribuindo direitos de patrocínio a uma SCA que utiliza a delegação do ERC-7710, permitindo que transações específicas sejam processadas sem que o usuário precise de ETH.

• Revogue aprovações de tokens com segurança delegando permissão a um contrato auxiliar que chama approve(0) em seu nome, usando o ERC-7710 para restringir rigorosamente o que ele pode fazer e garantir compatibilidade com qualquer token ERC-20 padrão.

E muito mais.

Definindo o Delegation Toolkit

A maneira mais simples de descrever o Delegation Toolkit é como um conjunto de ferramentas que inclui dois pacotes principais:

1. O Delegation Core SDK – Um pacote que permite aos desenvolvedores criar smart contract accounts compatíveis com ERC-4337 (contas delegadoras) que se beneficiam de todos os recursos introduzidos pela abstração de contas ERC-4337.

2. O Delegation Framework – Um sistema que permite que smart contract accounts deleguem permissões a outras contas Ethereum por meio do padrão ERC-7710 e permite que sites, dapps ou, futuramente, qualquer coisa solicite permissões da sua conta por meio do ERC-7715 (em breve).

Portanto, em termos simples, o Delegation Toolkit torna possível criar dapps que suportam smart contract accounts (SCAs) ERC-4337, delegam permissões a outras SCAs ou EOAs e permitem que dapps solicitem essas permissões, seja de smart accounts ou, após a atualização Pectra, até mesmo de EOAs.

Se você já conhece como as smart contract accounts funcionam, já sabe o que esperar do pacote Delegation Core VIEM. Mas se não, fique à vontade para conferir a documentação oficial para uma análise mais aprofundada. No restante deste artigo, vamos nos aprofundar no próprio Delegation Framework e destacar alguns dos princípios fundamentais que o tornam tão poderoso.

Delegação off-chain

As delegações não precisam existir on-chain para serem válidas. Depois que a Conta A assina uma delegação para a Conta B, ela pode ser armazenada em qualquer lugar — IPFS, cache do navegador, armazenamento em nuvem ou até mesmo baixada localmente — pois é criptograficamente segura e utilizável apenas pelo delegado pretendido. Isso torna todo o sistema mais escalável e flexível.

Por exemplo, B pode buscar a delegação assinada quando necessário e usá-la em uma transação sem precisar de armazenamento on-chain ou custos de gas antecipados.

Permissões revogáveis

As delegações não são permanentes. O delegador original, digamos a Conta A, pode revogar qualquer delegação ativa que tenha emitido, mesmo que essa delegação já tenha sido repassada por meio de delegação transitiva (veja a seção sobre Delegação transitiva ou encadeada abaixo). Uma vez revogada, o gerenciador de delegações rejeitará qualquer tentativa de resgatá-la, incluindo quaisquer sub-delegações que dependam dela. Isso é fundamental para a segurança.

Se a Conta A suspeitar de comprometimento ou quiser atualizar as permissões, pode cortar o acesso instantaneamente, tornando toda a cadeia de confiança inválida. É como poder desligar tudo a qualquer momento sem precisar rastrear todos os envolvidos.

Delegações com escopo definido

Com o Delegation Toolkit, as delegações são normalmente definidas para um delegado específico. Isso significa que, se a Conta A assinar uma delegação para a Conta B, somente B pode resgatá-la. Mesmo que outra pessoa obtenha a delegação assinada, ela será inútil, pois está criptograficamente vinculada a B.

No entanto, também há suporte para delegações abertas. Essas são delegações que não especificam um delegado antecipadamente e podem ser resgatadas por qualquer conta. As delegações abertas são úteis quando você ainda não sabe quem será o delegado, mas devem ser usadas com cautela para evitar uso indevido. Você pode criar uma definindo o campo delegate para a constante especial ANY_BENEFICIARY (0x0000000000000000000000000000000000000a11).

Se a Conta B quiser posteriormente repassar uma permissão com escopo definido para a Conta C, ela deve criar explicitamente uma nova delegação de B para C. Isso garante que os limites de permissão permaneçam claros e intencionais, mesmo ao usar fluxos abertos ou transitivos.

Caveats

Caveats são as regras que definem como uma delegação pode ser usada. Pense neles como condições personalizadas que o delegador pode anexar a uma delegação. Por exemplo, se a Conta A delega para a Conta B, pode incluir um caveat dizendo que B só pode transferir até 1 ETH ou interagir apenas com um contrato específico nas próximas 24 horas.

Os caveats são aplicados em tempo de execução usando contratos especiais chamados caveat enforcers, que verificam se as regras estão sendo seguidas antes que qualquer ação seja executada. Portanto, mesmo que B tenha o direito de agir, ainda está operando dentro de um limite bem definido estabelecido por A. Veja aqui a lista completa de caveats suportados ou aprenda como criar seu próprio caveat personalizado.

Delegação transitiva ou encadeada

Um dos recursos mais poderosos do Delegation Framework é que a delegação não precisa parar em uma única transferência. Com a delegação transitiva, uma conta que recebe permissão — digamos, a Conta B — pode, por sua vez, delegar toda ou parte dessa autoridade a outra conta, formando uma cadeia de delegações originada de uma única conta.

Cada elo da cadeia é assinado criptograficamente e definido com seus próprios caveats, o que significa que as permissões podem ser reduzidas ou redefinidas em cada nível. Em outras palavras, essas sub-delegações podem ser um subconjunto do original, com restrições mais rígidas ou capacidades limitadas.

É importante destacar que o delegador original ainda mantém controle total e pode revogar a delegação inicial a qualquer momento, o que invalida automaticamente todas as delegações posteriores na cadeia, criando uma cadeia de confiança flexível e segura, ideal para configurações de permissões complexas como DAOs e carteiras compartilhadas.

O que vem a seguir?

O Delegation Toolkit oferece as ferramentas para trazer sistemas de permissões mais seguros, inteligentes e flexíveis para seus dapps. Seja para habilitar gastos delegados, patrocínio de gas, fluxos de trabalho automatizados ou onboarding simplificado, tudo isso agora é possível sem precisar reinventar a roda.

Nos próximos posts, vamos colocar a mão na massa, começando com um tutorial sobre como criar um recurso de "Convide um Amigo" — um exemplo prático de delegação em ação. Fique ligado para o restante da série, onde abordaremos mais recursos que você pode implementar hoje.

Se você está animado para explorar essas ideias mais a fundo, fique de olho no próximo Gator Hackathon de abril, onde você terá a chance de desenvolver com o Delegation Toolkit ao lado de outros desenvolvedores.