§22. Layer 6 – Governance & Telemetry

Jason St George. "§22. Layer 6 – Governance & Telemetry" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/read/part-v/22-layer-6/

§22. Layer 6 – Governance & Telemetry

Layer 6 is the control plane and the nervous system of the stack.

Everything below it—hardware, comms, distribution, identity, proofs, settlement—can drift, centralize, or quietly break without anyone noticing until it’s too late. Layer 6 is the layer that refuses to let that drift remain invisible. It insists that:

• neutrality (no favored flows, no hidden house edge),
• repression‑resilience (still works under capital controls and censorship), and
• verification economics (VerifyPrice, VerifyReach, VerifySettle)

are service‑level objectives (SLOs), not marketing copy.

22.1 “No dashboards, no trust”: public SLOs as constitution

Most protocols ship documents called “constitutions.” In practice, the real constitution is whatever you cannot silently violate without getting caught.

For this stack, the constitution is:

• a set of SLOs on triad capacity and neutrality, plus
• a set of dashboards and receipts that make violations obvious.

Examples:

• “p95 VerifyPrice for canonical workloads W₁…Wₙ stays below T seconds on commodity hardware.”
• “Top‑N prover/LP/router share remains below X% by hashpower/FLOPs/liquidity.”
• “BTC↔ZEC/XMR corridors achieve ≥95% success with 100% refund safety and anonymity‑set ≥ A.”
• “At least K distinct jurisdictions and hardware profiles are actively verifying proofs and processing settlements.”

These are not just operational goals; they are the monetary invariants:

• If VerifyPrice creeps up, proofs stop being cheap to verify, and Proofs/Compute stop being monetary primitives.
• If corridors die or anonymity sets collapse, Privacy stops being a monetary primitive.
• If concentration spikes, neutrality and permissionlessness degrade into “trust the cartel.”

Layer 6’s first job is to publish and maintain these SLOs as public contracts, and to treat “no dashboards” as equivalent to “no guarantees.” A protocol with no public telemetry on VerifyPrice, VerifyReach, VerifySettle, decentralization, and hardware profiles simply does not qualify as “next‑gen store of value” in this frame.

22.2 Control surfaces: parameters, upgrades, emergency powers

The second job of Layer 6 is to define the control surfaces: the knobs that can be turned, by whom, and with what receipts.

At a minimum, those surfaces include:

• Economic parameters

  • Block reward curves and Work Credit issuance schedules.
  • Fee policies (floor, burn, split between security and dividends).
  • PoUW weighting across workloads (which canonical workloads get what share of rewards).

• Technical parameters

  • Circuit versions and proof‑system parameters.
  • Accepted hardware profiles (additions, deprecations).
  • Corridor policies (timelocks, refund windows, anonymity thresholds).

• Operational parameters

  • Telemetry granularity and reporting requirements.
  • Incident severity levels and response playbooks.
  • Key ceremonies, quorum sizes for specific actions.

Then, for each surface, Layer 6 specifies:

1. Who can propose a change?

   • On‑chain governance, foundation board, lab steering committee, or a combination.

2. Who can ratify it?

   • Token holders, node operators, Work‑Credit stakers, or an external council.

3. What data must be presented?

   • VerifyPrice deltas, decentralization impacts, corridor health projections, legal risk assessments.

4. What delay and rollback mechanisms exist?

   • Minimum notice periods, timelocked changes, emergency vetoes, and explicit rollback procedures.

5. Which changes are “emergency powers”?

   • For example: deprecating a compromised proof system; halting a bridge; freezing a specific workload type.
   • For these, the bar is higher: multi‑party sign‑off, auto‑expire, and mandatory post‑mortems.

The design goal is predictable, auditable governance:

• You can’t quietly bias PoUW towards your own accelerator.
• You can’t silently disable a corridor.
• You can’t change issuance rules without leaving a trail of receipts, votes, and telemetry.

Layer 6 does not dictate a single governance form, but whatever form exists must flow through these control surfaces with receipts attached.

22.3 Bell‑Labs‑style R&D vs on‑chain governance vs off‑chain norms

There are three governance “forces” that need to be reconciled:

1. Bell‑Labs‑style R&D.

   • The stack is explicitly framed as a “Bell Labs for Privacy, Proofs, and Compute.”
   • That requires a research org with autonomy to explore new circuits, proof systems, hardware profiles, and corridor designs.
   • It will propose upgrades, publish benchmarks, and maintain reference implementations.

2. On‑chain governance.

   • Token‑ or Work‑Credit‑weighted voting, parameter changes baked into protocol logic, upgrade paths controlled by smart contracts.
   • Good at encoding predictable mechanics and preventing arbitrary admin moves.
   • Bad at subtle technical decisions and fast incident response if over‑used.

3. Off‑chain norms and institutions.

   • Foundations, labs, dev collectives, and community norms.
   • Good at ambiguous trade‑offs (“is this proof system mature enough?”).
   • Vulnerable to capture, politics, and selective listening.

Layer 6’s thesis is not “pick one.” It is:

Use Bell‑Labs‑style R&D to discover, on‑chain governance to ratify and constrain, and off‑chain norms to fill the gaps — but keep all three under telemetry.

Concretely:

• The R&D lab:

  • Maintains public roadmaps and risk registers.
  • Publishes upgrade proposals with quantified impacts on VerifyPrice, VerifyReach, VerifySettle, decentralization, and hardware profiles.
  • Runs testnets and shadow deployments.

• On‑chain governance:

  • Controls scarce resources: issuance, reward splits, canonical workloads, acceptance/deprecation of proof systems and hardware profiles.
  • Is bounded by constitutional SLOs: certain changes are simply not allowed if they push metrics beyond thresholds unless higher‑order safety processes trigger.

• Off‑chain institutions:

  • Operate under public charters that explicitly state their mandate and constraints.
  • Are expected to publish minutes, risk assessments, and incident reports.

This three‑body system is inherently unstable; Layer 6 keeps it from drifting into pure plutocracy or pure priesthood by insisting that all three bodies are visible in telemetry:

• Changes in code and parameters appear on‑chain.
• Lab work appears in open repos and benchmarks.
• Institutional decisions appear in charters, public calls, and reports.

No dark corners; no “just trust us, we’re the stewards.”

22.4 Governance as SLOs (North Star & Invariants)

Governance and operations exist to keep one invariant true under stress:

Pay the machine only for work anyone can verify cheaply — and give humans lawful privacy by default.

Everything below—roles, metrics, runbooks, and legal posture—turns that sentence into procedures, with receipts. Where policy pressure rises, we default to measurement and non-custodial design rather than new gatekeepers. “No dashboards, no trust” is not a slogan; it is the rule for deciding when the system is still safe to treat as money.

So far the story has been mostly about what the stack does: verifiable machines, privacy rails, proof factories, compute markets, and the Create → Prove → Settle → Verify loop that turns them into monetary primitives. Governance and operations are about what happens when the world pushes back. They are the difference between a beautiful mechanism that works in a friendly lab and an actual monetary substrate that survives YCC (yield-curve control), capital controls, app-store bans, and “secure enclave” mandates.

We can summarize the protocol’s “constitution” as five invariants:

1. Verification asymmetry.

   For each canonical workload W, verification stays much cheaper than production. Formally, the verification overhead

   ( r(W) = v(W)/p(W) )

   remains at or below a published bound (e.g. 0.3, with a stretch goal of 0.1), and this is reported via VerifyPrice(W) on the Proof & Compute Board. If r(W) drifts up or p95 verify times blow past targets, the economic hinge of the triad fails; this is a Sev-1 condition.

2. Open admission.

   Anyone who brings correct work clears. Admission is not gated by identity, licensing, or proprietary hardware. Routers are neutral and open-source; house share and time-to-first-fill for new provers/LPs are visible on the Neutrality & Admission Board. If honest new entrants cannot join and get paid within a bounded window, decentralization is already drifting.

3. Useful-work security budget.

   Block rewards and fees underwrite useful work—MatMul-PoUW, verified inference, provenance and settlement proofs—under explicit SLAs, not waste. The security budget is tied to canonical workloads with published VerifyPrice, not to arbitrary hash puzzles with no external demand.

   Inference Verification Tiers and WC Eligibility:

   To prevent the “AI Money is backed by spot checks” critique, inference workloads are tiered by verification strength (see §21.1 for full taxonomy):

   Tier	Verification Type	WC Eligibility
   Tier A	Cryptographic (full ZK)	Full eligibility (1.0x)
   Tier B	Probabilistic (bounded error, audited)	Discounted (0.6x)
   Tier C	Attestation-only (TEE + sampling)	Service market only; no WC issuance

   Rule: Only Tier A and Tier B verified inference is eligible for Work Credit issuance. Tier B issuance is discounted by a published “soundness haircut” reflecting error bounds and audit rate. Tier C can exist as a service market but is not collateral-grade—it represents trust in TEE vendors, which is exactly what the thesis aims to minimize.

4. Lawful privacy by design.

   Settlement is neutral and non-custodial by default—adaptor-sig atomic swaps, shielded pools, privacy rails—but comes with viewing keys and auditable PIDL receipts so law-abiding users can evidence obligations without re-introducing chokepoints. The Settlement & Privacy Board reports swap success, refund safety, and anonymity-set health; flows that never touch custodians should still leave enough receipts that auditors can do their jobs.

5. Verifiable machines at Layer 0.

   Canonical proving and attestation paths run on open designs with sampled supply chains; hardware attestation becomes one input to proofs, not a vendor priesthood. Hardware profiles, lot-sampling coverage, and profile incidents show up on the Hardware/Layer-0 panes of the boards.

These invariants are hard to change and easy to measure. Everything else—fee curves, circuit versions, work-function parameters, corridor lists—is configuration.

To keep configuration from degenerating into a governance circus, we tie changes to observable triggers instead of vibes:

• If VerifyPrice p95 for a workload W drifts above its target band for a sustained window, that workload’s circuit and parameters are queued for revision. Blocking the change requires an explicit override that cites alternative SLOs and appears in the governance log.

• If entry latency for new provers/miners/LPs rises beyond a threshold, or the top-N share and house share breach caps, neutral routers automatically ratchet down house share and prioritize small bidders until the metric recovers. The Neutrality & Admission Board makes this visible.

• If a swap corridor’s refund-safety ever falls below 100% in VerifySettle, that corridor is removed from admissible routes by default. Re-listing requires a synthetic regression suite to pass (including stress tests) plus a public post-mortem.

In this frame, “governance” does not micromanage every adjustment; it writes the SLOs and the triggers. Operations enforces them and publishes the receipts. Most changes are data-driven roll-forward: parameters evolve in response to Verify* drift, with clear before/after numbers.

To keep rule-making separate from rent-collection, we also distinguish two broad roles:

• A spec & telemetry steward that publishes ABIs, PIDL schemas, canonical workloads, hardware profiles, and the VerifyPrice/Reach/Settle dashboards. It does not run routers or take custody. Its mandate is to keep the bill of materials and metrics honest and up to date.

• Market participants—miners, provers, routers, corridor LPs—who compete on price and reliability under those public SLOs, with SLA escrow and slashing keyed to PIDL receipts. Their incentives are economic; their constraints are the invariants and metrics.

This “two-chamber” structure keeps the job of defining rules and SLOs distinct from the job of selling capacity under those rules. It avoids the familiar pattern in which the entity that can edit parameters also happens to own the biggest fleet of nodes.

Governance as SLOs, not personality, is what lets the system answer policy pressure with dashboards and runbooks instead of press releases. When asked “how do you survive X?”, the right answer is not “trust the foundation,” but “look at this board, this trigger, and this incident playbook.”

22.5 Constitutional Enforcement

“SLO-bounded governance” is only credible if the enforcement mechanism is specified. Otherwise it reads like soft law. This section defines three action classes with increasing friction.

22.5.1 Machine-enforced constraints (Hard)

Certain invariants are enforced on-chain or in protocol code, not by social consensus:

Characteristic: These constraints cannot be violated without changing the code itself. They are the “bright line” invariants.

22.5.2 Override path (Slow, expensive)

Some constraints need flexibility for genuine emergencies or evolution. The override path exists but is deliberately expensive:

Example: Raising the issuance cap requires supermajority + 90-day timelock + published risk memo + 12-month expiry. This is intentionally harder than changing fee parameters.

22.5.3 Emergency path (Narrow)

True emergencies (proof system break, active exploit, hardware compromise) require faster action. The emergency path is narrow and auditable:

Why this matters:

Without explicit enforcement tiers, “governance as SLOs” is a promise that can be broken by a sufficiently motivated coalition. The three-tier structure ensures:

• Bright lines are hard: Machine enforcement prevents casual violation.
• Evolution is possible: Override path allows deliberate change with friction.
• Emergencies are bounded: Emergency path can respond fast but cannot expand power.

This transforms SLO governance from “we promise” into “here are the constraints the code enforces.”

22.6 Monetary Constitution

The economic loop that connects triad utility to asset value must be explicit enough to model. This section specifies the “bond indenture” of Work Credits.

22.6.1 Issuance envelope

Work Credit (WC-Base) issuance is governed by two components:

Issuance cap per epoch: The protocol enforces a hard cap; no governance action can issue beyond the cap except via override path (90-day timelock).

Capacity modulator formula (reference):

$\text{Issuance}_{epoch} = \text{BaseSchedule}_{epoch} \times (1 + 0.1 \times \tanh(\text{CapacityGrowthRate} - \text{TargetGrowthRate}))$

Where:

• CapacityGrowthRate = verified capacity added this epoch / total capacity
• TargetGrowthRate = governance-set target (e.g., 5%/year)

This allows supply to modestly expand when capacity grows faster than expected, and contract when growth slows, without discretionary minting.

22.6.2 Fee routing

When users pay for triad services (proof generation, privacy settlement, verified compute), fees are split:

Why burn? Burn creates deflationary pressure tied to usage. High demand → high fees → high burn → supply reduction → value appreciation. This closes the loop between utility and asset value.

22.6.3 Retirement rule

In addition to fee burn, WC-Base is retired in specific circumstances:

22.6.4 Risk haircuts

Work Credits minted under weaker assurance levels receive discounted issuance:

These haircuts are protocol parameters (not discretionary); they appear in dashboards and apply automatically.

22.6.5 Coverage target

The fee-coverage ratio measures what share of the security budget comes from fees vs. issuance:

$\text{FeeCoverage} = \frac{\text{FeeRevenue} + \text{Burn}}{\text{TotalSecurityBudget}}$

Why this matters: A system that relies entirely on issuance is inflating its way to security. A system where fees cover the budget has structural demand. The trajectory from issuance-funded to fee-funded is the path from “speculative token” to “productive asset.”

22.6.6 Value capture loop (summary)

┌─────────────────────────────────────────────────────────────────┐
│                    VALUE CAPTURE LOOP                           │
├─────────────────────────────────────────────────────────────────┤
│  DEMAND (users need Privacy, Proofs, Compute)                   │
│    │                                                            │
│    ▼                                                            │
│  Users pay fees in WC-Base for triad services                   │
│    │                                                            │
│    ├── 70% → Capacity providers (stakers must hold WC-Base)     │
│    ├── 20% → Burned (supply reduction)                          │
│    └── 10% → Assurance budget (sampling, audits)                │
│    │                                                            │
│    ▼                                                            │
│  Provers/routers must stake WC-Base as collateral               │
│    │                                                            │
│    ▼                                                            │
│  Issuance capped by schedule + capacity modulator               │
│    │                                                            │
│    ▼                                                            │
│  NET EFFECT: Demand → Fees → Burns + Staking Demand → Scarcity  │
│              Scarcity + Utility → Store of Value Premium        │
└─────────────────────────────────────────────────────────────────┘

Why demand doesn’t simply expand supply proportionally:

1. Issuance cap is hard: Protocol enforces epoch-level cap regardless of demand.
2. Burn is automatic: Higher demand → higher fees → higher burn → lower net supply.
3. Staking locks supply: More provers/routers → more collateral locked → less circulating supply.
4. Haircuts constrain issuance: Weak verification or concentrated provers earn less, limiting supply growth.

This is the “bond indenture” that makes the SoV claim auditable, not asserted.

Tip: hover a heading to reveal its permalink symbol for copying.