On-Chain Binding Patterns

Pattern vocabulary for binding a settlement transaction to the atrHash of the terms document — Native Field, Overlay Contract, Sidecar Attestation, Opaque Challenge, Id-Reuse, Protocol Extension.

This section is advisory.

LCP's Level 2+ evidence chain depends on a binding between a settlement transaction and the atrHash of the terms document. Different chains and protocols expose different mechanisms for carrying that binding. This page defines the pattern vocabulary in abstract terms; structural illustrations of each pattern are in Appendix B: Pattern Illustrations. Concrete chain-specific instantiations are the province of the relevant chain operators, who are encouraged to publish authoritative profiles in their own documentation.

Two Axes

Each pattern is characterized along two axes.

Wire compatibility — can the pattern be deployed against stock, unmodified protocol implementations?

Tier A — works today, no upstream coordination required.
Tier B — requires a coordinated change to the upstream specification (new fields, new covered headers, new mandate structures, new registered methods).

Adoption cost — what does a service (and the ecosystem around it) have to do to use the pattern?

Native Field — the binding rides in an existing protocol field the service already controls; no extra contract, no extra transaction.
Overlay Contract — the binding lives in a service-deployed contract that wraps or succeeds the canonical settlement call, emitting an indexed event.
Sidecar Attestation — the binding lives in a separate transaction or attestation anchored to the settlement transaction by reference.
Protocol Extension — a new scheme, method, or registered extension defines atrHash-aware semantics inside the host protocol.

Three Recovery Properties

Each pattern is evaluated against three recovery properties:

On-chain — is the binding visible on a public ledger?
Zero-party recoverable — can an auditor reconstruct atrHash from the settlement transaction hash alone, without trusting either party to produce records?
Forward-indexable — can an auditor enumerate all settlements bound to a given atrHash?

Native Field

The binding rides in a field the service controls in the canonical wire format, and that field is carried through to the settlement transaction.

Trade-offs:

Tier A where the protocol leaves the field's value unconstrained.
Off-canonical where the field is specified as client-chosen or as a deterministic derivation that excludes atrHash. In the off-canonical case the pattern works only within a controlled client ecosystem where the service can guarantee cooperating client behavior; it is not interoperable with stock implementations. Deployments using the off-canonical variant SHOULD publish a named LCP profile so third parties can opt in explicitly.
Zero deploy cost, zero extra gas, zero off-chain state.
Recovery properties depend on the field's on-chain visibility. Where the field is emitted in an indexed event topic, forward indexing is natively supported.

Overlay Contract

A service-deployed contract accepts the canonical settlement call as an inner operation and emits an LCP-specific event carrying atrHash as an indexed topic. The underlying settlement primitive is unchanged; the binding lives in the overlay event.

Trade-offs:

Tier A on the wire protocol — stock clients and verifiers see a spec-compliant settlement call.
Service-deployed per chain; requires audit and adds gas per payment.
On-chain, zero-party recoverable (an auditor reads the indexed topic from the receipt), forward-indexable (a log filter on the atrHash topic returns every payment bound to those terms).
Requires per-chain contract deployment and ongoing maintenance.

Sidecar Attestation

After settlement, the service or a third party publishes a separate attestation binding atrHash to the settlement transaction hash. The settlement itself is fully canonical.

Trade-offs:

Tier A — the settlement is untouched.
One extra transaction per payment (gas cost varies by rail).
Recovery is two-hop: settlement transaction hash → attestation lookup → atrHash.
Not zero-party in the strict sense — if the publishing party fails to publish, recovery depends on whoever else has observed and mirrored the binding.
Forward-indexable via the attestation indexer, not via the settlement ledger itself.

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.

Trade-offs:

Tier A where the host protocol defines an opaque parameter inside the signed envelope.
Cryptographic binding exists between the buyer signature and atrHash, but the commitment is visible only to parties who hold the original challenge.
Not on-chain. Not zero-party — auditors require access to the service's challenge store or a mirrored archive.
Appropriate where the dispute-resolution forum has subpoena power or direct access to service records, and on-chain visibility is not required.

Id-Reuse (Hashed Binding)

The protocol's required binding derivation is executed with atrHash as one of the inputs. The on-chain value is a hash that cannot be inverted, but a candidate atrHash plus the published other inputs can be verified against the on-chain value.

Trade-offs:

Tier A — fully spec-compliant, no new contracts, no client changes.
Provides a cryptographic commitment on-chain, but enables only verification of a candidate atrHash, not recovery.
Requires out-of-band publication of all inputs the auditor does not already have. Missing inputs are typically published via legal-context.json.
Not forward-indexable by atrHash alone — the on-chain value is a hash over atrHash and other inputs.

Protocol Extension

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

Trade-offs:

Tier B by definition.
Gives LCP first-class standing in the host protocol's extension registry, with interoperable semantics across implementations that adopt the extension.
Fragments adoption until upstream registration lands — stock implementations of the base protocol reject the extended variant.
Appropriate where the binding semantics are important enough to justify standardization cost, or as a forward path once a pattern has been proven via Tier A.

HTTP-Layer Advisory Reference

Not all LCP deployments need an on-chain binding. A deployment MAY expose atrHash purely at the HTTP layer — as a request or response field, a custom header, or equivalent protocol-specific carrier — without committing the value to the settlement transaction. The service maintains an off-chain mapping from settlement transaction to atrHash in its own records.

This is not one of the six patterns above — it is the no-binding baseline. It is:

Not on-chain.
Not zero-party recoverable (auditors require the service's records).
Not forward-indexable on any public ledger.
Trivial to deploy and compatible with every protocol.

Appropriate where the dispute forum accepts service-maintained records or where LCP adoption is informational only. Deployments that need stronger evidence should pair advisory HTTP metadata with one of the six on-chain binding patterns above.

How to Choose

The applicable patterns and the right choice depend on context:

Evidentiary posture. Where the dispute forum requires on-chain, zero-party, independently verifiable evidence (consumer-facing arbitration, cross-jurisdictional enforcement), only Native Field (where the rail provides one) and Overlay Contract qualify. Sidecar Attestation is adequate where the forum accepts a trusted indexer as a source. Opaque Challenge and Id-Reuse are adequate where the forum has direct access to service records.
Operational capacity. Services with contract-deployment and audit capacity can adopt Overlay Contract on chains that support it. Services without that capacity are limited to Native Field (where the protocol permits) or Opaque Challenge.
Rail coverage. Some rails expose a Native Field with full recovery properties; on those rails Overlay Contract is unnecessary. Other rails lack any Native Field path that survives spec-compliant verification — Id-Reuse gives an on-chain commitment but only verification of a candidate hash, and Opaque Challenge keeps the binding off-chain. Zero-party-recoverable on-chain binding on those rails therefore requires Overlay Contract or Sidecar Attestation.
Facilitator and client diversity. Strategies that require cooperating clients (off-canonical Native Field use) are fragile where the service does not control the client or facilitator stack. Overlay Contract and Sidecar Attestation are robust across facilitator and client choices because they operate outside the authorization-signature envelope.
Standardization horizon. Protocol Extension is a multi-month to multi-year path. Overlay Contract, Sidecar Attestation, and Native Field patterns ship immediately.

Chain operators and protocol stewards are invited to publish authoritative profiles describing concrete instantiations of these patterns on their own infrastructure; the standard does not endorse or canonize any particular profile.

On this page