Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

How Functor is Different

There are plenty of "agentic wallet" products. Most of them solve the same surface problem (letting an AI act on a user's wallet) but they all store the authorization state in places only their own stack can read.

Functor inverts that. Permissions are first-class on-chain objects. Any app, any agent, any chain that bridges to it can verify who is authorized to act on a wallet, without integrating with a wallet vendor's proprietary API.

What "agentic wallet" usually means

Most stacks combine:

  • a smart-account contract (ERC-4337 or similar) that holds funds
  • a session-key authorization mechanism (the agent signs intents, the wallet validates)
  • a vendor-side coordinator (a backend or proprietary contract) that knows which keys are authorized

The third piece is where the silos live. Two agents on the same user's wallet can't verify each other unless they're both clients of the same vendor. A DEX can't check whether an incoming caller is authorized without integrating per-vendor.

What Functor does

Functor replaces the vendor-side coordinator with Keystore: a public on-chain registry.

Most agentic walletsFunctor
Who knows which keys are authorizedThe vendor's backend or proprietary contractAnyone reading the on-chain registry
Cross-agent verificationRequires both agents on the same platformOne eth_call from any client
Cross-app integrationPer-vendor SDKRead the registry
RevocationA vendor API callOne on-chain transaction, global effect
CustodyOften vendor-side or platform-specificLocal. The integrator's signer.

Cost model

Keystore splits writes and reads.

  • Writes register or revoke a key. Done by the wallet itself, batched into the userOp the user was already submitting.
  • Reads are free and unlimited. Verifying whether a key is authorized is an eth_call against any RPC. An agent can check a million times per second at zero cost.

This is what makes cross-agent and cross-app verification practical at scale. The party doing the verification never pays.

Concretely, this enables

  • Agent-to-agent verification. Two AIs acting on the same wallet can verify each other's authority on-chain. No platform in between.
  • Cross-app authorization. A DEX, lending protocol, or orderbook can check whether a key is allowed to act on a wallet, without integrating with any wallet vendor.
  • One-tx revocation. Pulling a key from the registry is a single transaction. The effect is global and immediate; no off-chain coordination required.
  • A new class of agent services. Users hire AI agents through on-chain employment contracts. Anyone can verify what an agent is allowed to do, and revoke takes one tx.

What stays the same

  • You still get a smart-account wallet with the standard session-key features (scoped permissions, time-bounded expiry, on-chain validation).
  • You still use grantSession, execute, revokeSession. Same shape as any other session-key SDK.
  • Funds still live in the wallet's smart account. Functor never touches them.

The difference is what surface knows about the authorizations, and that difference is what unlocks the cross-app, cross-agent properties.

Read more

  • Keystore. The public registry, with code for verifying authorizations.
  • Sessions. Scoped delegations enforced on-chain.