Skip to main content
AI agents are transacting autonomously. The ones with guardrails get trusted with real money. The ones without don’t. Functor is the onchain infrastructure that lets developers control what their agents can do - without holding their keys.
Why agents need this
  • An agent managing a treasury needs spending limits, contract allowlists, and rate limits - enforced by the chain, not by trust
  • Session keys give basic scoping but no rolling limits, no cross-session state, no post-execution verification
  • Functor adds what’s missing: time-windowed spending, cross-session tracking, outcome verification, and a full audit trail
  • All enforcement happens onchain via ERC-7579 modules - no server, no database, no trust assumptions

The problem

Giving an AI agent access to a wallet today means one of two things: Hand over the private key. The agent has full control. A bug, a prompt injection, or a compromised dependency drains everything. Use session keys with basic policies. Better, but limited. Session keys give you static rules - call this contract, before this timestamp. They don’t track how much the agent has spent across sessions. They don’t reset daily. They can’t verify whether a swap actually returned the right tokens. Functor fills the gap between “no control” and “not enough control.”

How it works

Functor provides three onchain contracts that install on any ERC-7579 smart account:
ContractWhat it does
KeyStoreOnchain registry of public keys. The source of truth for who controls an account.
WebAuthnValidatorERC-7579 validator module. Verifies passkey signatures against the KeyStore.
FunctorPolicyHookERC-7579 hook module. Enforces policies before every transaction, verifies outcomes after, collects a flat fee, and emits an audit trail.
The developer installs these modules, configures policies via the dashboard or SDK, and their agent operates autonomously within the rules - enforced by the EVM itself.

What Functor adds beyond session keys

Session key modules like SmartSessions handle basic scoping. Functor adds what they can’t:
CapabilitySession KeysFunctor
Allowed contracts / functionsYesYes
Time-bounded sessionsYesYes
Lifetime spending capYesYes
Rolling time-windowed limits (1000 USDC/day, resets daily)NoYes
Cross-session state (total spend across all sessions)NoYes
Post-execution verification (did the swap actually work?)NoYes
Per-transaction audit trail (onchain events)PartialYes
Dashboard + SDK for managementNoYes

Architecture

How the three contracts work together.

KeyStore

Onchain key registry and identity.

Policy Hook

Onchain policy enforcement, fees, and audit.

End-to-End Flow

One transaction walked through the full stack.