Appendix B: Pattern Illustrations

This appendix is informative. It illustrates how the patterns defined on the On-Chain Binding Patterns page may be realized in practice, in abstract terms. Concrete chain-specific instantiations are the province of the relevant chain operators, who are encouraged to publish authoritative profiles in their own documentation.

This appendix walks through each pattern with a structural shape, expected on-chain footprint, recovery semantics, and forward-indexing properties. The illustrations use abstract primitives (an indexed event topic, a signed challenge envelope, a hash derivation) rather than naming specific chains or contracts.

Native Field

A protocol-level field is carried unchanged through to the settlement transaction and emitted in an indexed event topic.

Structural shape. The seller advertises a value V derived from atrHash (either V = atrHash directly, or V = HMAC-SHA256(sellerKey, atrHash)[:N] for a fixed-width slot of N bytes). The advertised value rides in a proposal field the protocol treats as opaque, is carried through to the settlement transaction, and is emitted as an indexed topic in the resulting event.

On-chain footprint. No additional contracts. No additional transactions. Gas cost identical to the canonical settlement.

Recovery. An auditor reads the settlement transaction receipt, extracts the indexed topic, and recovers V. If V = atrHash directly, the binding is recovered. If V is a derivation, the auditor verifies a candidate atrHash by recomputing the derivation; full recovery requires either possession of the candidate or a published mapping from V back to atrHash.

Forward indexing. A log filter on the indexed topic returns every settlement bound to that atrHash (or to that derivation of it).

Overlay Contract

A seller-deployed contract wraps the canonical settlement and emits an LCP-specific event carrying atrHash as an indexed topic. The underlying settlement primitive is unchanged.

Structural shape. The seller deploys a contract whose entry point accepts the canonical settlement payload as an inner call. The contract executes the canonical settlement, then emits an event of the form:

event LcpPayment(
  address indexed buyer,
  address indexed seller,
  uint256 amount,
  bytes32 indexed atrHash
);

The buyer's authorization, the on-chain settlement primitive, and the verifier's logic remain canonical — only the entry point differs.

On-chain footprint. Per-payment gas overhead for the wrapping call and event emission. Per-chain deployment cost for the wrapper contract itself. Audit cost.

Recovery. An auditor queries the chain's logs filtered by the atrHash topic. The settlement transaction hash is the indexed event's transaction hash; the binding is recovered without any off-chain state.

Forward indexing. Log filter on the atrHash topic returns every payment bound to those terms.

Sidecar Attestation

A separate transaction or signed attestation binds atrHash to the settlement transaction hash. The settlement is fully canonical.

Structural shape. After settlement, the seller (or a trusted indexer) publishes an attestation:

{
  "buyer": "<buyer-id>",
  "seller": "<seller-id>",
  "settlementTxHash": "<hash>",
  "atrHash": "<hash>",
  "timestamp": "<iso8601>",
  "signature": "<seller-signature>"
}

The attestation is published to a queryable substrate — an attestation contract on a chain that supports them, a content-addressed publication mechanism, or a discoverable registry. The settlement transaction itself carries no LCP data.

On-chain footprint. Canonical settlement plus one attestation transaction per payment, or one batched attestation per N payments.

Recovery. Two-hop. The auditor takes the settlement transaction hash, queries the attestation indexer, retrieves the attestation, and reads atrHash. Recovery depends on the attestation being published; if the publishing party fails to publish, recovery requires that some other party have observed and mirrored the binding.

Forward indexing. A query against the attestation indexer filtered by atrHash returns every settlement bound to those terms.

Opaque Challenge Parameter

atrHash is committed to a signed challenge structure whose fields are cryptographically covered by the payment authorization signature, but the committed value itself is not transmitted on-chain.

Structural shape. The protocol defines a signed challenge envelope with an application-defined field that the protocol treats as opaque:

challenge = {
  "id": "<unique-id>",
  "realm": "<seller-domain>",
  "amount": "<value>",
  "expires": "<timestamp>",
  "opaque": "<atrHash>"
}
challengeMac = HMAC(serverKey, canonicalize(challenge))

The seller places atrHash in the opaque field. The buyer's authorization signature covers the MAC, so atrHash is cryptographically committed even though it never leaves the off-chain channel.

On-chain footprint. Canonical settlement only. No additional bytes on-chain.

Recovery. Not on-chain. The auditor obtains the original challenge from the seller (or a mirror) and verifies the MAC against the buyer's signature. The auditor sees that the opaque field carried atrHash, but only by inspecting the off-chain artifact.

Forward indexing. Not feasible from the ledger alone. An off-chain index over the seller's challenge store can support it.

Id-Reuse (Hashed Binding)

A protocol's required binding derivation is executed with atrHash as one of the inputs. The on-chain value is a hash that does not reveal atrHash, but a candidate value can be verified against the on-chain artifact.

Structural shape. Suppose the protocol requires an authorization nonce of the form nonce = H(id || realm). The seller chooses id = atrHash. The on-chain settlement therefore carries nonce = H(atrHash || realm).

On-chain footprint. Canonical settlement only.

Recovery. Not directly. An auditor with a candidate atrHash and the published realm (typically advertised in legal-context.json) recomputes H(atrHash || realm) and compares against the on-chain value. The comparison confirms or rejects the candidate.

Forward indexing. Not feasible by atrHash alone — the on-chain value is a hash mixing atrHash with other inputs.

Protocol Extension

A new scheme, method, or registered extension is added to the host protocol with atrHash-aware semantics built into its verification and settlement procedure.

Structural shape. A new method or scheme is defined (for example, with a name like lcp-{base-method}) and registered in the host protocol's extension registry. The method's verifier requires a atrHash field to be present and covered by the authorization signature. The method's canonical settlement emits an event carrying atrHash natively.

On-chain footprint. As specified by the registered extension. Typically zero overhead, since the binding is built into the canonical primitives of the new method.

Recovery. As specified; typically on-chain and zero-party.

Forward indexing. As specified; typically supported via the canonical event signature.

Tier. Tier B by definition. The pattern requires upstream registration before stock implementations of the host protocol accept the extended variant.

HTTP-Layer Advisory (No On-Chain Binding)

The deployment exposes atrHash only at the HTTP layer — in a request or response field, a custom header, or equivalent — without committing the value to the settlement transaction.

Structural shape. The seller's payment proposal includes the hash as advisory metadata:

HTTP/1.1 402 Payment Required
X-LCP-Hash: 0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
Content-Type: application/json

{ ... payment requirements ... }

The settlement transaction contains nothing identifying atrHash. The seller maintains a private mapping from settlement transaction hash to atrHash in its own records.

On-chain footprint. None. The binding is entirely off-chain.

Recovery. Not zero-party. An auditor must consult the seller's records, either through cooperation or via a mirror the seller has exposed.

Forward indexing. Not feasible from any ledger. Possible only via the seller's own index.

When appropriate. Low-stakes flows, internal tooling, or environments where the dispute forum accepts seller-maintained records. Deployments that need stronger evidence should pair this advisory metadata with one of the on-chain binding patterns above.