---
title: "Carteira com chave de sessão"
description: "Entenda como chaves de sessão de contas inteligentes delegam autoridade limitada, quais restrições devem ser aplicadas e como verificar, revogar e reagir ao vazamento de uma chave."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Carteira com chave de sessão

> Conteúdo apenas educacional; não constitui aconselhamento de investimento. Uma chave de sessão vazada ou com privilégios excessivos pode causar perda irreversível de ativos digitais.

<a id="answer"></a>

## Resposta direta

Uma chave de sessão de carteira costuma ser uma chave de assinatura secundária, ou uma credencial delegada vinculada a ela, aceita por uma conta inteligente somente dentro de regras definidas. Essas regras podem limitar tempo, contratos de destino, seletores de função, quantias de tokens, número de transações ou outras condições. O objetivo é permitir que um aplicativo realize ações repetidas sem pedir ao titular que aprove cada operação com o signatário principal.

“Chave de sessão” é um padrão de projeto, não um padrão universal do Ethereum. O ERC-4337 oferece validação programável de contas e validação temporal de `UserOperation`, enquanto sistemas modulares como o ERC-7579 podem hospedar validadores, executores e hooks. O código implantado da conta e dos módulos determina, em última instância, o que a chave pode fazer. A expiração por si só não torna a sessão segura, e apagar uma cópia do navegador não revoga necessariamente a autoridade registrada on-chain ou contida em uma delegação ainda válida.

<a id="mechanism"></a>

## Como funciona

Um fluxo típico tem 5 etapas:

1. O titular cria um novo par de chaves em um dispositivo ou autoriza uma credencial que identifica o signatário da sessão. A chave privada de sessão nunca deve ser enviada ao servidor do aplicativo, a menos que o projeto torne esse servidor explicitamente um custodiante confiável.
2. O titular autoriza uma política com a carteira principal. Alguns sistemas instalam a chave e a política on-chain; outros usam uma delegação assinada que a conta valida quando uma operação chega.
3. O aplicativo monta uma operação e a assina com a chave de sessão. Em um fluxo ERC-4337, a lógica `validateUserOp` da conta verifica assinatura e política; a simulação de um bundler é um teste de admissão, não prova de execução ou segurança.
4. A conta deve aplicar todas as restrições antes da execução. A autoridade efetiva pode ser resumida como `A_effective = K ∩ P ∩ S`: a posse da chave (`K`), a política configurada (`P`) e o estado atual da conta ou da rede (`S`) devem permitir a ação.
5. A sessão termina por expiração, esgotamento do nonce ou da cota, revogação explícita, remoção do módulo ou outra via de invalidação específica da implementação. Confirme o estado resultante da conta na rede correta.

Antes de autorizar uma sessão, verifique:

- o ID da rede, o endereço da conta inteligente, a implementação da conta e o endereço do validador ou módulo;
- a chave pública de sessão ou o identificador da credencial e onde o material privado será armazenado;
- cada destino, seletor de função, token e regra de destinatário permitidos, além do limite de valor nativo e do teto por chamada ou acumulado;
- `validAfter`, `validUntil`, regras de nonce, contagem de usos e se o tempo é medido pelo timestamp do bloco ou por outra fonte;
- se lotes, chamadas aninhadas, `delegatecall`, aprovações de tokens, instalação de módulos, upgrades de conta e assinaturas de mensagem ERC-1271 ficam bloqueados salvo necessidade explícita;
- quem pode revogar a sessão, se o titular mantém uma rota independente de recuperação e se a revogação exige Gas ou um bundler ou paymaster em funcionamento.

A política precisa inspecionar a ação que será realmente executada. Verificar apenas o destino externo de um lote pode deixar chamadas internas sem restrição; verificar apenas o destinatário e ignorar função e valor causa o mesmo problema. Um limite só é efetivo quando o código que o aplica cobre todos os caminhos de execução.

<a id="example"></a>

## Exemplo

Uma carteira de jogo cria uma sessão com duração de 24 horas. Ela permite chamadas apenas a um contrato de jogo verificado, bloqueia `delegatecall` e aprovações de tokens, limita o valor nativo a `0.02 ETH` por chamada e o gasto total a `20 USDC`. O jogo pode enviar movimentos permitidos sem confirmações repetidas, mas um pedido para transferir um NFT não relacionado deve falhar na validação.

Antes do uso, o titular registra conta, rede, módulo, chave pública da sessão, expiração, limites e método de revogação. Ele testa uma ação de baixo valor, confere a chamada decodificada e o evento da conta e depois testa a revogação separadamente. Isso confirma o caminho configurado; não prova que o módulo não tenha vulnerabilidades nem que um dispositivo comprometido não possa gastar até os limites restantes.

<a id="risks"></a>

## Riscos e controles

- **Política ampla demais:** destinos curinga, seletores irrestritos, aprovações ilimitadas, lotes ou `delegatecall` podem transformar uma chave “limitada” em autoridade próxima à do titular. Use listas explícitas de permissão e bloqueie ações administrativas.
- **Roubo da chave:** armazenamento do navegador, logs, backups, extensões, malware e dispositivos compartilhados podem expor a chave. Prefira armazenamento isolado ou protegido por hardware quando houver suporte, prazos curtos e tetos acumulados baixos.
- **Aplicação defeituosa:** conta, validador, executor ou hook pode decodificar chamadas incorretamente ou deixar de cobrir uma rota alternativa. Use implantações verificadas, código revisado, auditorias e testes de desvio.
- **Replay e confusão de contexto:** nonce fraco ou falta de vínculo com rede, conta, módulo ou política pretendidos pode permitir reutilização. Verifique o domínio exato assinado e a proteção on-chain contra replay.
- **Suposições sobre expiração:** `validUntil` pode limitar uma operação ERC-4337 sem remover automaticamente chave registrada, allowance de token ou outra delegação. Confira o estado real de cada permissão após a expiração.
- **Falha na revogação:** apagar dados locais remove apenas uma cópia do segredo. Revogue pelo caminho documentado e confira o resultado on-chain; mantenha Gas suficiente e uma rota alternativa controlada pelo titular.
- **Módulos atualizáveis ou maliciosos:** podem ter grande poder de execução, e upgrades podem alterar a política. Verifique titulares, atraso de upgrade, poderes de pausa, endereço de implementação e procedimento de remoção.
- **Abuso de Gas e patrocínio:** a sessão pode consumir fundos da conta em Gas ou ficar inutilizável se um paymaster a rejeitar. Limite as taxas quando possível e mantenha uma rota independente de envio.

Se houver suspeita de exposição, pare de usar o aplicativo afetado, preserve o identificador da sessão e os hashes relevantes e revogue ou desative a chave em um dispositivo limpo controlado pelo titular. Depois examine operações pendentes e recentes, aprovações de tokens, módulos instalados, upgrades de conta e saldos em todas as redes compatíveis. Transfira os ativos restantes apenas se o projeto da conta ou módulo tornar a revogação pouco confiável; correr para um site de “recuperação” não verificado pode ampliar a perda.

<a id="misconceptions"></a>

## Equívocos comuns

- **“Uma chave de sessão não pode mover ativos.”** Ela pode executar tudo o que a política aplicada permitir, inclusive transferências, swaps, aprovações ou assinaturas.
- **“O ERC-4337 define permissões de chave de sessão.”** O ERC-4337 fornece uma estrutura de validação e execução; a política continua específica da carteira ou módulo.
- **“Expiração curta limita a perda máxima.”** A perda também depende de limites por chamada e acumulados, frequência, Gas, aprovações, preços e todos os caminhos alcançáveis.
- **“Sair da sessão revoga a chave.”** Isso pode apagar uma cópia local, mas não prova que o registro on-chain ou uma delegação assinada sejam inválidos.
- **“Simulação bem-sucedida significa operação segura.”** Ela pode mostrar que a validação atual aceita a operação; não prova intenção, inclusão futura, execução, finalidade nem ausência de vulnerabilidades.

<a id="related"></a>

## Tópicos relacionados

- [Abstração de conta](/pt-br/crypto/account-abstraction/)
- [Risco de Paymaster no ERC-4337](/pt-br/crypto/erc4337-paymaster-risk/)
- [Gestão de chaves privadas](/pt-br/crypto/private-key-management/)
- [Simulação de transações](/pt-br/crypto/transaction-simulation/)
- [Assinatura de carteira](/pt-br/crypto/wallet-signature/)

<a id="sources"></a>

## Fontes

- [Session Keys & Delegation](https://docs.erc4337.io/smart-accounts/session-keys-and-delegation.html) - ERC-4337 Documentation (acesso: 2026-08-21)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (acesso: 2026-08-21)
- [ERC-7579: Minimal Modular Smart Accounts](https://eips.ethereum.org/EIPS/eip-7579) - Ethereum Improvement Proposals (acesso: 2026-08-21)
- [Safe Modules](https://docs.safe.global/advanced/smart-account-modules) - Safe Docs (acesso: 2026-08-21)

Source: https://wiki.fcontext.com/pt-br/crypto/session-key-wallet/index.mdx