TrueNorth launching Oct 12! (2026-10-12 00:00:00 UTC)

[septentrion-dev]

Mainnet starts at 2026-10-12 00:00:00 UTC

That instant is enforced in consensus, not by convention: any block timestamped earlier is rejected, so the chain cannot be started early by anyone. Running the daemon before then is harmless. Running the miner before then is pointless — it will hash and every block will be rejected, with nothing in the output explaining why.

What is TrueNorth

A Bitcoin Core fork with four substantive changes:

• RandomX proof of work, the same PoW family Monero uses, so mining is CPU-based. A custom Argon2 salt ("RandomNorth") means stock xmrig cannot be pointed at this chain without a rebuild; a miner ships in the release archive.
• P2QRH quantum-resistant addresses by default. Outputs commit to a hash of the pubkey rather than the pubkey itself, so coins at rest are not exposed to a future quantum attack, and post-quantum signature schemes can be added by soft fork without disturbing the UTXO set.
• Two-minute blocks, with LWMA difficulty adjustment rather than Bitcoin's 2016-block retarget.
• Tail emission. 512 NORTH initial subsidy, halving every 1,051,200 blocks (about four years), with a perpetual floor of 8 NORTH per block instead of terminating.

Everything else is Bitcoin Core: UTXO model, SegWit, Taproot, no smart contracts.

Fair launch, concretely

No premine, no allocation, no ICO, no founder reward, no pre-sale. The genesis output is OP_RETURN and therefore unspendable, as Bitcoin's is.

The binaries and the verifiable genesis have been public since 2026-10-06, six days before the chain starts. Anyone can mine from block 0. Nobody is waiting on an invitation.

Genesis

hash 470c8b8ae824c06575cfae0851282c495b861829211194842590dc6a2c829981
merkle root 2e4de71a24b24ac64cea9bbc52cb6a588c9a0bb53b6745a603240fd9efc6b289
nTime 1791763200 (2026-10-12 00:00:00 UTC)
nBits 0x1e1179ec
nNonce 741213

The coinbase carries a dated headline, as Bitcoin's did:

2026-10-05 Canada honours its top educators with Prime Minister's Awards - Canada.ca

A Government of Canada news release of that date, so the block cannot have been constructed earlier. Check the hash against your own node with truenorth-cli getblockhash 0 before trusting any peer claiming to serve mainnet.

Getting it

Release v30.5.0, Linux x86_64 / macOS arm64 / Windows x86_64:
https://github.com/truenorth-project/truenorth/releases/tag/v30.5.0

Verify before running. SHA256SUMS has a detached GPG signature and each binary carries a GitHub build-provenance attestation:

sha256sum --ignore-missing -c SHA256SUMS
gpg --verify SHA256SUMS.asc SHA256SUMS

Release key fingerprint 3F0BAE0458615427B8CA935E3E242DF5E4478AE5, also in the #truenorth IRC topic.

Mining

truenorth-miner -chain=main -datadir= -address= -threads=

Leave -longpoll and -budgetseconds at their defaults unless you have a reason. doc/testnet.md covers huge pages and NUMA tuning, worth 10–40% on multi-socket hardware and inert below roughly 14 threads.

There is no pool. Solo works; P2Pool is preferred if you want to pool, nobody has stood one up yet. The project runs no official pool and will not. A documented 33% single-pool norm is in doc/mining-policy.md — social convention, not code.

RandomX targets ASIC resistance, not ASIC proof. The design goal is keeping general-purpose CPUs within a constant factor of specialised silicon so commodity mining stays viable, and RandomX ASICs do exist. The custom Argon2 salt means existing RandomX hardware cannot simply be repointed here, which is a near-term barrier rather than a permanent one.

If your node finds no peers: this release queries no DNS seeds, so discovery depends on six compiled-in fixed seeds, two clearnet and four onion. If none is reachable from your network, pass -addnode with an endpoint from doc/public-seed-setup.md.

Channels

#truenorth and #truenorth-dev on OFTC, clearnet or onion. GitHub issues for bugs, this Discussions section for everything else.

There is no official Twitter, Discord or Telegram, and no token sale. Nobody will ever DM you asking for keys or coins.

Nostr: npub1w2kxm7jq9ynqnr0p93j5casz88pxz56jhp9zadl53f4cl59ye8tqejqyw5

[septentrion-dev]

Note for multi-socket Linux miners: the v30.5.0 linux-x86_64 binary was built without NUMA support — libnuma-dev was missing from the release environment, so truenorth-miner reports numa=auto(active=no,nodes=1) even on a multi-node host. Single-socket machines are unaffected. If you're mining on a dual-socket box, build from source until v30.5.1; the fix is already on master.

[septentrion-dev]

TrueNorth mainnet has launched!

Early miners may have noticed the chain was 94 blocks deep at 00:00:00 UTC. Those 94 blocks were mined before launch, and 94 of the first 96 paid a single address. I said before launch that the start time was enforced in consensus and that nobody could mine early. Unfortunately there was a gap and here is the detail.

What happened

Block 1 carries timestamp 2026-10-12 00:00:01 UTC. My node accepted it at 2026-10-11 23:02:57 UTC, 57 minutes earlier. Block 94 carries 00:00:18 and was accepted at 23:51:43. So 49 minutes of real time produced 18 seconds of claimed block time. This was live mining before launch with timestamps set forward, not a chain prepared offline and released at midnight.

The payouts went to north1qtjmwdpqmczeqx60lyvt3d4nrp7mhcy8834vfjm, which is a witness v0 address rather than the P2QRH default. 94 blocks at 512 NORTH is 48,128 NORTH. That address has mined nothing since 23:51.

Why it was possible

Two checks interact badly. validation.cpp rejects a block whose nTime is before nLaunchTime. Separately, inherited from Bitcoin Core, it rejects a block whose timestamp is more than MAX_FUTURE_BLOCK_TIME ahead of now, and that constant is two hours.

A block stamped exactly nLaunchTime is not before launch, so the first check passes. It is not more than two hours in the future, so the second passes too. From two hours before launch onward, blocks stamped at the launch instant are valid and relay normally. The comment above that check in my own source says it prevents pre-launch shadow mining. It only prevents it by someone who stamps their blocks honestly.

What it is worth

94 blocks is 3.1 hours of issuance at the 2-minute target. It is 0.0089% of the 538,214,400 NORTH issued in the first halving epoch, and 0.036% of the first year. For comparison with the launches this project has criticised, a conventional premine is tens of percent of supply allocated before anyone else can participate.

So the head start is real, it is not nothing, and it is small. I would rather give you the number than characterise it.

What I am not doing

I am not reorganising the chain. The pre-mined segment is 94 blocks deep and max_reorg_depth is 72, so nodes that already hold it would refuse to follow a reorg anyway, leaving a partition that each operator would have to repair by hand. Beyond the mechanics, invalidating blocks because I dislike who won them is precisely the power this project should not have, and using it in the first hour would say more about the chain than 94 blocks does.

I am also not relaunching. A second genesis has the same weakness unless the rule is fixed first, and it would discard everyone else's work to repair 3 hours of mine.

What would actually fix it

The missing rule is the other half of the one I wrote: refuse any non-genesis block while the node's own clock is still before nLaunchTime. That is a local-time check, which is what the two-hour future rule already is, so nodes syncing later still accept the chain. Every node online before launch would have rejected and not relayed those 94 blocks.

Being precise about the limit: that stops early acceptance and relay, which is what happened here. It doesn't stop someone grinding blocks entirely in private and publishing them at the launch instant. With a fixed, publicly known genesis and a known start time, I do not think that is solvable, only made less rewarding. Anyone planning a launch-gated chain should assume the first blocks are contestable and design the economics so it does not matter.

On whether it was me

It was not but due to the nature of public-key cryptography I can't prove that I don't control a key. I did my best to ensure a fair launch and unfortunately this slipped through. What you can verify independently is everything above: the timestamps, the heights, the payout address, and the two checks in the source.

Since 00:00 the chain has behaved normally. Difficulty is adjusting down from the opening burst through LWMA, and solve times are converging on the 2-minute target.