Introduction

An agent that pays a seller should know what it is agreeing to. Under the Legal Context Protocol (LCP), the seller publishes the agreement's record, an Agentic Transaction Record (ATR), and advertises its SHA-256, the ATR hash (H), beside the payment request. Where the payment the agent approves carries H, that approval is the buyer's acceptance of that exact record; where it does not, the pairing's statement of what it proves says so.

The packages documented here are the buyer's side of that pattern. Their centre is the buyer gate, which, before your wallet signs anything:

1. fetches the ATR from the seller's https link, once and within bounds;
2. computes SHA-256 over the exact bytes it received and compares it with H;
3. only on a match, builds the payment with that hash and hands it to your signer;
4. reads H back from the completed payment, and returns the payment only if it is the hash of those bytes, or, where the proof is the agreement payment, without that reading.

It works across x402, MPP, card, AP2, UCP, ACP and ACK payments, on EVM chains, Tempo, Solana, Stellar, the XRP Ledger, Hedera, Algorand, Aptos, Sui, NEAR, Starknet, Polkadot, TRON, TON, Cardano, Casper, Concordium, Stacks and Lightning. It holds no keys, reads none of the record's content, and carries no business or legal logic.

The packagesCopy Anchor Link

The TypeScript and Python gates are two implementations of the same rules. They run the same shared vectors and build the same payments.

Where to startCopy Anchor Link

• Getting started: a payment in TypeScript and in Python, and the gate refusing a record that changed by one byte.
• Concepts: the record, the hash, pairings, bindings, and what the gate does not do.
• Pay with the gate: transact, and confirm then finish for a signer that lives elsewhere.
• MCP server: give an agent the gate as tools.
• Pairings: every protocol and rail the gate pays, and what each payment proves.