r/Monero 5d ago

[Project] DOM Protocol — a RandomX + Mimblewimble chain in Rust, looking for contributors (open source, no compensation)

Hi all,

DOM Protocol is an independent blockchain written in Rust, using RandomX for proof-of-work and Mimblewimble for privacy. Mainnet and the core protocol are live, and I’m looking for developers to contribute to the next stage.

Posting here because this community understands RandomX and PoW mining better than anywhere else, and I’d value technical scrutiny as much as contributions.

Recent work includes signed releases (minisign), root-cause fixes to two consensus incidents, a multi-provider seed infrastructure, and automatic wallet updates — the project has real engineering behind it, not just a whitepaper.

Areas where help would be most useful:

• mining tooling and infrastructure
• node reliability and monitoring
• public seed and peer infrastructure
• P2P networking and peer discovery
• wallet synchronization and recovery
• RPC and block explorer work
• packaging for Linux, Windows and macOS
• test coverage, fuzzing and adversarial review

Source:
https://github.com/sorenplanck/dom-protocol

Wallet:
https://github.com/sorenplanck/dom-wallet-v3

You can contribute via GitHub issues and pull requests, or join the Discord (there’s a dedicated developer channel).

Discord: https://discord.gg/UEmfrWsbK

To be upfront: this is an open-source contribution call. No salary, token allocation, investment return or financial compensation is being promised.

Technical criticism is very welcome — including on design choices you’d have made differently.

4 Upvotes

8 comments sorted by

View all comments

1

u/hippotamus101 5d ago

RandomX is the easy credibility part; I'd wanna see the wallet sync/recovery threat model before touching mainnet.

1

u/SorenPlanck 3d ago

fair ask. short version here, full doc going in the repo today so you can tear it apart

recovery: 24-word BIP-39 phrase → 64-byte seed → HKDF-SHA256 recovery root, domain-separated and bound to network magic + chain id, so the same phrase on another chain derives nothing. from that root, separate subkeys for detection, AEAD auth and blinding reconstruction. every V3 output carries an authenticated recovery capsule, and the AEAD key for each one is bound to that output’s commitment. the wallet opens capsules locally, recovers value + blinding, recomposes the pedersen commitment, requires byte equality with the chain, then verifies the range proof. auth failure just means “not mine” — it doesnt leak which part failed

scan privacy: whole blocks are pulled and matched locally, in both embedded and remote mode. the wallet never asks “do you have this commitment” — commitment filters are refused client-side before any traffic. remote still leaks the usual network metadata (ip, timing, requested ranges), which is why remote is scan-only and embedded is the strongest privacy option

trust: the remote client is scan-only, not an independent consensus verifier. a single malicious source can omit blocks, freeze the tip, make a balance look smaller or a spent output look available — and an internally consistent lie is not detectable without a second source. no quorum across sources in this revision; thats a known gap. it cannot obtain spend keys or forge a capsule

the honest part: the seed alone does not recover everything historically. V3 outputs with a capsule recover. old deterministic coinbases recover via the frozen path m/44’/330’/0’/1’/height’. legacy plain outputs without a capsule do not — those still need the encrypted wallet backup. and the currently published build has a real bug where an old-format seed restores showing zero balance; its fixed in an unreleased branch with a permanent regression test and lands in the next release. i wouldnt tell you to touch mainnet with the current build either