§6. The Triad as Monetary Base
Copy/paste (plain text):
Jason St George. "§6. The Triad as Monetary Base" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/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.
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).
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.
Tip: hover a heading to reveal its permalink symbol for copying.