Building and launching a Mimblewimble blockchain in Rust

sorenplanck — Sun, 19 Jul 2026 02:10:16 +0000

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.

DEV Community: sorenplanck

Building and launching a Mimblewimble blockchain in Rust

aBuilding and launching a Mimblewimble blockchain in Rust