Payment rail

EVM chains

On EVM chains the payer signs the ATR hash itself, as the nonce of its transfer authorization. Source: lcp docs: rails⁠ (opens in a new tab)

Sources (1)

lcp docs: rails⁠ (opens in a new tab)

Where the ATR hash rides

On this rail, the ATR hash rides in the signed authorization’s nonce.

The standard

With x402’s exact scheme, the EIP-3009 authorization’s nonce is the ATR hash. The token contract verifies the payer’s signature when it executes the transfer, and the ATR hash lands on chain as the nonce of the transfer’s event: anyone can read it back from the settlement alone. Source: lcp docs: rails⁠ (opens in a new tab) · Source: lcp docs: pairings reference⁠ (opens in a new tab)

MPP’s EVM charges derive their nonce from the challenge id that carries the ATR hash: a value that confirms the ATR hash, and does not reveal it. Source: lcp docs: MPP⁠ (opens in a new tab)

The nonce of the EIP-3009 authorization, or of the Permit2 witness transfer, the payer signs. Source: lcp docs: rails⁠ (opens in a new tab)
x402/exact/eip155/eip3009x402/exact/eip155/permit2x402/upto/eip155/permit2
The escrow payment’s salt, or a commitment over it with the receiver authorizer and policy, which the token authorization’s nonce commits to. Source: lcp docs: rails⁠ (opens in a new tab)
x402/auth-capture/eip155/eip3009x402/auth-capture/eip155/permit2
The salt of the redeemed leaf delegation; or, where the delegation signs no hash, the echoed extension only. Source: lcp docs: rails⁠ (opens in a new tab)
x402/exact/eip155/erc7710-saltx402/exact/eip155/erc7710
The channel’s salt. Source: lcp docs: rails⁠ (opens in a new tab)
x402/batch-settlement/eip155mpp/session/evm
A nonce or salt derived from the MPP challenge id. Source: lcp docs: rails⁠ (opens in a new tab)
mpp/charge/evm/authorizationmpp/charge/evm/permit2mpp/charge/usdc/evmmpp/charge/usdc/gateway
The challenge only; the payment transaction carries nothing. Source: lcp docs: rails⁠ (opens in a new tab)
mpp/charge/evm/transactionmpp/charge/evm/hash

Entry points: @integraledger/lcp/evm, @integraledger/lcp/x402, @integraledger/lcp/x402-batch-settlement, @integraledger/lcp/mpp

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The ATR hash of the site’s example ATR, as this rail carries it

H itself, as the EIP-3009 nonce (32 bytes)

0x8448dc1b716a5103287cb8f35e36b614ffd91e630ab8b7911833c54748ad5ca6

Computed from the site’s example ATR by this rail’s own helper in the package, when the site was built.

What a payment on this rail proves

Of these 15 pairings, 12 have the buyer’s signature cover the ATR hash, 12 leave a public proof of it, and 3 let anyone read it back from the chain alone. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Switch to Technical to see each pairing, and the sentence its record states about what a payment through it proves.

The standard

x402/exact/eip155/eip3009Native FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The nonce of the EIP-3009 authorization, or of the Permit2 witness transfer, the payer signs.
What a payment through it proves: The payer signed an EIP-3009 transfer authorization whose nonce is this ATR's hash. The token contract verified that signature when it executed the transfer, and the hash is on chain as the nonce topic of its AuthorizationUsed event in the settlement transaction. This does not show that amount, payee, asset or timing match the ATR's content.
LCP profile: x402/exact/eip155/eip3009⁠ (opens in a new tab)
x402/exact/eip155/permit2Native FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The nonce of the EIP-3009 authorization, or of the Permit2 witness transfer, the payer signs.
What a payment through it proves: The payer signed a Permit2 witness transfer whose nonce is this ATR's hash, with the scheme's x402 proxy as spender and the payee in the witness. Permit2 verified the signature when the proxy executed the transfer, and the hash is in the settlement transaction's calldata as the Permit2 nonce; no event carries it. This does not show that amount, payee, asset or timing match the ATR's content.
LCP profile: x402/exact/eip155/permit2⁠ (opens in a new tab)
x402/upto/eip155/permit2Native FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The nonce of the EIP-3009 authorization, or of the Permit2 witness transfer, the payer signs.
What a payment through it proves: The payer signed a Permit2 witness transfer whose nonce is this ATR's hash, with the scheme's x402 proxy as spender and the payee in the witness. Permit2 verified the signature when the proxy executed the transfer, and the hash is in the settlement transaction's calldata as the Permit2 nonce; no event carries it. This does not show that amount, payee, asset or timing match the ATR's content. The amount settled is the facilitator's, at most the signed maximum.
LCP profile: x402/upto/eip155/permit2⁠ (opens in a new tab)
x402/auth-capture/eip155/eip3009Id-ReuseBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: The escrow payment’s salt, or a commitment over it with the receiver authorizer and policy, which the token authorization’s nonce commits to.
What a payment through it proves: The payer signed a token authorization whose nonce commits, through the escrow's PaymentInfo, to a salt that is this ATR's hash when unbound, or a commitment over it with the receiver authorizer and policy when bound. The token contract or Permit2 verified the signature when the escrow collected the payment, and the escrow's event carries the salt. A holder of the ATR can confirm the hash from the salt; the chain alone does not reveal it. This record covers that first collection; capture, void, refund and reclaim are the operator's and the payer's.
LCP profile: x402/auth-capture/eip155⁠ (opens in a new tab)
x402/auth-capture/eip155/permit2Id-ReuseBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: The escrow payment’s salt, or a commitment over it with the receiver authorizer and policy, which the token authorization’s nonce commits to.
What a payment through it proves: The payer signed a token authorization whose nonce commits, through the escrow's PaymentInfo, to a salt that is this ATR's hash when unbound, or a commitment over it with the receiver authorizer and policy when bound. The token contract or Permit2 verified the signature when the escrow collected the payment, and the escrow's event carries the salt. A holder of the ATR can confirm the hash from the salt; the chain alone does not reveal it. This record covers that first collection; capture, void, refund and reclaim are the operator's and the payer's.
LCP profile: x402/auth-capture/eip155⁠ (opens in a new tab)
x402/exact/eip155/erc7710-saltNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The salt of the redeemed leaf delegation; or, where the delegation signs no hash, the echoed extension only.
What a payment through it proves: The leaf delegation of the permission context redeemed for this payment, made through MetaMask's DelegationManager, carries this ATR's hash as its signed salt. The manager verified every delegation's signature when it redeemed them, and the leaf, with its salt, is in a RedeemedDelegation event in the settlement transaction. The leaf's signer is its delegator, which may be an account the paying account authorised rather than the paying account itself. This does not show that amount, payee, asset or timing match the ATR's content.
LCP profile: x402/exact/eip155/erc7710-salt⁠ (opens in a new tab)
x402/exact/eip155/erc7710HTTP-layer advisoryBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: HTTP-layer advisory (LCP §8.3.7)⁠ (opens in a new tab)
Where the ATR hash rides: The salt of the redeemed leaf delegation; or, where the delegation signs no hash, the echoed extension only.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The ATR was assembled, written to the seller's storage and linked in the challenge before approval, and the buyer's payment payload echoed this ATR's hash in the x402 legalContext extension. The buyer's delegation does not sign the hash, and the settlement transaction does not carry it.
x402/batch-settlement/eip155Native FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The channel’s salt.
What a payment through it proves: The payer signed a token authorization for a deposit into an x402 batch-settlement channel whose identifier, the EIP-712 hash of the channel's configuration, commits to this ATR's hash as the configuration's salt. The token contract or Permit2 verified that signature when the channel contract collected the deposit, and the hash is on chain as the salt in the channel's ChannelCreated event. Later requests in this channel were paid under this ATR by vouchers the seller did not meter; each voucher signs a commitment to this ATR's hash. This does not show that amount, payee, asset or timing match the ATR's content.
LCP profile: x402/batch-settlement/eip155⁠ (opens in a new tab)
mpp/session/evmNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The channel’s salt.
What a payment through it proves: The ATR's hash is in the MPP session challenge this channel opened under: its id is the hash in base64url with the challenge's position. The payer opened a payment channel whose salt is this ATR's hash, so the channel id, keccak256 over the payer, payee, token, salt, authorized signer, escrow and chain, commits to it. The payer signed that opening as an open call carrying the salt, an EIP-3009 authorization whose nonce is MPP's hash over the channel parameters and the salt, or a Permit2 transfer whose witness carries the salt, and the escrow and the token verified it on chain. The seller read that the opening transaction succeeded and moved the payer's deposit to the escrow. Where the payer sent the open call, the seller read that call: it is to the escrow, its salt is this ATR's hash, and its sender, payee, token and authorized signer give this channel id, so the payer is the account that signed it. Where the opening is an EIP-3009 authorization or a Permit2 transfer, the seller's server verified that the transaction created this channel. This does not show that amount, payee, asset or timing match the ATR's content. Later requests in this channel were paid under this ATR by vouchers the seller did not meter; each voucher signs a commitment to this ATR's hash.
LCP profile: mpp/session/evm-tempo⁠ (opens in a new tab)
mpp/charge/evm/authorizationId-ReuseBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: A nonce or salt derived from the MPP challenge id.
What a payment through it proves: The payer signed an EIP-3009 transfer authorization whose nonce is keccak256 of this challenge's id and realm, and the id is this ATR's hash in base64url with the challenge's position. The token contract verified the signature when it executed the transfer, and the nonce is on chain as the nonce topic of its AuthorizationUsed event. A holder of the ATR and the realm can confirm the hash from that nonce; the chain alone does not reveal it. This does not show that amount, payee, asset or timing match the ATR's content.
mpp/charge/evm/permit2Id-ReuseBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: A nonce or salt derived from the MPP challenge id.
What a payment through it proves: The payer signed a Permit2 transfer, single or batch, whose witness carries keccak256 of this challenge's id and realm, and the id is this ATR's hash in base64url with the challenge's position. Permit2 verified the signature when it executed the transfer; a batch's transfers all executed in that one call. The witness is in the settlement transaction's calldata only as a hash, and no event carries it. This does not show that amount, payee, asset, splits or timing match the ATR's content.
mpp/charge/usdc/evmId-ReuseBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: A nonce or salt derived from the MPP challenge id.
What a payment through it proves: The payer signed an EIP-3009 authorization whose nonce is keccak256 of the JCS of this challenge's id, realm and request hash, and the id is this ATR's hash in base64url with the challenge's position. The token contract verified the signature when it executed the transfer, and the nonce is on chain in its AuthorizationUsed event. A holder of the ATR, the realm and the request can confirm the hash; the chain alone does not reveal it. This does not show that amount, payee, asset or timing match the ATR's content.
mpp/charge/usdc/gatewayId-ReuseBuyer signs H: yesH on chain: noPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: A nonce or salt derived from the MPP challenge id.
What a payment through it proves: The payer signed a Circle Gateway burn intent whose TransferSpec salt is keccak256 of the JCS of this challenge's id and parameters, and the id is this ATR's hash in base64url with the challenge's position. Circle Gateway validated the signature. The salt travels inside the TransferSpec that the destination mint carries, and the Gateway Minter emits that TransferSpec's keccak256 hash; this record reads no chain, and settlement is the seller's report. This does not show that amount, payee, asset or timing match the ATR's content.
mpp/charge/evm/transactionOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
Where the ATR hash rides: The challenge only; the payment transaction carries nothing.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The payment is an ERC-20 transfer the buyer signed as a whole transaction (`transaction`), or broadcast itself and named by its hash (`hash`), answering a challenge whose id and opaque carry this ATR's hash. The payment transaction does not carry the hash; the seller's server bound the challenge, and the settlement transaction it reported succeeded and moved the token. This does not show that amount, payee, asset or timing match the ATR's content.
mpp/charge/evm/hashOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
Where the ATR hash rides: The challenge only; the payment transaction carries nothing.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The payment is an ERC-20 transfer the buyer signed as a whole transaction (`transaction`), or broadcast itself and named by its hash (`hash`), answering a challenge whose id and opaque carry this ATR's hash. The payment transaction does not carry the hash; the seller's server bound the challenge, and the settlement transaction it reported succeeded and moved the token. This does not show that amount, payee, asset or timing match the ATR's content.

Where a sentence names <network> and <transaction>, the pairing’s record fills them in: they name the agreement payment the buyer made first. Source: lcp docs: pairings reference⁠ (opens in a new tab) · Source: lcp docs: the agreement URL⁠ (opens in a new tab)

Reading the settlement

The package reads a payment’s settlement through a reader you supply: the endpoint, the credentials, the timeouts and the retries are yours. A reader that fails never makes a payment read as failed. Source: lcp docs: reading settlement⁠ (opens in a new tab)

Sources (1)

lcp docs: reading settlement⁠ (opens in a new tab)

The standard

Reader: EvmReader
Its calls: eth_getTransactionReceipt, eth_getBlockByNumber for the safe and finalized marks, eth_getTransactionByHash, eth_call at a block number
A settled read carries: the finality mark reached: latest, safe or finalized Source: lcp docs: reading settlement⁠ (opens in a new tab)

The code

Compiled against the published packages when the site is built.

From the chain alone: read the ATR hash back from a settled transfer, through your own node

src/snippets/recover.ts

// Anyone, from the chain alone: read the fingerprint back from a settled EIP-3009 transfer, through your own node.
import { isRefusal } from '@integraledger/lcp';
import type { Eip155, EvmReader, Hex } from '@integraledger/lcp/evm';
import { exactEip3009 } from '@integraledger/lcp/x402';

export async function fingerprintOf(network: Eip155, asset: Hex, transaction: Hex, reader: EvmReader) {
  const h = await exactEip3009.recover({ network, asset, transaction }, reader);
  return isRefusal(h) ? null : h; // compare it with the hash of the record you hold
}

The protocols that pay on it

lcp docs: rails⁠ (opens in a new tab)

The live demonstrations are not running on this site at the moment.