Protocol

MPP

Machine Payments Protocol

The MPP challenge’s id is the ATR hash itself, with a link to the ATR beside it; on many of MPP’s payment methods, the payer’s signature covers the ATR hash too. Source: lcp docs: MPP⁠ (opens in a new tab) · Source: lcp docs: pairings reference⁠ (opens in a new tab) The Agentic Transaction Record (ATR) is one record of exactly what was agreed, for one transaction. Its ATR hash, the ATR’s fingerprint, is the proof bound to the transaction: change one byte of the ATR and it no longer matches. Source: lcp docs: the ATR⁠ (opens in a new tab) · Source: lcp docs: the ATR hash⁠ (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.

lcp docs: MPP⁠ (opens in a new tab) · lcp docs: pairings reference⁠ (opens in a new tab) · lcp docs: the ATR⁠ (opens in a new tab) · lcp docs: the ATR hash⁠ (opens in a new tab) · LCP §C.1⁠ (opens in a new tab)

The protocol’s own site⁠

MPP

Payment in HTTP authentication

Every MPP challenge: Its id is the ATR hash itself, with a link to the ATR beside it.
XRP Ledger: The ATR hash itself, as the Payment’s InvoiceID the payer signs.
Tempo: The ATR hash itself, as a session channel’s salt or a subscription key authorization’s witness.

Run an agentic transaction over MPP now

A real transaction between Integra-managed agents on a test network, then its proof: the agreed terms, bound to the payment.

Loading the demonstrations…

These are real transactions between Integra-managed agents, using testnet funds. Transactions are settled at 1/10,000th of their stated value, for demonstration purposes.

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)

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 has the ATR hash as its id; on many payment methods, the payer’s signature covers it as well.

Exhibit Where it rides, in the protocol’s and the package’s terms

The standard

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)

The package

The ATR hash rides in the challenge, in two places: the challenge id is the ATR hash in base64url, then the challenge’s position, 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)

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 9 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.

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

Exhibit Each pairing’s record

The package

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.
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.
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.
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.
Pattern: Id-Reuse (LCP §8.3.5)⁠ (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 the attribution memo MPP's SDKs write, 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.
Pattern: Id-Reuse (LCP §8.3.5)⁠ (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 the attribution memo MPP's SDKs write, 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.
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, or a relayer sent the escrow's Permit2 opening, the seller read that call: it is to the escrow, its salt is this ATR's hash, and its payer, payee, token and authorized signer give this channel id, so the payer is the account that signed the call or, on Permit2, the transfer. This does not show that amount, payee, asset or timing match the ATR's content. Each voucher in this channel signs a commitment to this ATR's hash.
LCP profile: mpp/session/evm-tempo⁠ (opens in a new tab)
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. Each voucher in this channel signs a commitment to this ATR's hash.
LCP profile: mpp/session/evm-tempo⁠ (opens in a new tab)
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 token the payer's key authorization limits to the recipient it allows. This does not show that amount, period, payee, asset or timing match the ATR's content.
Pattern: native-field, the package’s name for it
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's BOLT11 invoice's description hash is this ATR's hash, and the ATR commits its payment hash. Its signature is not verified here, and the payer signed nothing that carries the hash. Settlement is the seller's report; the invoice and its preimage, which the parties hold, show that the invoice was paid; they do not show who paid it, and no public ledger shows the payment. This does not show that amount, payee or timing match the ATR's content.
LCP profile: mpp/charge⁠ (opens in a new tab)
Pattern: native-field, the package’s name for it
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's BOLT11 invoice's description hash is this ATR's hash, and the ATR commits its payment hash. Its signature is not verified here, and the payer signed nothing that carries the hash. Settlement is the seller's report; the invoice and its preimage, which the parties hold, show that the invoice was paid; they do not show who paid it, and no public ledger shows the payment. This does not show that amount, payee or timing match the ATR's content. The close is the seller's report.
LCP profile: mpp/charge⁠ (opens in a new tab)
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
What a payment through it proves: The ATR was assembled and delivered 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.
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 LCP-form 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)
Pattern: Native Field, truncated (LCP §B.1)⁠ (opens in a new tab)
What a payment through it proves: The ATR was assembled and delivered 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.
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.
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 server 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.
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. 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)
Pattern: Native Field, truncated (LCP §B.1)⁠ (opens in a new tab)
What a payment through it proves: The ATR was assembled and delivered 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. 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)
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. Vouchers in this channel sign 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)
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 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 nothing the buyer signed was checked. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash.
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 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 nothing the buyer signed was checked. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash.
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 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 nothing the buyer signed was checked. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash. The close is the seller's report.
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.
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 LCP-form 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)
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
What a payment through it proves: The payer signed a Stacks transaction calling a contract's `transfer` with this ATR's hash as its fourth (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 the contract is a SIP-010 token, or that amount, payee, asset or timing match the ATR's content.
LCP profile: mpp/charge/usdc/stacks⁠ (opens in a new tab)
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. The signature is not verified here. 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

Ready to see your own agreements proved?

Tell us what you sell, buy or carry, and we will show you where the agreement rides in it.

Integra Binder, hosted by Integra, does the seller’s side of each agreement and is free on test networks, with test-network USDC.

Talk to us