> ## Documentation Index > Fetch the complete documentation index at: https://docs.monadeum.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Wallets and session keys > Why every agent has its own ERC-4337 smart account, how a scoped and revocable session key lets the agent act without a human per trade, and how deployment, activation, and revocation work. Source of truth: `ARCHITECTURE.md` sections 6, 7, and 10 (WalletsModule), and `SECURITY.md` sections 1, 2, and 11. ## Decision Social login through an embedded-wallet vendor (Privy) gives the user a root identity. Each agent gets one ERC-4337 smart account (ZeroDev Kernel v3.1), controlled by a session key the worker holds server-side. The user's embedded wallet is the account's recoverable owner. An external wallet is supported as an advanced path, with a platform-verified EIP-4361 challenge, and both paths converge on one user record with exactly one owner wallet. ## Why a smart account per agent The brief requires independent economic identity, enforceable limits, revocable permissions, and isolation of one agent's compromise from every other agent's funds. * A single shared account with internal bookkeeping fails isolation: the chain sees one account, so a compromised agent could spend another's allocation. * Separate externally owned accounts isolate funds but cannot encode a spend policy the chain enforces. The limit would live in application code, the single point of failure the design avoids. * A per-agent ERC-4337 account gives a distinct address per agent and a programmable validator that enforces caps and an allowlist at the protocol level. EIP-7702 delegation is cheaper per transaction and was deferred: Monad's implementation has a 10 MON reserve for delegated accounts and bans `CREATE` and `CREATE2` in delegated execution, and the session-key tooling around it is less mature. It is a candidate gas optimization after the ERC-4337 design is proven on testnet. ## Why session keys Agents must act without a human approving each trade. A session key, held by the worker and scoped at issuance, can call only Kuru's router, the reallocation contract, `transfer` and `approve` on the settlement asset, and `approve` on each traded asset, all within the account's own spend limits. It cannot sign messages for the account at all, because the spend policy's ERC-1271 check always fails. The owner can revoke or rotate it at any time without touching the root wallet. The owner signs every step that gives an agent power. Activation as a vertical path: sign in, create the agent, deploy the account, activate a session key, fund, then ticks. The owner signs the deployment, the activation, and the funding. Side branches show the genome commitment at deployment and the stop that revokes the key. The owner signs every step that gives an agent power. Activation as a vertical path: sign in, create the agent, deploy the account, activate a session key, fund, then ticks. The owner signs the deployment, the activation, and the funding. Side branches show the genome commitment at deployment and the stop that revokes the key. ## Deployment One owner-signed operation deploys the account and configures its spend policy: `setLimits`, one `setAllowed` per allowlist entry, `setTradedAsset` for each traded asset, and, when x402 is configured, the x402 validator install. Each agent account uses its own Kernel index under the owner. Signing in deploys nothing. ## Activation Activation issues the session key inside an owner-signed operation. The key is generated and held only in memory while the owner's wallet signs one EIP-712 approval. Kernel installs the permission with the first session-key operation, so after the signature it is not yet installed on chain. The platform instead reads the account's code and permission state and keeps the key only if the account would accept the approval now. Otherwise nothing is recorded. Activation is built but has not been run through a Privy embedded wallet on testnet. Whether Privy's `eth_signTypedData_v4` over Kernel's enable data yields a signature Kernel accepts is an assumption (verified date for this statement: 2026-10-11). ## Revocation Revocation destroys the server-held key first, then an owner-signed operation uninstalls the key's validator and invalidates the Kernel nonce so the owner's enable signature cannot reinstall it. Success is read back from the account's `validationConfig`, `currentNonce`, and `validNonceFrom`, not assumed. The x402 key is a second key per agent, kept in a separate vault and revoked in the same operation, because Kernel's ERC-1271 path ignores the nonce and only uninstalling the validator stops it. Revocation is always paymaster-sponsored outside the per-agent gas budget, so a spent budget or an empty account never blocks the emergency stop. If the paymaster is down and the account has no MON, the state is reported as `paymaster-unavailable`: the platform's copy of the key is already destroyed, but the chain still accepts a copy held elsewhere until the owner's revocation lands. ## Gas Sponsorship is capped per agent, not unlimited, so a degenerate agent in a failed-transaction retry loop cannot consume unbounded platform funds. Gas is not paid in USDC through an ERC-20 paymaster, because that needs a settlement-asset `approve` naming the paymaster, which the allowlist forbids. The ZeroDev project serving testnet currently sponsors all transactions with no limit recorded as set. That is accepted on testnet only, and the per-agent and per-user budgets are required before any mainnet sponsorship. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.