Building and launching a Mimblewimble blockchain in Rust

aBuilding and launching a Mimblewimble blockchain in Rust I recently launched DOM Protocol, an independent Layer 1 blockchain written in Rust. The goal was to build a network focused on private electronic cash, deterministic consensus behavior, CPU-accessible mining and a launch without privileged allocation. DOM combines: RandomX proof of work Mimblewimble transaction architecture confidential amounts Pedersen commitments Bulletproof range proofs transaction aggregation cut-through canonical serialization LMDB-backed persistent state encrypted peer-to-peer transport deterministic genesis identity This article summarizes the architecture, the launch model and some of the engineering decisions behind the project. --- ## Why Rust Rust was selected because the protocol needs: explicit ownership and lifetime semantics strong type safety checked arithmetic predictable error handling safe concurrency clear crate boundaries reproducible builds low-level access without requiring widespread unsafe code The repository is organized as a multi-crate workspace. Some of the main crates are: text dom-core dom-crypto dom-serialization dom-consensus dom-chain dom-store dom-pow dom-wire dom-node dom-wallet dom-rpc dom-explorer Each crate has a narrow responsibility. For example: * dom-core defines consensus constants and primitive types. * dom-crypto implements signatures, commitments and range-proof support. * dom-serialization defines canonical byte encoding. * dom-consensus validates transactions and blocks. * dom-chain applies blocks, handles forks and performs reorganizations. * dom-store persists chain state in LMDB. * dom-pow implements RandomX and difficulty logic. * dom-wire handles encrypted peer communication. * dom-node coordinates the full runtime. ⸻ Consensus design The protocol uses a Mimblewimble-style transaction model. Transaction amounts are not published directly. Instead, value conservation is enforced through Pedersen commitments. At a high level, the balance relation is checked in commitment space. The implementation also validates: * duplicate inputs * duplicate outputs * duplicate kernels * lock heights * coinbase maturity * transaction weight * block weight * range proofs * kernel signatures * PMMR roots * previous-block linkage * timestamp bounds * proof-of-work target Canonical serialization is treated as consensus-critical. The same object must produce exactly the same bytes on every supported platform. Trailing bytes, malformed lengths and oversized allocations are rejected. ⸻ RandomX proof of work DOM uses RandomX to keep mining oriented toward general-purpose CPUs. The network uses: * RandomX for block proof of work * ASERT for difficulty adjustment * a two-minute target block time * explicit RandomX seed derivation * persisted-seed validation * fail-closed network selection The Mainnet P2P port is: 33369 The public seed is: seed1.dom-protocol.org:33369 ⸻ Zero-issuance genesis The Mainnet genesis block creates no coins. Its canonical body contains: Inputs: 0 Outputs: 0 Kernels: 0 Transactions: 0 Issued DOM: 0 The first mining reward is created only at block height 1. Mainnet genesis hash: 182e10af28e7ec072f462e6044f580dc9dd8c866cb78dfc293bbfaee4e9325ce Chain ID: f9831fadabc8a4234beab35fbb6327e84581645f33e9f75ed2ea78e8bcf1165b Genesis inscription: Not a store of value. A means of exchange. The launch model includes: * no premine * no ICO * no presale * no founder allocation * no team allocation * no treasury allocation * no developer tax Every circulating unit must be created through public consensus rules. ⸻ Monetary policy The base unit is: 1 DOM = 100,000,000 noms The initial block reward is: 33 DOM The reward schedule decreases deterministically using integer arithmetic. The maximum issuance is: 3,299,996,676,900,000 noms The genesis block is economically empty, so the first reward-bearing block is height 1. ⸻ Storage and reorganization safety Chain state is persisted using LMDB. The node stores and validates: * canonical headers * block bodies * UTXO state * kernel indexes * chain height indexes * PMMR state * peer metadata * reorganization data The implementation follows a fail-closed approach. Examples of conditions that produce errors instead of silent recovery include: * missing canonical bodies * malformed persisted records * incorrect record length * invalid block height mapping * canonical hash mismatch * corrupted UTXO metadata * inconsistent chain state Reorganizations restore the previous canonical state through explicit undo data and deterministic transition logic. ⸻ P2P architecture The peer protocol uses encrypted transport and network-specific identity checks. The node performs: * inbound and outbound peer management * handshake validation * chain-ID binding * block relay * transaction relay * peer exchange * initial block download * orphan handling * missing-parent requests * rate limiting * peer reputation tracking Mainnet, Testnet and Regtest use distinct network magic values and ports. This prevents accidental cross-network peering. ⸻ Security engineering Before the v1.0.0 release, the DOM Core codebase went through an extended security and verification campaign. The work included: * fuzz testing * property-based testing * Kani verification harnesses * Miri execution on selected paths * deterministic replay tests * restart and corruption testing * reorganization campaigns * RandomX boundary tests * mempool invariants * storage invariants * P2P parser limits * reproducible release builds The final audited release commit is: 6c58b0383c095384cd0150cabf074aa00fb57b17 The release tag is: v1.0.0 This was an internal engineering verification campaign, not an independent third-party financial audit. ⸻ Running a node Clone the repository and check out the release: git clone https://github.com/sorenplanck/dom-protocol.git cd dom-protocol git checkout v1.0.0 cargo build --release Start a Mainnet validating node: DOM_NETWORK=mainnet \ DOM_SEED_PEERS="seed1.dom-protocol.org:33369" \ DOM_MINE=false \ DOM_DATA_DIR="$HOME/.dom-mainnet" \ DOM_P2P_LISTEN_ADDR="0.0.0.0:33369" \ DOM_LOG=info \ ./target/release/dom-node The current public bootstrap node is: seed1.dom-protocol.org:33369 Direct IP fallback: 168.100.9.70:33369 ⸻ Wallet The official DOM Wallet V3 project is published separately: https://github.com/sorenplanck/dom-wallet-v3 Releases: https://github.com/sorenplanck/dom-wallet-v3/releases Wallet users should: * back up their recovery phrase offline * never publish the recovery phrase * verify release checksums * avoid unofficial mirrors * test recovery before storing meaningful value ⸻ Current state The Mainnet node is online. Current state at launch: Network: MAINNET Height: 0 Mining on bootstrap node: disabled P2P port: 33369 The bootstrap node does not mine. The first valid proof-of-work block must be produced by an independent miner. ⸻ What I am looking for I am looking for technical review and independent participation. Areas where feedback would be particularly useful: * consensus validation * Mimblewimble balance rules * RandomX integration * storage durability * reorganization behavior * peer discovery * mining tooling * release packaging * reproducible builds * wallet recovery * Rust crate boundaries The code is open source and direct criticism is welcome. ⸻ Links Repository: https://github.com/sorenplanck/dom-protocol Mainnet release: https://github.com/sorenplanck/dom-protocol/releases/tag/v1.0.0 Wallet: https://github.com/sorenplanck/dom-wallet-v3/releases Public seed: seed1.dom-protocol.org:33369 DOM is experimental open-source monetary software. It is not an investment offering and there are no promises regarding price, liquidity or exchange listings. Enter fullscreen mode Exit fullscreen mode