Got questions?

The ZERA Protocol is a universal, direct-deposit privacy layer for the assets you already hold. It's token and chain-agnostic: bring existing tokens (e.g., USDC, USDT, SOL and more) into a single, unified cryptographic pool to receive shielded balances with private transfers—including offline, device-to-device payments that sync to chain later.

No synthetic pegs, no mixers, no bridging - just a composable privacy layer designed for real usage.

$ZERA is the ecosystem’s utility and governance token. It aligns value with protocol usage via volume based programmatic burns (no direct protocol fees), provides governance over upgrades/parameters, and unlocks access to premium features and early product tracks.

The token began as Monopoly Money ($M0N3Y) on pump.fun with a fixed supply of 1 billion, 100% circulating from day one(no presale, no team, no VC). That supply was migrated 1:1 to $ZERA during Sept 25 – Oct 2, 2025 as part of the rebrand from mnply M0N3Y to Zera Labs.

CA: 8avjtjHAHFqp4g2RR9ALAGBpSTqKPZR8nRbzSTwZERA

ZERA provides security and privacy for any supported token by combining conservative cryptography with a unified pool design. Assets are deposited directly into a single compressed pool; amounts and linkages are hidden, while correctness is verified by math—not trust.

• Formal Verification: Core circuits and contract logic follow formal methods and rigorous testing to eliminate entire classes of implementation bugs.
• Commitments & ZK Proofs: Pedersen commitments hide amounts; succinct zk-SNARKs prove balance conservation, membership, and correctness without revealing participants or balances.
• Deterministic Nullifiers (Single-Spend): Every spend carries a ZK-verified nullifier so the network finalizes the first valid spend it sees—preventing double-spends without revealing identity.
• Offline Security: Device-to-device transfers verify locally; nullifier checks and epoch updates bound the offline window. On reconnect, consensus simply orders the first valid nullifier.

We chose Solana for its low-latency finality, ultra-low fees, and parallel execution—ideal for private payments at consumer scale. Features like account compression (to shrink on-chain state) and mature token standards make it a natural fit for ZERA’s unified pool, where privacy needs throughput, predictable costs, and reliable UX.

That said, the protocol is chain- and provider-agnostic. ZERA’s cryptographic core is designed to port cleanly across other chains and even into traditional rails (e.g., card/banking networks) via modular adapters—preserving the same UX and guarantees. We’re stabilizing the core on Solana first, then expanding to additional networks where it best serves users and liquidity.

ZERA enables offline, peer-to-peer payments by moving value as cryptographic notesrather than live chain transfers. Your wallet creates a note that commits to an amount using Pedersen commitments and attaches succinct zk-proofs that the math is valid (inputs = outputs, note membership, correct ranges) - without revealing sender, receiver, or amount.

The payment is delivered device-to-device over NFC, Bluetooth, or QR. The recipient’s wallet verifies everything locally (no internet): proofs check out, balances conserve, and a deterministic nullifier (a one-time spend tag) is computed and cached to prevent accepting duplicates. This provides single-spend enforcement even while both parties are offline.

When either device reconnects, the wallet submits the same proofs and nullifier on-chain. Consensus simply orders the first valid nullifier it sees - finalizing the payment and rejecting any conflicting duplicates. ZERA’s epoch evolution (fresh, auditable entropy over time) re-salts proofs to shrink offline attack windowsand keep state fresh across devices.

Practically: you can pay offline, the recipient can verify instantly, and the network finalizes later - cash-like UX with cryptographic guarantees, withoutrelying on vendor-trusted hardware.

ZERA uses deterministic nullifiers - a one-time spend tag derived from a note’s secret (via a PRF) and proven in zero-knowledge. Each spend carries a ZK proof that its nullifier was computed correctly, so a given note can produce only one valid nullifier.

Offline, wallets keep a compact local cache of seen nullifiers and verify incoming payments locally. If a duplicate is presented, it’s rejected on the spot. When devices reconnect, the network finalizes the payment by ordering the first valid nullifier it observes and deterministically discarding any later conflicts.

ZERA also employs epoch evolution (fresh, auditable randomness over time) to re-salt proofs and shrink the offline attack window, further bounding risk without relying on vendor-trusted hardware or secure elements.

• Asset model: ZERA is token-native and chain-agnostic - you bring existing assets (e.g., USDC, USDT, SOL) into a unified pool. Bitcoin/Monero/Zcash are standalone currencies; ZERA adds privacy to the assets you already use.
• Privacy by default: Succinct ZK proofs + commitments conceal sender/receiver/amount. Monero/Zcash require specific flows/sets; Bitcoin is transparent by default.
• Offline payments: ZERA supports true device-to-device, offline value transfer with local verification and later chain sync—beyond what major L1s provide.
• Unified pool vs. per-asset silos: A single, compressed pool aggregates privacy across many assets, creating a larger anonymity set and lower state cost than per-asset mixers or coin-specific pools.
• Speed & cost: Built on Solana for low latency and ultra-low fees, with account compression to keep on-chain state small—suitable for everyday payments and high-throughput usage.
• DeFi composability: Shielded balances, planned private routing/relayer integrations, and selective-disclosure modes make ZERA a privacy layer that plugs into wallets, dApps, and institutional workflows—without synthetic pegs or IOUs.

The $ZERA flywheel ties token scarcity to real protocol usage - there are no direct user fees. Instead, adoption triggers programmatic burns that align value with activity.

When users shield assets or perform protocol actions (e.g., deposits, proof generation, offline settlement, cross-chain ops), the system burns $ZERA. Burns are satisfied either from a holder’s balance or via market buy-back & burn if the user doesn’t hold $ZERA. In short: ΔS = β × V (supply reduction equals burn-rate × volume).

• More privacy usage → more protocol volume (V) → more $ZERA burned.
• More burns → lower circulating supply (ΔS < 0) → rising scarcity and stronger value alignment.
• Stronger alignment → attracts builders, integrations, and users → drives more usage—completing the flywheel.

Yes—privacy is by default. Transactions are proved with succinct zero-knowledge proofs over Pedersen commitments and a unified, compressed pool. This conceals sender, receiver, amount, and linkage from on-chain observers while preserving mathematical verifiability.

Correctness (inputs = outputs, membership) is proven without revealing data, and deterministic nullifiers enforce single-spend without identities. For regulated workflows, ZERA supports selective disclosure—you can prove what’s required (e.g., compliance predicates) without exposing full history.

Governance is driven by $ZERA holders through a tiered, time‑weighted voting model - encouraging long-term participation while reducing short-term capture.

Community proposals can configure protocol parameters (e.g., burn coefficients and trigger weights), approve upgrades and deployments (adapters/relayers), and allocate treasury for audits, grants, and ecosystem growth.

Not live yet: the DAO and governance functions will roll out when mainnet release is approaching. Details and timelines will be announced ahead of activation.

We follow a phased, milestone-based roadmap—shipping components as they clear testing and audits (wallet betas, browser demo, SDKs, relayers/adapters, governance, and broader ecosystem integrations). No arbitrary deadlines; readiness drives release.

With the post-migration transition to $ZERA now underway, the public roadmap is being refreshed. The previous roadmap is lagging and will be superseded. We’ll publish an updated, post-migration plan that reflects current sequencing and dependencies.

As development advances, we’ll share timing updates for each milestone rather than fixed dates.Updated roadmap coming soon.