Capability records: documented facts per rail

Google Cloud with AP2

Provenance documentation-derived

AP2 is an authorization and evidence layer, not a settlement rail; the specification, mandate documents, considerations, FAQ and glossary contain no network-fee provision. Who pays a network fee depends on the payment instrument beneath AP2, which the protocol does not fix.

Machine Payments Protocol on Lightning

Provenance documentation-derived

Protocol layer (BOLT 7, BOLT 4): the origin node must pay each forwarding node the fee that node advertises, and the amount forwarded to a non-final hop includes the origin-computed fee. Operator layer (Spark, Lightspark): payLightningInvoice takes a required maximum fee the payer will pay, and the Spark fee table lists a fee structure for Spark to Lightning sends. Neither the Machine Payments Protocol Lightning draft nor the Spark pages read say whether the payer recovers the fee from the payee.

Machine Payments Protocol on Tempo

Provenance documentation-derived

The Tempo charge method draft makes the fee bearer a per-challenge choice: with methodDetails.feePayer false or omitted the client sets the fee token and arranges payment of the fee; with feePayer true the server commits to paying the fee and may recover the cost through pricing. The Tempo fee specification (chain layer, operator Tempo Labs) states that without a fee payer signature the sender pays, and that a fee payer signature authorizes a third party to pay; fees go to the block proposer.

x402 on Base

Provenance documentation-derived

The exact-on-EVM scheme states that the facilitator pays the gas and the client signs. The scheme-level text says a facilitator may pay the fee or relay a payer-funded payment. The CDP FAQ states the facilitator pays gas and that the per-transaction price covers it; the CDP pricing text places that price on the seller.

x402 on Solana

Provenance documentation-derived

The exact-on-Solana scheme assigns the network fee to the fee-payer account, which may be the merchant or a third-party facilitator, and restricts that account to paying the fee. Solana documentation states the fee is deducted from the fee payer and is charged even if the transaction fails. No document read says the fee is recovered from either party.

x402 on Stellar

Provenance documentation-derived

The Stellar exact scheme has the facilitator rebuild the transaction with its own account as source, and that account pays the fee; the paying agent signs an authorization entry, not the transaction. The specification does not say whether the cost is recovered; the OpenZeppelin Channels documentation for the service used by the hosted Built on Stellar facilitator says fees are paid by the service and that the service is free to use.

Google Cloud with AP2

Provenance documentation-derived

AP2 is an authorization and evidence layer, not a settlement rail; AP2 describes itself as a security feature within a commerce protocol and defines mandates and receipts, not settlement. No finality class is defined.

Machine Payments Protocol on Lightning

Provenance documentation-derived

BOLT 2 states that knowledge of the payment preimage is irrevocable by definition, and the BOLT glossary defines the preimage as proof that payment has been received. The Machine Payments Protocol Lightning draft states that settlement is final once the preimage is revealed and that the preimage is not revealed until the HTLC resolves.

Machine Payments Protocol on Tempo

Provenance documentation-derived

The Tempo chain documentation (operator Tempo Labs) states that Tempo uses Simplex BFT consensus with deterministic finality and that a finalized block cannot be reverted; integrators are told to treat finalized blocks as irreversible.

x402 on Base

Provenance documentation-derived

The Base documentation describes finality for ordinary Base transactions as a sequence of named stages, each giving increasing security guarantees. The x402 specification does not define a finality class; its settle endpoint establishes finality from the resource server perspective.

x402 on Solana

Provenance documentation-derived

The Solana RPC overview defines three named commitment levels (processed, confirmed, finalized) that state how finalized a block must be, with processed described as still able to be rolled back. The x402 specification does not define a finality class.

x402 on Stellar

Provenance documentation-derived

The Stellar Consensus Protocol page describes federated voting in which a confirmed statement cannot be contradicted, and states that the protocol prioritizes safety over liveness; the transaction lifecycle page says consensus settles on a single transaction set per ledger. The pages read do not use the word finality.

Google Cloud with AP2

Provenance documentation-derived

AP2 v0.2 names double spend as a threat. Its mitigation places a MUST on the Shopping Agent not to sign or present overlapping closed mandates from one open mandate without a rejection receipt for the earlier one, and gives verifiers a MAY to reject overlapping mandates. Each closed Payment Mandate carries a transaction_id that is the hash of the checkout it pays for. Whether the instrument beneath can move value twice on an identical resubmit is not answered at this layer.

Machine Payments Protocol on Lightning

Provenance documentation-derived

The core draft requires single-use proofs and the Lightning method draft requires that a consumed challenge is never accepted again, with acceptance and invalidation atomic. BOLT 4 says a final node whose payment hash has already been paid MAY succeed in accepting the HTLC, so another payment to the same hash is not prevented at the protocol layer. On the Spark path, payLightningInvoice takes an optional transferId for retrying the same logical payment, and the docs tell integrators not to create another payment because the original call threw.

Machine Payments Protocol on Tempo

Provenance documentation-derived

The core draft requires single-use proof semantics and concurrent-request protection, and the charge intent draft requires each challenge id to be single-use; the Tempo method draft names chain ID binding, nonce consumption and validity windows. At the chain layer TIP-1009 states that a transaction hash cannot execute twice but that changing validBefore produces a different hash, so a freshly signed transaction is a distinct transaction. In pull mode the server broadcasts, so another credential for a consumed challenge is rejected before broadcast; in push mode the client broadcasts before presenting the credential, and no document read says whether a second client-broadcast transaction for the same challenge is prevented. The mppx SDK (operator layer) claims transaction hashes and proof challenge IDs in a replay store.

x402 on Base

Provenance documentation-derived

EIP-3009 rejects an authorization whose nonce is already used, and x402 relies on that for replay protection. A newly signed authorization carries a new nonce and is a separate authorization; CDP warns that creating another payment before reconciling can charge the buyer twice. An optional x402 extension defines an idempotency key that resource servers and facilitators may honour.

x402 on Solana

Provenance documentation-derived

The x402 SVM scheme states that Solana deduplication makes a resubmitted transaction execute once, while the facilitator could still report success to each caller, and specifies a settlement cache as a mitigation. Solana documentation states that re-signing before the original blockhash expires can lead to both transactions being accepted.

x402 on Stellar

Provenance documentation-derived

The authorization entry the agent signs carries a nonce unique per address until its expiration ledger, and the host verifies and consumes it, so the same entry cannot apply twice. Nothing read prevents the agent from signing another entry with a new nonce. The x402 payment-identifier extension, published in the canonical repository, offers an optional idempotency key that resource servers and facilitators may use.

Google Cloud with AP2

Provenance documentation-derived

The protocol requires a signed Payment Receipt to be returned once the Merchant Payment Processor accepts or rejects the Payment Mandate, but sets no time by which it must arrive. Mandates may carry an expiry, advised by the specification for open mandates and optional on the closed Payment Mandate; that limits how long the authorization is usable, not how long the agent waits to learn the result.

Machine Payments Protocol on Lightning

boundField

HTLC cltv_expiry (protocol layer; not documented as exposed on the Spark path)

Provenance documentation-derived

Protocol half (stated): BOLT 7 has the origin compute HTLC expiries backward from the destination, each hop advertises the blocks it subtracts, and the delta contributes to the time funds are unavailable if the payment fails; BOLT 2 gates failure on downstream resolution and derives an upper allowance in blocks from stated assumptions. Operator half (not stated as a bound available to the agent): on the Spark path the hosted Lightning payment provider builds the route; payLightningInvoice returns no expiry field, the Spark overview says operators lock the sender leaves until a specified time, and the wallet guide says the swap expiry is not a guaranteed refund time.

Machine Payments Protocol on Tempo

boundField

valid_before

Provenance documentation-derived

The Tempo Transaction carries an optional valid_before expiration timestamp that the payer signs, and the Tempo charge method draft has the client sign with validBefore no later than the challenge expires auth-param, within which the server may submit. TIP-1009 expiring-nonce transactions require validBefore and reject transactions outside a protocol maximum window.

x402 on Base

boundField

authorization.validBefore

Provenance documentation-derived

The signed EIP-3009 authorization carries validBefore, and the reference contract logic refuses execution at or after it, so an authorization unconsumed at that time cannot later be consumed. x402 adds a non-terminal settlement_pending code for a broadcast whose confirmation was not observed; CDP tells the caller to reconcile on chain and treat a revert, failure or expiry as the terminal failure.

x402 on Solana

boundField

recentBlockhash (expiry height computed by the client)

Provenance documentation-derived

The signed transaction carries a recent blockhash and expires when that blockhash is no longer recent; Solana documentation says a dropped transaction can be discarded once the blockhash is older than lastValidBlockHeight, and that an expired transaction will never be processed. The x402 scheme can pass lastValidBlockHeight as an informational hint that is not part of the transaction, so the client computes the bound.

x402 on Stellar

boundField

signatureExpirationLedger

Provenance documentation-derived

The agent sets the expiration ledger of the authorization entry it signs, and the facilitator must reject an entry whose expiration exceeds the bound derived from maxTimeoutSeconds. The bound is expressed in ledger sequence numbers.

Google Cloud with AP2

Provenance documentation-derived

AP2 v0.2 defines a signed Payment Receipt with a Success or Error status, returned to the Shopping Agent by the Merchant Payment Processor, a party to the payment. The protocol defines no public arbiter; a trustless read, if any, would come from the instrument, which AP2 does not fix.

Machine Payments Protocol on Lightning

Provenance documentation-derived

On the profiled Spark path the paying agent learns the outcome by polling the operator: the preimage is not returned by the payment call and must be fetched from getLightningSendRequest, and the incoming-transfer event does not fire for outgoing Lightning sends. The Spark overview describes a Lightning payment provider that pays the invoice and submits proof to the Spark operators. At the protocol layer the routing error channel is documented as unreliable, and no document read describes a public arbiter for a Lightning payment.

Machine Payments Protocol on Tempo

Provenance documentation-derived

In pull mode the server broadcasts the signed transaction and reports success through a Payment-Receipt carrying the transaction hash, so knowledge at submission passes through the payee; the Tempo chain documentation then states that finalized blocks can be queried through standard JSON-RPC and that a public explorer shows transactions and accounts, so the arbiter is readable without the payee. In push mode the client broadcasts and can read the chain itself.

x402 on Base

Provenance documentation-derived

The paying agent initially learns the outcome from the settlement response the resource server relays from the facilitator. The arbiter is public: EIP-3009 exposes authorizationState as a view function, and CDP directs callers to look the transaction up on the network. An optional x402 extension lets the resource server return a signed receipt; that receipt is signed by the payee side.

x402 on Solana

Provenance documentation-derived

The settlement response travels from the fee-paying party to the resource server and then to the client. The x402 SVM scheme notes the facilitator could report success to several callers for one transfer. Solana documentation describes getSignatureStatuses for reading a signature status from a node, and warns that a network error or malformed facilitator response is not proof of payment.

x402 on Stellar

Provenance documentation-derived

The agent initially learns the outcome through the facilitator and resource server (the SettlementResponse carrying a transaction hash); afterwards the outcome can be read from the public Stellar ledger by that hash. The optional offer-and-receipt extension adds a receipt signed by the resource server, which is still a party to the payment.

Google Cloud with AP2

Provenance documentation-derived

The evidence half of a dispute path is specified: mandates and receipts can be brought together and verified as dispute evidence. The resolution half (who initiates, how value returns, who bears any fee) is declared outside the specification. No refund, reversal or cancellation path is defined.

Machine Payments Protocol on Lightning

Provenance documentation-derived

After settlement (preimage revealed) no in-protocol return path exists in the documents read; the method draft says so explicitly. Before settlement, the HTLC can be cancelled or failed back at the protocol layer, and on the Spark path the operator lock lapses at a specified time. Any refund of a settled charge is out-of-protocol and at the payee discretion.

Machine Payments Protocol on Tempo

Provenance documentation-derived

At the protocol layer the charge intent draft states reversibility is method-dependent and neither the core nor the Tempo method draft defines a refund. The mpp.dev refunds page (operator layer) states that refunds in the charge flow are out-of-protocol transfers back to the client. The chain documentation states that finalized blocks cannot be reverted, so no reversal or chargeback path exists at the settlement layer in the documents read.

x402 on Base

Provenance documentation-derived

The x402 exact scheme defines no refund and leaves any remedy to the resource server. EIP-3009 defines an optional cancellation of an unused authorization. CDP describes settled payments as irreversible and a refund as a new transfer back to the payer.

x402 on Solana

Provenance documentation-derived

The x402 exact scheme states that it defines no refund and leaves any remedy to the resource server. The SVM scheme, the core specification and the Solana x402 and facilitator pages define no refund, reversal, chargeback, dispute or cancellation path for an exact payment.

x402 on Stellar

Provenance documentation-derived

No refund, reversal, chargeback, dispute or cancellation path is defined in the x402 v2 specification, the Stellar exact scheme, the Stellar x402 pages or the OpenZeppelin facilitator documentation read. An unsettled authorization entry lapses at its expiration ledger, which is expiry rather than a restitution path.

Google Cloud with AP2

Provenance documentation-derived

AP2 shares mandates with named roles and requires selective disclosure and data minimisation; it publishes nothing to a public ledger. What a party outside the payment can see is determined by the instrument beneath, which the documents do not address beyond noting that sharing with other parties is outside the scope of AP2.

Machine Payments Protocol on Lightning

Provenance documentation-derived

BOLT 4 states intermediate nodes cannot learn route members beyond their predecessor and successor, and that hops see an ephemeral key for the origin in place of its identity; each hop payload carries the amount to forward. BOLT 11 invoices carry the payee node public key and a payment description. The Lightning method draft calls the payment hash a publicly shareable receipt identifier. Spark states new wallets start with privacy off and public clients can query their Bitcoin balances and transfer history.

Machine Payments Protocol on Tempo

Provenance documentation-derived

The Tempo documentation states that on Tempo Mainnet anyone can read any account balance and that the public explorer shows transactions, accounts and token activity. The method draft settles by TIP-20 transfer or transferWithMemo calls and defines an optional bytes32 memo; the mpp.dev Tempo charge page states the mppx client adds a challenge-bound attribution memo to the primary transfer. The core draft asks payment methods to support pseudonymous options where possible.

x402 on Base

Provenance documentation-derived

Base documentation states that a transfer on the public chain exposes sender, recipient and amount. EIP-3009 emits an event indexed by authorizer and nonce. The x402 facilitator interface publishes signer addresses, and CDP appends attribution codes to settlement calldata when the builder-code extension is used.

x402 on Solana

Provenance documentation-derived

Solana documentation states that its public ledger makes every transaction, token account and mint auditable, that memos are recorded on chain and visible in logs, and that privacy is provided by application-level tools. The x402 exact scheme requires a TransferChecked transfer and a Memo instruction, and reports the payer as a public address.

x402 on Stellar

Provenance documentation-derived

Stellar documents itself as a public blockchain on which every transaction is visible. The x402 exact scheme moves value with a token transfer(from, to, amount) call, so payer address, payee address and amount are transfer arguments in a public transaction; the facilitator appears as the transaction source account.

Google Cloud with AP2

Provenance documentation-derived

The site and the repository both carry the v0.2 specification; the repository release v0.2.0 and the last commit touching the specification file are dated 2026-04-28. The AP2 site and FAQ say the specification work continues in the FIDO Alliance, while the site also says the GitHub repository hosts the latest specification.

Machine Payments Protocol on Lightning

Provenance documentation-derived

The Machine Payments Protocol layer is defined by the Lightning charge method draft (Lightspark authors), the core scheme draft and the charge intent draft in tempoxyz/mpp-specs; the Lightning layer by BOLT 2, 4, 7 and 11 in lightning/bolts. Dates are the last commits touching each file per the GitHub commits API.

Machine Payments Protocol on Tempo

Provenance documentation-derived

The payment flow is defined by the core Payment HTTP Authentication Scheme draft, the charge intent draft and the Tempo charge method draft in tempoxyz/mpp-specs, with the Tempo transaction format defined on the Tempo documentation site. Last-change dates are the last commits touching each file per the GitHub commits API.

x402 on Base

Provenance documentation-derived

The payment flow is defined by the x402 v2 core specification, the exact scheme documents and EIP-3009. Dates are the last commits touching each file, read from the GitHub commits API.

x402 on Solana

Provenance documentation-derived

The payment flow is defined by the x402 v2 core specification and the exact scheme documents for Solana. Dates are the last commits touching each file, read from the GitHub commits API.

x402 on Stellar

Provenance documentation-derived

The payment flow is defined by the x402 v2 core specification and the Stellar binding of the exact scheme in the canonical x402-foundation repository; the Stellar developer page describes the operator path.

Google Cloud with AP2

scope

no hosted service documented

Provenance documentation-derived

AP2 is a protocol with an SDK and samples, not a hosted API; no document read declares a rate or throughput limit.

Machine Payments Protocol on Lightning

scope

Spark Lightning send path

Provenance documentation-derived

None of the Spark wallet SDK or API reference pages read, the Spark limitations page, or the mpp.dev Lightning pages declares a rate or throughput limit for the Spark Lightning send path or the Lightning payment provider. The core draft advises servers to rate-limit challenges but declares no figure.

Machine Payments Protocol on Tempo

scope

hosted Tempo API, per API key and per client IP; not stated for the public JSON-RPC endpoint

Provenance documentation-derived

Tempo Labs declares default rate limits for the hosted Tempo API in fixed one-minute windows, with separate defaults for API-key and anonymous callers, and states the authoritative limit is the RateLimit-Limit response header. The API reference describes direct JSON-RPC access as outside the stable API contract with no availability guarantees. The core draft advises servers to rate-limit challenges and verification attempts but declares no figure.

x402 on Base

scope

Coinbase Developer Platform API, write and read operations

Provenance documentation-derived

CDP publishes rate limits for the CDP API with figures for write and read operations and a 429 response. No page read states a limit for the x402 facilitator endpoints; the settle endpoint reference lists rate_limit_exceeded among its error types.

x402 on Solana

scope

Solana public RPC endpoints

Provenance documentation-derived

Solana documentation declares rate limits for its public RPC endpoints, which a client may use to fetch a blockhash or read a signature status. No facilitator operator is named in the R9 corpus, and no facilitator rate limit is declared.

x402 on Stellar

scope

OpenZeppelin Channels service used by the hosted facilitator

Provenance documentation-derived

The Channels guide declares a fair-use policy in which each API key has a fee consumption limit, and requests return FEE_LIMIT_EXCEEDED once it is reached. The Stellar x402 page says the hosted facilitator leverages Channels, and its API keys are generated at the Channels address; no document read states a request-per-second limit for /verify or /settle.

Google Cloud with AP2

Provenance documentation-derived

No status page is linked from ap2-protocol.org, the repository README or the documentation; AP2 documents no hosted service whose status could be published.

Machine Payments Protocol on Lightning

addresses

• https://spark.money/status

Provenance documentation-derived

The Spark documentation index (llms.txt) lists a status page address. mpp.dev links no status page.

Machine Payments Protocol on Tempo

addresses

• https://status.tempo.xyz/

Provenance documentation-derived

The Tempo homepage links a Status page at status.tempo.xyz. No status page link was found on mpp.dev or in the Tempo developer documentation index.

x402 on Base

addresses

• https://status.coinbase.com/
• https://status.base.org/

Provenance documentation-derived

Both operators on the profiled path publish a status page reachable from their own documentation. Existence and address are recorded; no uptime or incident content is recorded.

x402 on Solana

Provenance documentation-derived

No link to a service status page was found in the Solana documentation corpus or in the x402 documents read.

x402 on Stellar

addresses

• https://status.stellar.org/

Provenance documentation-derived

The Stellar developer documentation links a status page for Stellar.org services. No status page is linked from the OpenZeppelin facilitator, Relayer or Channels documentation read.

Google Cloud with AP2

Provenance documentation-derived

The repository names a Python SDK as its primary artifact and says future language SDKs would sit beside it. Reference implementations are published as Python, Go and Android samples.

Machine Payments Protocol on Lightning

Provenance documentation-derived

mpp.dev names @buildonspark/lightning-mpp-sdk as the implementation of the Lightning payment method, extending the mppx TypeScript SDK, with Spark as the reference wallet. The Spark documentation documents the TypeScript wallet SDK. The mpp.dev SDK feature matrix lists the Tempo and Stripe methods for its five core SDKs and says additional methods implement their own SDKs; Lightning is not marked in any core SDK.

Machine Payments Protocol on Tempo

Provenance documentation-derived

mpp.dev lists five official Machine Payments Protocol SDKs (TypeScript, Python, Rust, Go, Ruby), and its feature matrix marks the Tempo method and charge intent as supported in all five. The Tempo documentation separately lists chain SDKs; Foundry is listed as tooling and is not counted as a language SDK.

x402 on Base

Provenance documentation-derived

The x402 Foundation README documents reference SDKs in TypeScript, Python and Go. CDP documents its own x402 helpers in TypeScript and a facilitator configuration module in Python, and states that its SDK has no Go x402 helpers.

x402 on Solana

Provenance documentation-derived

The x402 Foundation README documents reference SDKs in TypeScript, Python and Go. The Solana x402 guide builds its client and server with the TypeScript @x402 packages including @x402/svm.

x402 on Stellar

Provenance documentation-derived

The x402 Foundation publishes a Stellar mechanism package for TypeScript covering client, server and facilitator roles. The canonical repository tree contains no Stellar mechanism for Python, Go or Java. The Stellar organisation publishes a TypeScript examples repository, and OpenZeppelin publishes the facilitator plugin in TypeScript.

Google Cloud with AP2

address

https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/agent_authorization.md

enumeration

Agent Authorization Framework error codes; receipt error field

Provenance documentation-derived

The Agent Authorization Framework document defines four error codes for all action authorizations and marks two as terminal; receipts carry an error code when the status is Error.

Machine Payments Protocol on Lightning

address

https://github.com/tempoxyz/mpp-specs/blob/main/specs/methods/lightning/draft-lightning-charge-00.md

enumeration

Lightning problem types in the method draft (absent from the paymentauth.org index); BOLT 4 failure_code

Provenance documentation-derived

The Lightning method draft defines four RFC 9457 problem types on top of the core codes. BOLT 4 lists the supported failure_code values returned to the origin node. The Spark pages read publish no error catalogue for payLightningInvoice or getLightningSendRequest; the guide shows one send status value. The paymentauth.org problems index lists core and session types and no Lightning types.

Machine Payments Protocol on Tempo

address

https://paymentauth.org/problems/

enumeration

Problem Details types (RFC 9457) under the paymentauth.org base URI; Tempo API error.code values

Provenance documentation-derived

The core draft defines a table of payment error codes delivered as RFC 9457 Problem Details types under a canonical base URI, and the paymentauth.org problems page lists the same core types plus session types. The Tempo charge method draft refers failures to HTTP status codes and Problem Details without adding types. The Tempo API errors page lists stable error.code values for the hosted API.

x402 on Base

address

https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md

enumeration

x402 error codes (errorReason, invalidReason), section 9; Coinbase Developer Platform x402SettleErrorReason

Provenance documentation-derived

The x402 specification lists standard error codes, including EVM-specific ones and the non-terminal settlement_pending. CDP publishes an enumeration of settle error reasons and a reference table, and states that it returns a smaller set than the specification defines.

x402 on Solana

address

https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md

enumeration

x402 error codes (errorReason, invalidReason), section 9; further codes named in the SVM scheme text

Provenance documentation-derived

The x402 specification publishes a list of standard error codes; the SVM scheme adds named codes in its text without a separate enumeration. Solana documentation lists HTTP error codes for its public RPC endpoints.

x402 on Stellar

address

https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md

enumeration

x402 error codes (errorReason, invalidReason), section 9; one Stellar scheme code; OpenZeppelin Channels error table

Provenance documentation-derived

The v2 specification lists standard error codes returned by facilitators or resource servers; the Stellar scheme adds one scheme-specific code for the fee ceiling. The Channels guide publishes a table of service error codes.

Google Cloud with AP2

Provenance documentation-derived

AP2 v0.2 defines signed mandates and a signed Payment Receipt bound to the closed Mandate by hash, and the reference SDK verifies the receipt's ES256 signature locally given the issuer's public key. How a verifier obtains and trusts that key is not stated in the documents read. The signer is the Merchant Payment Processor, a party to the payment.

Machine Payments Protocol on Lightning

Provenance documentation-derived

The Machine Payments Protocol Lightning method and the mpp.dev Lightning page state that the preimage is verified by a single hash operation, locally, without contacting any external service. Two limits: the documents describe the server performing that check, and no page read states it from the paying agent's side; and a preimage shows that the invoice was settled, not which agent paid.

Machine Payments Protocol on Tempo

Provenance documentation-derived

The Payment-Receipt defined by the Machine Payments Protocol core draft is a plain JSON object with no signature field, and neither the core draft nor the mpp.dev receipts page addresses signing or offline verification. The receipt carries a transaction reference, so establishing the outcome is a read of that transaction on the Tempo chain.

x402 on Base

Provenance documentation-derived

The x402 Offer and Receipt extension, an optional addition to x402, lets the settlement response carry a receipt signed by the resource server on success. On this network the signer address is recovered from an EIP-712 signature with no network call. Three limits are stated in the extension: a valid signature does not establish that the key may sign for the service, and no mechanism for establishing that is mandated (some of the listed routes are network lookups); the receipt is the resource server's own statement and by default omits the transaction reference; and the extension is optional, with its wire shape not yet stable. The settle response itself is unsigned.

x402 on Solana

Provenance documentation-derived

The x402 Offer and Receipt extension, an optional addition to x402, lets the settlement response carry a receipt signed by the resource server on success, and states that its EIP-712 signing works on non-EVM networks including Solana. Three limits are stated in the extension: a valid signature does not establish that the key may sign for the service, and no mechanism for establishing that is mandated (some of the listed routes are network lookups); the receipt is the resource server's own statement and by default omits the transaction reference; and the extension is optional, with its wire shape not yet stable. Without the extension the agent holds a transaction signature, which is checked by querying a node.

x402 on Stellar

Provenance documentation-derived

The x402 Offer and Receipt extension defines an optional receipt signed by the resource server; the settle response of the x402 v2 specification is unsigned. Whether that receipt can be checked offline on a Stellar network is not settled by the documents read: one section of the extension limits EIP-712 receipts to EVM networks while another states that EIP-712 signing works on non-EVM networks, and a JWS receipt needs a DID URL resolved by a method the extension does not fix. The Stellar x402 page read does not mention the extension.