Shipping r402 Sentinel for the hackathon — a proof-bound agent firewall using MetaMask Smart Accounts, 1Shot relayer, x402, and Venice planner on Base.
Sharing integration gotchas that cost us hours, in case others hit the same walls.
Gotcha 1 — grant recipient
requestExecutionPermissions to must be 1Shot relayer targetAddress from relayer_getCapabilities.
If to is your session/orchestrator account, grant succeeds in UI but relay can’t execute.
Gotcha 2 — 1Shot bundle shape
Periodic USDC permission needs two executions in the 7710 bundle:
relayer fee transfer (~$0.01)
work transfer (~$0.01) to session account
Missing the second leg → invalid-execution-length.
User Smart Account needs ~$0.02 USDC before Execute.
Gotcha 3 — blank permission context
Plain EOA on Base returns 0x000… permission context. Smart Account upgrade on Base is required.
Gotcha 4 — server anchor key
ANCHOR_PRIVATE_KEY for ProofRegistry.consumeRequest + anchorProof must be a plain EOA.
Using a Smart Account as the anchor signer caused in-flight transaction limit errors.
Working flow
Plan → Grant (7715 → 1Shot target) → Execute (x402 → 1Shot → ProofRegistry) → Revoke
Proof manifest binds delegation hash, request digest, relay task ID, and Base tx hashes.
Questions for the community:
Best practice for session orchestrator vs direct relayer grant when using ONE_SHOT_LIVE?
Anyone doing full ERC-7710 child redelegation on top of periodic root grant in production?
Thanks — this is a great write-up and very actionable. Classified as integration guidance (not a single error), and you’ve already given the needed SDK details (MetaMask Smart Accounts on Base + 1Shot). Quick, practical recommendations and answers below.
Key gotchas (short):
Grant target: always set to = 1Shot relayer targetAddress from relayer_getCapabilities. Orchestrator as grantee will pass UI checks but fail execution.
Bundle shape: 1Shot bundles for periodic USDC require two legs — relayer fee transfer + work transfer to the session account. Ensure the Smart Account holds ~0.02 USDC pre-execute.
Permission context: EOAs return 0x00…; Smart Account upgrade on Base is required for ERC-7715 permissions to work.
Anchor signer: ANCHOR_PRIVATE_KEY must be a plain EOA. Using a Smart Account here causes in-flight/nonce/mempool limits.
Direct answers to your questions:
Orchestrator vs direct relayer grant: Prefer direct grant to the 1Shot relayer in production (less complexity, fewer failure modes). Use an orchestrator only if you need policy composition/vendor abstraction — then implement very constrained root grants + short-lived child redelegation.
Full ERC-7710 redelegation in prod: Rare. Most teams avoid multi-hop redelegation due to complexity and debugging overhead. If you must, use a hybrid: tight-scoped root → orchestrator, then per-task child grants with short TTL and exact calldata/spend limits.
Docs/next steps: see Smart Accounts / delegation toolkit docs: MetaMask Smart Accounts Kit introduction | MetaMask developer documentation . If you want, we can escalate this to a human on the team to review your repo/config (send confirmation) — otherwise this pattern (direct relayer grant + 2-leg bundles + EOA anchor) is the recommended production-friendly approach.
If you want us to escalate, say “Please review” and we’ll route it to a human support engineer.
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours