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.
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.
Deployment and activation: the owner signs the account deployment, then the session key activation, then the funding authorization. The genome commitment step is written but AgentCommitments is not deployed. Session key issuance through an embedded wallet and the relayed funding transfer have not been run on testnet. Source: ARCHITECTURE.md sections 6 and 10.
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’svalidationConfig, 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-assetapprove 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.