Summary
We’re proposing a standard interface for session keys on Starknet smart accounts. Time limits, call limits, selector restrictions, paymaster compatibility.
Session keys let users delegate limited authority to a secondary key so they can interact with dApps without paying gas or signing every transaction. Think gaming, DeFi automation, payments, AI agents. Multiple teams have already built session key implementations (Argent, Braavos, Cartridge, Bibliotheca DAO, Chipi Pay), each optimized for different use cases, but they’re all mutually incompatible. A dApp built for one wallet’s sessions won’t work with another. A paymaster built for one format can’t validate another.
This SNIP proposes a shared interface layer. Not a replacement for any existing approach.
What the SNIP defines
- An
ISessionKeyManagertrait andSessionDatastruct - A 4 element session signature format:
[session_pubkey, r, s, valid_until] - An 8 step validation algorithm
- An admin selector blocklist (9 selectors that session keys MUST NOT bypass)
- A paymaster/account interaction protocol (discovery,
OutsideExecutionconstruction, signature passthrough) - A canonical SNIP-12 typed data format for session aware hashing
Why now
Two things are converging.
Starknet’s account ecosystem is moving toward native passkeys for owner authentication. Braavos’ Hardware Signer, Cartridge’s Controller, and the SNIP-6 discussion (where Xiang confirmed a native passkey implementation in April 2024) all point in this direction. Passkeys solve authentication: prove who you are via biometrics, no seed phrase. Session keys solve authorization: define what a delegate can do. As passkey wallets become the default onboarding path, every new user will need scoped, revocable delegation for dApps, agents, and automated workflows. These are complementary layers of the same UX stack.
Then there’s AI agents. A trading bot, yield optimizer, or gaming agent needs exactly the primitives session keys provide: time bounded access, function scoped permissions, call limits, and an emergency kill switch. A standard interface lets any agent framework work with any wallet without custom integration per vendor.
Current state of implementations
| Team | Approach | Signature Format | Paymaster Compatible |
|---|---|---|---|
| Argent | Backend guardian | 3+ elements | Native |
| Braavos | External library | Proof based | Partial |
| Cartridge | Controller + passkeys | WebAuthn | Custom |
| Bibliotheca DAO | Arcade Accounts | Custom | No |
| Chipi Pay | On chain validation | 4 elements | Via AVNU |
| starknet-agentic | Agent account + spending policies | 3 elements | No |
Each approach serves real use cases well. Argent’s guardian model is battle tested at consumer scale. Braavos’ library keeps wallet contracts simple. Cartridge’s passkey integration serves gaming. Bibliotheca DAO pioneered the concept with Arcade Accounts. This SNIP provides a coordination layer that enables interoperability across all of them.
What we learned building this
We built a session account contract on top of OpenZeppelin’s AccountComponent and integrated it with AVNU’s paymaster. The process taught us that small implementation mismatches cause cascading failures. We had incorrect SNIP-12 timestamp types (Felt instead of U128), missing SRC-5 interface registration, and a misconfigured caller field. All the issues were on our side. AVNU’s paymaster works correctly with properly configured accounts.
That experience is exactly why a shared specification matters. Clear rules about hash formats, interface registration, and signature conventions would have prevented every one of those integration issues.
Reference implementation
The reference implementation is live on Starknet mainnet at class hash 0x0484bbd2404b3c7264bea271f7267d6d4004821ac7787a9eed7f472e79ef40d1 (v33). We ran it through Nethermind’s AuditAgent (AI powered auditing tool) four times between January and February 2026. The findings trajectory was 10 then 3 then 5 then 0, with the final scan coming back clean. Each round caught real vulnerabilities: nested __execute__ privilege escalation, set_public_key account takeover, missing SRC-5 registration. Those findings directly shaped the admin blocklist (now 9 selectors), self call block, and validation ordering in the spec. There are 65 passing Cairo tests plus 28/28 mainnet integration tests covering session validation, audit regressions, SNIP-9 compatibility, and spending policy.
The session key logic is extracted into a reusable SessionKeyComponent that any wallet can embed, not just OZ accounts. The component requires only a single function HasAccountOwner trait (assert_only_self()) with zero OpenZeppelin dependencies. Any wallet framework (Argent, Braavos, Cartridge, custom) can integrate in 5 steps:
- Add
component!()declaration - Implement
HasAccountOwner - Call
is_session_allowed_for_calls()in__validate__ - Call
consume_session_call()after signature verification - Optionally call
check_and_update_spending()in__execute__
Session keys as a reusable building block, not a monolithic contract to fork.
There’s also an optional SpendingPolicyComponent for per token spending limits, proposed by @OmarEspejel / keep-starknet-strange in Issue #5 and informed by starknet-agentic’s implementation. Fully independent with its own storage. Built on OpenZeppelin Cairo Contracts v3.0.0 and Starknet 2.14.0.
A security audit is the next step before we formally submit the SNIP.
Full draft and research
The complete SNIP specification: SNIP_DRAFT.md
An ecosystem research document covering all existing approaches, standards dependencies, security considerations, and the full journey from first line of code through four audit rounds: SNIP_RESEARCH.md
Related work
EthSign proposed Access Control for Function Call Delegation in October 2024 using off chain signed permits. Complementary approach: their permits are lighter but can’t be revoked once signed. Our SNIP uses on chain state for revocability and composability. The ecosystem benefits from both patterns.
The SNIP-6 Standard Account discussion is evolving toward Array<felt252> signatures to support passkeys. Our session key interface builds on SNIP-6 and the 4 element session signature is already compatible with that direction.
SNIP-9 (Outside Execution) is the foundation that makes paymaster sponsored sessions possible. This SNIP defines the missing layer on top: how session keys and paymasters interact.
Acknowledgments
This proposal builds on work by the entire Starknet ecosystem. Bibliotheca DAO built the first session key implementation. Argent/Ready, Braavos, and Cartridge each brought battle tested approaches. AVNU built the paymaster infrastructure. OpenZeppelin provides the component architecture. Nethermind’s AuditAgent caught real vulnerabilities across four scans. Medialane tested every class hash on mainnet and gave us consistent feedback. The Starknet Foundation funded this work through a seed grant and guided us throughout the process. EthSign explored similar territory with their delegation proposal. And @OmarEspejel / keep-starknet-strange proposed the spending policy extension that became Part H of the spec.
The fragmentation that motivates this standard is not a failure. It’s the natural result of teams independently solving the same problem well.
Feedback welcome
We’d especially like input from wallet teams (Argent, Braavos, Cartridge, Cavos) on whether this interface accommodates their session models. From paymaster operators (AVNU) on whether the discovery and interaction protocol matches their needs. From dApp developers on whether a unified session SDK would help. From AI agent builders (KasarLabs) on whether the session primitives cover their authorization needs. And from OpenZeppelin on whether a SessionKeyComponent based on this interface fits the Cairo Contracts architecture.
We know SRC standards take time. SNIP-6, SNIP-9, and SNIP-12 have been in Review for 2+ years. We’re here for the process.