pull in latest upstream - #2
Open
TtheBC01 wants to merge 907 commits into
Open
Conversation
github-actions
Bot
added
typescript
python
go
java
sdk
legacy
examples
specs
docs
website
ci
ecosystem
labels
* fixes * chore: version typescript packages * fix format
#2366) * migrate to v2 tagged go module * changelog and use most recent version * fix changelog entry and update to use the correct version * update docs * more fixes * fix go lint and tests
* chore(go): release v2.14.0 * chore(go): release v2.14.0
…#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 #2374
* fix(python): run failure hooks after after-hook errors * chore(python): add changelog for failure hooks fix
…2045) (#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 #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>
* fix: mcp support for x402 v1 * fix: lock * fix: format
* feat: reject eoas as assets * fix: pr feedback
Generated-By: mintlify-agent Mintlify-Source: dashboard-editor Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* add spend controls * align mcp * review feedback * add test * unify money coversion * add guard * rebase
Generated-By: mintlify-agent Mintlify-Source: dashboard-editor Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* spend controls go * Address review: share EVM money conversion and document MCP spend-control options. Co-authored-by: Cursor <cursoragent@cursor.com> * Apply MCP spend-control Options in NewX402MCPClient as well as FromConfig. Co-authored-by: Cursor <cursoragent@cursor.com> * Remove unused ExactEvmScheme.ConvertToTokenAmount that collided with the package helper. Co-authored-by: Cursor <cursoragent@cursor.com> * clean up dead code * revert duplicated mcp wrapper options * unify money parser * add guard * rebase --------- Co-authored-by: Cursor <cursoragent@cursor.com>
* Update docs/sdk-features.md Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/getting-started/quickstart-for-buyers.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* Update docs/sdk-features.md Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/sdk-features.md Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* docs(svm): add `batch-settlement` SVM scheme specification SVM profile of the network-agnostic `batch-settlement` scheme: high-throughput channel payments where a client deposits once, signs cumulative Ed25519 vouchers verified off-chain, and the operator redeems the latest voucher per channel on-chain in batches. The multi-voucher generalization of `upto`. * docs(svm/batch): cascade upto role-model + cleanups to batch-settlement Mirrors the upto spec revision, adapted for batch's client-signed cumulative vouchers: - Role model: the operator is the channel `payee` (the program requires the `settle_and_finalize` merchant == `channel.payee`), as well as fee payer and `rentPayer`; `authorizedSigner` stays the payer (client signs vouchers). `payTo` is realized as the payee (self-facilitating, `operator == payTo`) or a `distributionSplits` entry (separate facilitator). Added the self-facilitating reference-status note and set `payee = operator` / `rentPayer = operator` at open. - Cleanups (match upto): dropped the `pay-kit`-controlled / `CHNLxY` program-id / "program we control" references. - Clarified that `expiresAt` is a genuine *client* commitment here (the client signs each voucher), unlike upto's operator-attested field. Deliberately NOT cascaded: `deposit == maxAmount` — batch's deposit is a multi-request escrow, so the ceiling is `cumulativeAmount ≤ deposit`, not equality. * docs(svm/batch): address review feedback (security, conformance, clarity) Resolves @notorious-d-e-v's review on PR #2698 (verified against the payment-channels program where relevant): - Voucher replay (#8): the cumulativeAmount is the per-request nonce — a new request needs a strict increment (watermark + amount); an equal voucher is only an idempotent retry that replays the response cached at that cumulative, never a fresh serve. - Async expiry (#9): expires_at is re-checked on-chain at settle (not just settleAndFinalize), so vouchers must use expiresAt == 0 or a TTL outlasting the redemption window (grace + buffer). - Fee-payer guard (#7): validate the full compiled open tx (ALT resolution, allowed-instruction-set only, fee payer never an authority/source/writable except fees), per the exact SVM scheme. - State ownership (#3): the watermark/ChannelStore is the resource server's state; a separate facilitator stays stateless. - Response shape (#6): nest chargedAmount/channelState under extra, amount optional (core SettleResponse + EVM batch companion). - asset is the concrete mint, not a symbol (#5); dropped SDK function names (#1); added a grace buffer SHOULD (#2); genericized the per-tx settle cap (#10). * docs(svm): align batch-settlement spec with channels * docs(svm): align batch settlement wire contract * docs(svm): refine batch settlement lifecycle * docs(svm): add batch refund authorization * docs(svm): define batch refund fallback Make payer-signed request_close the portable refund path, with facilitator-funded initiation and asynchronous finalization after a bounded grace period. Keep authenticated cooperative close as an optional fast path and align setup validation with the current SVM upto profile. Co-authored-by: Ludo Galabru <ludo.galabru@solana.org> Signed-off-by: Ludo Galabru <ludo.galabru@solana.org> * docs(svm): drop block height hint Co-authored-by: Ludo Galabru <ludo.galabru@solana.org> Signed-off-by: Ludo Galabru <ludo.galabru@solana.org> * docs(svm): batch-settlement review follow-ups - switch the scheme to the protocol-default authorization payment flow: read-only verify before the handler, voucher commit and deposit broadcast in the post-handler settle - clarify that the 900-2592000 withdrawDelay range is an x402 conformance bound enforced by facilitators, not a program constraint - quantify the voucher-expiry settlement buffer via an advertised extra.settlementBufferSeconds (default 60) so clients can compute a passing expiresAt from the 402 alone - require clients to verify the corrective 402 voucherState signature before adopting chargedCumulativeAmount Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(svm): add settlement-buffer error code Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(svm): make non-expiring vouchers normative Voucher expiry added a second clock the server had to beat on top of the forced-close grace period, and a nonzero expiresAt could make an accepted voucher unredeemable while the channel was still open. The client MUST now sign expiresAt = 0, the server and facilitator MUST reject nonzero values, and extra.settlementBufferSeconds is dropped along with the expiry-window bound. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Signed-off-by: Ludo Galabru <ludo.galabru@solana.org> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Generated-By: mintlify-agent Mintlify-Source: dashboard-editor Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
The chain-implementation template still asks for an `X-Payment` header payload, which is v1. A contributor following it today writes a spec against a header the v2 transport does not use; the real names are `PAYMENT-REQUIRED` and `PAYMENT-SIGNATURE` (specs/transports-v2/http.md). specs/CONTRIBUTING.md has drifted the same way: its directory diagram points at x402-specification.md and transports/, neither of which exists, and it lists `exact` as the only scheme when upto, auth-capture and batch-settlement have since merged. The extensions/ directory is missing from the diagram entirely. Docs only; no normative change.
Enable dollar-string pricing and paywall faucet support on Sei mainnet and testnet across all SDKs.
* fix(mcp-ts): handle facilitator failure before resource delivery * add changeset
* batch-settlement response validation * harden checks * add go/py patches
* feat(py): payment flow * add missing files * pr feedback
* Update docs/advanced-concepts/lifecycle-hooks.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/sdk-features.md Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* fix(go/py): align default asset declaration with ts * restore network config * fix(go/py/ts): restore ethereum/avalanche defaults and SVM network checks Put USDC back on eip155:1 and eip155:43114 in the shared default-asset tables, and reject unsupported Solana networks in EnhancePaymentRequirements when an explicit asset is set. Co-authored-by: Cursor <cursoragent@cursor.com> * test: drop tautological ethereum/avalanche default-asset lookups Table round-trips do not cover behavior; parse_price and SVM network rejection tests remain. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
Generated-By: mintlify-agent Mintlify-Source: dashboard-editor Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* feat(ts): implement settlement-pending behavior in facilitator * feat(ts): implement settlement-pending behavior in server * feat(ts): add tests * feat(go): implement settlement-pending behavior in facilitator * feat(go): implement settlement-pending behavior in server * feat(go): add tests * feat(py): implement settlement-pending behavior in facilitator * feat(py): implement settlement-pending behavior in server * feat(py): add tests * feat: pr cleanup * feat: more pr cleanup * fix: address pr review feedback * fix: py format * chore: sync e2e Python lockfiles to x402 2.20.0 Update editable x402 version metadata in e2e uv.lock files after the python package bump on this branch. Co-authored-by: Cursor <cursoragent@cursor.com> * fix: address settlement-pending PR review feedback Distinguish terminal onchain confirmation failures from confirm-timeouts (TransactionOnchainFailureError) across SVM exact/upto settle paths so only timeouts stay settlement_pending; terminal failures now clear both caches and return transaction_failed. Run verifyPostSettlement during smart-wallet pending-settlement reconciliation to keep TOCTOU coverage on retries. Key upto deposit pending-settlement entries by transaction message hash (like exact) instead of channelId alone. Fall back to an optimistic channelState snapshot in batch-settlement deposit reconciliation when the post-confirm read fails, per spec. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
Generated-By: mintlify-agent Mintlify-Source: dashboard-editor Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* update auth-capture spec * sync vs async * improve backward compat * spec review 2 * refinements * clarify facilitator captureAuthorizer
* update spec * add upfront to evm/svm * add other networks * add go * add upfront to py
* Update docs/schemes/overview.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/schemes/exact.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/schemes/exact.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
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
19 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.
Description
Tests
Checklist