Linked Liability is the accountability layer for Z00Z flows that cannot depend on perfect online prevention. Offline payments, machine service rights, API budgets, aid vouchers, and agent spending envelopes may all be useful before every participant has seen the latest checkpoint. That creates a real fraud question: if the same private right is reused incompatibly, who pays, what is revealed, and how far should the consequence spread?

The answer is not a public account freeze. Z00Z does not want to turn every delayed flow into a reusable public identity or public reputation table. The answer is narrower: a right can carry a hidden responsibility lane from issuance, remain private in the honest case, and become attributable only when conflict proof shows that the lane was abused. Liability is therefore bound early, revealed late, and scoped to the affected domain.

The Normal Case

In the honest path, the liability machinery is present but dormant. A wallet, merchant, machine, or service checks the private right, validates the policy envelope it can see, and accepts a local transfer or service request. Later, the package enters checkpoint settlement. If no incompatible spend appears, the settlement lane stays ordinary. Observers learn only the public evidence required for replay-safe validity, not the hidden liability domain behind the right.

That hiddenness is not a decorative privacy feature. If honest use published a stable liability identifier, the protocol would recreate the account graph it is trying to avoid. The right may be economically backed by a bond or reserve, but honest counterparties do not need to see the full responsibility graph to accept a bounded right.

The Conflict Case

The conflict path is deliberately different. When two incompatible presentations, receipts, or settlement packages prove that the same hidden responsibility lane was reused, the system can extract a FraudProof. That proof should reveal only the minimum facts needed for enforcement:

• that the conflict exists;
• that the same liability domain backs the incompatible uses;
• which bond or reserve surface answers for the harm;
• which penalty and unlock policy applies.

The proof should not reveal unrelated wallet history, unrelated rights, or a permanent public user profile. This is the difference between liability and surveillance. Liability answers a proven conflict. Surveillance tracks ordinary use.

Core Objects

Linked Liability is easiest to reason about as a small object family rather than as a broad policy phrase.

This object split keeps the accountability model readable. A bond without proof becomes discretionary punishment. A proof without a bond becomes moral language. A lock without domain scoping becomes overreach. A domain without privacy becomes surveillance. All six pieces are needed for the design to stay both useful and bounded.

Bonds And Compensation

The economic logic is simple: cheating should cost more than the one-shot local gain. A low-risk capped offline lane may need a smaller bond than a high-risk autonomous machine lane, but every lane needs a credible answer to harm. The first job of a bond response is victim compensation up to the proven loss and policy cap. Deterrence and reserve routing come after that.

This ordering matters because Linked Liability is not punishment theater. A merchant, charger, gateway, or aid provider who accepted a bounded right locally needs a credible recovery path if the right was fraudulently reused. If the protocol only burns collateral without compensating harmed parties, it may deter some abuse but still leave local acceptance commercially weak.

Policy Boundary

Linked Liability also has a governance boundary. The base protocol can define proof structure, lock state, fail-closed behavior, and domain-scoped consequences. Wallets, issuers, service providers, and governance layers may add dispute UX, parameter choices, arbitration, support workflows, or additional legal overlays. Those additions are legitimate only if they do not redefine the core meaning of valid proof or widen a domain lock into a general user ban.

This is also where legal language matters. A linked-liability lane should not be described as a universal deanonymization tool, a public bad-actor list, or an operator-controlled recovery desk. The safer description is narrower: the protocol can support proof-triggered, domain-scoped accountability for rights that were designed to carry that accountability from the start.

Why It Is Not Ordinary Surveillance

Surveillance starts from continuous observation. Linked Liability starts from dormant commitment and activates under proof. Surveillance follows ordinary use. Linked Liability reveals only after misuse. Surveillance tends toward identity aggregation. Linked Liability should stay domain-scoped, right-scoped, and purpose-bound.

That distinction is especially important for the use cases that most need this mechanism. Offline cash, emergency resource vouchers, agent budgets, and machine-service rights are often privacy-sensitive precisely because public identity graphs are harmful. The accountability layer must therefore preserve honest-case privacy while still making abuse expensive.

Reader Checklist

A linked-liability design is on the right track when a reader can answer five questions without guessing. First, what exact right family carries the hidden responsibility lane? Second, what maximum local loss can one conflicting use create? Third, what bond or reserve answers for that loss, and who receives compensation before any penalty residue is routed elsewhere? Fourth, what evidence turns suspicion into a valid FraudProof? Fifth, what future rights are blocked while the domain is locked?

If any answer is missing, the page should not imply deployment readiness. Missing scope turns liability into overreach. Missing bond turns it into rhetoric. Missing proof turns it into operator discretion. Missing unlock rules can trap honest recovery. This checklist is intentionally practical because linked liability has value only when merchants, machines, agents, and wallets can reason about it before they accept delayed risk.

Current Versus Target Status

The architecture is clear enough for public explanation today. Z00Z already has the broader vocabulary of wallet-local possession, delayed reconciliation, checkpointed settlement, replay safety, and rights-based objects. The full FraudProof encoding, lock registry semantics, slashing automation, unlock proofs, and production compensation pipeline remain target architecture. Documentation should present them as intended components, not as already-final live consensus behavior.

Read Next

• Wallet-Local Possession explains why private possession remains local before settlement.
• Object Lifecycle shows how rights move from issuance to settlement and retirement.
• Proof Of Useful Work explains a related proof-first reward lane.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

• Linked Liability Whitepaper sections 2 through 10 define the protocol thesis, hidden domains, object model, normal-case execution, fraud activation, bond design, security properties, use cases, governance boundary, and implementation status.
• Legal Architecture Whitepaper sections 5 through 7, 10, 16, and 17 explain why treasury, contributor, liability, and public-claim surfaces must remain rule-bound rather than discretionary.
• Use Cases Whitepaper sections 4 through 9 ground the need for delayed settlement, external rights, vouchers, distribution programs, and machine or agent rights.