# PILLAR Protocol - Technical Overview (Supporting Whitepaper) This document is a supplemental technical section aligned to the full whitepaper. Section numbering begins at 3 to match the corresponding references. ## Protocol Invariants (always true) - `SHARE_SUPPLY_MAX` is immutable. - `burned_shares_t` is monotonically increasing. - `reserve_pool_shares_t` is monotonically decreasing. - No operation may increase `SHARE_SUPPLY_MAX`. --- ## 3. Genesis Assumptions and Reserve Model For illustrative and simulation purposes: - Global sovereign + central-bank liabilities converted at genesis: 300 trillion USD-equivalent units (FX snapshot at genesis). - Paired time-locked reserve pool (operator subsidy): 300 trillion USD-equivalent units, unlocking at 1-2% per year (exponential decay). - `SHARE_SUPPLY_MAX` is fixed; the above figures are illustrative label-unit equivalents, not a separate mintable supply. Notes: - The reserve is issuance capacity, not pre-minted balances. - Reserve capacity is consumed on issuance and never replenished, including on asset redemption. - Reserve unlock distribution should be fee-weighted (not raw tx-count weighted) to reduce spam incentives. --- ## 4. Network Topology ### 4.1 Node Types #### 4.1.1 Federated Country Nodes (FCNs) Operated by central banks or designated monetary authorities. Responsibilities: - Transaction intake and validation - Local settlement and batching - Liquidity allocation under custody rules - Fee collection and reporting - Participation in global settlement consensus Constraints: - Cannot mint or burn supply arbitrarily - Cannot rehypothecate liquidity - Cannot block cross-border transfers - Cannot alter protocol invariants FCNs function as sovereign clearing hubs, not monetary issuers. #### 4.1.2 Processing Nodes Non-sovereign infrastructure participants. Responsibilities: - Transaction propagation - Cryptographic verification - Data availability enforcement - Redundant fragment storage Constraints: - Do not custody liquidity - Do not participate in economic decisions - Do not influence monetary state --- ## 5. Ledger Architecture (Non-Monolithic) ### 5.1 Distributed Redundant Ledger Fabric The protocol does not rely on a single canonical chain. Each FCN maintains: - A local transaction log - Partial global monetary state - Rolling cryptographic commitments Redundancy is achieved through: - Merkle commitments - Erasure-coded data fragments - Deterministic epoch finality No single node or region can become monetarily authoritative. ### 5.2 Epoch-Based Settlement Time is divided into fixed epochs (for example, 1-5 seconds). For epoch e: - Each FCN produces a batch `B_i^e`. - Batch hash: `h_i^e = H(B_i^e)`. - FCNs broadcast: - `h_i^e` - Liquidity deltas - Fee totals - Issuance and burn events --- ## 6. Global State Commitment ### 6.1 Merkle-of-Merkles Finality The Global Coordination Layer computes: `R^e = MerkleRoot(h_1^e, h_2^e, ..., h_N^e)` `R^e` represents global finality for epoch e. Loss of up to < 1/3 of FCNs does not prevent verification or reconstruction. --- ## 7. Fault Tolerance and Redundancy ### 7.1 Erasure-Coded Ledger Fragments (open design) Ledger and state data may be: - Split into k fragments - Encoded into n fragments (n > k) - Distributed across FCNs and processing nodes Properties: - Any k fragments reconstruct data - No node holds sufficient data alone - Regional capture does not imply monetary control --- ## 8. Cryptography ### 8.1 Wallet Authorization - Ed25519 or secp256k1 signatures - Deterministic nonces - Optional hardware-backed keys Bearer wallets: - Full per-transaction signatures Verified wallets: - Session tokens - Deferred batch verification ### 8.2 Hashing - SHA-256 or BLAKE3 - Merkle trees for: - Transaction inclusion - Epoch commitments - Monetary state proofs ### 8.3 Zero-Knowledge Extensions (optional) Potential future use: - zk-SNARKs or zk-STARKs for: - Balance validity proofs - Contract correctness - Liquidity stress proofs ZK is optional and non-essential to monetary correctness. --- ## 9. Consensus Model ### 9.1 Federated Deterministic Settlement (FDS) - FCNs sign epoch commitments. - Finality requires stake weight sum >= 66%. StakeWeight is derived from: - Custodied balances (bounded) - Historical correctness - Uptime metrics No probabilistic forks. No proof-of-work. No inflation. ### 9.2 Anti-Collusion Enforcement If a node signs conflicting roots: - Stake weight is slashed - Future signatures are ignored - Liquidity allocation weight is reduced --- ## 10. Liquidity and Lending Accounting ### 10.1 Custodial Liquidity Liquidity is system-owned at all times. Allocators: - Cannot spend principal - Cannot own principal - May only assign under contract ### 10.2 Fee-Based Usage For assigned principal P over time Delta t: `UsageFee = P * r_s * Delta t` Where: - `r_s` is the system usage fee (for example, 2% simple annually) Fees reduce balances. Principal always returns 1:1. Optionally, Country Nodes may apply a domestic transaction tax up to 10% in addition to network fees; tax rules are sovereign-defined and published. --- ## 11. Physical Asset Custody and Exit ### 11.1 Physical Asset Deposit (Issuance Event) When a verified physical asset (for example, gold) is deposited: - Asset enters custody - Protocol issues circulating shares from the reserve pool at the published `vps` - Issuance consumes reserve capacity (`reserve_pool_shares_t` decreases) ### 11.2 Physical Asset Redemption (Burn Event) When a holder redeems physical assets: - Holder submits protocol shares - Shares are burned - Asset exits custody Reserve capacity is not replenished. Redemption: - Requires no market liquidity - Requires no counterparty - Is a unilateral state transition - Is processed on a separate redemption window schedule (physical logistics are not tied to 1-5s settlement epochs) --- ## 12. Denomination and Precision - Protocol uses fixed integer units with high divisibility. - Suggested base precision: >= 10^12 subunits. - All accounting is integer-based. - Named denominations (for example, "Pollar") are UI-layer abstractions defined as fixed share amounts (aliases). - No rebasing occurs at any layer. --- ## 13. Validation Economics There is no mining. Processing and validation nodes earn: - Deterministic fees for verification - Compensation for availability and storage Optionally, an additional deterministic subsidy may be paid by unlocking shares from the reserve pool on a fixed schedule (still bounded by `SHARE_SUPPLY_MAX`; no discretionary issuance). --- ## 14. Data Availability Guarantees Each epoch requires: - m independent availability attestations - Random sampling of fragments - Automatic penalties for non-availability --- ## 15. Security Model Summary | Threat | Mitigation | | --- | --- | | Node failure | Erasure coding and redundancy | | Ledger rewrite | Epoch-root anchoring | | Collusion | Stake-weighted finality | | Bank-run dynamics | Exit does not depend on liquidity | | Inflation | Fixed maximum supply | | Exploitation loops | Burn on exit | --- ## 16. Open Design Areas The following require further engineering work: 1. Optimal erasure-coding parameters 2. StakeWeight bounds and caps 3. Cross-node latency optimization 4. Custody audit standards for physical assets 5. Hardware security assumptions These do not affect monetary correctness. --- ## 17. Closing Note This technical specification enforces strict separation between: - Monetary invariants (fully specified) - Consensus and cryptography (largely specified) - Redundancy optimization (partially open) The protocol replaces discretionary monetary trust with deterministic state transitions and guarantees that value can always exit the system without requiring liquidity, counterparties, or discretionary intervention.