MoneroUSD Protocol
Whitepaper v1.3 — Protocol v1.2.225 · Adds PIR Side-Index, FROST Bridge Custody, Atomic Swaps (zk-v6), Sovereign Web Hosting, IDE & Self-Upgrading Governance
May 2026
Whitepaper v1.3 — Protocol v1.2.225 · Adds PIR Side-Index, FROST Bridge Custody, Atomic Swaps (zk-v6), Sovereign Web Hosting, IDE & Self-Upgrading Governance
May 2026
MoneroUSD (USDm) is a privacy-preserving, overcollateralized USD stablecoin built on a Monero technology fork. It combines Monero's battle-tested privacy infrastructure with stablecoin mechanics to create a digital dollar that respects user sovereignty. USDm is backed by a basket of BTC and XMR reserves that starts at a 150% collateralization floor and is designed to grow toward 400%+ over time as protocol fees, mint bonds, and sovereign-site publish fees accumulate into the reserve. Adaptive fees and usage-proportional emission protect reserve solvency under all market conditions; the ecosystem's own utility is what compounds the buffer.
The protocol employs FCMP++ (Full-Chain Membership Proofs) for transaction privacy, providing an anonymity set equal to the entire UTXO set — a significant improvement over traditional ring signature schemes. All wallet operations are performed locally; private keys never leave the user's machine.
The cryptocurrency ecosystem lacks a stablecoin that genuinely respects user privacy. Existing stablecoins (USDT, USDC, DAI) operate on transparent blockchains where every transaction is publicly traceable. This creates a surveillance infrastructure incompatible with financial privacy.
Monero has proven that privacy-preserving cryptocurrency is viable at scale. However, Monero's price volatility limits its utility for everyday transactions, savings, and commerce. A merchant accepting XMR faces exchange rate risk; a user holding XMR for rent money faces the same.
MoneroUSD bridges this gap: the stability of a dollar-pegged asset with the privacy guarantees Monero users expect. It is not a replacement for XMR — it is a complement to it. Where XMR serves as private digital cash, USDm serves as a private digital dollar.
MoneroUSD is a standalone blockchain forked from Haven Protocol (itself a Monero fork), extended with FCMP++ privacy proofs and a stablecoin reserve system. It runs its own network, consensus, and mining — separate from Monero mainnet.
CPU-friendly PoW, same as Monero
Matching Monero's 2-minute target
Mainnet addresses start with M
Full-chain membership proofs
The desktop wallet operates in a CakeWallet-style model: a local wallet-RPC process handles all cryptographic operations on the user's machine, communicating with a remote daemon for blockchain synchronization only. No relay servers, no session tokens, no cookies. The wallet is a direct peer of the network.
MoneroUSD implements FCMP++ (Full-Chain Membership Proofs with Forward Secrecy), representing the next generation of Monero privacy research. Unlike ring signatures, which provide a fixed anonymity set of 16 decoys, FCMP++ proves that a spent output belongs to the entire UTXO set without revealing which specific output is being spent.
| Property | Ring Signatures (Monero) | FCMP++ (MoneroUSD) |
|---|---|---|
| Anonymity set | 16 decoys per ring | Entire UTXO set |
| Statistical analysis resistance | Vulnerable to intersection attacks over time | Every output equally likely |
| ring_size parameter | 16 (configurable) | 1 (FCMP++ replaces rings) |
| Proof system | CLSAG | Curve tree membership proofs |
The USDm peg is maintained by a crypto reserve consisting of BTC and XMR, held in protocol-controlled wallets under threshold custody. The reserve system enforces a minimum 150% collateralization floor — for every $1 of USDm in circulation, at least $1.50 of crypto assets back it — and is designed to grow toward 400%+ over time. Every protocol fee, every mint bond, every sovereign-site publish fee, and every successful Buy USDm flow routes its over-collateral into the reserve. The ratio is a floor that compounds upward as ecosystem activity accrues.
The reserve health directly controls three protocol parameters: swap fees (Section 7), mining emission (Section 8), and lending capacity. This creates a self-correcting feedback loop — stress conditions increase fee revenue while reducing outflows, naturally restoring reserve health.
The 1.5:1 floor provides a substantial buffer against crypto market volatility from day one — even a 33% decline in BTC/XMR prices keeps the reserve at 100% coverage. The combination of overcollateralization + adaptive fees + emission gating creates three independent defense layers. For comparison, MakerDAO requires 150-175% collateralization for DAI — MoneroUSD's floor is within established DeFi norms.
The crucial design choice, however, is that the ratio is not static. Every fee category in the protocol — swap fees, mint bonds, sovereign-site publish bonds, atomic-swap LP fees, mining fee splits, bridge fees, lending interest splits — routes a share into the reserve. As the ecosystem's utility grows, the reserve grows faster than the float. The system is designed to converge toward 400%+ collateralization over time, at which point even a catastrophic 75% crypto drawdown leaves USDm fully backed. There is no upper limit; the ratio compounds with use.
MoneroUSD supports bidirectional swaps between USDm and two collateral assets: BTC and XMR. The swap protocol uses on-chain verification to ensure atomicity — no trust in third parties required.
The user deposits BTC or XMR to a protocol-controlled address. Once the deposit is confirmed on-chain, the protocol mints USDm. The 1.5x collateral ratio means depositing $150 of BTC yields 100 USDm (minus the fee). The surplus grows the reserve.
The user burns USDm on the MoneroUSD blockchain. Once the burn transaction is confirmed, the protocol pays out the equivalent crypto. The collateral ratio does NOT apply to redemptions — only the adaptive fee is deducted. This ensures users can always exit at close to face value.
Burns are verified at the daemon level using on-chain transaction confirmation via the /get_transactions RPC endpoint. This is more reliable than wallet-RPC methods (which require an open wallet) and works regardless of wallet state. The protocol also supports check_tx_key as a supplementary verification when available.
If a swap fails due to transient issues (network timeout, service restart, temporary resource unavailability), the protocol automatically detects and recovers the swap on the next service restart. Failed burns are reset to their pre-failure state and retried. Users never lose funds due to transient infrastructure issues.
Swap fees dynamically adjust based on reserve health. The base fee rate is 0.5%, competitive with major decentralized exchanges. Under reserve stress, fees increase in predefined tiers to create a natural circuit breaker.
| Tier | Reserve Ratio | Fee Rate | Effect |
|---|---|---|---|
| Normal | > 120% | 0.5% | Standard operation, competitive rates |
| Warning | 100% – 120% | 1.0% | Mildly discourages outflows |
| Stress | 80% – 100% | 2.0% | Strongly discourages outflows, doubles fee revenue |
| Emergency | < 80% | 3.0% | Maximum protection, high fee revenue per swap |
Directly strengthens the backing
Funds staking rewards
Infrastructure and development
The adaptive fee system creates a self-correcting feedback loop. During stress, higher fees simultaneously discourage outflows (reducing selling pressure) and generate more revenue per swap (rebuilding reserves faster). This is fundamentally different from algorithmic stablecoins (like UST) that relied on arbitrage incentives that collapsed under stress. MoneroUSD's fees are a transparent, deterministic circuit breaker — users always know the current rate.
MoneroUSD uses a usage-proportional emission model rather than a fixed block reward. Mining rewards scale with network activity, preventing reserve dilution while rewarding miners proportionally to the value they secure.
Of average fee per block
Minimum USDm per block
Maximum USDm per block
Rewards drop to floor under reserve stress
A fixed emission rate (e.g., 30 USDm/block) creates constant inflation regardless of network usage. In a stablecoin, uncontrolled inflation directly threatens the peg by diluting reserve backing. Adaptive emission solves this: high network activity generates fees, which justify proportionally larger rewards. Low activity means low fees and minimal emission. Under reserve stress, rewards drop to the floor (0.00001 USDm) — mining never stops, because the blockchain's security depends on continuous block production, but emission becomes negligible to protect reserve backing.
Blocks are only mined by the primary node when the mempool contains transactions. A peer node handles keepalive (empty) blocks to maintain chain liveness. This design minimizes unnecessary emission and ensures miner rewards are correlated with actual economic activity on the network.
Accurate, manipulation-resistant price data is essential for a stablecoin swap protocol. MoneroUSD implements a multi-source median oracle with redundancy, caching, and deduplication designed to serve thousands of concurrent users reliably.
| # | Source | Type | Assets |
|---|---|---|---|
| 1 | CoinGecko | Aggregator | BTC, XMR |
| 2 | CryptoCompare | Aggregator | BTC, XMR |
| 3 | Coinbase | Exchange | BTC, XMR |
| 4 | Kraken | Exchange | BTC, XMR |
| 5 | Binance | Exchange | BTC, XMR |
| 6 | OKX | Exchange | BTC, XMR |
| 7 | Bitfinex | Exchange | BTC, XMR |
All 7 sources are queried in parallel. The median price is used — not the mean. Median pricing is resistant to manipulation: even if 3 out of 7 sources are compromised or return outlier data, the median remains accurate. Any source reporting a price more than 10% off the median is flagged and logged for investigation.
MoneroUSD supports collateralized lending, allowing users to borrow USDm against their BTC or XMR holdings without selling them. This preserves crypto exposure while providing stablecoin liquidity.
| Parameter | BTC Collateral | XMR Collateral |
|---|---|---|
| Max Loan-to-Value | 60% | 55% |
| Liquidation Threshold | 65% | 65% |
| Interest | Variable, market-driven | Variable, market-driven |
| Collateral Ratio | > 150% at all times | > 150% at all times |
The lower LTV for XMR reflects its higher volatility relative to BTC. Liquidation triggers at 65% LTV, giving borrowers a 5-10% buffer to manage their positions. All loan interest flows into the yield pool, which funds staking rewards — creating a closed economic loop where borrower demand generates staker yield.
USDm holders can stake their tokens for yield, with higher rates for longer lock periods. Critically, yield is paid exclusively from lending interest — never from reserves or newly minted tokens.
| Lock Period | APR | Withdrawal |
|---|---|---|
| Flexible (no lock) | 1.5% | Anytime |
| 30 days | 3.0% | After lock expires |
| 90 days | 4.5% | After lock expires |
| 180 days | 6.0% | After lock expires |
The MoneroUSD desktop wallet follows a local-first, CakeWallet-style architecture. Private keys are generated and stored locally on the user's machine. All cryptographic operations (signing, proof generation) happen locally via a bundled wallet-RPC process.
MoneroUSD is designed for easy node deployment. The desktop wallet includes a one-click node manager that downloads the daemon binary, configures the data directory, starts syncing, and automatically connects the wallet to the local node upon successful verification.
The wallet supports three daemon connection modes, selectable at runtime with no restart required:
get_info probe confirms the remote daemon is reachable and running USDmd. Non-USDm endpoints are naturally rejected by response validation.Switching between modes uses a fast path (set_daemon RPC) when only the daemon address changes, avoiding a full wallet-RPC restart. The wallet auto-refreshes balances and sync state after every switch.
When a local node is running, the wallet automatically starts CPU mining on three code paths to ensure blocks are always produced:
onLocalNodeRestarted event.Mining uses background mode with configurable thread count (default 2). This ensures the blockchain always advances, even when only a single local node is running.
The block height displayed in the Local Node panel is interactive. Clicking it navigates the in-app dApp browser to the MoneroUSD block explorer at that specific height, providing instant visibility into block contents, transactions, and miner rewards without leaving the wallet.
An expandable Advanced Options panel provides power-user controls: daemon address input, VPS connectivity testing, and custom node configuration. The panel is styled for discoverability (visible accent border) but collapsed by default to keep the primary UI clean. All inputs use .textContent assignment (never innerHTML) to prevent XSS, and daemon processes are spawned with array-based arguments to prevent shell injection.
For VPS operators and terminal users, a single-command installer handles platform detection, binary download with SHA256 verification, directory setup, and optional systemd service creation. Both desktop and terminal methods use checkpoint-based fast-sync: hardcoded block hashes at known heights allow new nodes to verify chain integrity via hash comparison rather than re-validating every historical transaction. This is cryptographically sound — a block hash commits to the entire block content including all transactions, so a matching hash at height N transitively proves all blocks 0..N are correct. Blocks above the checkpoint height receive full validation: adaptive LWMA difficulty, PoW verification, miner transaction validation, FCMP++ proof verification, and double-spend checks.
Network ports: P2P sync on 17749, daemon RPC on 17750, restricted RPC on 17751 (public nodes), wallet-RPC on 27750. Seed node discovery via seed.monerousd.org with hardcoded IP fallback for DNS failure resilience. For full setup instructions, see Run a Node.
Privacy in MoneroUSD does not stop at the user's transaction layer. The network operators — the people running daemons and the validators securing bridge custody — are designed to be pseudonymous + un-correlatable by default. A network whose users are private but whose operators must publish their hosting addresses, IPs, and identities is not actually private; it is just a surveillance graph one degree deeper. MoneroUSD treats infrastructure privacy as a first-class concern.
USDmd inherits the standard CryptoNote SOCKS-proxy and hidden-service primitives (--tx-proxy, --p2p-bind-port-tor, --anonymous-inbound). Operators can run a daemon as a Tor hidden service; wallets connect to the .onion address through the bundled Tor supervisor without ever revealing their IP to the daemon host. Both the wallet's "Local Node" toggle and the operator-curated public node list accept .onion endpoints natively. A user who never wants to reveal their IP can run a fully sovereign stack — local wallet + local Tor + .onion-only remote daemon as fallback — with one click in Settings.
Every component of the desktop wallet that handles sensitive state binds 127.0.0.1 only: wallet-RPC on :27750, the dApp-browser authentication proxy on :27751, the sovereign-server on :27752, the bundled Tor SOCKS5 listener on :19150. The bindings are enforced at the OS socket level, not at application-CSP level — a misconfigured firewall, a NAT misadventure, or a malicious local app cannot accidentally expose any of these to the public internet. The wallet's attack surface for a remote adversary is exactly the network calls it makes outbound, never an inbound port.
Mining produces blocks — the settlement layer for every protocol primitive — and mining payouts are stealth-addressed by the same FCMP++ machinery that protects ordinary transactions. The pool stratum supports incoming connections via Tor SOCKS5, so a miner's IP is unlinked from both the pool operator and from the on-chain emission payouts. There is no KYC at any layer; a miner's only protocol-visible artifact is the payout subaddress they nominate, which carries no link to off-chain identity.
Becoming a bridge validator requires exactly two things: a USDm bond and a libp2p PeerID. There is no KYC, no jurisdiction binding, no real-name disclosure. The validator's bond ed25519 pubkey appears on chain (necessary for FROST signature aggregation), but the validator's IP address, hosting provider, geographic location, and real identity remain entirely off-chain and off-platform. A validator who participates from a censored jurisdiction is operationally indistinguishable from one in a permissive jurisdiction; the protocol simply does not encode where its operators live.
FROST sign rounds and DKG ceremonies operate over a libp2p peer-to-peer mesh secured with Noise-XX handshakes. Validators identify each other by 32-byte derived peer IDs, not by hostname, registry entry, or contact list. The mesh has no central coordinator with a master list of validator endpoints — there is no single registry to be compelled, subpoenaed, or correlated. Each validator's host learns its peers' PeerIDs through gossip, and PeerIDs by themselves cannot be linked to real-world infrastructure unless an operator chooses to publish that linkage.
Validator signer daemons inherit libp2p's transport-agnostic design. A signer can serve over Tor, I2P, plain TCP, or any future libp2p transport with no protocol change. A validator operating from a censored jurisdiction can run an onion-only signer; their participation in FROST sign rounds is cryptographically indistinguishable from a validator on a residential IP. This is the property that lets the validator set grow into any jurisdiction without exposing earlier participants to the new arrival's threat model.
The following table compares MoneroUSD against major stablecoin designs across dimensions that matter most to users who value privacy and sovereignty.
| Feature | USDT / USDC | DAI | UST (failed) | MoneroUSD |
|---|---|---|---|---|
| Privacy | None (transparent ledger) | None (Ethereum) | None (Terra) | FCMP++ (full-chain privacy) |
| Backing | Fiat reserves (trust required) | Overcollateralized (150%+) | Algorithmic (failed) | Overcollateralized (150%+ BTC/XMR) |
| Centralization | Centralized issuer | Semi-decentralized (MKR governance) | Decentralized (failed) | Decentralized (protocol-enforced) |
| Censorship Resistance | Can freeze addresses | Moderate | N/A | Full (Monero-level) |
| Mining | None | None | None | RandomX CPU mining |
| Auditability | Attestations only | Full (Ethereum) | N/A | View key verification |
| Self-Custody | Optional (exchange-dependent) | Yes (Ethereum wallet) | N/A | Required (25-word seed) |
DAI is the closest comparable system in terms of collateralization. The key differences are privacy (DAI is fully transparent on Ethereum, MoneroUSD uses FCMP++) and governance (DAI relies on MKR holder votes, MoneroUSD uses deterministic protocol rules). The tradeoff is that MoneroUSD does not benefit from Ethereum's DeFi composability, operating instead as an independent chain optimized for private value transfer.
The three-layer defense system (150% overcollateralization + adaptive fees + emission gating) provides defense-in-depth against reserve depletion. Unlike algorithmic stablecoins that rely on market confidence, MoneroUSD's reserves are real crypto assets held in protocol wallets.
Median pricing across 7 independent sources makes oracle manipulation economically infeasible — an attacker would need to compromise 4+ sources simultaneously to move the price. Outlier detection provides real-time alerting for attempted manipulation.
All protocol services use systemd process management with automatic restart, port cleanup on startup (preventing stale process conflicts), and rate limiting. Transient failures trigger automatic recovery rather than permanent failure states.
FCMP++ provides unconditional privacy — all transactions use full-chain membership proofs regardless of transaction type. There is no "transparent mode" or privacy opt-out. The protocol treats privacy as a fundamental right, not a feature toggle.
Ion Swap is MoneroUSD's native decentralized exchange (DEX), operating at ion.monerousd.org. It provides private automated market-making (AMM), dark-pool limit orders, a PoW mining pool, and multi-asset bridging — all inheriting FCMP++ privacy at the consensus layer. Every swap, every liquidity position, and every limit order is private by default. There is no transparent mode.
Ion Swap uses a sealed-bid batch AMM based on the Uniswap v2 constant-product formula (x × y = k). Unlike conventional DEXs where trades execute immediately and are visible in the mempool, every Ion Swap trade goes through a mandatory commit-reveal cycle that makes front-running and MEV extraction cryptographically impossible.
Large trades can be placed as encrypted limit orders on Ion Swap's dark-pool book. Orders are encrypted with the committee's public key. The committee decrypts and matches orders internally, publishing only per-block net flow — individual order details remain hidden from all observers.
Every fee collected anywhere in Ion Swap routes through a non-configurable split, enforced at the settlement layer. The split is frozen at release time and cannot be adjusted at runtime — it is a protocol constant, not an operator parameter.
| Source | Rate | Reserves | POL | Bounty |
|---|---|---|---|---|
| Standard swap | 30 bps | 60% | 30% | 10% |
| Stable-pair swap | 5 bps | 60% | 30% | 10% |
| Dark-pool match | 20 bps | 60% | 30% | 10% |
| Flash-loan | 9 bps | 70% | 20% | 10% |
| PoW mining pool | 1% | 80% | — | 20% |
| Merchant invoicing | 30 bps | 60% | 30% | 10% |
| Bridge wrap/unwrap | 10 bps | 70% | 20% | 10% |
| Token creation bond | Flat | 60% | 30% | 10% |
| NFT royalty | 200 bps | 50% | 30% | 20% |
Every feature in Ion Swap is designed to be reserve-accretive or reserve-neutral. No feature can drain MoneroUSD reserves. LP rewards never come from minted USDm — only from accumulated fee revenue, hard-capped by the reserves slice collected each block.
USDm issuance operates on two rails, selected automatically based on the source asset's class. Users see a unified interface; the protocol dispatches internally.
Ion Swap supports bridging from 12+ home chains. Every bridge operation follows a zero-deposit model — the user's wallet only needs the asset being bridged, never a separate gas token. Bridge relayers pay all source-chain gas via chain-appropriate fee-delegation mechanisms.
BTC, XMR, ETH, LTC, DOGE, SOL, ADA, BCH
USDC (Stellar, Algo, Hedera, ETH, SOL), RLUSD, USDT
Private fungible tokens with FCMP++ privacy
Hidden ownership, encrypted content, view-key reveals
Every asset on the MoneroUSD network is identified by a unique ion1_ token address — a 69-character identifier derived from a BLAKE2b-256 cryptographic hash. Token addresses provide a universal, privacy-preserving identification scheme for both protocol-native verified assets and user-created custom tokens.
For protocol-native verified assets (USDm, wBTC, wXMR, wETH, etc.), addresses are derived deterministically from the protocol identifier: BLAKE2b("MoneroUSD_protocol_asset:" + symbol). These addresses are permanent, reproducible, and independently verifiable. For user-created custom tokens, addresses are derived from the creator’s stealth key and a random salt: BLAKE2b(creatorStealth + randomSalt). This ensures that custom token addresses are unique and privacy-preserving — the address reveals neither the creator’s identity nor the token’s name.
Version byte 1 — distinguishes token addresses from wallet addresses and tx hashes
CryptoNote-native hash function — same as key derivation and tx hashing
5-char prefix + 64 hex digits (256-bit security)
Custom token addresses hide creator identity via stealth key + random salt
ion1_ prefix (version 1) enables future address format upgrades without ambiguity.
Ion Swap includes several privacy-first features that are impossible on transparent blockchains. Each generates protocol revenue and strengthens reserves.
Scheduled recurring swaps with time jitter to break correlation patterns
Merchants receive any asset, settled privately via stealth subaddresses
Enforced .onion routing, fresh subaddresses, no localStorage
Borrow + repay in one batch window. 9 bps fee to reserves
Pedersen-committed savings vault earning fee-split yield
Confidential asset tags hide even the asset type from observers
Ion Swap operates a Stratum V2 + RandomX mining pool for USDm hashrate. PPLNS payout with per-miner variable difficulty. Username is a USDm wallet address — no account creation required. A Tor (.onion) stratum endpoint provides IP privacy for miners.
80% to reserves, 20% to bounty
Sliding window share accounting
Per-miner adaptive adjustment
The protocol includes automated reserve-recovery mechanisms that activate during market stress. Critically, no feature is ever halted or disabled — the Monero ethos requires recovery through increased fees, not restrictions.
Ion Swap is non-custodial. The operator does not hold user funds — every reserve wallet, pool wallet, and swap-signing key is bound to the protocol itself and governed by the settlement rules encoded on the USDm chain. The backend publishes a Merkle root of all pool state (reserves, positions, balances) to the USDm chain each block. Every swap is signed by the protocol's settlement key under rules the operator cannot modify, pause, or freeze at runtime. A discrepancy between the signed receipt and on-chain settlement constitutes a cryptographic fraud proof.
The MoneroUSD base layer defines a fixed set of protocol operations — token create, LP mint/burn, bridge wrap/unwrap, NFT mint, limit order, DCA, savings — each dispatched through a hardcoded opcode inside the attestation monitor. This scales cleanly through v1, but every new protocol feature requires a coordinated change across the backend monitor, the wallet's approval-modal renderer, and the indexer's state-derivation logic. Past that point, most of the interesting things developers want to build on Monero-style economics do not belong in the core backend — they belong in user-deployed contracts.
Dark Contracts extend the attestation dispatcher into a programmable virtual machine. Developers write in DarkSolidity (DSOL), a Solidity-like language with privacy-native types and commit-reveal semantics. The compiler emits .dc bytecode that runs in a deterministic off-chain VM, DarkVM, hosted identically by every Ion Swap indexer operator. Every state mutation lands in the same append-only pool_events log that the existing Merkle publisher anchors to the USDm chain each block — Dark Contracts inherit the base layer's consensus-by-convention discipline without adding a new publisher path.
The goal is to match Solidity's developer UX while surpassing it on privacy. Five capabilities that transparent smart-contract chains fundamentally cannot offer are native here:
@batch attribute. There is no public mempool race window.msg.sender resolves to a caller's stealth address, not a persistent account. The same user signs successive calls from different stealth identities with no on-chain linkability.syscall(BRIDGE_WRAP) / syscall(BRIDGE_UNWRAP) host-call forms let DSOL contracts pull wBTC, wXMR, wETH, and other wrapped assets into contract logic without revealing amounts.The DarkVM is a pure-JavaScript stack machine with approximately 60 opcodes. It uses BigInt throughout — no Number, no Date, no Math.random — so every indexer operator running the same bytecode converges on byte-identical state. The interpreter is auditable end-to-end in roughly a week of review. A WASM backend is planned for Phase 3 performance work; the bytecode semantics do not change.
Resource discipline is intentionally flat, not market-priced. Every call pays a fixed 0.1 USDm fee and is capped at 1,000,000 instructions and 256 KB of combined stack + heap memory. The limits are constants, not parameters, so no two indexers can ever disagree on whether a given call halted successfully or ran out of budget. This trades the flexibility of per-opcode gas for a stronger consensus guarantee — in line with the broader Monero ethos of avoiding fee auctions wherever possible.
DSOL is a Solidity-dialect source language. The compiler lowers DSOL source through an abstract syntax tree, a typed intermediate representation, and a code generator that produces the .dc bytecode artifact plus a companion abi.json descriptor. Source is advisory; bytecode is the consensus artifact. The compiler ships inside the desktop wallet so every user can compile and sign a contract deployment locally, without uploading source anywhere.
A production-ready private ERC-20 analogue in DSOL:
Three require guards on transfer are mandatory across every DSOL transfer entrypoint — amount > 0 rejects no-op gas-burn calls, to != msg.sender rejects no-op self-transfers, and the balance check rejects overdrafts. The compiler does not insert these for you. v1.2.182's production-readiness sweep made them mandatory across the standard library; any contract that ships without them is a regression.
Four language constructs do most of the privacy work:
private fields are Pedersen-committed on every write; range proofs are emitted at reveal time.@batch on an entrypoint forces the commit-reveal cycle so the call cannot be front-run — the compiler emits a REQUIRE_COMMIT_REVEAL preamble that the runtime enforces (invariant DC-4).emit encrypted AES-256-GCM-wraps the event payload using a key derived via HKDF-SHA256 from the caller's viewkey, the contract id, and the event name — only the caller can decrypt.when revealed on a return type compiles to an explicit open-and-prove: the compiler auto-generates the range proof and encrypts the opened value to msg.sender, so a public getter is actually a per-caller private disclosure.Phase 3 of the language adds Solidity-familiar constructs: is inheritance with C3 linearization, modifier declarations inlined per-entrypoint, and EXT_CALL_TAIL — an inter-contract call restricted to tail position. Tail-only calling eliminates reentrancy by construction, because there is no caller frame to return into. Upgrades are expressed through a nullifier-gated proxy pattern rather than mutable bytecode, preserving invariant DC-13.
deriveDarkState pass picks up every state diff deterministically; the explorer decodes arguments against abi.json.Scheduled logic is handled through a permissionless keeper model. Contracts expose a public tick() entrypoint that anyone can call for a per-call bounty; there is no per-block "run every contract" loop that would force every indexer to do work the operator may not care about. Contracts the operator is not interested in can be replayed lazily on demand — the /v1/contracts/:id endpoint surfaces a lastComputedBlock so clients can tell whether they are looking at up-to-date state.
Dark Contracts layer fifteen invariants on top of the existing base-layer rules. Each one has a single enforcement point so the audit surface stays small.
| # | Invariant | Enforcement |
|---|---|---|
| DC-1 | Deterministic execution | Pure-JS BigInt VM; no Number / Date / Math.random; typecheck rejects non-deterministic sources. |
| DC-2 | Step-limit termination | 1,000,000-opcode counter in vm.js::execute; overrun aborts the call, rolls back state, keeps the fee. |
| DC-3 | Memory-limit termination | Per-call 256 KB cap tracked across stack + heap. |
| DC-4 | Commit-reveal for private mutations | Compiler emits REQUIRE_COMMIT_REVEAL preamble; runtime rejects direct calls. |
| DC-5 | Nullifier uniqueness | contract_nullifiers primary-key enforcement; duplicate insert aborts the tx. |
| DC-6 | No plaintext private state in public APIs | /v1/contracts returns commitment hex + range-proof hash only. |
| DC-7 | Syscall allowlist | Frozen table in host.js; unknown codes yield DC_SYSCALL_UNKNOWN. |
| DC-8 | Syscall invariants propagate | Host forwards to existing base-layer handlers; same rules apply. |
| DC-9 | State anchored every block | Existing pool_events + Merkle publisher pipeline; zero new publisher code. |
| DC-10 | Deployment bond non-refundable | Re-uses the same bond path as TOKEN_CREATE. |
| DC-11 | No transparent call path | No HTTP route mutates contract state; only attestations can. |
| DC-12 | No pool_events bypass | Single writer always emits the event inside the mutation's transaction. |
| DC-13 | Bytecode immutable | code_hash update trigger denies mutation; upgrades flow through the proxy pattern only. |
| DC-14 | Compile-time privacy analysis | Typecheck runs information-flow analysis: private → public without when revealed is a compile error. |
| DC-15 | Wallet decodes before approval | The approval modal decodes DC_CALL arguments against ABI; loud warning if the ABI is missing. |
Dark Contracts are strictly additive. The hardcoded fast path for TOKEN_TRANSFER, LP_MINT, BRIDGE_WRAP, and the other v1 opcodes remains unchanged — any asset the base layer already tracks keeps its fast-path guarantees. New DSOL contracts that need those primitives reach them through the syscall interface (syscall(TOKEN_TRANSFER_EMIT, {...})), which forwards into the exact same backend handler that processes the hardcoded path. The on-chain token_transfer, bridge_mint, and bridge_burn events are byte-identical whether a base-layer op or a Dark Contract produced them, so indexers require no special-casing.
Inter-contract calls are restricted to tail position through the EXT_CALL_TAIL opcode. This removes the entire class of reentrancy vulnerabilities that have driven most historical smart-contract exploits on transparent chains — there is no caller frame to return into, so there is no window in which a callee can re-enter a mid-execution caller. Arbitrary call graphs are intentionally deferred; they will return only alongside a formal reentrancy discipline.
Two security rules are now binding on every DSOL contract that lands in the wallet bundle:
operatorStealth set at deploy may call any function that mutates state attributed to a specific actor, acts as a privileged operator, or modifies another actor's resource. Comments-as-authorization (e.g. // operator-only without the matching require()) are forbidden — that bug class produced two critical findings in the v1.2.182 audit.msg.sender guards on every privileged path, positivity checks on numeric inputs, self-transfer + zero-destination checks on transfer paths, unique nullifiers per authorized intent, and parent-guard replication across every override. The full DSOL test suite must pass.require() chain is one layer; the backend canonical-handler check (e.g. tokens/mint.js::mintSupply validating creator_stealth === ctx.callerStealth) is another. Both must hold for the operation to land. A DSOL bug that bypasses one layer is caught by the other.Pedersen commitments hide values, but a commitment alone cannot prove the value is in a sensible range. Without a range proof, a malicious party could commit to a negative balance, an absurdly large overdraft, or any other field-element value the verifier cannot directly inspect. Bulletproofs++ closes that gap: it lets a prover demonstrate that a committed value lies in [0, 264) without revealing the value itself, in 544 bytes per proof, with no trusted setup.
The MoneroUSD verifier is a clean-room implementation in approximately 2,660 lines of pure-JavaScript BigInt arithmetic — auditable end-to-end, deterministic across every indexer operator, and live across the protocol since v1.2.182. Soundness defenses were validated against the twelve-item attack-surface review in BPP-AUDIT.md, with 250 adversarial tests covering torsion-point rejection, non-canonical scalar refusal, transcript-replay resistance, and prover/verifier fold-round consistency.
Bulletproofs+ (BP+, single-plus) is the proof system shipping today inside Monero's base layer. Bulletproofs++ (BP++, double-plus) is the next-generation construction by Eagen, Kanjalkar, Ruffing, and Nick (IACR ePrint 2022/510, EUROCRYPT 2024) that swaps BP+'s inner-product argument for the weighted norm linear argument (WNLA) built on top of a reciprocal set-membership argument. Practical wins:
vs ~672 B for BP+ on the same 64-bit range
End-to-end on commodity hardware
Pure DL hardness on ed25519
WNLA composes for batch range proofs
The Bulletproofs++ verifier is implemented as a stack of four well-defined pieces, each independently testable. The combined module is approximately 2,660 lines of JavaScript, audited end-to-end (see BPP-AUDIT.md) against twelve attack-surface items.
X into k digits in base b, then proves digit-validity via the identity ri · (di + e) = 1 where e is a Fiat-Shamir challenge. The trick: this identity holds iff every di is in [0, b). Canonical parameterization for uint64 is k = b = 16.n vectors, emitting one cross-term commitment (R, X) pair per fold round. For canonical parameters, four fold rounds shrink the proof to two final scalars per side.BPPP-V1-) sequence of length-prefixed appends. Every challenge is non-zero-checked. The same transcript shape is replayed by the verifier — any prover/verifier divergence on a single byte produces a different challenge and the proof is rejected.The serialized proof is fixed-length for given (Nd, Np) = (16, 16):
The byte layout has no internal length prefixes — the deserializer parses by offset. Two byte sequences of the SAME length cannot decode to the same proof because every field is bijective at its offset, so malleable-serialization attacks (A4 in the audit) are foreclosed by construction.
Dark Contracts call the verifier through a single syscall:
The syscall charges 100,000 instruction steps (10% of the per-call 1,000,000 budget) — heavy enough to deter contracts that loop on verification, cheap enough that ~10 verifications per call are economically reasonable. Step-cost is consensus-relevant: every indexer running the same bytecode on the same input consumes the same budget.
Twelve attack-surface items (A1–A12) were enumerated in the original spec and covered by adversarial tests before activation. Highlights:
| # | Attack | Defense |
|---|---|---|
| A1 | Small-subgroup point input | Every deserialized point routes through assertPrimeOrder backed by noble's isTorsionFree(). Tested against all 7 real ed25519 torsion points + a contamination case. |
| A4 | Malleable serialization | Fixed-length wire format (no internal prefixes); length mismatch throws BPPP_WIRE_LENGTH_MISMATCH. |
| A5 | Zero / edge-case challenge | challenge() loops on zero; every consumed challenge is in [1, L). |
| A8 | Non-canonical scalar (≥ L) | scalarFromBytes32 rejects encodings whose value reduces to a non-canonical representative. |
| A9 | Compressed-point ambiguity | noble's canonical fromHex rejects y ≥ p + off-curve encodings. |
| A12 | WNLA fold inconsistency | Pure-function fold-count derivation from (Nd, Np) guarantees prover/verifier agreement. |
Out-of-scope items, declared explicitly: side-channel timing leaks from the prover (the verifier runs in trusted contexts; the prover's wallet is not the threat model), and quantum resistance (BP++ relies on DL hardness, broken by Shor — same posture as the rest of the MoneroUSD stack).
The complete defense matrix lives in BPP-AUDIT.md. Total tests: 250 (229 in bulletproofs-plus-plus.test.js + 14 in bppp-integration.test.js + 7 in pedersen.test.js).
Every Dark Contract has direct access to the verifier via syscall(VERIFY_RANGE_PROOF_BPPP_V1, …), and every Pedersen-committed value the protocol emits — LP positions, custom-token balances, NFT rarity commitments — is range-bounded by a 544-byte BP++ proof. pedersen.js::rangeProof() emits the canonical (commitment, proof) pair as 576 bytes; consumers parse by fixed offsets, and any byte tampering produces an immediate length-mismatch reject before the cryptographic check runs.
Wallet restore is the single most user-visible slow path in any cryptocurrency. On a wallet with 17,000+ historical transactions, a classical chain scan walks every block looking for outputs the receiver can claim — minutes of wall-clock time, every device, every time. MoneroUSD addresses this with a two-layer architecture: a Light Wallet Server (LWS) for cross-device fast restore, and a PIR layer over an FCMP++-anchored side-index for queries that don't leak the receiver's address.
Each wallet derives a scope key pair from its spend key via HKDF-SHA512(spend_priv, "monerousd-lws-scope-v1"). Receivers publish ECIES-encrypted SCOPE_TAG_V1 entries keyed by scope_id = SHA-256(scope_pub)[..8]. Senders embed the SCOPE_TAG in the carrier transaction's tx_extra, so the daemon's block-time parser indexes every confirmed output as it arrives — no operator needs to backfill historical state.
The LWS index is operator-run but operator-blind: it stores ECIES ciphertext keyed by 8-byte scope_id. The operator can see that a given scope_id has N entries but cannot learn the receiver's address, the amount, the sender, or any correlation across different scope_ids. Forging entries is impossible (ECIES AEAD catches that), and the wallet's spend_priv never leaves its process.
The original SCOPE_TAG plaintext encoded only (output_idx, view_tag_hint, amount_hint) — implicitly USDm-only. V1.5 appends a 32-byte token_id slot (all-zero = USDm sentinel; SHA-256("ion1_asset_v1/" + symbol) for wrapped or custom tokens). Receivers detect shape by decoded plaintext length: 13 bytes = v1 (legacy), 45 bytes = v1.5. A single LWS query during welcome-restore now returns USDm + every wrapped/custom token the user has received, all rendered in < 2 seconds.
An encrypted scope-tag index is fast but leaks query patterns: the operator can see which scope_id a wallet reads, even when it cannot decrypt the entries. The PIR layer closes that gap by routing every scope-id query through a SimplePIR (Henzinger et al., USENIX Sec 2023) round over the FCMP++-anchored side-index. The operator sees only an opaque LWE-encoded query vector; it cannot determine which scope_id the wallet read, nor whether the entry was found.
Operator can't correlate scope_ids across queries by the same wallet
8 fixed PIR queries per scope_id, parallel — independent of result existence
Daemon hashes side-index root every block; tampering rejected at consensus
SimplePIR over secp256k1-equivalent — DLOG-hard
The USDmd daemon maintains a side_index LMDB table mapping scope_id → ECIES ciphertext entries. Every block's parser walks new transactions' tx_extra for SCOPE_TAG_V1 tags and appends matching entries; rollbacks atomically undo the same way the main UTXO state does. A Merkle root over the side-index is committed in each block header, so a third-party verifier replaying the chain produces a byte-identical index — operator integrity is enforced at the consensus layer, not by trust.
Daemon-side EC validation rejects malformed entries at block time (BIP-340-style point-on-curve check via rct::toPointCheckOrder). The PIR retrieval uses a collision-immune row layout with linear probing (MAX_PROBES = 8, fixed regardless of whether the entry exists) so the operator can't learn found-vs-not by query timing or response shape. A real Rust libfcmp_pir.a handles the LWE math; the wallet's JS reference impl is byte-for-byte parity-tested against it (250+ assertions across 18 distinct gates, all green).
First restore on a fresh device: sub-second balance + full asset rendering, no chain scan, no operator visibility into which addresses you're asking about. Subsequent restores on the same device: the cache survives across launches and never re-queries the LWS. A user who runs their own daemon gets identical results from the side-index they themselves committed to — no operator trust required at any layer.
Bridge reserves — the BTC, XMR, ETH, and other crypto that backs every wrapped asset on the MoneroUSD chain — are held under FROST t-of-n threshold custody, not single-key operator hot wallets. A single host compromise CANNOT move funds; an attacker needs simultaneous compromise of at least t independent signer hosts.
The threshold scales as t = floor(2n/3) + 1 — pure Byzantine fault tolerance. The validator set is designed to grow over time: new validators join via the existing DKG2-add ceremony, and the threshold automatically recomputes to maintain 2/3+ as n grows. The group public key stays the same (so reserve addresses remain stable), but the access policy strengthens with every new member. As the set matures, no minority can move funds and no single host compromise threatens reserves.
| n validators | t threshold | Attacker needs |
|---|---|---|
| 3 | 2 | 2 simultaneous host compromises |
| 10 | 7 | 7 simultaneous compromises across operator orgs |
| 21 | 14 | 14 simultaneous compromises |
| 100 | 67 | 67 simultaneous compromises across 67 independent orgs |
FROST does NOT require manual sign-off per claim. Each validator runs a signer daemon — a long-running process holding that validator's share, listening on a libp2p mesh for sign-round requests. When the chain monitor sees a confirmed deposit:
t validators agree, partial sigs aggregate into a BIP-340 Schnorr signature valid for the FROST group key.The whole flow is sub-second wall-clock when validators are healthy. A compromised coordinator can ask for a signature but cannot bypass any validator's policy. To drain reserves an attacker must compromise t independent hosts, each independently rejecting the malicious request based on its own indexer view.
The BTC FROST implementation uses FROST(secp256k1, SHA-256, TR) — BIP-340 Schnorr signatures over secp256k1, compatible with Taproot key-path spends. The XMR side uses Monero's native N-of-M wallet-multisig via monerod-wallet-rpc. Each chain's FROST infrastructure is independently DKG'd (no shared secret material across chains) so a compromise of one chain's quorum doesn't cascade.
For Taproot outputs with script trees (e.g. the user-refundable HTLCs in the Buy USDm flow), the signer applies the BIP-341 tap-tweak to its key share before signing: d' = d + t_tap (mod n) where t_tap = tagged_hash("TapTweak", internal_xonly || merkle_root). The resulting signature verifies against the tweaked output key on chain — no validator ever sees the user's actual destination, only its tap-leaf hash.
The 150% PSM mint flow (deposit BTC, receive USDm) is the central reserve-growing flow. The deposit address is no longer a single-key operator hot wallet — it's a per-intent BIP-341 Taproot output:
<timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP <user_xonly> OP_CHECKSIGThe same architectural pattern extends to wXMR (Monero atomic-swap with multi-sig) and the wETH/wSOL/wADA/wRLUSD wrappers (each chain's native multi-sig primitive). The protocol-level intent — "script-lock the deposit window, FROST-quorum the claim" — is identical regardless of the chain.
Layered on top of FROST custody is a second, complementary bridge architecture: peer-to-peer atomic swaps, where bridging happens directly between a user and a liquidity provider with no central operator in the loop. Subpoena-resistant by construction — there is no protocol operator that can be compelled to reveal user-to-mint mappings, because there is no such mapping recorded anywhere.
A user wanting wBTC (or wanting to redeem wBTC for BTC) finds an LP via the off-chain offer mesh, agrees on a price, and executes a four-phase swap:
AtomicSwapEscrow.dsol Dark Contract.t_user on the USDm chain.t_user in the published USDm sig, uses it to claim the BTC HTLC. Swap complete.Adaptor signatures (Aumayr-Maffei-Moreno-Sanchez-Riahi, Asiacrypt 2021) make the two-chain settlement atomic: completing one chain's signature is mathematically equivalent to revealing the secret that completes the other. Neither party can unilaterally claim without releasing the value the counter-party needs.
From the chain analyst's perspective: the BTC chain shows "X BTC moved from user-address to LP-address." The USDm chain shows "X wBTC moved from LP-stealth to user-stealth." The linkage between the two — the same adaptor secret t on both — exists only in the signature bytes; recovering it requires the discrete log problem.
codeHash d1017d4242a3cc8b…). Three entrypoints: lock(), claim(), refund().VERIFY_SCHNORR_ADAPTOR_V1, ESCROW_LOCK_V1, ESCROW_RELEASE_V1. Step cost 100,000 each./v1/atomic-swap/offers) where LPs publish signed offers and users browse them. Operator cannot alter offer parameters or learn user-LP linkages./v1/atomic-swap/contract resolves the canonical AtomicSwapEscrow contractId from chain state by codeHash, with no hardcoded values on either client or server.v6 atomic swaps and the FROST-quorum PSM mint coexist: PSM mint is the high-throughput, predictable-price path for everyday Buy USDm; atomic swap is the operator-less, peer-to-peer path for users who prefer market-rate value-for-value trades. Same wrappers, same chain, different trust models.
Every protocol whose UI lives on a single DNS hostname is one registrar takedown, one TLS revocation, one edge outage away from invisibility. MoneroUSD addresses this by mirroring every official front-end — monerousd.org, ionswap.monerousd.org, explorer.monerousd.org, ide.monerousd.org, installers.monerousd.org — on chain, with the desktop wallet serving byte-identical copies from a local HTTP server.
Every desktop wallet ships every official site in its installer. Zero network round-trips. SHA-256 verified against the chain anchor before serving.
Per-site SITE_PUBLISH attestation records the bundle's root hash + size + content-type on the USDm chain. site-updater.js background-polls indexer operators for newer versions, verifies hash, atomically swaps.
Wallet can be pointed at a local dev directory for active site development. Marked "⚠ Dev mode" in the UI; never confused with verified content.
Sovereign hosting is governed by twenty cryptographic + architectural invariants enforced in code:
SITE_TRANSFER.window.monerousd throws SOVEREIGN_SANDBOXED until the user explicitly opts in. Verified sites get the provider unconditionally.nodeIntegration:false, contextIsolation:true.localhost:8080 shows the same on-chain anchor as ide.monerousd.org, because the bytes match by design.If monerousd.org goes dark — registrar pressure, TLS revocation, CDN kill — every installed wallet keeps serving the full UI surface locally. New installs can pull the bundle from any indexer operator, BitTorrent fallback, or another user's wallet over a libp2p mesh. The fees that fund this layer route entirely to the reserve, so the protocol grows stronger as developers publish more dapps.
The MoneroUSD IDE (ide.monerousd.org) is a browser-based development environment for the DSOL Dark Contract language: editor, compiler, browser-side DarkVM preview, on-chain DC_DEPLOY + DC_CALL_*, and SITE_PUBLISH for sovereign sites — all without leaving the wallet's approval flow.
ide.monerousd.org), wallet launchpad <webview>, and sovereign mirror (localhost:27752/ide.monerousd.org/). All three serve byte-identical bytes by design.SYSCALL_PREVIEW_DISABLED by design). Lets developers verify logic before deploying.window.monerousd.deployContract / window.monerousd.callContract. Every chain-touching action goes through the wallet's standard approval modal — no new approval surface in the IDE.The IDE ships with six DSOL templates (counter, token-transfer, erc-private, NFT collection, voting, escrow) and four site templates (blank, single-page bio, blog, dApp shell). The full DSOL language reference, the PROTOCOL-DC-V1 ABI, and the sovereign-site PROTOCOL-SITES-V1 ABI are bundled in the Reference panel for offline access.
The IDE was itself published to ide.monerousd.org via its own SITE_PUBLISH flow — the recursive bootstrap. The first sovereign site that publishes sovereign sites is a sovereign site.
The MoneroUSD ecosystem is community-owned. Every parameter that can change without breaking core invariants is governed by on-chain proposals; a small set of core invariants are protected by defense in depth across multiple independent layers. There is no admin key, no founder backdoor, no upgrade authority above the validator quorum.
| Namespace | What it changes | Validator quorum | Miner quorum | TTL | Bond |
|---|---|---|---|---|---|
Idea/* | Informational (no enactment) | — | — | 7d | 100 USDm |
Mimir/* | Bounded parameter tweak | ⌈2n/3⌉ | ½ of signaled @ 10% | 7d | 100 USDm |
Upgrade/* | ETH PSM contract upgrade | ⌈2n/3⌉ | ⌈2n/3⌉ @ 30% | 7d + 24h timelock | 100 USDm |
DSOLUpgrade/* | Replace Dark Contract bytecode | ⌈2n/3⌉ | ⌈2n/3⌉ @ 30% | 7d | 100 USDm |
Rollback/* | Un-enact a prior DSOL change | ⌈2n/3⌉ | ⌈2n/3⌉ @ 30% | 7d | 100 USDm |
Constitutional/* | Amend Constitution (within bounds) | ⌈4n/5⌉ | ⌈4n/5⌉ @ 30% | 30d + 60d activation | 1000 USDm |
EmergencyCancel/* | Cancel a pending proposal | ⌈n/2⌉ | — | 1d | 100 USDm |
Every enacting proposal requires both a validator quorum AND a miner-hashpower quorum, with a per-namespace participation floor (10% of blocks for Mimir, 30% for Upgrade-class, 50% for daemon binary upgrades). This is the structural answer to "huge hashpower vs. many bonded validators — neither should overpower the other."
An attacker holding 4/5 of validators but only 1/2 of hashpower cannot pass any state-mutating proposal; an attacker renting 2/3 hashpower but only controlling 1/2 of validators is equally blocked. The combined cost is the product of two independent expensive attacks sustained across the full TTL, with the 1-day EmergencyCancel as a community-driven veto if a manipulation slips past initial review.
The on-chain Constitution exposes two classes of slot: amendable-within-bounds (rate parameters with min/max guardrails the community can tune) and protected (core invariants the protocol relies on). Protected invariants are enforced at four independent layers:
Constitution.dsol exposes no setter for protected slots; calls to mutate them fail at the language level.checkProposalConstitutional rejects every proposal targeting a protected slot before any bond is escrowed.A successful attack would need to compromise all four layers simultaneously. The community always retains Bitcoin-style social hard-fork resistance — refusing to run a daemon binary that breaks the rule.
Validators bond USDm to apply, and the bond scales superlinearly with validator count: bond_N = MIN_BOND × (1 + N²/10000). Cumulative attacker cost to deploy K Sybil validators:
| K Sybils | Cumulative bond cost (× MIN_BOND) |
|---|---|
| 10 | ~10× |
| 100 | ~13× (13,000 USDm at MIN_BOND = 100) |
| 1,000 | ~333× (333,000 USDm) |
| 10,000 | ~3,333× (astronomical) |
Combined with bicameral consensus, even a successful Sybil on validators cannot pass enacting proposals without ALSO controlling 2/3 of hashpower. The two defenses multiply: the cost to manipulate the protocol is the product of validator-Sybil and hashpower-rental costs, sustained across the full TTL.
Within Constitution bounds, the community can vote to: adjust fee splits (subject to MIMIR_BOUNDS), upgrade Dark Contracts, change miner-emission curves, add new wrapped assets, rotate the amendment driver's FROST quorum, transfer sovereign-site domain ownership, and roll back any prior DSOL change. Every enactment is chain-anchored, every proposal is publicly auditable, and every bond contributes to the reserve.
Several areas are under active development or consideration for future protocol upgrades:
MoneroUSD proves privacy and stability are not a tradeoff. Built on Monero's battle-tested privacy stack and extended with FCMP++, overcollateralized BTC + XMR reserves, adaptive fees, and usage-proportional emission, USDm delivers a digital dollar that respects user sovereignty without compromising on the privacy guarantees Monero users expect.
Ion Swap, Dark Contracts, and the cross-chain bridge turn that foundation into a complete private DeFi ecosystem — sealed-bid AMM, programmable smart contracts in DarkSolidity, custom ion1_ tokens, hidden-ownership NFTs, multi-chain wrapped assets, and CPU-friendly RandomX mining. Every contract inherits privacy by construction: Pedersen commitments backed by Bulletproofs++ range proofs, commit-reveal that defeats front-running, AES-GCM-encrypted events sealed to the caller's viewkey, and tail-only inter-contract calls that make reentrancy impossible.
The protocol is non-custodial, deterministic, and open-source from the daemon to the contract layer. Settlement keys are bound to the chain, not to any operator. Fee revenue routes through a frozen three-lane split (reserves, protocol-owned liquidity, bounty) that monotonically strengthens the peg with every trade and every bridge. Tradeoffs are acknowledged honestly: standalone privacy chain (no Ethereum DeFi composition), ~20-second sealed-bid batch latency (MEV is cryptographically impossible), flat per-call resource ceilings (deterministic over auction-priced).
MoneroUSD is not a replacement for Monero — it's a complement, built by the same principles: privacy by default, keys on your machine, no surveillance, no compromises. For users who refuse to choose between financial privacy and a working DeFi stack, this is the answer.
The MoneroUSD protocol is open source. Verify everything. Trust nothing.
— Cas