1. Wallet signs and submits
The sender signs a share-denominated transaction. The message includes nonce, amount, fee fields, and chain identity.
Operational Flow
How the protocol moves from genesis setup to live transfers, finality, and redemption.
1. Genesis conversion
Legacy obligations convert into share balances.
Legacy obligations convert into share balances.
→
2. Share assignment
Wallet and treasury balances are published.
Wallet and treasury balances are published.
→
3. Live transfer and allocation
Users send shares under policy constraints.
Users send shares under policy constraints.
4. Fee accrual by time
Usage and transfer fees accrue in shares.
Usage and transfer fees accrue in shares.
→
5. Epoch batch and root
Country Nodes commit batch hashes.
Country Nodes commit batch hashes.
→
6. Finality and publication
Threshold signatures finalize global state.
Threshold signatures finalize global state.
7. Availability attestation
Fragments are sampled and verified.
Fragments are sampled and verified.
→
8. Redemption queue
Requests enter FIFO windows and cap checks.
Requests enter FIFO windows and cap checks.
→
9. Burn sink update
Redeemed shares are permanently removed.
Redeemed shares are permanently removed.
Transfer Pipeline
A single transfer follows a deterministic sequence from signature to final ledger inclusion.
2. Processing Nodes propagate
Processing Nodes relay and stage the transaction while preserving path evidence for traceability and replay resistance.
3. Country Node validates
The proposer checks signature validity, nonce order, balance sufficiency, fee floors, and policy constraints.
4. Batch and consensus root
Validated transactions enter an epoch batch. Country Nodes sign the root, then finality requires threshold weight and sovereign diversity.
5. Finalized state and proof
The transfer becomes final once consensus criteria are met. The ledger, proof path, and signatures can be inspected by clients.
tx -> mempool -> batch hash -> signed root -> finalized ledger state
Redemption Lifecycle
Request Intake
A holder submits shares for redemption. The request must be at or above the minimum redemption threshold.
Queue and Window Check
The request enters FIFO order. Per-window backing caps are applied to prevent discretionary prioritization or sudden outflow spikes.
Settlement at Published Value
When the window opens and capacity exists, backing is released using the published value-per-share for the applicable window.
Burn Finalization
Redeemed shares move to the burn sink and cannot return to circulation, preserving supply partition integrity.
Example: redemption timing
A holder submits 100,000 shares to redeem. If queue position and the current window cap permit execution, backing is released and shares are burned in that window.
If capacity is full
The request remains in FIFO order for the next eligible window. This keeps redemption scheduling deterministic and publicly auditable.
Failure and Recovery Behavior
Availability interruption
If required fragments are unavailable, affected processing can pause while reconstruction runs. Queue order and published state remain intact.
Validator under-participation
Nodes that miss required finality or attestation criteria can lose eligibility until they requalify under published participation rules.
Operational continuity
Role separation between Country Nodes and Processing Nodes limits single-role concentration and keeps settlement and data duties explicit.
Why this flow matters
PILLAR keeps each transition visible: who validated, what was finalized, what was queued, and what was burned. The protocol reduces ambiguity by making each stage inspectable in public state.
Continue
Watch the live transaction path
Open the simulation to create wallets, submit transfers, and inspect the pipeline from wallet signature to country-node finality.
Open SimulationRead full protocol specification
The whitepaper defines formulas, invariants, parameter boundaries, and governance controls used by the operational flow.
Open Whitepaper