Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesNewsletterUpdates by emailGlossaryDefinitionsFAQFrequently asked questions
Get Started ↗ JA
Glossary · Protocols & Agents

EIP-3009 — Transfer With Authorization

EIP-3009

An Ethereum extension that lets a signature alone authorize an ERC-20 transfer — no gas paid by the signer. Signer, recipient, amount, validity window, and nonce are signed under EIP-712 and submitted by a third party.

Definition

The signed message is a structured payload: TransferWithAuthorization(address from, address to, uint256 value, uint256 validAfter, uint256 validBefore, bytes32 nonce). EIP-712 typed-data signing blocks replay attacks and cross-network confusion.

The nonce is a user-chosen 32-byte value; the token contract tracks used nonces in a bitmap. Unlike EIP-2612's sequential nonces, parallel authorizations can be processed in any order.

validAfter / validBefore let you schedule: "sign now, valid in two weeks, expires in three." USDC and other major stablecoins implement this.

Lemma implementation

The x402 EVM scheme (scheme_exact_evm) wires EIP-3009's transferWithAuthorization directly into its settlement primitive. The client includes the EIP-3009 signature in the payment payload; the facilitator submits it on-chain.

Lemma's Trust402 requires both the EIP-3009 signature and an authorization-delegation proof, so the "mechanical validity" and the "organizational legitimacy" of a signature are verified separately.

Because the recipient is baked into the signed message, a phished signature still cannot be redirected. This is a safer-default design than EIP-2612 (permit).

Get started

Extend single-signature payments with verifiability.