Section 07
Token Utility and Economics
Two tokens, one calibration formula, and a graduated response to stress
Pim Protocol runs on two tokens with deliberately separate jobs. QOL is the everyday currency: a demand-responsive, energy-backed unit meant to function as cash for payments, fees, and savings, targeting 1–2% daily volatility. PYM is the governance and staking token: a fixed supply, capped at 100 million from the genesis block, with no further issuance ever possible. Separating these two roles is a deliberate choice — it keeps the currency people actually transact with insulated from the speculative pressures that typically affect a governance token, while keeping governance power tied to a token whose supply cannot be diluted by monetary policy decisions.
7.1EQCF — The Energy Quotient Calibration Formula
QOL's issuance rate is not set by a single ratio, the way many "energy-backed" tokens work. It is calibrated through a seven-stage pipeline that combines five independently measured signals into one smoothly adjusting value. The purpose of this multi-stage design is to solve a specific failure mode: a single noisy or temporarily anomalous input — a brief dip in energy reporting, a thin trading session — should never be able to swing currency issuance on its own. Each stage adds a specific safeguard.
1. Raw Signal Collection
Five inputs are sampled every 12-hour cycle: energy cost (from weighted energy-proof submissions), hashrate deviation, on-chain currency velocity, market liquidity depth, and price volatility. Each is normalised to a 0–1 scale before being combined.
2. Weighted Composition
The five signals are combined into a single composite score, with energy cost weighted most heavily because it is the signal backed by hardware-verified proof — the others contribute lighter, stabilising corrections.
3. Confidence Scoring
Each cycle's composite score is assigned a confidence weight based on how complete energy-proof reporting was that cycle and whether the system's anomaly detection flagged anything unusual. Low-confidence cycles are down-weighted, never simply thrown away.
4. Smoothing
The confidence-weighted score is blended with the running average from previous cycles, so that a single anomalous cycle can move the smoothed output by at most a small, bounded fraction of the deviation — turning short-term noise into a gradual, observable drift rather than a sudden jump.
5. Persistence Gate
A directional change must hold steady for three consecutive 12-hour cycles — 36 hours — before it is allowed to cross a policy-relevant threshold. This is the primary defence against any single-cycle noise driving an actual monetary policy reaction.
6. Hard Bounds
The calibration value is hard-capped within a fixed range, enforced directly by the consensus rules. No combination of inputs can push it outside this range; changing the range itself would require a full protocol upgrade.
7. Minting Formula
The final issuance amount is the lesser of two independent limits — one derived from the calibration pipeline, one from network hashrate — multiplied by a demand factor. Neither limit alone determines issuance; both must agree.
κ_t = 0.55·Ê_t + 0.20·Ĥ_t + 0.10·V̂_t + 0.10·L̂_t + 0.05·σ̂_t
EQCF_t = λ·κ_t + (1−λ)·EQCF_(t−1)
λ = 0.15
EQCF_t ∈ [0.40, 2.50]
Δ(EQCF_t) ≤ 3% per cycle
1.5% during Tightening
QOL_minted = min(effective_signal(EQCF_t, state) × E_agg_t, β × HR_t) × F_t
In plain terms: Ê_t is the normalised energy-cost signal, Ĥ_t the hashrate-deviation signal, V̂_t the currency-velocity signal, L̂_t the market-liquidity signal, and σ̂_t the inverse-volatility signal — each measured at cycle t. The weights (0.55, 0.20, 0.10, 0.10, 0.05) reflect how much each signal is trusted, with the hardware-verified energy signal dominating by design. λ controls the smoothing speed described in Stage 4. The final minting formula takes the smaller of two outcomes — the calibrated signal applied to aggregate reported energy E_agg_t, or a fixed multiple β of network hashrate HR_t — and then scales the result by a demand factor F_t.
The Demand Factor
F_t = clip((TPS_realized / 15,100) × (V_7d / V_hist), 0.5, 1.5)
This compares realised transaction throughput against the network's stable-state benchmark of 15,100 TPS, and compares seven-day currency velocity against its historical average, then bounds the result between 50% and 150% of the base issuance rate.
The Liquidity Signal
The market-liquidity signal, L̂_t, is derived entirely from on-chain trading-pool data rather than from any external price feed.
7.2ADTMS — The Four-State Monetary Circuit Breaker
CSI_t = 0.45·PriceDeviation_t + 0.25·(1 − C_PoEC,t) + 0.20·TPSDeficit_t + 0.10·EQCFDrift_5c
| State | Condition |
|---|---|
| Stable | CSI < 0.25 |
| Tightening | 0.25 ≤ CSI < 0.50 |
| Transition | 0.50 ≤ CSI < 0.75 |
| Critical | CSI ≥ 0.75 |
| State | Behaviour |
|---|---|
| Stable | Full issuance · calibration formula governs directly · 20% of fees burned |
| Tightening | 50% issuance rate · slower calibration adjustment · 60% of fees burned |
| Transition | Issuance halted · reserve-funded buybacks active · 80–100% of fees burned |
| Critical | Mandatory ≥12h halt · reserve deployed to market · 100% of fees burned |
Recovery back toward Stable is deliberately conservative: six conditions must hold simultaneously for four consecutive cycles.
7.3Proof-of-Energy Cost — Verifying the Energy Backing Is Real
| Tier | Representative Hardware | Attestation Method |
|---|---|---|
| SEL (Tier 0) | ESP32, nRF52840, ultra-constrained IoT | Hardware-fingerprint attestation; no TPM required |
| Edge Coordinator (Tier 1) | Raspberry Pi-class, Android with TrustZone | TrustZone attestation or hardware-fingerprint attestation |
| Mobile/IoT Node (Tier 2) | 1.5–3 GB RAM mobile devices | Lightweight cryptographic proof via TrustZone or open-source enclave |
| PC Node (Tier 3) | 4–8 GB RAM desktop hardware | Full zero-knowledge proof with TPM 2.0 or TrustZone |
| GPU Node (Tier 4) | 16+ GB RAM, GPU-equipped | Full zero-knowledge proof with TPM 2.0 hardware attestation |
7.4The Pim Cell Type Standard — Native Ledger Objects
Object_valid = verify_lock(object.lock_script, tx.signature)
AND
verify_type(object.type_script, tx.inputs, tx.outputs)
| Object Type | Name | Primary Use |
|---|---|---|
| 1a | Coin (QOL) | The everyday currency — payments, fees, market swaps |
| 1b | Coin (PYM) | Governance token transfers |
| 1c | Governance Object | On-chain votes, confirmed via the owned-object fast path |
| 1d | Staking Object | PYM staking; penalties route to the stability reserve, not destroyed |
| 1e | Energy Bond Object | Energy attestation bonding — feeds the EQCF pipeline |
| 2 | Non-Fungible Object | Unique assets — collectibles, land titles, energy-proof instruments |
| 3 | Custom Token | Developer-issued fungible tokens, automatically listed on the exchange |
| 4 | Real-World Asset | Tokenisation of physical or financial assets |
| 5 | Accounting Object | Double-entry bookkeeping enforced at the consensus layer |
| 6 | Business Revenue | Merchant payment capture; on-chain credit history |
| 7 | Cooperative Object | Collective treasuries; cooperative governance |
| 8 | Rotating Savings Object | Trustless community savings circles, with no human coordinator needed |
| 9 | Equity / Debt Object | Tokenised equity and debt instruments |
| 10 | Agent Delegation | Bounded spending authority for AI agents, rooted in human approval |
| 11 | Identity Object | Zero-knowledge identity verification; resistance to fake-account attacks |
| 12 | Escrow Object | Consensus-enforced escrow across multiple release conditions |
| 13 | Ledger Record | Sovereign personal records — ten distinct record types |
| 14 | DAO Proposal | Multi-chamber on-chain governance with treasury disbursement |
| 15 | Diaspora Object | Cross-border remittance, equity splits, impact instruments |
| 16 | Guardian Object | Personal security — collision avoidance, escort, alert systems |
7.5The Protocol-Level Exchange
k = QOL_reserve × PYM_reserve
7.6Fee Flows and the Stability Reserve
Penalties for dishonest or non-compliant node behaviour are routed into a Stability Reserve rather than being destroyed.
7.7Optional Privacy — Cash Mode
| Cash Mode Usage | Effective Throughput | Reduction |
|---|---|---|
| 0% (fully transparent) | 70,000 TPS | 0% |
| 5% | 67,200 TPS | −4% |
| 10% | 64,500 TPS | −8% |
| 20% | 59,200 TPS | −15% |
| 30% | 54,000 TPS | −23% |
| 50% | 44,800 TPS | −36% (fee escalation self-corrects beyond this point) |
7.8How the Stability Mechanisms Work Together
| Mechanism | Active When | Function |
|---|---|---|
| Demand-responsive issuance | Stable state | Adjusts issuance between 50–150% of baseline based on real network usage |
| Energy-calibrated issuance (EQCF) | All states | Recalibrates every 12 hours; issuance contracts automatically as energy costs rise |
| Reserve-funded buybacks | Transition + Critical | The Stability Reserve buys back QOL on the open market |
| Fee burns | All states, rate varies | A rising share of transaction fees is permanently removed from circulation |
| Stability Reserve | Fills continuously; deploys under stress | Funded from genesis allocation, penalty routing, and exchange fees |
| Emergency halt | Critical only | A mandatory minimum 12-hour pause in issuance |
"The calibration formula makes small, smooth adjustments. The circuit breaker blocks extreme reactions to short-term noise. Recovery requires sustained, multi-condition stability before normal operation resumes. Every parameter in this system is bounded, observable on-chain, and adjustable only through governance — never through unilateral intervention."
Previous
Consensus MechanismNext
Security Model