The exact permission.
Nothing more.
Scope is a permission layer for AI agents acting on-chain. You set the agent's spending cap, the actions it can call, and when the grant expires. The chain enforces the boundary, not an app.
Why
You want agents.
You don't want to
hand them the keys.
LLMs can already do the work. Swap, rebalance, claim rewards, place bids. Authorization is the hard part. Handing over an EOA gives the agent way too much. Pre-approving infinite USDC has the same problem. An off-chain rate-limiter only works until your backend gets owned.
Scope is the third option: an on-chain envelope. Inside, the agent acts freely. Outside, the chain refuses.
- Max spend
- 500 USDC
- Allowed
- rebalance, swap
- ✓Denied
- withdraw
- Expires
- 30D
How it works
A four-line spec.
Four steps. One contract enforces all of them.
- 01DEFINE THE SCOPE
- 02COMPILE TO PERMISSIONS
- 03AGENT ACTS INSIDE
- 04CHAIN REFUSES THE REST
Pick an agent address, a token, a spending cap, the actions you allow, and an expiry.
The spec is written to a permission contract. Bitmap of actions, remaining cap, expiry.
The agent calls the contract for every action. The contract checks the scope, decrements the cap.
Anything outside the scope reverts on-chain. No off-chain rate limiter, no app guardrail.
Standard
Built ahead of
EIP-8141.
EIP-8141 introduces an APPROVE opcode that separates execution rights from payment rights. An account can grant another address a permission with a spending cap, an action allowlist, and an expiry, without handing over signing power.
The standard is still a draft, targeting Ethereum's Hegota fork. Scope ships now on Base with a conventional permission contract that mirrors the same model. When Hegota lands, the UX migrates to the native opcode.
Disclaimer
Scope is not live on Ethereum mainnet. The EIP-8141 framing is forward-looking. The Base build enforces the same boundary through a conventional permission contract. The UX matches what the native opcode will look like once Hegota ships.