Proof of human + skill
Purpose-bound uniqueness and capability proofs with minimal disclosure.
How it works / intended design
Four ideas. One trust system.
IUNUA brings together private records, clear checks and shared rules. Think of these as the pieces of a system we are working toward.
See the ideas in the demo →Planned architecture. These illustrations explain a design. Creating the existing Devnet token did not implement private accounting, proof verification or governed settlement. A dated 10 September 2026 composition note treats Monero Stagenet as the intended treasury rail and keeps World sessions separate from signing.
01 / Private ledger
Keep a private notebook.
Imagine a notebook that records what you receive and send. The intended private ledger would protect those records instead of publishing your whole activity history.
Like keeping your own accounts without pinning every page to a noticeboard.
02 / Eligibility and proofs
Check only what is needed.
Before a reward is given, the system would check a condition: for example, whether the work qualifies. The aim is to answer that question without handing over a whole personal record.
Like showing a valid ticket at a door instead of sharing your life story.
03 / Optional public settlement
Choose a public record when needed.
A future connection could move approved value from the private system to a public network. Public accounts and amounts can be linked and inspected, so this choice needs to be clear.
Like choosing to put one entry on a noticeboard. Everyone can read what is posted.
04 / Governance and disclosure
Agree how the rules can change.
The proposed Pantheon governance would require a recorded proposal, approval and a waiting period before a change takes effect. A history would show which rules applied to earlier actions.
Like agreeing on the rules of a shared project, then announcing changes before using them.
Sharing should be a deliberate choice.
The design also includes limited audit access: choosing specific records for a reviewer. Ending future access would not erase information already seen or copied. The demo makes that limit visible.
The complete written explanation.
The whitepaper connects the intended architecture to current evidence, open economic decisions and mainnet prerequisites.
Read the architecture in the whitepaper →Technical details: architecture, disclosure and Pantheon governance
Architecture map
The private core stays authoritative.
Public settlement is an adapter—not a second source of truth. Identity, wallet, governance, and service subjects remain separate, joined only through controlled proofs.
Private trust layer Eligibility proofs Optional public rail Governance
Wallet & proof BFF
Session UI, explicit approvals, redacted balances, and proof orchestration.
- HttpOnly session
- No browser bearer token
Private commitment ledger
Commitments, nullifiers, proof envelopes, audit windows, and versioned policy.
- PostgreSQL · planned
- Append-only receipts · planned
Programmable settlement rail
Public mint, burn, settlement, and policy hooks after private-layer approval.
- Solana-style adapter
- No private identity data
Pantheon policy
Supply, limits, pauses, code hashes, approvals, and timelocked upgrades.
What stays private
Real identity links, full private balances, private-ledger counterparties, work history, and heavy proof material.
What may cross
Public settlement accounts, selected amount and timing, one-use nullifier, policy version, and attestation metadata.
What remains inspectable
Upgrade history, active policy, public settlement events, and deliberately scoped audit records.
Changeable, not silently mutable
A programmable layer with visible gates.
Upgradeability is useful only when the path is harder to hide than to inspect. The prototype keeps every receipt pinned to its original policy while newer actions adopt the approved version.
- 01ProposalCode hash + parameter diff
- 02Pantheon approvalThreshold vote recorded
- 0348h timelockReview, veto, or pause
- 04ActivationNew policy; old history retained