§6. The Triad as Monetary Base
Copy/paste (plain text):
Jason St George. "§6. The Triad as Monetary Base" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v1.1. /v/1.1/read/part-ii/6-triad-as-monetary-base/ §6. The triad as monetary base
Traditional monetary regimes pick a base reality and build promises on top of it:
- Gold: geology + metallurgy.
- Fiat: law, taxation, and war.
- Bitcoin: thermodynamics and code.
Each regime implicitly answers two questions:
- What counts as real work?
- What object or capacity will we treat as the canonical memory of that work?
In a civilization where intelligence is largely machine‑executed and verification can be cheap and public, the answer shifts: work is what machines can do and humans can verify cheaply, and the “object” that records that work no longer has to be a metal or a pure ledger entry. It can be a capacity.
The claim is conditional: Privacy, Proofs, and Compute can support store-of-value instruments if verification remains cheap, privacy settlement remains usable, useful-work markets avoid capture, and protocol design converts recurring triad demand into scarce, non-bypassable asset value.
This thesis treats three capacities as monetary primitives:
- Privacy: censorship‑resistant settlement that preserves agency.
- Proofs: portable attestations of computation and provenance.
- Compute: useful work wrapped in succinct guarantees.
Each is:
- Indispensable in a dense digital economy (no safe commerce without privacy; no safe coordination without proofs; no AI without compute).
- Verifiably scarce at any point in time (bandwidth, cycles, proof capacity are bounded by physics and capital).
- Cheap to verify (you can check whether you have privacy, a valid proof, or a verified FLOP without trusting a platform).
The monetary base in this frame is not “the token” but the networked capacity to deliver Privacy, Proofs, and Compute under adversarial conditions. Tokens, credits, and instruments are just ways of slicing claims on that capacity.
A few distinctions help:
-
Base vs. wrappers: The base is “how much verifiable Privacy/Proofs/Compute per unit time this stack can deliver at target SLOs.” Wrappers are things like Work Credits, corridor tokens, and staking positions that slice this capacity into transferable claims.
-
Nominal vs. real: Nominal pricing of the triad will oscillate in terms of fiat and BTC. Real value is “does this capacity still buy me censorship‑resistant settlement, proofs, and verified FLOPs when repression and AI get worse?”
-
Symbol vs. utility: Gold and BTC partly trade as symbols. The triad trades as plumbing: “can I still pay people, prove things, and run intelligence without asking permission?”
From a monetary perspective, the key property is that the world must keep buying the triad’s utility:
- Treasuries and individuals purchase private settlement to escape surveillance and yield‑curve control.
- Platforms, enterprises, and states purchase proofs to secure provenance, compliance, and audit trails in an AI‑polluted information environment.
- AI labs, agents, and applications purchase verified compute to sell trustworthy services.
The claim is not that the triad replaces all money, but that it behaves like a reserve asset: a base layer of verifiable capacity that other instruments reference, hedge with, or settle into. Private Money and AI Money are just two lenses on how that base is held and used.
6.1 Monetary objects and value capture
The thesis claims that triad capacity can earn a “durable store-of-value premium.” For that claim to be testable, we must answer four questions without poetry:
- What exactly is the asset?
- What do users pay in?
- How does holding capture value?
- Why doesn’t value leak entirely to operators?
This section answers those questions by committing to three reference designs—not infinite agnosticism, but concrete instruments that can be evaluated.
Question 1: What is the asset?
The triad stack can issue several kinds of holdable instruments:
| Instrument | What It Represents | Scarce? | Transferable? | SoV Candidate? |
|---|---|---|---|---|
| Base Token | Native unit of the protocol; required for fees, staking, governance | Yes (capped issuance) | Yes | Primary |
| Work Credits | Claims on verified capacity; minted against attested work | Yes (capacity-bounded) | Yes | Secondary |
| LP/Staking Positions | Rights to fee share from corridors, proof pools, or validators | Yes (capital-bounded) | Sometimes | Derivative |
| Capacity Vouchers | Prepaid access to proofs/compute/settlement at fixed rates | No (redeemable, expires) | Yes | No (hedge instrument) |
| PIDL Receipts | Proof that work was done | No (copyable) | Yes | No (not scarce) |
The primary SoV candidate is the base token: the unit in which fees are paid, burns occur, and collateral is posted. Work Credits and LP positions are secondary instruments whose value derives from the base.
Question 2: What do users pay in?
All triad services are priced in the base token:
- Proofs: Pay base tokens to provers; portion burned.
- Privacy settlement: Pay base tokens for corridor fees; portion burned.
- Verified compute: Pay base tokens for inference/MatMul; portion burned.
- Staking/collateral: Provers, routers, and LPs must lock base tokens to participate.
This creates structural demand: every use of the triad requires acquiring the base token.
Question 3: How does holding capture value?
Value accrues to holders through four channels:
┌─────────────────────────────────────────────────────────────────┐
│ VALUE CAPTURE LOOP │
├─────────────────────────────────────────────────────────────────┤
│ Triad Demand (proofs, privacy, compute) │
│ ↓ │
│ Users acquire base tokens to pay fees │
│ ↓ │
│ Fees paid → Split: [Burn %] + [Staker %] + [Operator %] │
│ ↓ ↓ ↓ │
│ Burns reduce supply Stakers earn yield Operators paid │
│ ↓ ↓ │
│ Scarcity increases Holding earns income │
│ ↓ ↓ │
│ Price appreciation ←────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Concrete parameters (reference design):
| Parameter | Reference Value | Effect |
|---|---|---|
| Fee burn rate | 30–50% of fees | Deflationary pressure proportional to usage |
| Staker yield | 20–40% of fees | Income for holders who stake |
| Operator share | 20–40% of fees | Incentive for provers/routers/LPs |
| Collateral requirement | 10–20% of capacity value | Locks supply proportional to network size |
| Issuance cap | Fixed schedule or capacity-linked ceiling | Bounds total supply |
Why this creates SoV behavior:
- Demand is structural: AI, commerce, and compliance create ongoing need for triad services.
- Supply is bounded: Issuance is capped; burns reduce circulating supply.
- Holding is rewarded: Stakers earn yield; appreciation accrues to all holders via burns.
- Velocity is limited: Collateral requirements lock significant supply.
Question 4: Why doesn’t value leak entirely to operators?
The “utility token trap” occurs when operators (provers, LPs, routers) capture all economic value while token holders merely provide exit liquidity.
The stack avoids this through:
| Mechanism | How It Protects Holders |
|---|---|
| Fee burns | 30–50% of fees are permanently destroyed, benefiting all holders—not just operators. |
| Staking yields | Passive holders can stake to earn fee share without operating infrastructure. |
| Collateral requirements | Operators must hold significant tokens to participate, aligning their interests with holders. |
| Governance rights | Token holders vote on fee splits, issuance changes, and protocol upgrades. |
| Issuance constraints | New tokens cannot be minted arbitrarily; issuance is tied to capacity growth via FERs and telemetry. |
Net effect: At steady state, fee burns ≥ new issuance, so total supply is flat or declining. Holders benefit from both yield (if staked) and appreciation (via burns).
Value Capture Lemma
Demand for Privacy, Proofs, and Compute creates store-of-value premium for the native asset only if five conditions hold simultaneously:
- Required fee medium: the asset is required for core fees, and users cannot pay in fiat, stablecoins, or other tokens at equivalent service quality.
- Supply reduction: a meaningful share of fees is burned or permanently retired.
- Collateral lockup: operators must stake the asset as collateral to provide services.
- Issuance discipline: issuance is capped by schedule, capacity, or both—not by governance fiat.
- Non-bypassability: users cannot obtain equivalent triad capacity through bypass channels (cloud contracts, stablecoin-denominated services, direct fiat payment to operators) that avoid touching the asset.
If any condition fails, the system may be useful infrastructure but not a store-of-value asset. This lemma is the central bridge between ‘these capacities are indispensable’ and ‘therefore a specific asset earns monetary premium.’
Three Reference Designs
To make the thesis testable, we commit to three concrete designs. Implementations may vary, but at least one must be viable for the SoV claim to hold.
Design A: Base Token as SoV (Primary)
- Issuance: Fixed schedule with halvings (like BTC) or capacity-linked ceiling.
- Fee medium: All triad services priced in base token.
- Burns: 40% of fees permanently destroyed.
- Staking: 30% of fees to stakers; 10–15% collateral requirement.
- Operators: 30% of fees to provers/routers/LPs.
- Governance: Token-weighted voting on parameters.
SoV properties: Credible scarcity (capped + burns), native demand (fees), duration-neutral (no coupons), cheap verification (VerifyPrice dashboards).
Risk: If demand stalls, burns decline and scarcity weakens.
Design B: Work Credits as Capacity Vouchers (Hedge Instrument)
- Issuance: Minted against verified work (FERs + proofs); no fixed cap.
- Redemption: Burnable for priority access to proofs/compute/settlement at SLA-guaranteed rates.
- Expiry: Credits decay or expire after N years to prevent hoarding and bank-run dynamics.
- Transferable: Yes, but primarily used for cost hedging, not long-term savings.
Use case: Enterprises hedge against compute cost spikes; treasuries lock in future settlement capacity.
Not a SoV: Supply expands with capacity; expiry prevents indefinite accumulation. This is infrastructure hedging, not a store of value.
Design C: Triad Index Token (SoV Candidate)
- Backing: Diversified revenue streams across privacy corridors, proof pools, and compute markets.
- Value capture: Protocol revenue used for periodic buyback-and-burn or dividend distribution.
- Issuance: Fixed supply; no new minting after genesis.
- Governance: Index holders vote on revenue allocation and rebalancing.
SoV properties: Diversified exposure to triad demand; fixed supply; yield via buybacks or dividends.
Risk: Concentration in specific corridors or proof markets; governance capture.
Which design does the thesis endorse?
The thesis is compatible with all three, but Design A (Base Token as SoV) is the primary reference design because:
- It is closest to the BTC model that has demonstrated SoV behavior.
- Fee burns create clear, measurable scarcity.
- Staking and collateral create structural demand beyond speculation.
- VerifyPrice and telemetry make the value linkage auditable.
Design B is useful for enterprises but is explicitly not pitched as a SoV. Design C is viable but adds complexity (index construction, rebalancing).
The rest of Part II assumes Design A as the default when discussing “the asset” or “Work Credits as SoV.” Where Design B semantics apply (vouchers, hedging), we will note it explicitly.
6.2 From Utility Demand to Monetary Premium
Many indispensable services—electricity, bandwidth, compute instances, legal services, cloud storage—have recurring demand without being stores of value. The monetary argument requires explaining why this utility becomes monetized savings demand, not just operating expense.
The bridge has eight conditions:
-
Utility demand is not enough. Recurring demand for a service does not automatically create a scarce, holdable asset. Bandwidth is indispensable, but claims on bandwidth do not become money.
-
The asset must be required for fees or settlement. Every use of the triad must flow through the base token. If operators accept fiat directly, the asset is optional.
-
Fees must produce burns, retirement, or staking yield. Fee revenue must reduce circulating supply or compensate holders, not merely pay operators.
-
Operators must post the asset as collateral. Provers, routers, and LPs must lock the asset to participate, creating structural demand beyond fee payment.
-
Issuance must be capped or capacity-constrained. New supply cannot expand by governance decree; it must track real, verified capacity.
-
Users must not be able to bypass the asset at equal service quality. If AWS, a ZK prover marketplace, or a stablecoin-based privacy wallet can sell equivalent triad capacity for fiat, the native asset becomes unnecessary.
-
Telemetry must prove the loop is working. Fee coverage, burn rates, collateral lockups, and workload demand must be publicly verifiable—not asserted.
-
If any condition fails, the asset is infrastructure exposure, not money. It may still be useful and valuable, but it does not earn a store-of-value premium distinct from its service value.
This section is the “utility-token trap” defense. The thesis does not claim that useful things automatically become money; it claims that under specific, testable value-capture conditions, a useful asset can earn monetary premium.
6.3 Why Users Cannot Simply Bypass the Asset
The strongest economic objection to the thesis is simple: ‘Why can’t AWS, a ZK prover marketplace, or a privacy wallet sell the same service for fiat or stablecoins and bypass Work Credits entirely?’
The objection is valid unless the protocol enforces native value capture. The required mitigations:
-
Core fees are denominated in the base token. Provers, routers, and settlement corridors accept only the native asset for protocol-level fees. Fiat or stablecoin payment requires acquiring the asset first.
-
Collateral must be posted in the base token. Operators cannot participate without holding significant quantities of the asset, creating structural demand beyond speculation.
-
Burns create scarcity tied to usage. A meaningful share of fees is permanently destroyed. Higher triad usage means lower circulating supply.
-
SLA priority requires the asset. Gold-tier SLAs, governance participation, and priority access during congestion require holding or staking the asset.
-
Settlement paths are natively denominated. Privacy corridors and settlement rails denominate in the base token; off-ramps exist but are not the default.
Honest admission: If users can in practice bypass the asset—for example, if most operators accept stablecoins and immediately off-ramp, or if hyperscaler-hosted provers dominate the market and set prices in fiat—then the SoV thesis fails. The system may remain useful infrastructure, but the monetary claim collapses. The telemetry must track this: native-asset fee share, bypass channel volume, and operator off-ramp rates should be visible on the Economic Coverage Board (§23).
Sidebar: Co-option as bypass. The bypass threat is not always a competing product. It can also be institutional co-option: ETFs, treasury companies, margin loans, and regulated custody that deliver exposure to the asset’s price without requiring users to interact with the protocol’s privacy, proof, or settlement rails. If the majority of demand is satisfied by custodial wrappers that bypass the fee-burn-collateral loop, the asset’s price may rise while its monetary thesis weakens. The telemetry must distinguish between custodial exposure (which does not exercise value capture) and protocol-native usage (which does).
Tip: hover a heading to reveal its permalink symbol for copying.