pull in latest upstream#2
Open
TtheBC01 wants to merge 794 commits into
Open
Conversation
github-actions
Bot
added
typescript
python
go
java
sdk
legacy
examples
specs
docs
website
ci
ecosystem
labels
…2152) The isitagentready.com scanner cannot detect x402 support through the existing /protected page (tried sitemap inclusion, Link headers, X-X402-Supported header). Add a dedicated API endpoint at /api/x402/demo that returns a clean HTTP 402 with PAYMENT-REQUIRED header using the same payment config as /protected.
* Add codeowners per-network * Update CODEOWNERS
…h, and Python alignment (#2094) * update withBazaar * Fix bazaar MCP discovery parity across TS/Python/Go; tighten e2e validation; update docs/examples. * python format * remove formatting-only changes * remove formatting-only changes * reinstate old comments * clean up response shape * revert pagination to object instead of top level fields * address review comments
* specs(exact): propose TON exact scheme for x402 v2 (spec-only) Adds scheme_exact_ton.md defining the exact payment scheme for TON blockchain. Uses W5 wallet internal_signed messages for gasless Jetton (TEP-74) transfers. Updates scheme_exact.md with TON-specific validation rules. * specs(exact/ton): address review feedback — exact amounts, commission bounds, stateInit verification - Change amount verification from >= to == (exact match), aligning with all other chain specs (SVM, Stellar, EVM). The relay commission is a separate jetton_transfer in the W5 batch, not bundled into the payment. - Add extra.maxRelayCommission field to PaymentRequirements, allowing resource servers to cap the relay commission amount. - Add stateInit verification rule: when seqno == 0, facilitator must verify contract code against a known W5 wallet code hash allowlist. - Tighten action count: W5 message must contain exactly the payment transfer and optionally a relay commission transfer, nothing else. * specs(exact/ton): rewrite to self-relay architecture — address all review comments * chore(spec): simplify TON spec — remove external_signed, condense references - Remove external_signed (0x7369676e) mode — all x402 payments use gasless internal_signed. External mode deferred to future extension. - Remove on-chain proof table (7 tx links) — promotional, not normative. Proofs already linked in PR comments. - Condense Reference Implementations to 3 lines (was 20+). - Settlement Logic now single-path (no dual-mode branching). - 349 → 320 lines. Closer to SVM/Stellar spec size. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(spec): remove 50% gas buffer — emulation is already worst-case * specs(exact/ton): address all review comments — remove /prepare, add RPC Changes: - Remove /prepare endpoint: client resolves seqno + jetton wallet via TON RPC directly (same pattern as SVM/Stellar/Aptos) - Remove nonce field: dedup uses BoC hash, not nonce - Transfer amount: strict equality (== not >=) - Add jetton wallet verification: recipient MUST match get_wallet_address(payTo) on the asset master - Seqno check: MUST NOT be less than on-chain seqno (was SHOULD) - Add client balance check requirement - Move simulation to /verify (was optional pre-settlement) - Remove HTTP header references (transport-agnostic) - Replace hardcoded 600s with maxTimeoutSeconds - Add Client RPC Requirements appendix section * specs(exact/ton): add facilitator safety, explicit jetton wallet check - Add section 3 (Facilitator Safety): facilitator address MUST NOT appear as sender or Jetton transfer source. Matches SVM/Stellar. - Make get_wallet_address check explicit per @skywardboundd: the destination in the deserialized BoC must match the resolved wallet. - Align verification intro phrasing with SVM/Stellar style. * specs(exact/ton): add areFeesSponsored flag per Stellar pattern Follows Stellar's approach: extra.areFeesSponsored boolean, currently always true. Non-sponsored flow (client pays gas) to be added later. * specs(exact/ton): fix validUntil duplication, add stateInit code hash check - Remove duplicate validUntil check from section 2 (already in section 5) - Add stateInit code hash verification for seqno==0 deployments (per arjun215-eng's earlier feedback) * specs(exact/ton): add payload.to and source Jetton wallet checks Per @skywardboundd review: 1. payload.to MUST equal requirements.payTo (explicit metadata check) 2. Source Jetton wallet (W5 internal msg destination) MUST match get_wallet_address(from) — prevents substitute source contract 3. jetton_transfer body destination MUST equal requirements.payTo Tested against deployed facilitator with real on-chain data. Facilitator commit: ohld/x402-ton-facilitator@6f92320 * specs(exact/ton): remove facilitatorUrl, fix dedup TTL, add canonical W5R1 hash - Remove facilitatorUrl from extra (implementation detail, not protocol field) - Fix dedup TTL: use fixed 300s instead of per-request maxTimeoutSeconds - Add canonical W5R1 code hash for stateInit verification - Note simulation as alternative to code hash checks for seqno>0 Per @phdargen review on coinbase/x402#1455 * specs(exact/ton): internal message BoC, minimal payload, strict seqno Major rework based on TON Core team review: - settlementBoc is now an internal message (not external) - Payload reduced to {settlementBoc, asset}, all fields derived from BoC - Public key derived from stateInit or on-chain get_public_key - Seqno check changed to strict equality (TON requirement) - Internal message must be bounceable - Removed facilitatorUrl, nonce, walletPublicKey - Clarified simulation in /verify, extensibility for non-gasless flows - Updated parent scheme_exact.md TON section * spec: address skywardboundd review -- account states, asset clarification, simulation chain - Replace seqno==0 with proper TON account states (nonexist/uninit) for stateInit condition - Clarify that payload.asset is a JSON field, not a BoC-internal field (TEP-74 has no asset) - Add full TEP-74 transfer chain verification to simulation section - Remove non-normative timing note from settlement step 7 - Add W5 gasless transactions reference link * spec: address remaining review comments from skywardboundd - Narrow wallet scope to W5 v5r1 (not v5r1+), only version that exists today - Remove redundant "x402 protocol-level requirement" sentence - Add get_jetton_data hint for decimal resolution - Add walletId to derived fields list - Rename section 2 to "Message and signature verification" - Move balance check from Replay protection to Payment intent - Remove redundant seqno explanation sentence * spec: clarify TON exact flow for optional jetton transfer params Refine the TON `exact` scheme spec to better describe how client-signed W5 jetton transfers are verified and relayed by the facilitator. This update expands the TON payment requirements and verification rules to account for optional jetton transfer parameters exposed through `extra`, and clarifies how those parameters are interpreted when they are omitted. Changes included: - add optional `extra.forwardPayload` and `extra.forwardTonAmount` to TON `PaymentRequirements` and define their effective defaults as zero-bit payload and `"0"` - add optional `extra.responseDestination` and define its effective default as `addr_none` - require facilitators to compare the effective values of `responseDestination`, `forwardPayload`, and `forwardTonAmount` between `accepted.extra` and `requirements.extra` - extend payment intent validation so the facilitator derives and checks `response_destination`, `forward_payload`, and `forward_ton_amount` from the signed W5 action - clarify that the facilitator-funded relay must cover both outer relay execution and the value expected by the client-signed inner transfer - clarify that the client-signed inner message must carry enough TON to fund payer-side execution from the payer jetton wallet to the source jetton wallet - specify that the outbound internal message from the client W5 wallet to the source jetton wallet must be bounceable - specify that the `settlementBoc` wrapper itself does not need to be bounceable - clean up terminology and consistency across the document: `BoC`, `zero-bit`, `forwardPayload`, `forwardTonAmount`, and derived field descriptions This is a spec clarification/update only. It does not introduce a new TON payment scheme, but makes the existing gas-sponsored W5 relay flow more precise. * specs(exact/ton): clarify W5 account states and extra field semantics * soec(exact/ton): clarify code hash check * spec(exact/ton): update reference implementations * spec(exact/ton): allow sending mode 3 --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Arkadiy Stena <arkadiystena@gmail.com>
- Replace Contact nav button with Get Started (links to buyer quickstart docs) - Move Contact link to footer; add GitHub and Discord icon links to nav - Move Trusted By partner logos into HeroSection below the code snippet - Pin platform stats to bottom of hero left column on desktop (xl) with mt-auto - Fix HeroIllustration not rendering at xl: remove broken animation, add min-w-0 - Replace unreliable Tailwind xl: variants with explicit @media rules in globals.css - Fix mobile hero left column overflow by scoping items-start to lg+ only - Add copyCode prop to CodeSnippet to separate display from clipboard content - Adjust phone illustration vertical position for top alignment at xl
The /api/x402/demo endpoint did not help the isitagentready.com scanner detect x402 support. Removing dead code.
* docs: add builder_code.md spec * support services array
* spec + sdk * add auto recover and topUp; add filestorage * add session manager * fix nonce reset * add cooperativeWithdraw to spec/contract * add cooperative withdraw to sdk * update sdk to match spec v1.2 * change to auto-generated getters * improve server devx * improve client devx * added concurrent request example * minor fixes * add cas * add streaming example * rename files to batched* * updated scheme name deferred -> batched * update to new contracts * align paymentresponse.extra for all payloads * fix recovery after refund * fix withdraw -> refund flag * fix channel manager * rename to batch-settlement * align with cloudflare specs * remove claim/refund without sign * add tx sim * improve specs * specs ready * add unit/integration tests * fix tests * improve typing, remove dead code * add readmes * add e2e tests * fix fileStorage * increase depositMultiplier for streaming * refund without paid request * refactor convertToTokenAmount * refactor scheme * fix recovery for refund flow * refactor client scheme * rename session -> channel * remove chargedCumulativeAmount from deposit payload * scheme hook adapters * add enrichSettlementPayload/enrichSettlementResponse hooks * move batch-settlement scheme to scheme hook adapters and enrichSettlementResponse * refactor refund and other payloads * add client hook adapters * align payment-response shapes * move corrective 402 info from errorDetails to requirements.extra.channelState * fix corrective deposit flow * update to latest deployment and change channelId computation to EIP-712 * add hook to handle route handler failures * add atomic channel update and request context primitives * guard channels with pending reservations * fix concurrent claim/settle * skip facilitator and verify locally if onchain state fresh * add redis storage * add fullstack next example with redis and fix settlementOverride for next package * align payment-response for all payloads * add permit2 support and fix extra enrichment for nested objects * fix DEPOSIT_WITNESS_TYPE_STRING * test client state-loss recovery scenario in e2e * fix recovery for axios * improve channel manager * update client deposit policy * clean up examples * add to testnet facilitator * update READMEs * for the culture * add changesets * update to latest deployment * align error codes * remove receiverAuthorizer fallback
* feat: added cdk to example * feat: pin x402 package versions * feat: updated pin to float patch
* batch-settlement on EVM * update refund flow and payloads * move corrective 402 info from errorDetails to requirements.extra.ChannelState and compute channelID from EIP712Hash * align payment-response for all payloads * post audit updates * add deposit collector addresses * update error codes
* docs: add repo move note to README (#40) * add service metadata on resource to all 3 SDKs * lint * changelog * review: harden iconUrl validators + tighten signatures * review: constrain serviceName/tags to printable ASCII * add checks to harden iconurl + tag/name validators * update v2 spec + python lint * python format --------- Co-authored-by: Ash <105402607+Must-be-Ash@users.noreply.github.com>
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 * Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
…ecoin (Permit2 + EIP-2612) (#2038) * feat(evm): add Radius Network and Radius Testnet default stablecoin (Permit2 + EIP-2612) Add SBC as the default stablecoin for Radius Network (eip155:723487) and Radius Testnet (eip155:72344) across Go, TypeScript, and Python SDKs. SBC does not support EIP-3009, so Permit2 is the required transfer method. SBC does support EIP-2612 permit() for gasless approval. * docs: add Radius default-stablecoin entries to user-facing docs * chore(paywall): update generated Radius decimals
* docs(facilitators): add Solvador to facilitators list * docs(facilitators:solvador): add NEAR support
…t error (#2721) * fix(python/flask): return 500 (and log) on unexpected settlement error * chore(changelog): name flask settlement fragment by PR number * fix(python/flask): surface unexpected settlement error as 402 + PAYMENT-RESPONSE (mirror #2622) * fix(python/flask): use canonical unexpected_settle_error reason (parity with #2622) * style(python): apply ruff format to test_flask.py * chore(python): restore uv.lock to main (no dependency changes in this PR) * chore(python): leave uv.lock untouched (no dependency changes)
* verify aptos sign * verify aptos sign
* feat(xrpl): add exact scheme TypeScript reference implementation Implements specs/schemes/exact/scheme_exact_xrpl.md as @x402/xrpl with client, resource-server, and facilitator schemes for payer-signed XRPL Payment transactions: - sequence and ticketSequence asset transfer methods with the spec's resolution order, per-method verification (current account Sequence, ticket availability), and a createTickets utility - extra.areFeesSponsored=false advertised via facilitator getExtra and enforced in envelope verification - offline signature validation, NetworkID binding, InvoiceID invoice binding (Memos rejected), Delegate/Paths/DeliverMin/partial-payment rejection, fee caps, LastLedgerSequence expiry policy, and simulation (signature fields stripped: the XRPL simulate API only accepts unsigned transactions) - settlement re-verifies, submits, and requires validated tesSUCCESS - XRP drops and issued-currency decimal value amounts compared with exact decimal arithmetic (no extra.decimals field) The server scheme keeps enhancePaymentRequirements deterministic (requirements are rebuilt per request), so invoice binding activates only when the resource configuration provides extra.invoiceId. Adds unit and integration tests, publish workflows, release-script and changeset fixed-group wiring, and the root test:integration filter. * feat(e2e): wire XRPL into the e2e harness and participants Adds the xrpl protocol family to the harness networks/types/env plumbing, registers @x402/xrpl in the axios and fetch clients, the express/fastify/hono/next servers (GET /exact/xrpl routes priced in XRP drops), the TypeScript facilitator (keyless: the payer signs and pays XRPL fees), and the mock facilitator supported response. Verified locally against XRPL Testnet (xrpl:1) with funded faucet accounts: pnpm test --testnet --families=xrpl --versions=2 passes all 10 scenarios (axios/fetch x express/fastify/hono/next incl. withX402). * feat(examples): add XRPL to the advanced all_networks examples Registers @x402/xrpl in the client, server, and facilitator all_networks examples (alphabetical by network prefix), with XRPL_SEED/XRPL_ADDRESS/XRPL_NETWORK/XRPL_WS_URL configuration. * docs(examples): add XRPL setup to the advanced example READMEs Document the XRPL environment variables, testnet faucet steps, and reserve/trust line requirements in the advanced client, server, and facilitator example READMEs, and add the matching .env-local entries. The facilitator README also notes the keyless XRPL scheme (enabled via XRPL_NETWORK), its /supported kind with areFeesSponsored=false, and the xrpl:0 / xrpl:1 network identifiers. * fix(typescript): regenerate pnpm-lock.yaml after rebase onto main The website deprecation (#2794) removed the jiti-suffixed peer-dependency variants that the @x402/xrpl importer entries resolved to. Re-resolve the lockfile against the current workspace so frozen installs succeed. * fix(xrpl): bind signatures to account authorization and harden verification - Verify the embedded SigningPubKey is authorized for Account (master key pair unless disabled, or the configured regular key) via a validated account_info lookup. Offline signature validation only proves the blob was signed by its embedded key, and simulation strips signature fields, so an unauthorized signer previously passed /verify and failed at /settle with tefBAD_AUTH or tefMASTER_DISABLED. - Reject single-signed blobs that carry a Signers array; the single signature does not cover Signers, so hybrid blobs still pass verifySignature. - Fail closed on malformed extra.destinationTag in the facilitator, resource server, and client instead of silently skipping the tx-level binding. - Correct the changeset wording: the server scheme passes through configured invoice ids, it does not generate them. - Cover the new checks and previously untested spec rules in unit tests: envelope mismatches, NetworkID branches, XRP/IOU amount and SendMax variants, LastLedgerSequence bounds, InvoiceID mismatch, sequence 0, settle outcomes, and client-side NetworkID handling. * test(xrpl): add env-gated live settlement integration test Mirror the NEAR exact-near.live.test.ts pattern: when XRPL_PAYER_SEED and XRPL_LIVE_PAYTO (or the e2e CLIENT_XRPL_SEED / SERVER_XRPL_ADDRESS names) are set, drive the reference client, resource server, and keyless facilitator end to end against a real network and assert the payTo XRP balance increases by exactly the requested drops. Skipped when the accounts are not configured, so it stays inert in CI. Verified against XRPL Testnet: settled tx 6AF0A4F630F2B43CA44544D5246B58260A01860A3CCBB331625229CD78696791. * fix(xrpl): mirror rippled signer-key ordering and require canonical signing keys - Authorize the configured regular key before the master-disabled check, matching rippled's fixMasterKeyAsRegularKey ordering so legacy accounts whose RegularKey equals their own address are not wrongly rejected. - Reject non-canonical SigningPubKey encodings (only 33-byte compressed secp256k1 or ed25519 keys) before signature validation; rippled refuses such keys at preflight, so accepting them would let verification pass for a transaction that can never settle. * feat(xrpl): create tickets automatically for ticketSequence payments When a ticketSequence payment finds no available ticket, the client now creates tickets through the ClientXrplSigner abstraction instead of throwing and requiring a manual createTickets() call. The new ticketCreateCount option controls the policy: it defaults to 1, allows up to 250 tickets per TicketCreate, and 0 restores the previous fail-fast behavior for pre-provisioned setups. Available tickets are still reused first and skip the creation transaction entirely. - Widen ClientXrplSigner.sign from Payment to SubmittableTransaction so the same signer can sign TicketCreate; createTickets accepts the signer abstraction instead of an xrpl.js Wallet. - Cover the default, configured, and disabled policies plus invalid counts in unit tests. * fix(xrpl): return a stable reason code for unexpected verification failures The verify() catch-all embedded the raw error message in the invalidReason string (invalid_exact_xrpl_payload_malformed: <message>), so integrators could not match on a stable code. Return invalid_exact_xrpl_facilitator_error and carry the raw diagnostic text separately in invalidMessage. Settlement submission errors keep the existing transaction_failed: <diagnostic> reason. * fix(xrpl): fail closed on missing or invalid IOU issuers Issued-currency requirements and accepted payloads must both carry a valid classic issuer address before the issuer comparison runs. Two absent issuers previously compared equal and passed envelope validation, and a single absent issuer surfaced as a confusing mismatch. Missing or malformed issuers now return invalid_exact_xrpl_iou_issuer_missing. * fix(xrpl): set the custom-network NetworkID when building payments The client validated that prepared transactions carried the correct NetworkID on custom networks (id > 1024) but relied on the preparer to add the field. Insert it while building the payment so the default and custom preparers both start from a correct transaction; validation still rejects preparers that remove or replace it. * refactor(xrpl): reuse parseMoneyString from @x402/core Replace the server scheme's hand-rolled money-string parsing with the shared parseMoneyString helper used by the other mechanism packages, aligning string-price edge-case handling with the rest of the SDK. * test(e2e): cover both XRPL asset-transfer methods on every server Replace the single /exact/xrpl route with explicit sequence and ticketSequence endpoints on Express, Fastify, Hono, and Next (both the proxy middleware and withX402), pinning extra.assetTransferMethod and the issuer for issued-currency pricing in each route config. Teach the harness that asset transfer methods are not EVM-only metadata: xrpl endpoints resolve their declared method and default to sequence, and the server proxy forwards the configured issuer. * test(e2e): add a self-managed XRPL Testnet IOU fixture pnpm xrpl:iou:setup creates or reuses dedicated Testnet issuer, payer, and payee accounts, funds missing ones through the faucet, enables DefaultRipple on the issuer, establishes the trust lines, and issues test USD to the payer, replenishing it on re-runs. Credentials are persisted only in the git-ignored e2e/.env with 0600 permissions, seeds are never logged, and the script refuses to run unless the connected ledger reports Testnet network id 1. Mask seed values alongside private keys in the harness debug output. * fix(xrpl): reject duplicate settlements with a settlement cache Concurrent /settle calls carrying the same signed blob each passed verification, and because XRPL submission is idempotent on the transaction hash, submitAndWait resolved the same validated tesSUCCESS for every caller. The facilitator therefore returned success to all of them, letting a client access the resource N times while paying once. Add an in-memory SettlementCache (mirroring the SVM one) keyed on the signed transaction hash. settle() checks and inserts the key synchronously between re-verification and submission, so concurrent duplicates are serialized: the first proceeds, the rest return a duplicate_settlement error. Unlike Solana's protocol-fixed blockhash lifetime, an XRPL transaction stays landable until its LastLedgerSequence, which the scheme derives from maxTimeoutSeconds. Each entry's retention is sized to that window (plus a margin) rather than a flat interval, so an entry cannot be evicted while a slow-to-validate duplicate could still pass re-verification. Document the mitigation as REQUIRED in the spec, including the per-process scope and the shared-store requirement for horizontally scaled facilitators.
Follow-up to #2801, implementing the maintainer suggestion to add XRPL as an optional network on the x402.org testnet facilitator. Unlike the other optional networks, XRPL is gated on an explicit FACILITATOR_XRPL_ENABLED=true flag rather than a private key: in the XRPL exact scheme the payer signs the transaction and pays its fee, so the facilitator needs no key or funds — it only verifies and submits the pre-signed blob. An optional FACILITATOR_XRPL_TESTNET_WS_URL override is supported for deployments that prefer their own node over the default public testnet endpoint, mirroring the e2e facilitator's XRPL_WS_URL option.
* 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 * 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>
…2856) * docs: add XRPL to buyer quickstart, network lists, and facilitators Complements #2854 (XRPL Setup in exact.mdx + sdk-features tables) with the remaining pages, mirroring how NEAR was documented in #2771: - quickstart-for-buyers: install line, XRPL signer section, multi-scheme registration example, and the summary package list - schemes/overview: add XRPL to the network implementations sentence - network-and-token-support: add the xrpl:<networkId> CAIP-2 identifier - dev-tools/facilitators: list the T54 XRPL facilitator (mainnet and testnet), which previously appeared on the ecosystem page removed in #2794 * docs: add XRPL to the token support table The Token Support ecosystem table and its intro sentence stopped at Concordium; add the XRPL row (XRP or any issued currency, transferred via a payer-signed Payment transaction) alongside the CAIP-2 identifier added in the previous commit. * docs: add XRPL to the network support summary bullet The Summary list at the bottom of network-and-token-support.mdx parallels the intro sentence updated in the previous commit; bring it in line so both lists end with the same network set.
* Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/core-concepts/network-and-token-support.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* SIWX configured-origin fix * py+go * updated docs
* harden channel storage * handle failures * few more fixes * go * py * fix fmt
* Update docs/advanced-concepts/lifecycle-hooks.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/advanced-concepts/lifecycle-hooks.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
#2884) * fix(evm): auto-wrap any eth_account BaseAccount, not just LocalAccount _wrap_if_local_account only checked isinstance(signer, LocalAccount), so third-party wallet-provider adapters that extend eth_account's abstract BaseAccount directly (e.g. Coinbase AgentKit's EvmWalletSigner, or any custom-custody signer) were passed through unwrapped instead of being wrapped in EthAccountSigner. Calling such a signer's sign_typed_data with x402's positional (domain, types, primary_type, message) convention then misassigns arguments against its eth_account-style keyword signature, raising a KeyError deep in eth_account.messages.encode_typed_data. Broaden the check to BaseAccount (LocalAccount's own parent class) in all three duplicated occurrences: exact, upto, and batch_settlement client schemes. Adds regression tests with a minimal BaseAccount-only signer. Reproduced against a real x402 v2 GatewayWalletBatched payment requirement signed by an AWS KMS-backed signer wrapped in a BaseAccount subclass. Note: most of this change was written with AI assistance (Claude Code) and reviewed/verified by me before submission, per this repo's AI-assisted contribution guidelines. * docs(changelog): add fragment for #2884
* feat(extensions): add code and cause to SIWx failure results * refactor(extensions): align SIWx validation result with verify response shape * remove cause, also align SIWxVerifyResult with facilitator verify --------- Co-authored-by: vraspar <v2parikh@uwaterloo.ca>
* Update docs/extensions/sign-in-with-x.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/extensions/sign-in-with-x.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/extensions/sign-in-with-x.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor * Update docs/extensions/sign-in-with-x.mdx Generated-By: mintlify-agent Mintlify-Source: dashboard-editor --------- Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
* py SIWX structured-error * go SIWX structured-error
The examples index was last updated in #345 (2025-08-18). The v2 restructure in #705 rewrote every example under examples/typescript but left it untouched: of its 20 entries, 13 point at directories that no longer exist, and 29 of the 35 examples on disk are missing. Rebuild all four listings from what is on disk, add indexes for fullstack/ and facilitator/, and correct claims that no longer hold: custom/ does not use @x402/core alone, and Fastify now has a package.
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
20 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