What this changes
Balances use shares as the base unit while labels remain stable for interface use.
Whitepaper
PILLAR: A Percent-native, Fixed-supply Monetary Protocol
Author: Sam Gon & Jaaz — Revision: February 6, 2026.
Executive Summary
PILLAR is a fixed-supply, share-native protocol for global settlement. It separates account values from display labels, enforces audited issuance rules, and keeps redemption, custody, and governance operations explicit.
The design is built for participants who want predictable monetary accounting, clear custody boundaries, and auditable policy changes instead of discretionary monetary levers. Liquidity allocation replaces hidden refinancing mechanisms, and every policy switch must be published and time-locked.
Why this matters
Users can verify outcomes with published parameters and formulas instead of trust-based interpretation.
Where it applies
Cross-border settlement, redemption workflows, custody evidence, and sovereign coordination.
Abstract
PILLAR is a global monetary protocol design in which all balances and state transitions are represented as fixed shares of an immutable total supply. Instead of treating labels such as dollar or penny as the ledger unit, they become fixed aliases over shares. The protocol combines sovereign custody nodes, deterministic issuance, and explicit redemption windows to enable transparent cross-jurisdiction clearing without discretionary inflation.
The protocol is built around three principles: mathematical cap stability, role-separated infrastructure, and explicit accountability through public proofs, windows, and published parameters.
1. Vision and Problem
1.1 Why a global share model?
Conventional legacy systems depend on policy levers to handle scarcity, inflation, and exit paths. In PILLAR, the unit of account is not a mutable label, but a stable share of a fixed cap. This narrows the set of operations that can silently alter the accounting model.
1.2 What problem is solved?
The design reduces hidden coupling between liquidity creation, sovereign debt migration, and settlement mechanics. This yields a protocol where reserve dynamics are explicit and auditable while leaving policy space where it is structurally expected: governance and parameter control.
2. Core Monetary Model
PILLAR defines all economic state in terms of shares. A share is a fixed, indivisible base unit from the perspective of protocol accounting.
2.1 Share constants
- SHARE_SUPPLY_MAX = 600,000,000,000,000,000 shares
- DOLLAR_SHARES = 1,000 shares
- PENNY_SHARES = 10 shares
- PILLAR_SHARES = 1 share
2.2 Invariant decomposition
Circulating = SHARE_SUPPLY_MAX - reserve_pool_shares - burned_shares
This is the economic base for value-per-share and redemption accounting.
Example 1 — label conversion
Given a legacy value of 250.00 in Dollar-equivalent terms:
shares = 250 × DOLLAR_SHARES = 250,000 shares
Under this definition, a UI label “$250” always maps to the same number of shares.
2.3 Penny-Candy Precision
A “penny-candy” condition appears when tiny labels such as Penny are treated as hard anchors while purchasing power shifts through inflation or deflation. Under inflation, more real value may be required than one Penny suggests; under deflation, one small spending unit can span multiple Penny labels. In that state, users see stable small-number labels while actual settlement math differs.
PILLAR avoids this by fixing label aliases at constant share counts: `PENNY_SHARES = 10`, `DOLLAR_SHARES = 1,000`, and `MIN_SHARES = 1`. Label values never rebase; only shares move through deterministic protocol rules.
3. Genesis and Conversion
Genesis is a one-time conversion process where participating sovereign liabilities are converted into shares using a ratified FX snapshot. After conversion, FX updates no longer alter ledger state.
3.1 Conversion method
For each converted balance in currency c:
shares = floor(FX_snapshot(reference,c) × value_c × DOLLAR_SHARES)
Rounding and minimum-flooring rules prevent fractional leakage.
3.2 Governance requirements
Each participation boundary and sovereign debt mapping is a legal and policy step outside pure protocol state. The protocol preserves the results in immutable post-genesis accounting.
4. Node Model and Settlement Fabric
4.1 Country Nodes
- Validate transactions and apply custody policy.
- Build epoch batch hashes h_i^e.
- Sign distributed roots R^e when weighted and diverse.
- Collect fees and maintain ledger commitments.
4.2 Processing Nodes
- Propagate and store fragmentized records.
- Participate in availability sampling.
- Do not control monetary policy inputs.
- Provide reconstruction support under partial failure.
R^e = MerkleRoot(h_1^e, h_2^e, ..., h_N^e)
Finality is achieved with threshold signatures plus sovereign diversity checks.
5. Liquidity, Fees, and Allocation
5.1 Custodial allocation
Principal is held under custody structure. Allocators cannot mint or expand principal; they can only assign according to policy windows.
5.2 Usage fee
UsageFee = shares_assigned × r_s × dt_seconds / seconds_per_year
Fee is deterministic and monotonic over elapsed time, with floor rounding to `MIN_SHARES`.
5.3 Base tx fee
tx_fee = max(MIN_SHARES, floor(transfer_shares × fee_rate))
Fee floors and optional sovereign taxes are published in parameter sets.
Example 2 — usage accrual
Assigned shares: 500,000. Annual usage rate: 2%. Time elapsed: 43,200 seconds.
accrual = floor(500000 × 0.02 × 43200 / 31,536,000) = 13 shares
So the holder pays exactly 13 shares for the period.
6. Redemption and Issuance
6.1 Issuance from reserve
Verified deposits can mint shares from the reserve issuance pool according to published `vps`. Issuance reduces reserve pool and increases circulating supply.
6.2 Unilateral redemption
Redeemers submit shares and enter FIFO windows. Redemption burns shares and removes backing at published `vps`, while respecting caps and queue order.
asset_out = redeem_shares × vps_request
where `vps_request` is the published value-per-share at request time.
7. Security and Data Availability
7.1 Erasure coding
Each batch is split to n fragments with reconstruction threshold k. Nodes are sampled and penalized for missing attestations.
7.2 Slashing and exclusion
Conflicting signatures, missed attestation, and faulty reporting reduce availability score and can remove nodes from reward participation.
7.3 Threat model focus
Primary threats: collusion, selective withholding, replay under partitions, and oracle/UI misinformation. The protocol mitigates by separating roles and anchoring state in transparent commitments.
8. Governance, Upgrades, and Guardrails
8.1 Immutable elements
- Max supply and share label mapping
- Burn behavior and basic redemption semantics
- Monetary invariants and non-discretionary issuance rules
8.2 Upgradable elements
- DA parameters (k,n,m,S)
- Epoch timing and participation caps
- Fee bounds and reserve unlock ceilings
8.3 Process
Upgrade changes require sovereign quorum plus time-lock, followed by on-chain publication and activation lag.
9. Governance Deep-Dive and Operations
The protocol requires operational playbooks for pause events, major key rotation, custody attestations, and parameter emergencies. The intent is not to remove policy entirely but to force every policy change into auditable pathways.
Example 3 — emergency window miss
If a node misses required attestations across three consecutive epochs, it can be excluded from immediate finality credits and required to requalify after probation plus repaired history.
10. Parameters Snapshot
Epoch Length2 seconds
DA Parametersk=10, n=16, m=12, S=8
Minimum Sovereign Diversity7 distinct nodes
Min. shares1 share
Min redemption1,000 shares
Redemption window86,400 s
Window redemption cap0.5% of backing
Country tax cap10% (optional)
Usage rate r_s0.02 annualized (default)
Reserve unlock1–2% annualized (cap-controlled)
Figures
11. Open Questions for Further Research
- What legal frameworks are required for sovereign onboarding sequencing?
- How to operationalize physical custody attestations and cross-border audit interoperability?
- How to express transaction-level privacy while preserving light-client proofs?
- What benchmark set is appropriate for stress scenarios and redemption spikes?
- How should sovereign optional taxation interact with global protocol fee accounting?
Supporting Files
Reference files: PILLAR-Executive-Summary.txt · whitepaper.txt · technical-doc.txt · technical-overview.txt · software-spec.txt