Draft ERC defining a `wallet_grantPermissions` JSON-RPC method that lets dApps ask smart-account wallets for granular, time-boxed, scoped permissions (session keys, spend caps, contract allowlists) without holding the user's primary signer. Status: Draft.
- 01session keys for smart accounts
- 02delegated automated trading bots
- 03spend caps and allowance budgets
- 04gasless / sponsored UX with scoped authority
- 05background agents with bounded permissions
- pnpm add viem
- # experimental support: viem `experimental` actions, ZeroDev permissions, MetaMask Snaps
Use `wallet_grantPermissions` (ERC-7715) to request a session-key-style permission set from a 4337/7702 smart wallet. Request shape: `{ chainId, address, expiry, signer: { type, data }, permissions: [{ type, data, policies: [{ type, data }] }] }` where common permission types are `native-token-transfer`, `erc20-token-transfer`, `contract-call`, and policies include `spending-limit`, `gas-limit`, `rate-limit`, `allowed-contracts`. Wallet returns `{ grantedPermissions, expiry, accountMeta, signerMeta, permissionsContext }`. Persist `permissionsContext` and `signer` privately; on each subsequent UserOp attach the context so the wallet's permission validator (often an ERC-7579 module) authorizes the call without re-prompting. Pair with viem's experimental `grantPermissions` action and MetaMask's Smart Account Snap or ZeroDev's permission system.
- ⚑Status is Draft — RPC method name (`wallet_grantPermissions`) and request schema are still moving. Pin a wallet+SDK version pair and watch ERC repo for breaking changes.
- ⚑Permission storage lives INSIDE the smart account (typically as an ERC-7579 validator module) — revocation requires an on-chain transaction from the primary signer. A compromised dApp keeps the permission until on-chain revoke confirms.
- ⚑`expiry` is a UNIX timestamp — clock drift between dApp and chain time can cause permissions to look valid client-side but revert on-chain at the validator. Always check on-chain `block.timestamp` before submitting.
- ⚑Spending-limit policies are typically PER-PERMISSION cumulative, not per-transaction — a single high-gas tx that fits under the cap can drain near-full budget. UI must display remaining budget, not just the original cap.
- ⚑Most EOA wallets (MetaMask without smart-account mode, Rainbow, Coinbase EOA) DO NOT implement `wallet_grantPermissions` — feature-detect via `wallet_getCapabilities` (ERC-5792) and gracefully fall back to per-tx prompts.
- ⚑ERC-7715 ≠ ERC-7710 — 7710 is the contract-level on-chain delegation interface, 7715 is the wallet RPC method. They are usually used together but can be implemented independently.