feat(e2e): add multi-mechanism /protected-multi endpoint to Express server#1450
Open
ryanRfox wants to merge 1 commit intocoinbase:mainfrom
Open
feat(e2e): add multi-mechanism /protected-multi endpoint to Express server#1450ryanRfox wants to merge 1 commit intocoinbase:mainfrom
ryanRfox wants to merge 1 commit intocoinbase:mainfrom
Conversation
🟡 Heimdall Review Status
|
|
@ryanRfox is attempting to deploy a commit to the Coinbase Team on Vercel. A member of the Team first needs to authorize it. |
fb18877 to
431e509
Compare
…erver Add the first reference implementation of a multi-element accepts array to the e2e test suite. The endpoint offers four payment options spanning two chains (Base Sepolia + Solana Devnet), three transfer mechanisms (EIP-3009, Permit2, SVM native), and both gas sponsoring flavors (erc20ApprovalGasSponsoring + eip2612GasSponsoring). Options: 1. USDC via EIP-3009 (Base Sepolia) — default for USDC holders 2. WETH via Permit2 (Base Sepolia) — default for WETH holders 3. USDC native transfer (Solana Devnet) — cross-chain alternative 4. USDC via Permit2 (Base Sepolia) — EIP-2612 gas sponsoring demo Includes 7 unit tests: 5 Express middleware tests (multi-element accepts creation, 402 response with length assertion, PAYMENT-REQUIRED header, gas sponsoring extension keys, settlement) and 2 core initialize tests (multi-chain + multi-mechanism validation, unsupported network rejection). Closes coinbase#1449
431e509 to
da95b5d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a
/protected-multiendpoint to the Express e2e server — the first reference implementation of a multi-elementacceptsarray. The endpoint offers four payment options spanning two chains, three transfer mechanisms, and both gas sponsoring flavors.Closes #1449
Design
The
acceptsarray has four options covering the full range of x402 payment mechanisms:erc20ApprovalGasSponsoringeip2612GasSponsoringPaymentPolicyWhy WETH for option 2? The default client selector picks the first compatible option. If options 1 and 2 both used USDC on the same network, a client with USDC would always match option 1 — making option 2 unreachable without a custom
PaymentPolicy. WETH (0x4200000000000000000000000000000000000006, OP Stack predeploy) is a distinct asset, so each option is independently exercisable based on what the client holds. WETH is a plain ERC-20 with no EIP-3009 or EIP-2612, making Permit2 the only valid transfer method.Why option 4 shares USDC with option 1? Option 4 demonstrates the atomic
settleWithPermit()flow — the facilitator callspermit()+permitWitnessTransferFrom()in a single transaction. USDC is the only widely available token on Base Sepolia with EIP-2612permit()support. Since option 1 also uses USDC (via EIP-3009), option 4 is not auto-reachable by default client behavior — it requires a customPaymentPolicyto exercise, which is expected to be covered in a follow-up PR focused on this aspect, so we consider it out of scope in this PR.Gas sponsoring: Both flavors are declared on this route:
erc20ApprovalGasSponsoring— for WETH (option 2). Facilitator broadcasts the client's signedapprove()tx, paying gas. Two on-chain transactions.eip2612GasSponsoring— for USDC-via-Permit2 (option 4). Facilitator callspermit()+ transfer atomically viasettleWithPermit(). Single transaction.Extensions are per-route (not per-option) in the current spec. The client SDK handles this correctly — options that don't need gas sponsoring (EIP-3009, SVM) simply ignore the extension data. The client also checks existing
allowance(owner, Permit2)before signing any gas sponsoring artifact, skipping it if already approved.Changes
/protected-multiendpoint configuration with four-optionacceptsarrayerc20ApprovalGasSponsoring+eip2612GasSponsoring)test.config.jsonfor e2e discoveryTest plan
GET /protected-multireturns 402 with fouracceptsentriesPAYMENT-REQUIREDresponseFuture work (separate PR)
Client-side
PaymentPolicy/registerPolicy()tests: