Appendix B

The Coordination Substrate

18 min read

The problem is precisely how to extend the span of our utilization of resources beyond the span of the control of any one mind.
— Friedrich Hayek, 'The Use of Knowledge in Society' (1945)

The mathematics is one thing. Whether its assumptions hold is another. A derivation can be internally consistent and empirically wrong. Whether the premises obtain in practice is addressed here for each major component: the operator-specific outside option, the bonding mechanism, the attestation infrastructure, secured-capital curves, and assurance pricing.

Readers who accept the mathematics but doubt its applicability should find their objections anticipated. Readers who reject specific premises should be able to identify exactly where the framework would break.

B.1 — When a Mining Outside Option Matters

Appendix A.1 defines a site- and operator-specific outside option. The question is whether Bitcoin mining belongs to the accessible opportunity set $\Omega_s$ for the operator being studied.

Hardware specificity. Competitive Bitcoin mining uses SHA-256 ASICs. Frontier inference ordinarily uses GPUs or other inference accelerators. The hardware is not interchangeable. A comparison may still matter at a power-development margin—whether a site installs miners, inference hardware, storage, or another load—but that is a capital-allocation comparison, not instantaneous workload switching.

Site and grid specificity. Electricity cannot be moved without transmission, interconnection, congestion, and loss. Mining at one site does not establish a return available to an inference operator elsewhere. The relevant comparison uses the same constrained resource, location, financing access, and decision maker.

Capital and contract specificity. Mining requires hardware, facilities, pool access, working capital, and operating competence. Buying BTC requires market and custody access. Selling power or curtailment services requires contracts. Each alternative carries different risks and switching costs.

Time specificity. Network difficulty, fees, BTC price, energy price, curtailment value, and hardware efficiency change. The outside option is a dated observation or model input, not a permanent constant.

Measurement rule. An empirical comparison should publish:

the operator and site,
the constrained input,
the accessible alternatives,
hardware, interconnection, financing, and switching assumptions,
gross revenue, full cost, and risk adjustments separately,
the accounting unit and as-of date.

Falsifier. A mining-linked outside option does not discipline the target workload when measured target returns remain independent of that outside option after the named frictions and opportunity set are modeled. The narrower conclusion may still hold for another operator or site.

B.2 — When Collateralized Bonding Is Useful

Appendix A.3 separates deterrence from restitution. The relevant constraint is enforceable consequence, not a universal absence of identity.

A runtime may be operated by a corporation, principal, platform, or regulated intermediary with legal identity and attachable assets. Another runtime may operate under a persistent hardware identity, a closed platform account, or a reputation system with valuable future rents. A third may have no reachable principal at all. The enforcement profile must be stated rather than inferred from the word “agent.”

Three candidate enforcement channels exist in human commerce:

Law. Works when counterparties have legal identity and attachable assets. Courts can compel performance, award damages, and seize property. The mechanism requires persistent identity, jurisdictional reach, and the infrastructure of civil procedure. An unbound software runtime lacks legal standing; a runtime acting through a corporation, trust, registered individual, or another recognized principal can inherit bounded authority and expose that principal to consequence. The enforcement question is therefore whether the particular runtime is validly bound to a reachable principal.

Reputation. Works when identity is persistent and expensive to discard, and when the discounted value of future rents exceeds the one-shot gain from defection. An unbound, disposable runtime can be copied or reinstantiated cheaply, which weakens continuity. A runtime tied to a costly platform account, hardware identity, license, deposit, customer base, or reachable principal may possess valuable future rents. Persistence, attribution, transferability, and exit cost must be measured for the deployed identity rather than inferred from software copyability.

Reputation can contribute where a sybil-resistant identity or institutional wrapper makes identity expensive to replace and losses difficult to externalize. Its strength is deployment-specific and does not follow from the model or runtime name alone.

Force. Applies to people, facilities, accounts, hardware, keys, and other coercible surfaces around a runtime. A disposable runtime has no body of its own, but its operator, infrastructure, and reachable assets may remain exposed. The profile must identify those surfaces rather than treating either their existence or absence as universal.

Collateralized bonding is one useful profile when coordination must proceed without adequate post hoc recovery. It can pre-position value and make a limited consequence executable under declared conditions. It does not remove trust in the predicate, evidence, keys, custody, forum, priority, or settlement path. It does not make defection unprofitable unless the detection, authorization, collection, and future-rent terms satisfy the incentive condition in Appendix A.3.

Other profiles include legal guarantees, bank escrow, internal reserves, insurance, platform holdbacks, hardware-rooted controls, and combinations of these. Each profile exposes different dependencies.

Boundary conditions. Overcollateralized bonding is not necessary if:

Agents operate exclusively through entities with legal personhood and balance sheets (a "firm-first" agent economy where every runtime is a subsidiary)
A widely adopted, sybil-resistant identity layer emerges and becomes practically unavoidable, allowing reputation to substitute for collateral
Hardware-rooted identity plus remote attestation becomes ubiquitous and binding to settlement, so "invocation" is no longer cheap to discard

Each condition can reduce the amount or form of collateral required. The empirical task is to measure which enforcement channels are actually reachable, how much loss each covers, and whether they remain available under stress.

B.3 — The Attestation Architecture

Every enforcement mechanism in the framework depends on accurate attestation of state transitions. The bonding covenants in A.3 release or slash based on oracle reports. The term structure in A.4 requires price feeds. Agent-CAPM in A.5 requires verified performance data. Attestation is not a peripheral concern. It is the infrastructure on which everything else rests.

If attestation fails, if oracles are unreliable, corrupt, or capturable—the enforcement mechanism collapses. Collateral does not enforce if the covenant cannot determine whether performance occurred. A term structure based on manipulated price feeds is worse than no term structure at all. The framework's viability depends on attestation reliability exceeding some threshold. The question is what that requires.

The structure of credible attestation. An attestation is credible when the attester has more to lose from false reporting than to gain. This can be achieved through several mechanisms:

Skin in the game. The attester posts a bond that may be slashed after a proven false attestation. Nominal bond size alone is insufficient. Expected collectible penalty plus forfeited future rents must exceed the gain from false reporting, which requires adequate detection, authorized adjudication, collection, and identity persistence.

Reputation with exit barriers. If the attester cannot easily exit and reconstitute under a new identity, accumulated reputation becomes a hostage. This requires the same sybil-resistance that agent identity lacks. Attesters may need to be entities with persistent legal standing even when agents are not.

Cryptographic proofs. For deterministic computations, zero-knowledge proofs or verifiable computation can establish that an output follows from committed inputs and a committed program. The proof does not establish that the inputs correspond to the world, that the program encodes the right predicate, or that the named authority adopted the predicate.

Multi-oracle consensus. When no single attester is fully trusted, requiring agreement among multiple independent attesters raises the bar for manipulation. An attacker must corrupt a threshold rather than a single point.

Attack surfaces. The attestation layer faces specific attacks:

Collusion. If the agent and oracle are controlled by the same party, they can coordinate false reports to extract collateral from counterparties. Mitigation requires oracle independence: separation of control, rotation, or random selection.

Bribery. Even separately controlled oracles can be bribed. The relevant comparison is the expected collectible penalty and lost future rents against the bribe and other gains, not the nominal bond alone.

Front-running. If the oracle's report is observable before settlement, parties can trade on the information. This may not corrupt the attestation but can redistribute value in ways that undermine market integrity.

Manipulation of inputs. The oracle reports what it observes. If observations are manipulable (price feeds on thin markets, sensor data on compromised hardware), the attestation faithfully reports a corrupted reality.

The recursive problem. If attesters must be bonded, who attests to the attester's performance? The regress has to terminate somewhere. Three candidate termination points exist, each with structural weaknesses.

Legal identity. The regress terminates at a layer of attesters with legal personhood and attachable assets. Courts can reach them. This is the most mature option: traditional auditing firms, regulated custodians, licensed professionals. The weakness is jurisdictional. Attestation disputes that cross borders require choice-of-law provisions, international enforcement, and months or years of litigation. For high-frequency, low-value attestations, legal recourse is too slow and expensive to be credible. For cross-jurisdictional agent activity, no court has uncontested reach. Legal termination works for the subset of attestations that occur within a single jurisdiction, involve high enough stakes to justify legal cost, and can wait for judicial resolution. The rest requires something else.

Hardware-rooted trust. The regress terminates at trusted execution environments (TEEs) that cannot lie about their computation. Intel SGX, AMD SEV, ARM TrustZone: hardware enclaves that attest to their own code and state. The weakness is the supply chain. Who certifies the certifiers of the silicon? The hardware manufacturer could insert backdoors. The firmware could be compromised. The attestation key could be extracted. Each layer of the stack introduces parties who must be trusted: foundry, packaging, firmware authors, key ceremony operators. Hardware trust does not eliminate trust. It concentrates it in semiconductor supply chains rather than in attestation service providers. For applications where the threat model excludes nation-state adversaries with fab access, hardware trust may suffice. For applications where it does not, the termination point is insufficient.

Social consensus. The regress terminates at a community of verifiers whose collective judgment is the final word. This is how Bitcoin itself terminates its consensus regress: full nodes run by thousands of independent operators, any of whom can reject invalid blocks. The weakness is the apparent tension with B.2's claim that reputation does not work for agents. The tension is real but resolvable. Social consensus can work as an attestation backstop precisely because the attesters are not agents. They are humans or human-controlled institutions with persistent identity, reputational stake, and legal exposure. The community that validates attestations need not be composed of stateless runtimes. It can be composed of entities for whom reputation does function. The cost is that this layer operates at human speed, not machine speed. Social consensus is suitable for low-frequency, high-stakes attestations (quarterly audits, dispute resolution, protocol upgrades) but cannot clear the volume of attestations that high-frequency agent commerce would require. It is a court of last resort, not a transaction processor.

The framework does not resolve the recursive problem. It flags that some termination point is required, that no termination point is fully satisfactory, and that practical systems will likely employ all three in combination: hardware trust for the high-frequency layer, legal identity for the medium-stakes layer, and social consensus as the ultimate backstop.

Deterministic versus subjective attestation. The attestation problem varies by claim type:

Deterministic claims can often be verified by recomputation after the inputs, program, environment, and predicate are fixed. “Does this hash match?” is narrow and direct. “Did this code compile?” also depends on the committed compiler and environment. “Did this transaction confirm before this block height?” depends on the accepted chain checkpoint. Recomputation reduces an attestation dependency. It does not establish occurrence or input provenance by itself.

Subjective claims cannot be verified by recomputation. "Did the agent provide satisfactory service?" "Was the medical recommendation appropriate?" "Is this content harmful?" These require human judgment or AI evaluation that is itself contestable. The oracle problem for subjective claims remains open.

The framework's enforcement mechanisms are most mechanically tractable for closed deterministic predicates. Subjective claims require appraisal, challenge, and forum transitions rather than an automatic reclassification as deterministic proxies.

The attestation problem as V/C problem. The recursive attestation regress described above appears intractable when stated as a monolithic problem: who verifies the verifier? The framework's own central concept provides the organizing principle that decomposes it. The V/C ratio—the ratio of value at stake to the cost of credible verification—varies by claim type, and the appropriate attestation architecture varies with it.

For closed deterministic claims, marginal recomputation cost may be low relative to value. That does not make the V/C ratio infinite, and it does not eliminate provenance, occurrence, authority, or coverage costs. The program and committed inputs may be self-checking while the connection to a real event remains external.

For observable-but-contestable claims—component quality within specification, delivery within a time window, sensor readings within tolerance—verification cost is moderate and V/C is in the range where bonded attestation with optimistic resolution operates. The UMA and Kleros pattern applies: the attester posts a bond, attestations are assumed correct unless challenged, and challengers must also post bonds. The economics work when the cost of a challenge is lower than the value at risk but high enough to deter frivolous disputes.

For subjective claims—service satisfaction, medical appropriateness, content quality—verification cost is high, V/C is low, and the attestation problem reduces to the same liability-sink structures identified elsewhere in the framework. Human judgment is the terminal oracle, and the cost of that judgment is the irreducible floor on verification. These claims cannot be made cheaply credible. They can only be made credible at a price that scales with consequence.

The regress terminates, then, not at a single backstop but at a graduated architecture. Each claim type receives the attestation mechanism its V/C ratio warrants. The decomposition reduces the monolithic oracle problem to a set of domain-specific engineering problems at different maturity stages: some already solved, some solvable with existing mechanisms, and some requiring the human-in-the-loop structures that the framework predicts will persist as liability sinks.

The prior question: semantic agreement. The entire attestation architecture presupposes that agents can determine whether their claims are about the same things, that when Agent A reports "delivery completed" and Agent B reports "delivery not received," the disagreement is factual rather than terminological. In practice, agents with heterogeneous representations (different schemas, different evaluation criteria, different scoping of terms) may disagree not because one is lying but because they are not talking about the same object under the same conditions. A diagnostic that determines whether agreement is structurally possible given the agents' overlap structure — and that produces a verifiable certificate when it is not — sits beneath the attestation layer in the architecture. One candidate for this diagnostic is the SHEAF protocol, which examines pairwise overlaps and returns a verdict: agreement achievable, agreement structurally impossible (with certificate), or configuration too complex for exact determination. When impossibility is certified, the diagnostic can price the infrastructure corrections (additional shared contexts, relaxed equivalence standards) that would make agreement feasible. The attestation architecture described above assumes semantic agreement as a precondition; a protocol like SHEAF would make that precondition inspectable rather than assumed. Whether SHEAF specifically or some alternative diagnostic fills this role is an open engineering question; that some such diagnostic is needed is a structural requirement of the architecture.

Threshold requirements. The framework functions if attestation error rates stay below some threshold. The threshold depends on the application:

For high-value, low-frequency commitments (infrastructure finance), even 1% error may be intolerable
For low-value, high-frequency commitments (micro-payments for API calls), 5% error may be acceptable if the expected value remains positive

A pricing model may incorporate attestation error, detection, challenge, collection, and tail loss as separate charges. Appendix A.5 treats a covariance model as conjectural. No observed market yet establishes that a single spread absorbs these dimensions.

Falsifier. The attestation architecture fails if:

Oracle collusion or bribery becomes endemic (more than 10% of high-value attestations corrupted)
No credible termination point emerges for the attestation regress (every proposed backstop is demonstrated vulnerable)
Attestation costs remain high enough that only high-value transactions can bear them (the long tail of small transactions cannot be economically verified)

B.4 — Bootstrapping Secured-Capital Curves

Appendix A.4 shows that a discount curve can be extracted from comparable traded claims. It does not show that a liquid Bitcoin curve will emerge or that coordination requires one.

The bootstrap problem is institutional. Issuers must define comparable claims. Capital providers must accept custody and liquidation arrangements. Market makers must quote both sides. A publisher must disclose methodology, conflicts, venue coverage, and fallback rules. Different custody, priority, and legal terms may justify several curves rather than one.

A possible sequence:

Short-duration secured quotes become observable.
One or more balance sheets publish comparable rates and transaction terms.
Independent publishers normalize the rail-specific conditions rather than hiding them inside one number.
Adjacent maturities become liquid enough for basis and carry trades to test consistency.

Failure modes:

persistent venue, custody, priority, or jurisdictional segmentation,
thin trading that makes published points indicative rather than executable,
benchmark administration captured by a conflicted balance sheet,
fallback rules that silently substitute incomparable observations,
a curve treated as “risk-free” despite material custody, key, counterparty, or legal exposure.

The collateral gap. Some operators may need a third party to post capital on behalf of a service configuration. That party is a guarantor or capital provider, not proof that every runtime lacks a principal or balance sheet.

Specification underwriting. Underwriting may use model, tool, policy, evidence, coverage, incident, recovery, and correction histories. These inputs are not all deterministic and the outcomes are not all machine-verifiable. A configuration with no observed failures may have inadequate exposure or detection. Pricing requires denominators, independently meaningful loss events, collection outcomes, and semantic and authority epochs.

Rate publication. A capital provider can publish its own assurance charges by tenor. Those rates may become one reference curve if other participants find the methodology portable. Publication does not confer neutrality or benchmark status by itself.

B.5 — Assurance Pricing in Practice

Appendix A.5 places expected loss and tail risk before Agent-CAPM. Operational pricing therefore begins with a structured assurance record, not a universal beta.

Inputs an underwriter needs:

exact promise, exposure, and maximum covered loss,
predicate and evidence policy,
occurrence and coverage records,
challenge, forum, and settlement authority,
collateral amount, allocation, priority, custody, and collectibility,
observed incidents, findings, attempted settlements, recoveries, and corrections,
liquidity and correlation stress assumptions,
a named funding or lock-opportunity-cost curve.

Capital cost may dominate compute cost for some long-duration, highly collateralized promises. Compute may dominate for short, expensive workloads. Adjudication or expected loss may dominate elsewhere. The ordering is empirical and cannot be fixed in advance.

What must be measured:

exposure time and amount,
detected and estimated-undetected failure,
severity, challenge, authorization, collection, and recovery,
collateral availability under stress,
common-cause and counterparty correlation,
custody, liquidity, and legal loss,
parameter stability across semantic and authority epochs.

An Agent-CAPM covariance term is a conjectural supplement. It earns operational standing only if it improves out-of-sample pricing after jump, liquidity, custody, adjudication, and collection risks are modeled.

Falsifier. The underwriting model fails if it systematically admits inadequately collateralized promises, understates tail loss, cannot reproduce recovery outcomes, or changes materially when economically equivalent settlement adapters are substituted.

The mathematical machinery in Appendix A operates on assumptions that this appendix has made explicit:

Section	Core Assumption	Failure Mode
B.1	A named operator can access the modeled outside option	Hardware, site, capital, or contract mismatch
B.2	The selected enforcement channels impose collectible consequence	Weak detection, authority, priority, collection, or identity persistence
B.3	Attestation is accurate above threshold	Collusion, bribery, or input manipulation becomes endemic
B.4	Comparable traded claims support a useful curve	Segmentation, thin liquidity, or conflicted administration
B.5	Exposure, loss, recovery, and tail risk are measurable	Missing denominators, unstable epochs, or unavailable collection data

The framework does not require all assumptions to hold perfectly. It requires them to hold well enough that the mechanisms function. "Well enough" is an empirical question that the markets themselves will answer.

One assumption the table does not capture is semantic: the coordination substrate presupposes that agents can determine whether their local claims compose into globally consistent agreements. Section B.3 identifies this as the prior question that the attestation architecture presupposes and describes one candidate diagnostic (the SHEAF protocol) that could make the precondition inspectable. The coordination substrate's argument does not depend on SHEAF specifically but on the existence of some mechanism with these properties.

If the framework is wrong, it will fail in specific ways that trace back to specific premises. The traces should now be visible.