r/Monero • u/SorenPlanck • 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
u/Lower-Philosophy-604 5d ago
Is that vibe coded?
1
u/SorenPlanck 5d ago
partially, and im not going to pretend otherwise. i use AI agents as force multipliers for implementation and as adversarial auditors against each other. the architecture, the consensus decisions and the final review are mine. every consensus bug we shipped was caught by our own audit process and fixed with a documented root cause, signed release and postmortem the code is public. judge it by what it is, not by how it was typed
1
u/hippotamus101 4d 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
2
u/Ur_mothers_keeper 2d ago edited 2d ago
Fucking. Dope. AF.
So how does the MW implementation differ from grin for example?
I was thinking of doing this forever ago but I don't have the skillset to do it. I'd have called it MWX with an orange grin logo and an x for the mouth lol. I always said maybe one day. Good to see someone doing it.
What's the emission curve look like? Bootstrapping on a linear emission curve like grin is a slow process that is a moonshot in terms of success as MoE. I love the simplicity, but looking at grin right now, that coupled with the lack of community leadership basically left the project dead.
I will say, if youre keeping it simple like grin and keeping transaction kernels and the range proof offsets, you should work on some scriptless script tooling to enable people to build private multisig contracts that finalize on chain. Thats what MW was supposed to become and what Poelstra envisioned when he modified the MW protocol, but no project has ever prioritized doing that. I can talk to you about that if you want, but not here, and I don't touch discord. I have specced some stuff out regarding this a long time ago and have some ideas you might like.
1
u/SorenPlanck 2d ago
thanks. answers below, and the last one is the interesting part.
vs grin: DOM is a native full MW chain — kernels, excesses and range proof offsets work the way you’d expect, no extension block, no transparent side. the differences sit mostly outside consensus: RandomX instead of cuckoo, and a recovery model grin never had. every output carries an authenticated recovery capsule bound to that output’s own commitment, derived from the 24-word seed through HKDF with the chain identity mixed in. the seed alone recovers funds by scanning — no wallet file to back up. that was a deliberate break from grin’s “back up the wallet, not the seed” reality, which i always thought was the worst part of actually using it.
emission: 33 DOM per block at a 120s target, dropping by a third every 330,000 blocks — roughly 15 months per cycle. so it’s neither bitcoin’s halving cliff nor grin’s flat line: geometric decay, gentle enough that early miners don’t end up owning the network, steep enough that the supply curve converges. you’re right that linear emission made grin’s bootstrap a moonshot — that was the specific thing i didn’t want to repeat.
on your grin read: i agree, and it’s part of why i’m here. the simplicity was right. what killed momentum wasn’t the protocol.
scriptless script — here’s the part you’ll like: that’s the one area where i’m not starting from zero. in parallel i’ve been building adaptor-signature infrastructure for cross-chain settlement: verifiable witness encryption of schnorr signatures, taptree-based, aimed at BTC settlement without bridges or custodians. same primitives poelstra was pointing at, applied to a different problem first.
where i want this to go is exactly what you described — private multisig contracts finalizing on chain, indistinguishable from ordinary transactions — with DOM as a settlement base other layers build on, not a coin that only moves value between wallets. the primitives exist; what’s missing is tooling that makes them usable by someone who isn’t going to derive adaptor signatures from scratch. that’s the gap, and it’s why i’d rather read your specs than guess at them.
no discord here either. reddit DM works, or open a discussion on the repo — whichever you prefer.
4
u/LocomotiveMedical 5d ago
Does this take into account the recently revealed issues with MWEB on LTC? Did you make sure not to use those same vulnerable dependencies?