Protocol

MPP

Machine Payments Protocol

The MPP challenge itself carries the ATR hash: its id is derived from it, so whatever the payer signs over the challenge commits to it. Source: lcp docs: MPP⁠ (opens in a new tab)

MPP, the Machine Payments Protocol, is a Tempo Labs and Stripe project. Source: LCP §C.1⁠ (opens in a new tab) Integra is not affiliated; we read their published interfaces.

Sources (1)

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

The protocol’s own site⁠The standard’s illustration of this protocol (LCP §C.1)⁠

What it is

MPP carries payment in HTTP authentication: the seller answers with WWW-Authenticate: Payment challenges, each naming a method (such as evm, tempo, solana or stripe) and an intent (charge, session or subscription), and the buyer answers with a credential that echoes the challenge it pays. Source: lcp docs: MPP⁠ (opens in a new tab)

Its core scheme is an individual submission to the IETF, not a working-group document, with per-method specifications for Card, EVM, Hedera, Lightning, NEAR Intents, Solana, Stellar, Stripe, Tempo and USDC. Source: LCP §C.1⁠ (opens in a new tab)

Sources (2)

lcp docs: MPP⁠ (opens in a new tab) · LCP §C.1⁠ (opens in a new tab)

Where the ATR hash rides

The seller’s payment challenge is named after the ATR hash, so whatever the payer signs in answer commits to it.

The standard

The ATR hash rides in the challenge, in two places: the challenge id is derived from it, and the challenge’s opaque member carries it with the link to the ATR. Source: lcp docs: MPP⁠ (opens in a new tab)

Some methods also carry it in a member the payer signs: the Solana charge’s Memo instruction, the XRP Ledger Payment’s InvoiceID. Source: lcp docs: MPP⁠ (opens in a new tab)

MPP binds each challenge id to the challenge’s own parameters by whatever means the seller’s server chooses (the draft recommends an HMAC and does not require one). That binding lets the server detect a changed challenge; it proves nothing to a third party who lacks the server’s key or store. Source: LCP §C.1⁠ (opens in a new tab) · Source: LCP §8.3.4⁠ (opens in a new tab)

On MPP’s EVM charge the signed nonce is keccak256 of the challenge id and realm: an Id-Reuse binding, which verifies a candidate ATR hash, H, and does not recover it. Source: LCP §C.1⁠ (opens in a new tab) · Source: lcp docs: MPP⁠ (opens in a new tab)

On Tempo and Hedera, MPP’s attribution memo depends on H through 7 bytes only, and on Stellar the muxed id through 8: each pairing’s record says what that does and does not bind. Source: lcp docs: MPP⁠ (opens in a new tab)

What a payment through it proves

Each pairing’s record states what a payment through it shows, and what it does not, in the package’s own words. These are read from the package when the site is built. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Of these 26 pairings, 13 have the buyer’s signature cover the ATR hash, 18 leave a public proof of it, and 7 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.

Sources (1)

lcp docs: pairings reference⁠ (opens in a new tab)

The standard

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)
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)
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/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)
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)
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/tempo/memoOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: yesRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
What a payment through it proves: The ATR's hash is in the MPP challenge this payment answered: its id is the hash in base64url with the challenge's position, protected by the server's binding of the challenge. The payer signed a Tempo transaction whose transferWithMemo call carries MPP's attribution memo, whose 7-byte nonce is keccak256 of that id. The chain verified the signature when it executed the call, and the memo is on chain as the memo topic of the token's TransferWithMemo event. It ties the payment to the challenge instance, and binds this ATR's hash only through those 7 bytes: whoever assembles the ATR can construct a second ATR whose challenge id gives the same 7 bytes. This does not show that amount, payee, asset or timing match the ATR's content.
mpp/charge/tempo/pushOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: yesRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
What a payment through it proves: The ATR's hash is in the MPP challenge this payment answered: its id is the hash in base64url with the challenge's position, protected by the server's binding of the challenge. The payer signed and broadcast a Tempo transaction whose transferWithMemo call carries MPP's attribution memo, whose 7-byte nonce is keccak256 of that id. The chain verified the signature when it executed the call, and the memo is on chain as the memo topic of the token's TransferWithMemo event, read after the money had moved. It ties the payment to the challenge instance, and binds this ATR's hash only through those 7 bytes: whoever assembles the ATR can construct a second ATR whose challenge id gives the same 7 bytes. This does not show that amount, payee, asset or timing match the ATR's content.
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)
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/session/tempoNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
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 signed a Tempo transaction whose one call to the channel escrow opens a channel with this ATR's hash as its salt, and the chain verified that signature when it executed the call. The escrow's ChannelOpened event names the channel, whose id commits to the salt; on the TIP-1034 escrow the event also carries the salt itself. 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/subscription/tempoNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The ATR's hash is the MPP subscription challenge's id, in base64url. The payer's root key signed a Tempo key authorization whose witness is this ATR's hash, granting the seller's access key a per-period limit. The chain verified that signature when the activation transaction registered the key, and the account keychain's KeyAuthorizationWitness event carries the payer's account and this hash as topics. The same transaction transferred the first period's payment to the recipient. This does not show that amount, period, payee, asset or timing match the ATR's content. Later billing periods were paid under this ATR by renewal transfers the seller did not read.
mpp/charge/lightningNative FieldBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
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 seller's node signed a BOLT11 invoice whose description hash is this ATR's hash, and whose payment hash the ATR commits. The payer paid that invoice, and its node checked the node signature before paying. The payer signed nothing that carries the hash, and the seller did not verify the invoice signature. The invoice and its preimage, which the parties hold, are the proof of the payment. No public ledger shows it. This does not show that amount, payee or timing match the ATR's content.
LCP profile: mpp/charge⁠ (opens in a new tab)
mpp/session/lightningNative FieldBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
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 seller's node signed a BOLT11 invoice whose description hash is this ATR's hash, and whose payment hash the ATR commits. The payer paid that invoice, and its node checked the node signature before paying. The payer signed nothing that carries the hash, and the seller did not verify the invoice signature. The invoice and its preimage, which the parties hold, are the proof of the payment. No public ledger shows it. This does not show that amount, payee or timing match the ATR's content. Later requests in this session were paid under this ATR from its deposit, by bearer proofs the seller did not meter. The close is the seller's report.
LCP profile: mpp/charge⁠ (opens in a new tab)
mpp/charge/hederaOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: yesRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
What a payment through it proves: The ATR was assembled, written to the seller's storage and linked in the challenge before approval, and its hash is in the MPP challenge this payment answered, protected by the server's binding of the challenge, not by the payer's signature. The payer signed a memo whose 7-byte nonce is keccak256 of that challenge's id. It ties the payment to the challenge instance, and binds this ATR's hash only through those 7 bytes: whoever assembles the ATR can construct a second ATR whose challenge id gives the same 7 bytes. This does not show that amount, recipient, token or timing match the ATR's content.
mpp/charge/solanaNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed a Solana transaction whose one Memo instruction carries this ATR's hash in LCP string form, and the transaction executed without error, carrying a token or SOL transfer. The memo is in the transaction's instruction data on chain. This does not show that amount, recipient, mint or timing match the ATR's content.
LCP profile: mpp/charge/solana⁠ (opens in a new tab)
mpp/charge/stellarNative Field, truncatedBuyer signs H: noH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field, truncated (LCP §B.1)⁠ (opens in a new tab)
What a payment through it proves: The ATR was assembled, written to the seller's storage and linked in the challenge before approval, and its hash is in the payment challenge, which the payer did not sign. The payer signed a transfer to the seller's muxed address whose 8-byte id is the first 8 bytes of this ATR's hash, and the transaction succeeded. The id binds this hash only through its first 8 bytes: whoever assembles the ATR can construct a second ATR whose hash begins with the same 8 bytes. This does not show that amount, asset or timing match the ATR's content.
mpp/charge/xrplNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed, with a single key, an XRPL Payment whose InvoiceID is this ATR's hash, and the Payment is in a validated ledger with tesSUCCESS. This does not show that amount, destination, asset or timing match the ATR's content.
mpp/charge/nearintentsOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
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 seller's MPP challenge carried this ATR's hash in its externalId, bound by the seller's own key to a deposit address issued for that challenge only, and the seller reported delivery. The buyer's deposit does not carry the hash, and the buyer did not sign it. The NEAR Intents backend, not a contract the buyer signed, links the deposit to the seller.
mpp/session/hederaNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed a Hedera EVM transaction that opened an MPP session channel on the escrow contract named in the challenge, with this ATR's hash as the channel's salt, and it reached consensus. The escrow's ChannelOpened event carries the salt, and the channel id is keccak256 over an encoding that includes it. The hash is also in the MPP challenge the opening answered. Later requests in this channel were paid under this ATR by vouchers the seller did not meter. Each voucher signs that channel id, which commits to this ATR's hash. This does not show that amount, deposit, recipient, token or timing match the ATR's content.
LCP profile: mpp/session/hedera-solana-xrpl⁠ (opens in a new tab)
mpp/session/solanaNative Field, truncatedBuyer signs H: noH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field, truncated (LCP §B.1)⁠ (opens in a new tab)
What a payment through it proves: The ATR was assembled, written to the seller's storage and linked in the challenge before approval, and its hash is in the MPP challenge the opening answered, protected by the server's binding of the challenge. The payer signed a Solana transaction that opened a session channel on the channel program named in the challenge, with the first 8 bytes of this ATR's hash as the channel's salt, and it executed without error. The salt binds only this hash's first 8 bytes: whoever assembles the ATR can construct a second ATR whose hash shares them. Later requests in this channel were paid under this ATR by vouchers the seller did not meter. Where the operator signs the vouchers, each request also carried the payer's session proof, which signs the opening challenge's id and so this ATR's hash. This does not show that amount, deposit, recipient, mint or timing match the ATR's content.
LCP profile: mpp/session/hedera-solana-xrpl⁠ (opens in a new tab)
mpp/session/xrplNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed, with a single key, an XRPL PaymentChannelCreate whose one LCP memo carries this ATR's hash, and it is in a validated ledger with tesSUCCESS. The memo is in the public transaction. Later requests in this channel were paid under this ATR by vouchers the seller did not meter; each signs the channel id and an amount, not the hash. This does not show that amount, deposit, destination, settle delay or timing match the ATR's content.
LCP profile: mpp/session/hedera-solana-xrpl⁠ (opens in a new tab)
mpp/charge/cardOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
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 in the seller's storage before payment. The seller's MPP challenge carried this ATR's hash in its id and its opaque reference, bound to the challenge by the seller's own server, and the buyer's credential echoed that challenge. The seller also placed the hash in the method's reference field (externalId for card; the PaymentIntent's metadata for Stripe). Nothing the buyer or its card or Stripe token signed carries the hash, and the seller checked nothing the buyer signed. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash.
mpp/charge/stripeOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
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 in the seller's storage before payment. The seller's MPP challenge carried this ATR's hash in its id and its opaque reference, bound to the challenge by the seller's own server, and the buyer's credential echoed that challenge. The seller also placed the hash in the method's reference field (externalId for card; the PaymentIntent's metadata for Stripe). Nothing the buyer or its card or Stripe token signed carries the hash, and the seller checked nothing the buyer signed. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash.
mpp/subscription/stripeOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
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 in the seller's storage before payment. The seller's MPP challenge carried this ATR's hash in its id and its opaque reference, bound to the challenge by the seller's own server, and the buyer's credential echoed that challenge. The seller also placed the hash in the method's reference field (externalId for card; the PaymentIntent's metadata for Stripe). Nothing the buyer or its card or Stripe token signed carries the hash, and the seller checked nothing the buyer signed. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash. Later billing periods were paid under this ATR by renewal invoices the seller did not read. The close is the seller's report.
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)
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/solanaNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed a Solana transaction whose one Memo instruction carries this ATR's hash in LCP string form, and the transaction executed without error, carrying a token or SOL transfer. The memo is in the transaction's instruction data on chain. This does not show that amount, recipient, mint or timing match the ATR's content.
LCP profile: mpp/charge/solana⁠ (opens in a new tab)
mpp/charge/usdc/stacksNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed a Stacks transaction whose SIP-010 transfer carries this ATR's hash as its memo argument. The chain verified the signature, the transaction executed with status success, and the memo is in the mined transaction on chain. This does not show that amount, payee, asset or timing match the ATR's content.
LCP profile: mpp/charge/usdc/stacks⁠ (opens in a new tab)
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)
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.

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)

The rails it settles on

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