If you've built anything with agents, bots, or automation that touches onchain assets, you've probably run into the same wall I keep thinking about: how do you give software enough wallet access to be useful without giving it enough access to ruin your day?
With a regular EOA, there is basically no nuance. If something has the private key, it can do whatever it wants. There is no clean native way to say: "you can spend up to 100 USDC over the next 24 hours, and absolutely nothing outside of that." It is usually all or nothing.
That is exactly why I find ERC-4337 smart wallets so compelling. The rules can live in code, not just in whoever happens to control the key.
Namera, built on ZeroDev's Kernel smart account, is a TypeScript toolkit focused on issuing and managing session keys for real products, real agents, and real developer workflows.
What session keys are
A session key is a scoped credential. You generate one, attach policies (rules/permissions) to it, and hand it to whatever needs to act on your account (usually an AI agent).
The important part is that these policies are enforced onchain. If the holder of that session key tries to go beyond the permissions you gave it, the transaction simply does not pass. This is not a polite suggestion. The contract enforces it.
Policies you can attach:
- Call policy: which contracts and functions can be called, down to specific argument values (e.g., amount ≤ 100 USDC)
- Gas policy: hard cap on total gas spent
- Timestamp policy: valid-after / valid-until window
- Rate-limit policy: max transactions per interval
- Signature policy: restrict which contracts can request signature validation
- Sudo policy: full access, for when you actually trust the delegate
What matters most here is that these policies compose. You are not forced to choose one guardrail. You can stack them.
One session key can have a gas cap, a time window, and a call restriction all at once. Every condition has to pass. That is where session keys become genuinely useful for agents and automation, not just a neat idea on paper.
Two signers, two use cases
Namera supports ECDSA and passkeys. Which one you want depends entirely on what you're building.
ECDSA makes the most sense for backend automation and agent workflows. The clever bit here is that the owner signs a Merkle root once, and that single signature can cover session keys across all supported chains. Each chain then verifies using a proof derived from that root.
If you are running multi-chain pipelines, that matters. You are not sitting there collecting separate approvals chain by chain. That is a meaningful UX and architecture win.
Passkey is the better fit for consumer-facing apps. WebAuthn credentials such as Face ID, Touch ID, or hardware security keys keep signing material in the device's secure enclave instead of on your server.
Each chain still needs one user approval, but there is no private key flying around your backend, and users authenticate with biometrics instead of seed phrases. That matters a lot because seed phrases are still one of the biggest onboarding walls in crypto.
The SDK
@namera-ai/sdk is split into focused entry points:
@namera-ai/sdk/account // smart account creation and management
@namera-ai/sdk/session-key // issue, check, revoke
@namera-ai/sdk/policy // build policy rules
@namera-ai/sdk/transaction // batched, parallel, multi-chain execution
@namera-ai/sdk/passkey // WebAuthn utilities
The workflow is straightforward: create a smart account client, issue a session key with policies, create a session key client from it, and execute transactions through that client. The session key signs, the smart account validates, and the policies do the enforcement.
Transaction execution uses a lane model. Each batch maps to one UserOperation. Calls inside a batch execute atomically and in sequence, so your approve + swap either happen together or not at all.
If you give two batches different nonceKey values, they can run in parallel without blocking one another. If you give batches different chainId values, they route to the correct chain.
This detail matters because agent systems often need to do multiple things across chains at the same time. The lane model was designed to make that easier: batches can execute atomically when needed, or run in parallel when they should not block each other.
The CLI
One thing we were intentional about here was not forcing humans and agents through the same awkward interface.
For humans, there are interactive prompts. For agents, every command exposes a JSON schema you can query with namera schema session-key.create and accepts --params as a JSON payload. No prompts. Deterministic behavior. Output in plain text, JSON, or NDJSON.
namera session-key create --params '{
"alias": "my-agent-key",
"smartAccountAlias": "my-wallet",
"chains": ["eth-mainnet"],
"sessionKeyPassword": "...",
"ownerKeystorePassword": "...",
"policyParams": [
{ "type": "gas", "allowed": "100000000000000000" },
{ "type": "timestamp", "validUntil": 1750000000 }
]
}'Agents should not be forced to pretend they are humans filling out terminal forms.
The MCP server
Every time I speak with someone building an onchain agent, the same question comes up sooner or later: how do you let the agent use a wallet without effectively giving it unlimited access to funds?
Run namera mcp start and any MCP-compatible agent, whether Claude or anything else that speaks the protocol, gets access to a set of wallet tools such as get_wallet_address, get_balance, read_contract, native_transfer, and execute_transaction.
The important part is that the agent operates through the session key's scoped permissions, while the owner key never leaves the local keystore.
namera mcp start \
--smart-account my-wallet \
--session-key my-agent-key=my-password \
--transport http \
--port 8080This is where the architecture becomes especially useful.
Session key plus policy enforcement plus MCP means the agent can only do what you explicitly allowed it to do, and that boundary is enforced onchain. No custom permission middleware that you now need to maintain forever. No relying on offchain application logic alone to enforce those constraints.
A technical choice worth knowing about
Namera is built on Effect, a functional TypeScript library that treats errors, dependencies, and async as typed values. The codebase avoids throw, models failures explicitly, and wires dependencies through a layer system.
That is not the most common choice in Ethereum tooling, but it makes sense here. If you are dealing with complex async workflows, multiple chains, policy validation, and transaction orchestration, explicit typed failures are a lot better than runtime surprises and half-handled edge cases.
The SDK is tree-shakeable too, so you are not dragging the whole thing into a frontend bundle if you only need one slice of it.
Getting started
npm i @namera-ai/sdk viemCLI:
npm i -g @namera-ai/cliFull docs at namera.ai/docs. Source at thenamespace/namera (Apache 2.0).
Namera is still early, but the design direction is clear.
Session keys are one of those things that feel increasingly inevitable if we want serious onchain agents, better smart wallet UX, and safer automation. Policy enforcement at the contract level, a sensible multi-chain signing model, passkey support, and MCP support built in all push in that direction.
If you are building agents or any kind of automation that touches onchain assets, Namera is well worth a look.