Bitcoin Forum
July 29, 2026, 10:23:43 PM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [ANN][DOM] Protocolo DOM — RandomX PoW | Mimblewimble | Sem Premine | Mainnet Live  (Read 380 times)
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 19, 2026, 12:28:33 AM
Last edit: July 22, 2026, 08:09:17 PM by sorenplanck
 #1

Official v1.0.0 release and source download:

https://github.com/sorenplanck/dom-protocol/releases/tag/v1.0.0



Official source repository:

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



Release version: v1.0.0



DOM Core commit:



Code:

6c58b0383c095384cd0150cabf074aa00fb57b17




SHA-256 checksums:



Checksums for compiled Linux and Windows binaries will be published on the official GitHub v1.0.0 release page together with the release assets.



Until those binaries are attached, the v1.0.0 Git tag and the official GitHub source archives are the authoritative distribution.







Public Mainnet Node



The initial DOM Mainnet node is online on a public VPS.



Code:

Network:        MAINNET

Status:         ONLINE

Current height: 0

Mining:         Disabled

Service:        dom-mainnet.service



DNS seed:

seed1.dom-protocol.org



Public IP:

168.100.9.70



P2P endpoint:

seed1.dom-protocol.org:33369



Direct IP fallback:

168.100.9.70:33369



P2P protocol:

TCP



RPC:

Private / not publicly exposed




Mainnet identity:



Code:

Chain ID:

f9831fadabc8a4234beab35fbb6327e84581645f33e9f75ed2ea78e8bcf1165b



Genesis hash:

182e10af28e7ec072f462e6044f580dc9dd8c866cb78dfc293bbfaee4e9325ce




The bootstrap node does not mine. Its purpose is to provide public peer discovery, block relay, transaction relay and initial synchronization.



Block height remains at zero until the first valid proof-of-work block is mined by a network participant.







Run a DOM Mainnet Node



Clone and build the exact v1.0.0 release:



Code:

git clone https://github.com/sorenplanck/dom-protocol.git

cd dom-protocol

git checkout v1.0.0

cargo build --release




Start a validating and relay-only Mainnet node:



Code:

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




Direct-IP bootstrap alternative:



Code:

DOM_NETWORK=mainnet \

DOM_SEED_PEERS="168.100.9.70: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




Operators must allow inbound TCP traffic on port:



Code:

33369/TCP




RPC and administrative interfaces should remain bound to loopback or protected private interfaces.







VPS Service Management



The initial public node runs under systemd:



Code:

sudo systemctl enable --now dom-mainnet.service

sudo systemctl status dom-mainnet.service --no-pager




Follow the Mainnet logs:



Code:

sudo journalctl -u dom-mainnet.service -f




Restart the node:



Code:

sudo systemctl restart dom-mainnet.service




Verify the public P2P listener:



Code:

sudo ss -lntp | grep 33369




Expected listener:



Code:

0.0.0.0:33369








Solo CPU Mining



DOM uses RandomX proof of work and supports integrated CPU mining.



Before mining, create and securely back up a DOM wallet. The miner wallet must be stored locally and protected with a strong password.



Example Mainnet mining command:



Code:

read -rsp "Miner wallet password: " DOM_WALLET_PASSWORD

echo

export DOM_WALLET_PASSWORD



DOM_NETWORK=mainnet \

DOM_SEED_PEERS="seed1.dom-protocol.org:33369" \

DOM_MINE=true \

DOM_MINER_THREADS="$(nproc)" \

DOM_WALLET_PATH="$HOME/.dom/miner.wallet" \

DOM_DATA_DIR="$HOME/.dom-mainnet-miner" \

DOM_P2P_LISTEN_ADDR="0.0.0.0:33369" \

DOM_LOG=info \

./target/release/dom-node



unset DOM_WALLET_PASSWORD




Direct-IP bootstrap alternative:



Code:

DOM_NETWORK=mainnet \

DOM_SEED_PEERS="168.100.9.70:33369" \

DOM_MINE=true \

DOM_MINER_THREADS="$(nproc)" \

DOM_WALLET_PATH="$HOME/.dom/miner.wallet" \

DOM_DATA_DIR="$HOME/.dom-mainnet-miner" \

DOM_P2P_LISTEN_ADDR="0.0.0.0:33369" \

DOM_LOG=info \

./target/release/dom-node




The miner must have access to a valid local wallet file:



Code:

$HOME/.dom/miner.wallet




Never publish the wallet password or recovery phrase.



Never include the wallet password in public scripts, screenshots, configuration files or shell history.







Official DOM Wallet



Official DOM Wallet V3



Official Linux and Windows wallet releases are published in the dedicated DOM Wallet V3 repository:



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



Official wallet repository:



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



Download DOM Wallet V3 only from the official GitHub Releases page.



Before installing:



  • Verify the release version and attached checksums.
  • Back up the recovery phrase offline.
  • Never share the wallet password or recovery phrase.
  • Never download installers from unofficial mirrors.

The public Mainnet explorer is being prepared.



The official explorer URL will be posted in this announcement thread and on the official project website after deployment.



The explorer is informational only. Consensus is determined independently by validating DOM nodes.







Official Website



https://dom-protocol.org







Technical Documentation



Mainnet documentation:



https://github.com/sorenplanck/dom-protocol/tree/release/mainnet/docs



Mainnet source branch:



https://github.com/sorenplanck/dom-protocol/tree/release/mainnet



Mainnet v1.0.0 release:



https://github.com/sorenplanck/dom-protocol/releases/tag/v1.0.0







Official Community and Support



This Bitcointalk announcement thread is the initial official public discussion channel.



Technical issues and reproducible bug reports:



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



Additional official channels will be announced only through:



  • This Bitcointalk announcement thread
  • The official GitHub repository
  • The official project website


OFFICIAL CHANNELS

• GitHub: https://github.com/sorenplanck/dom-protocol
• Telegram (announcements): https://t.me/dom_announcements
• Discord: https://discord.gg/UEmfrWsbK
• Website: https://dom-protocol.org

These are the ONLY official channels. Anything else is not us.

━━━━━━━━━━━━━━━━━━━━

RUNNING A NODE / MINING

Build and run from source (release/mainnet branch on GitHub). Node updates and consensus changes are always announced here first — keep your node updated to stay on the network.

━━━━━━━━━━━━━━━━━━━━

SECURITY — READ THIS

• DOM will NEVER DM you asking for money, seed phrases, or wallet passwords.
• We do NOT offer or sell paid exchange listings. Any “listing manager” emailing or messaging you is a scam.
• Admins ONLY post in this channel. No admin will ever contact you first in private.
• Always verify links against this pinned post.

━━━━━━━━━━━━━━━━━━━━

Sound money · Sovereign people.






DOM Mainnet is online.



Public seed: seed1.dom-protocol.org:33369



No premine. No ICO. No founder allocation.



Not a store of value. A means of exchange.

yunta
Newbie
*
Offline

Activity: 14
Merit: 0


View Profile
July 19, 2026, 04:49:57 AM
 #2

没有命令行钱包吗, solo必须本地钱包这个好难搞,服务器一般不支持GUI。或者有矿池没。
longdi
Newbie
*
Offline

Activity: 6
Merit: 0


View Profile
July 19, 2026, 06:56:31 AM
 #3

Subject: One seed node for an entire mainnet — and it's down. Seriously?

So let me get this straight: the entire DOM mainnet hangs off exactly one seed node (seed1.dom-protocol.org = 168.100.9.70), and that node has been dead for hours. TCP still connects (that's just your DDoS proxy answering), then... nothing. Noise handshake times out after 10 seconds, every single time, from every machine we've tried. We were synced to height 195 earlier — then the network just vanished.

A whole "mainnet" that stops existing when one box goes down. Impressive engineering.

And it gets better: your anti-DDoS layer silently drops all datacenter/cloud IPs. We tested from clean VPSes in New York and Singapore — not even a TCP SYN-ACK on :33369 or :443. So even when your one seed comes back from its nap, nobody can actually run infrastructure on this network: no pools, no explorers, no public nodes. You firewalled out the exact people who could stop your single point of failure from being a single point of failure. Grin shipped with multiple redundant seeds back in 2019 — it's 2026 and DOM launched with one, hidden behind a hostile firewall.

The README says "Not a store of value. A means of exchange." Right now it's neither — it's a whitepaper with a disconnected phone number.

Since I'd actually like this network to live:

1. Is seed1 down, or did you change the filtering? Any ETA?
2. Spin up 2–3 more seeds on different providers/ASNs. This is table stakes for a mainnet.
3. Give clean datacenter IPs a way in — whitelist or a documented policy. We have a public node + mining pool built from your canonical v1.0.0 tag (6c58b038…) sitting ready to deploy, which would give your network exactly the extra peers it desperately needs. We can be part of the fix the moment we can handshake.

Your move.
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 21, 2026, 02:15:36 AM
Last edit: July 21, 2026, 08:28:36 PM by Welsh
 #4

没有命令行钱包吗, solo必须本地钱包这个好难搞,服务器一般不支持GUI。或者有矿池没。

没有命令行钱包吗, solo必须本地钱包这个好难搞,服务器一般不支持GUI。或者有矿池没。

Thanks for the comment.

Yes, DOM currently runs through the command line. Solo mining is done through the node binary, and headless server deployment is expected. A GUI wallet can exist separately, but the protocol itself is designed to run without requiring a desktop environment.

We will publish clearer miner and node setup instructions so operators can bootstrap more easily on VPS and server environments.
Quote from: longdi on July 19, 2026, 07:56:31 (https://bitcointalk.org/index.php?topic=5588797.msg66956441#msg66956441)Subject: One seed node for an entire mainnet — and it's down. Seriously?

So let me get this straight: the entire DOM mainnet hangs off exactly one seed node (seed1.dom-protocol.org = 168.100.9.70), and that node has been dead for hours. TCP still connects (that's just your DDoS proxy answering), then... nothing. Noise handshake times out after 10 seconds, every single time, from every machine we've tried. We were synced to height 195 earlier — then the network just vanished.

A whole "mainnet" that stops existing when one box goes down. Impressive engineering.

And it gets better: your anti-DDoS layer silently drops all datacenter/cloud IPs. We tested from clean VPSes in New York and Singapore — not even a TCP SYN-ACK on :33369 or :443. So even when your one seed comes back from its nap, nobody can actually run infrastructure on this network: no pools, no explorers, no public nodes. You firewalled out the exact people who could stop your single point of failure from being a single point of failure. Grin shipped with multiple redundant seeds back in 2019 — it's 2026 and DOM launched with one, hidden behind a hostile firewall.

The README says "Not a store of value. A means of exchange." Right now it's neither — it's a whitepaper with a disconnected phone number.

Since I'd actually like this network to live:

1. Is seed1 down, or did you change the filtering? Any ETA?
2. Spin up 2–3 more seeds on different providers/ASNs. This is table stakes for a mainnet.
3. Give clean datacenter IPs a way in — whitelist or a documented policy. We have a public node + mining pool built from your canonical v1.0.0 tag (6c58b038…) sitting ready to deploy, which would give your network exactly the extra peers it desperately needs. We can be part of the fix the moment we can handshake.

Your move.
Thank you for taking the time to test the network, document your observations, and report the issues in detail.

Your feedback was useful.

After investigating the behavior, we confirmed that the main issue was not a consensus failure, inflation bug, or chain-identity problem. It was an operational defect in the miner: under prolonged mining conditions, the miner could remain stuck hashing an outdated block template with an obsolete timestamp and target instead of refreshing the candidate properly over time.

That defect has now been fixed.

To be explicit, the fix did not change:

- genesis
- Chain ID
- ASERT formula or parameters
- reward schedule
- validation rules
- consensus rules
- economic policy

So this was not a hard fork or a consensus rewrite. It was a miner-side template refresh correction.

Your point about bootstrap resiliency was also fair. Seed redundancy and broader public entry-point availability are important for a live network, and improving that operational layer is a valid priority. A mainnet should be easier for independent operators, public nodes, miners, and infrastructure providers to reach reliably.

The network is advancing again, and the correction was deployed without changing consensus.

Thank you again for the scrutiny and for raising the issue constructively. External technical review, even when critical, is valuable — especially at this stage.


Thank you for taking the time to test the network, document your observations, and report the issue in detail.

Your feedback was useful.

After investigation, we confirmed that the problem was not a consensus failure, not an inflation issue, and not a Chain ID, genesis, or ASERT rule problem. The root cause was an operational defect in the miner: under prolonged mining conditions, the miner could continue hashing an outdated block template with an obsolete timestamp and target instead of refreshing the candidate over time.

That issue has now been fixed.

To be explicit, this correction did not change:

- genesis
- Chain ID
- ASERT formula or parameters
- target block spacing
- block rewards
- transaction rules
- validation rules
- economic policy
- historical block validity

So this was not a hard fork and not a consensus change. It was a miner-side template refresh fix.

The network is advancing again, and the correction was deployed without altering consensus.

Additional bootstrap resilience is also being prioritized. Seed redundancy and broader public entry-point availability are valid operational concerns for a live network, and that layer will continue to be improved.

--------------------------------------------------
MINER UPDATE
--------------------------------------------------

All miners should update and restart their node process.

Older miner binaries may still become stuck on an outdated block template and should be considered obsolete for mining purposes.

Release:
https://github.com/sorenplanck/dom-protocol/releases/tag/v0.1.1

Binary:
dom-node-linux-x86_64

Platform:
Linux x86_64

SHA-256:
223b23270bf6a0305f1d37505c8bfd730dd50d99f4d51f2e41726cdf792cee60

Verify before installing:

sha256sum dom-node-linux-x86_64

The result must exactly match:

223b23270bf6a0305f1d37505c8bfd730dd50d99f4d51f2e41726cdf792cee60

--------------------------------------------------
INSTALLATION
--------------------------------------------------

1. Download the new Linux x86_64 binary from the release page.
2. Verify the SHA-256 checksum.
3. Stop the currently running DOM miner/node process.
4. Back up the existing binary.
5. Replace it with the new binary.
6. Restart the node with the same configuration/environment previously used.
7. Do not delete wallet data or blockchain data.

This update is required for miners.

Existing non-mining validating nodes remain compatible and can continue accepting new blocks.

Thank you again for the scrutiny and for raising the issue constructively. External technical review, especially at this stage, is useful and appreciated.


Network Status Update

Hello everyone,

During the first hours after the Mainnet launch, I identified an issue that prevents the network from progressing beyond the genesis state.

The problem is related to the mining initialization path and does not affect the integrity of the genesis block, the Chain ID, or the consensus parameters that were released in v1.0.2

As a precaution, I have temporarily paused the launch while I investigate and correct the issue.

At this stage:

* The Mainnet genesis remains unchanged.
* The released source code remains available for review.
* No premine or privileged issuance has occurred.
* No blockchain history needs to be rewritten because no valid blocks have been mined beyond genesis.

I prefer to delay the public launch rather than release a network with a known consensus issue.

A corrected release will be published as soon as the root cause has been identified, tested, and independently verified.

Thank you for your patience and for everyone who has already started reviewing the code and testing the network.

— DOM Protocol Development Team
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 22, 2026, 12:01:30 AM
 #5

[Important update] DOM mainnet — difficulty fix (activates at height 4849)

Mainnet difficulty collapsed until the computed target exceeded MAX_TARGET, which stalled consensus. Nodes WITHOUT this update stop at height 4848 (or 4946), rejecting blocks with the error:

    invalid compact target: target > MAX_TARGET

The fix is a height-activated consensus change, already live on the network. All nodes must update to stay on the correct chain.

Technical details:
- Activation height: 4849
- ASERT re-anchored at height 4848
- Target ceiling raised + half-life shortened
- Heights below 4849 keep the original rules (history unchanged)

How to update:

    git fetch origin
    git merge --ff-only origin/release/mainnet
    cargo build --release -p dom-node
    systemctl restart dom-node

No wallet or data migration is needed. After restarting, the node syncs the missing blocks automatically.

Repository: https://github.com/sorenplanck/dom-protocol (branch release/mainnet)
Commit: 065e48432a52321004e0063bf2d772d49f68a2a0
Patch SHA-256: 5dc4051ace4b377aa7376ea02d6e72e9d60dde16b8db8d052f3d43be3ab704c5
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 22, 2026, 04:52:29 PM
Last edit: July 22, 2026, 09:30:01 PM by Welsh
 #6

[MANDATORY UPDATE] DOM mainnet — fork resolution fix

A consensus bug caused nodes at the same height with different tip hashes to never reconcile, fragmenting the network into separate chains. This update fixes it: nodes now detect equal-height fork divergence, exchange headers down to the common ancestor, and converge on the chain with the most accumulated work.

All nodes must update. Nodes running the old binary stay stuck on a minority fork and will not rejoin the network until updated.

How to update:

    git fetch origin
    git merge --ff-only origin/release/mainnet
    cargo build --release -p dom-node
    systemctl restart dom-node

No wallet or data migration is needed. After restarting, the node syncs and reconciles automatically.

Repository: https://github.com/sorenplanck/dom-protocol (branch release/mainnet)
Commit: 5fad7083ef46a24a767c8de410725debfa6498c7
Direct link: https://github.com/sorenplanck/dom-protocol/commit/5fad7083ef46a24a767c8de410725debfa6498c7
Summary: fix(p2p): resolve equal-height fork divergence

Official announcements: https://t.me/dom_announcements

---

Security notice: DOM will NEVER contact you privately asking for money, seed phrases, or wallet passwords. We do not offer paid exchange listings. Ignore any DM or email claiming otherwise — these are scams. Admins only post in the official channel above.

Sound money · Sovereign people.

have discord group?
. Not yet — Discord is being set up and will be announced soon.

For now, join our official Telegram announcements channel: https://t.me/dom_announcements

All network updates, releases, and critical alerts are posted
fibonacciopstan
Jr. Member
*
Offline

Activity: 98
Merit: 2


View Profile
July 23, 2026, 08:55:26 AM
 #7

The launch information is unusually specific, especially the exact commit, chain ID, genesis hash, public seed and the statement that consensus changes will always be announced through the official channels.

That raises an important question about the project’s own historical record.

DOM may be able to prove blocks and transactions through consensus, but the surrounding public claims still depend on GitHub pages, this forum thread, Telegram posts and the project website. All of those can be edited, replaced or removed later. Even the pinned list of “only official channels” could change, leaving future users unsure which version was valid at a particular point in time.

This matters especially for announcements about consensus changes, binary checksums, release authenticity, mining rules and the repeated claims of no premine, no ICO and no founder allocation. A project can publish accurate information today, but long-term trust also requires proving exactly what was announced and when.

Has DOM created any immutable public log where its official releases, security notices and protocol commitments are permanently timestamped and remain visible even after later updates? I would be interested in checking it, so please share the address if it exists.
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 23, 2026, 01:40:39 PM
 #8

The launch information is unusually specific, especially the exact commit, chain ID, genesis hash, public seed and the statement that consensus changes will always be announced through the official channels.

That raises an important question about the project’s own historical record.

DOM may be able to prove blocks and transactions through consensus, but the surrounding public claims still depend on GitHub pages, this forum thread, Telegram posts and the project website. All of those can be edited, replaced or removed later. Even the pinned list of “only official channels” could change, leaving future users unsure which version was valid at a particular point in time.

This matters especially for announcements about consensus changes, binary checksums, release authenticity, mining rules and the repeated claims of no premine, no ICO and no founder allocation. A project can publish accurate information today, but long-term trust also requires proving exactly what was announced and when.

Has DOM created any immutable public log where its official releases, security notices and protocol commitments are permanently timestamped and remain visible even after later updates? I would be interested in checking it, so please share the address if it exists.


Fair question, and worth answering directly: no, DOM does not currently maintain a dedicated immutable log of announcements. It should, and I’ll describe below what we’re going to do about it.

But it’s worth separating what actually depends on trusting our posts from what doesn’t.

What is already cryptographically anchored, not merely claimed:

Git history is a hash-chained structure. The launch commit published in this thread can be verified against the repository — and no commit can be altered without changing the hash of every descendant. Anyone who recorded that hash at launch can check it today.

The genesis hash and chain ID are properties of the chain itself, not of any announcement. A node that disagrees with them simply does not join.

Most importantly, the no-premine claim does not rest on trust in anything we published. It is verifiable directly from the chain: sync from genesis and check that no output exists before block 1 other than what the consensus rules mint per block. That is independent of GitHub, this thread, Telegram, or the website. If any of those disappeared tomorrow, the claim would remain checkable by anyone with a copy of the chain.

What your point correctly identifies as unprotected:

Release binary checksums, security notices, and the record of when a consensus change was announced. Those live in editable places today, and you’re right that a reader in a year cannot prove what was said at a given moment.

What we will add, using standard tooling and no third-party dependency:

   1.   GPG-signed release tags and binaries — establishes authorship, verifiable offline against a published key.
   2.   OpenTimestamps proofs for each release manifest — anchors the manifest hash in the Bitcoin blockchain, proving the date without requiring anyone to trust us or any service.
   3.   A RELEASES.md and SECURITY.md kept in-repo, so the record itself lives inside the hash-chained git history rather than in an editable web page.

That combination gives exactly what you describe — authenticity plus permanent timestamping — while keeping the guarantee anchored in Bitcoin rather than in any single provider, ours included.

If you’d like, I can publish an OpenTimestamps proof for the current release manifest and the launch parameters now, so there is a fixed reference point going forward.
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 25, 2026, 07:44:59 PM
 #9

**DOM — Network update & the new self-updating wallet**

First, an apology. Over the past days the network went through repeated consensus stalls, and some of that traced back to problems on the wallet side of the project. Those have been sorted out. This post explains what changed and what you need to do.

**What happened**

The mainnet hit two consensus bugs: a difficulty collapse and, at the root, nodes at the same height with different tips never reconciling — the network fragmented into separate chains. Both are fixed:

- `065e484` — ASERT rescue (activates at height 4849)
- `5fad708` — equal-height fork divergence resolution

An old wallet build that shipped a pre-mainnet node was also taking down new users silently — it has been unpublished, and its old installers removed.

**The new wallet — recommended path for miners**

A new signed desktop wallet is out (Windows, Linux, macOS). If you mine, this is now the recommended way to run a node.

The reason: it updates itself. When a consensus change ships, the wallet verifies and applies it automatically — you don't have to watch this channel and manually rebuild every time the network changes. That manual dependency is exactly what caused nodes to stall this week. The wallet removes it.

Download and verification instructions are in the pinned message / release page. Every release is signed — verify before running.

**If you run a node outside the wallet**

You must update **and restart** to v0.1.2 or later. Updating the source without restarting leaves the old binary running in memory — this is why several nodes appeared stuck after updating.

```
git fetch origin
git merge --ff-only origin/release/mainnet
cargo build --release -p dom-node
systemctl restart dom-node
```

Or use the prebuilt signed binary:
https://github.com/sorenplanck/dom-protocol/releases/tag/v0.1.2

Verify it:
```
curl -LO https://github.com/sorenplanck/dom-protocol/releases/download/v0.1.2/dom-release.pub
minisign -V -p dom-release.pub -m dom-node-linux-x86_64
```

Nodes on earlier binaries stall and reject blocks with `invalid compact target: target > MAX_TARGET`.

**One more change** — two RPC routes now require the bearer token: `/wallet/balance` and `/chain/scan`. If you have scripts hitting them, add the header:
```
curl -H "Authorization: Bearer $(cat ~/.dom/rpc_token)" http://127.0.0.1:8080/wallet/balance
```

**Reminder:** DOM will never DM you asking for money, seed phrases, or passwords, and we don't offer paid listings or paid AMAs. Admins only post in the official channel. Ignore anything else.

Sound money · Sovereign people.
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 27, 2026, 09:15:37 PM
 #10

Developers Wanted

DOM Protocol is looking for independent developers interested in contributing to the next stage of the project.

The Mainnet and core protocol are already live. The current focus is on final hardening, infrastructure, tooling, documentation and ecosystem development.

We are particularly interested in contributors with experience in:

• Rust
• distributed systems
• blockchain consensus
• Mimblewimble
• RandomX
• P2P networking
• wallet engineering
• Linux packaging
• reproducible builds
• security testing and fuzzing
• block explorers and mining infrastructure

Current contribution areas include:

• node reliability and monitoring
• public seed and peer infrastructure
• mining tools
• RPC and block explorer improvements
• wallet synchronization and recovery
• packaging for Linux, Windows and macOS
• documentation and onboarding
• test coverage, fuzzing and adversarial review

The project is open source:

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

Wallet repository:

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

Developers can participate through GitHub issues, pull requests and technical discussion.

Anyone interested in contributing or applying to participate in the development can also join the official DOM Protocol Discord.

A dedicated private channel for developers will be available inside the Discord for technical coordination, task discussion and direct communication with the project team.

Interested developers should join the Discord and send a message introducing themselves, their technical background and the areas where they would like to contribute.

Discord:

https://discord.gg/UEmfrWsbK

This is currently an open-source contribution call. No salary, token allocation, investment return or financial compensation is being promised.

Technical criticism is welcome.
sorenplanck (OP)
Newbie
*
Offline

Activity: 8
Merit: 0


View Profile
July 28, 2026, 05:34:00 PM
 #11

INFRASTRUCTURE UPDATE — Seed node migration + Wallet v0.2.8
   1.   Seed nodes migrated to new servers
Earlier today our previous hosting provider terminated the account hosting both seed servers, without prior notice. Since day one the official seeds have been published as DNS hostnames rather than raw IPs, so recovery was a DNS update:
seed1.dom-protocol.org → 66.42.127.141
seed2.dom-protocol.org → 64.177.121.62
DNS has propagated globally and both seeds were verified reachable on port 33369 from external networks. Both run the signed v0.1.2 node binary (commit 28ba3cef, containing the ASERT rescue and equal-height fork fixes).
Impact on the network: none. The chain never stopped — blocks continued at the normal cadence throughout the migration, and no consensus rule or chain data was affected. Seed nodes are only bootstrap entry points.
Action required:
   •   Connecting via the hostnames (the default): nothing to do.
   •   If you hardcoded the old IPs (168.100.9.70 or 198.13.158.194) in your config: replace them with the hostnames. This event is exactly why hostnames are the recommended form.
   2.   DOM Wallet V3 v0.2.8 (stable)
Released today: https://github.com/sorenplanck/dom-wallet-v3/releases/tag/wallet-v0.2.8
   •   Signed auto-update feed (latest.json) now live — from this version onward the wallet verifies minisign signatures and SHA-256 before applying any update
   •   Builds for Linux (AppImage), Windows (setup.exe) and macOS (aarch64), each with published SHA-256 and minisign signature
   •   Standalone dom-node binary included for headless operators
As always: verify signatures against the published keys before running anything. Key IDs and hashes are in the release notes.
— Soren Planck
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!