Chore/merge upstream main - #11
Merged
Merged
Conversation
…x402-foundation#2375) executeSettle submits the settle(receiver, token) transaction via writeContract with no explicit gas, so viem auto-estimates immediately before broadcasting. The on-chain settle is bimodal: it early-returns (~25.5k gas) when totalClaimed == totalSettled, and performs an SSTORE plus an ERC-20 transfer (~57k gas) otherwise. The eth_estimateGas viem runs is an independent RPC call that can resolve against a node whose state has not yet caught up to the just-mined claim; it then estimates the early-return path, the transaction is broadcast under-gassed, and it reverts out of gas once the claim is visible. Observed intermittently on Base mainnet (settle gasLimit == gasUsed, reverted). settle's cost is bounded -- one SSTORE plus one transfer, no loop, so it does not scale with voucher or channel count -- so a fixed limit is correct. SETTLE_GAS_LIMIT (120_000n) leaves ~2x margin over the transfer-path cost. deposit-permit2.ts already uses this explicit-gas pattern. Adds a unit test asserting executeSettle passes an explicit gas to writeContract. Refs x402-foundation#2374
…on#2540) * fix(python): run failure hooks after after-hook errors * chore(python): add changelog for failure hooks fix
…402-foundation#2045) (x402-foundation#2078) Contributors currently have to read test source code to discover which env vars the integration suites need. This PR closes that gap across the three SDK CONTRIBUTING.md files and adds the missing .env.example referenced by the Go guide. - go/.env.example: new template covering EVM_*/SVM_* vars, mirrored from the env names read in go/test/integration/evm_test.go and svm_test.go. The Go CONTRIBUTING.md already walks through `cp .env.example .env` at line 217, but the template file didn't exist on disk -- this wires up the walkthrough. - python/CONTRIBUTING.md: new "Integration Tests" subsection under Testing, pointing to the existing autoloader in tests/conftest.py and listing the EVM_*/SVM_* vars read by tests/integrations/test_evm.py, test_mcp_evm.py, and test_svm.py. - typescript/CONTRIBUTING.md: Integration Tests section now enumerates the env vars consumed by @x402/evm, @x402/svm, Stellar, and Aptos suites, with a note pointing at each package's test/integrations/*.ts file as the authoritative list. All three additive documentation changes are scoped per-SDK; no code or test behavior changes. Closes x402-foundation#2045. Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
* add svm smart wallet e2e test * add to testnet facilitator
Generated-By: mintlify-agent Mintlify-Source: dashboard-editor Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* feat: add builder-code extension for ERC-8021 attribution in x402 payments Adds a new builder-code extension that enables ERC-8021 Schema 2 attribution tracking for x402 payments. Three parties can attach their builder code to settlement transactions: - Agent (client): sets the "a" field via BuilderCodeClientExtension - Service (server): declares in 402 response via declareBuilderCodeExtension() - Facilitator: adds to "s" array at settlement via BuilderCodeFacilitatorExtension At settlement, the facilitator encodes all builder codes as a Schema 2 CBOR suffix and appends it to the transferWithAuthorization calldata. The EVM ignores trailing calldata bytes, so the transfer executes normally while indexers (Coindexer, Beacon, Dune) can parse the suffix. Changes: - New extension package: @x402/extensions/builder-code - EVM mechanism: executeTransferWithAuthorization accepts optional calldataSuffix - settleEIP3009 reads builder code extension from FacilitatorContext - scheme.ts passes context through to EIP-3009 settlement * refactor: service as app (a), facilitator as wallet (w), remove client extension - Service declares its builder code as "a" (app) — it's the application exposing the x402 endpoint - Facilitator adds its code as "w" (wallet) — it's the entity that signs and broadcasts the settlement transaction - Service can optionally include related on-chain services in "s" array (e.g., Morpho, Aerodrome) - Remove BuilderCodeClientExtension — agent doesn't attach builder codes, the service's extension data passes through untouched - CBOR encoder now handles "a", "w", and "s" fields * feat: EIP-3009 builder-code support in facilitator + examples * refactor * add facilitator validation * add ts examples * add client extension * cleanup refactor * fix format * add builder codes to permit2, upto, batch-settlement * add unit tests * remove paymentRequiredExtensions * validate extension echo --------- Co-authored-by: Peter Kim <peter.kim@coinbase.com> Co-authored-by: Philippe d'Argent <p.dargent@cern.ch>
Co-authored-by: samsamtrum <samsamtrum@users.noreply.github.com>
Kammerlo
added a commit
to Kammerlo/x402
that referenced
this pull request
Jun 9, 2026
…e/merge-upstream-main Chore/merge upstream main
Kammerlo
pushed a commit
that referenced
this pull request
Jul 8, 2026
…foundation#2390) * feat(concordium): exact mechanism implementation * feat(concordium): align exact impl with spec + examples * fix(concordium): address exact mechanism review * style(concordium): format advanced example readmes * feat(concordium): add shared e2e testnet coverage * test(concordium): fix offline facilitator signer mock * build(typescript): fix x402 CI validation * fix(concordium): address all PR x402-foundation#2390 review comments - Build fix: cast ccdNetwork as Network in all_networks.ts (x402-foundation#29) - v2-only: getRequiredAmount() returns requirements.amount directly (#22) - Remove offline e2e test (#4) - Add defaultMoneyConversion() for Concordium native CCD (#8/x402-foundation#35) - Private key support: new overload accepting hex-encoded Ed25519 key (#11/#19) - Client runtime: traced createPaymentPayload path, all guards correct (x402-foundation#30) - Tx simulation: addressed as chain limitation, preflightLikelyToSucceed correct (#3) - Fix lint: JSDoc completeness for signer overloads, unused param naming * fix(concordium): update e2e facilitator and integration tests for private key support - e2e facilitator: support CCD_FACILITATOR_PRIVATE_KEY + CCD_FACILITATOR_ADDRESS env vars as preferred path, with wallet export as fallback - e2e test.config.json: add new CCD env vars to optional list - Integration tests: support CONCORDIUM_CLIENT_PRIVATE_KEY + CONCORDIUM_CLIENT_ADDRESS and CONCORDIUM_FACILITATOR_PRIVATE_KEY + CONCORDIUM_FACILITATOR_ADDRESS as alternatives to wallet export files - Fix integration test expectations: asset field is 'CCD' for native CCD (matches actual parseAssetAmount/defaultMoneyConversion behavior) - Fix AssetAmount pass-through test: amount is converted to atomic units * fix(concordium): remove sponsor_as_recipient safety check The check blocked the standard x402 deployment model where the service provider runs both the facilitator (sponsoring gas) and the server (receiving payment). No other mechanism (EVM, SVM, Aptos, Hedera, Stellar, TVM) has this restriction. Verified with on-chain integration tests: - wallet 1 → wallet 2 (client pays service provider) - wallet 2 sponsors the transaction - Both CCD payment flows confirmed on Concordium testnet * fix(concordium): pass token decimals from server to client for PLT transfers Server parseAssetAmount now includes decimals in extra, which flows through PaymentRequirements.extra to the client. Client buildPltTransfer reads decimals from requirements.extra and uses it in TokenAmount.create instead of hardcoding 0. This fixes the invalid_token_amount_decimals error during facilitator verification of PLT token payments (e.g. EURR with 6 decimals). Integration tests: 10/10 pass including on-chain EURR transfer. * fix(e2e): support CCD private key env vars in e2e test runner Adds CCD_PRIVATE_KEY + CCD_ADDRESS as an alternative to CCD_WALLET_PATH across the entire e2e stack: - ClientConfig + FacilitatorConfig types: new optional fields - GenericClientProxy + GenericFacilitatorProxy: map to env vars - FacilitatorManager: pass through from process.env - fetch + axios clients: prefer private key, fall back to wallet - e2e/test.ts: read new env vars, OR-logic validation for CCD Backward compatible: wallet export path still works when private key vars are not set. * style(concordium): fix lint and format issues - Fix corrupted JSDoc in _get_tokens.ts - Add missing @PARAM decimals description in client scheme - Fix unused decodedPayload param in checkPayloadSafety (rename to _) - Fix _decodedPayload → decodedPayload in verify() local variable - Apply prettier formatting to integration test and server scheme * test(concordium): add USDR PLT token integration test case * fix: minimize e2e diff — revert refactoring, keep only Concordium additions Reverted 7 e2e runtime files to upstream2/main baseline and re-applied only Concordium-specific additions as localized inserts. Zero existing code touched — EVM, SVM, and all other chains completely unchanged. Also: - Restore EVM/SVM to required in all test.config.json files - Fix missing/extra braces in fastify Keeta/CCD route blocks - Fix duplicate ProtocolFamily type in networks.ts + types.ts - Remove trailing newline in DEFAULT_ASSETS.md - Revert EVM/SVM ! -> || '' in e2e/test.ts - Hardcode CCD testnet in facilitator example E2e runtime diff: 305 lines added (was 2,839 — 89% reduction) Zero Concordium-related tsc errors. All tests passing. * test(concordium): expand unit + integration coverage — large amounts, unknown token, asset deduplication - Unit: 106 tests covering buildCcdTransfer, buildPltTransfer, validation, edge cases - Integration: 32 tests covering happy path, large amounts, non-existent token, asset dedup - Total: 138 Concordium tests, all green * fix(concordium): simplify server scheme and fetch token decimals from RPC - Server scheme: remove registerAsset, getAsset, getSupportedAssets, getSupportedSymbols, parseAssetAmount, assetKey, toWholeUnits, isAssetAmount, defaultMoneyConversion, CCD_NATIVE, ConcordiumAssetInfo, AssetType (291→140 lines) - AssetAmount pass-through in atomic units, asset field required (throws if missing) - Money (string/number) throws unless money parser registered — no silent CCD fallback - Client: fetch PLT token decimals from gRPC getTokenInfo instead of trusting server-provided metadata - Update unit + integration tests for new scheme behavior * fix(concordium): replace CCD_WALLET_PATH with private key + address - e2e: replace CLIENT_CCD_WALLET_PATH/FACILITATOR_CCD_WALLET_PATH with CCD_PRIVATE_KEY + CCD_ADDRESS throughout test runner, clients, facilitators, and README - e2e/README.md: remove Concordium offline e2e section - examples/clients/advanced: CCD_WALLET_PATH → CCD_PRIVATE_KEY + CCD_ADDRESS, parseWallet → buildBasicAccountSigner - examples/servers/advanced/README.md: simplify Concordium testnet funding instructions * docs(concordium): update README and package metadata for new scheme - README: remove registerAsset() examples, add AssetAmount + registerMoneyParser() patterns, update Amount Format section - README: fix Supported Assets table (PLT decimals token-dependent), wildcard description - typescript/package.json: reorder devDependencies - e2e/package.json: minor dependency update * test(concordium): add unit and integration tests for review round 5 gaps - Server (7 tests): no-decimals leak, money parser chain, asset required, extra preservation - Facilitator (6 tests): preflight nonce/balance checks, PLT token balance preflight - Client (3 tests): decimal edge cases (0, 18, large+6) - Integration (7 tests): null/undefined/empty asset, no-decimals leak, preflight CCD+PLT, large-amount preflight Addresses D1-D3, E1, O2 from PR x402-foundation#2390 review round 5 * chore: resolve e2e/pnpm-lock.yaml conflict with upstream/main
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
8 participants
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.
No description provided.