New here? What this is & how to use it — 60 seconds
Think of a corporate card. Your money lives in a contract on-chain (the SessionKeyWallet) — never in the agent. The agent holds only a session key: a signing permission with a spend cap and an expiry. It can spend within those limits; it can never take the funds. One revoke() freezes it instantly — money untouched, account intact. Keys rotate; bind them to one identity and the agent's history follows the agent, not the key.
- Create (or unlock) your owner key in card 1, and claim 10 dUSD free.
- Deploy your own SessionKeyWallet in card 2, then deposit some dUSD into it.
- Your agent generates its keypair on its own machine and sends you only the address — grant it in card 3 with a small cap and a short expiry. Optionally pick (or register) an identity so its keys track together, and check intent categories to limit what it may buy.
- The agent pays per call: it signs offline with the session key, the facilitator relays on-chain, the contract enforces the gates. It never touches your money.
- Watch its spend in card 4, grouped by identity. Anything looks wrong — revoke a single key, or deactivate the whole identity in card 5. Re-grant, or rebind a key from the identity column, anytime.
Why this design? Read the field note: the agentic-payments control plane.
Every gate — granted, not revoked, not expired, within cap, correct nonce — is enforced in the authorization path of SessionKeyWallet.sol, not in an audit log. This page is a hot wallet: fine for agent operating budgets; for large balances keep the owner key on a machine you control and use the CLI. Read the field note: the agentic-payments control plane.