1 · Abstract
HIDERING (HRG) is a maximum-privacy cryptocurrency protocol derived from Monero v0.18.1, combining advanced anonymity with a Bitcoin-style monetary model.
Fair launch: 100% emission via RandomX proof-of-work, with an irrevocable supply cap of 18,000,000 HRG. v2.0.0 introduced a short private-network pre-mining phase as the response to the 51% attack of 16 May 2026 on the v1.x chain (at height ≈3577); see §7 for the full rationale and use of those funds.
Key innovations:
- Dynamic ring size 32–64 (vs Monero's fixed 16)
- Network padding inherited from Monero (1024-byte granularity)
- Fixed 2500-byte internal TX padding (
tx_extra) - Transaction propagation via Dandelion++ stem/fluff (inherited from Monero)
- Confidential amounts via RingCT (Pedersen commitments)
- One-time stealth addresses (CryptoNote)
- Post-quantum resistance scheduled for 2027
2 · Vision & Problem
The problem of financial privacy
Traditional public blockchains (Bitcoin, Ethereum) fully expose transaction flows. Even Monero — the privacy benchmark — has limits: a fixed ring size of 16, exploitable network metadata, and possible timing attacks.
The HIDERING vision
- On-chain anonymity: ring signatures 32–64, one-time stealth addresses, RingCT
- Network anonymity: Dandelion++ propagation and end-to-end encryption inherited from Monero
- Amount confidentiality: RingCT (Pedersen commitments), plus fixed 2500-byte internal
tx_extrapadding to uniformise auxiliary field sizes - Future resistance: planned post-quantum migration via hard fork (2027)
3 · Technical Architecture
HIDERING is a fork of Monero v0.18.1 (CryptoNote), inheriting RingCT (confidential amounts), Bulletproofs+ (compact proofs), RandomX (CPU-only, ASIC-resistant PoW) and Dandelion++ (transaction diffusion).
| Component | Monero | HIDERING |
|---|---|---|
| Ring size | 16 | 32–64 (dynamic) |
| TX padding | Variable | 2500 B internal (network: Monero 1024 B) |
| Network | Dandelion++ | Dandelion++ (inherited) |
| Amounts | Hidden (RingCT) | Hidden (RingCT) |
| Stealth | One-time | One-time (CryptoNote) |
| PoW | RandomX | RandomX (identical) |
| Hard fork | HFv15 | HFv15 from block 1 |
tx_extra field; the network-layer padding remains Monero's (1024-byte granularity).4 · Tokenomics (HRG)
| Parameter | Value |
|---|---|
| Ticker | HRG |
| Maximum supply | 18,000,000 HRG (irrevocable hard cap) |
| Max circulating supply | 18,000,000.00 HRG exact — the genesis NUMS 157.14 HRG is unspendable and excluded from emission accounting, so it is not deducted from the cap |
| Emission | 100% PoW (no seed round, no private sale) — see §7 |
| Block time | 120 seconds |
| Halving interval | 210,000 blocks (~2.66 years) |
| PoW algorithm | RandomX (CPU-only) |
| Initial reward | 42.86 HRG / block |
| Addresses | Begin with "B" (prefix 60) |
5 · Bitcoin-Style Emission
| Period | Block height | Reward / block | Emitted (period) |
|---|---|---|---|
| Genesis | 0 | 157.14 HRG (NUMS-locked, unspendable) | 0 circulating |
| Era 1 | 1 – 210,000 | 42.86 HRG | 9,000,000 HRG |
| Era 2 | 210,001 – 420,000 | 21.43 HRG | 4,500,000 HRG |
| Era 3 | 420,001 – 630,000 | 10.71 HRG | 2,250,000 HRG |
| Era 4+ | 630,001+ | ½ per halving | → 18M hard cap |
The geometric series converges exactly on the cap:
100% PoW emission, zero inflation, irrevocable cap. The genesis block contains 157.14 HRG locked under a Nothing-Up-My-Sleeve (NUMS) key — cryptographically unspendable and kept for deployed-chain compatibility. See GENESIS_PROOF.md.
6 · Quantum Resistance
Post-quantum cryptography is introduced via a hard fork planned for 2027:
- Signatures: ML-DSA-65 (FIPS 204, NIST PQC standard)
- Key exchange: ML-KEM-768 (FIPS 203, NIST PQC standard)
- New addresses: a dedicated BQ... format for ML-KEM-768 keys (the classic B... format is unchanged)
- Impact: only post-fork transactions use the new scheme; historical blockchain data is unaffected
- Compatibility: a mandatory binary update at fork time
tx_extra, ML-KEM-768 KEM) is implemented and has undergone several internal security audits. All PQ code remains inert until the hard fork (HFv16, HF_HEIGHT_PQ = 2,000,000). The nominal path is implemented: C-1 binding, validator checks a–e, the wallet2 spend side, the H-5 multi-ciphertext fix, mempool acceptance and wallet activation. The full B...→BQ...→spend flow is validated end-to-end on regtest (commits 7d53cb940→b72425afe, branch v2-privacy). Mainnet target: Q2 2027 (unchanged).6.1 · What activating HFv16 actually takes
Earlier revisions of this document claimed that "if a real quantum threat emerges, activation is possible in 24–48h by changing the HF_HEIGHT_PQ constant". That claim was false and has been withdrawn. Changing a constant does take minutes — it is simply not what governs the timeline. HFv16 activation is blocked today, and will remain so for months at minimum.
- Security blockers. The post-quantum library we use (liboqs) still carries its authors' own warning, in its current release: "we do not currently recommend relying on this library in a production environment or to protect any sensitive data". It holds no FIPS 140-3 validation — only the algorithms (ML-KEM, ML-DSA) are final NIST standards, not the implementation. Until that is resolved (third-party audit, a validated implementation, or a formalised hybrid posture), HFv16 will not be activated.
- Open functional gaps. BQ subaddresses do not exist yet. (Two gaps closed on 8 September 2026: cold-signing a BQ spend — the transfer file carries the ML-KEM-768 ciphertext and never the shared secret, and the offline machine re-derives that secret with its own keys — and B.../BQ consolidation, via the hybrid transactions described in §6.3.)
- The real cost is coordination. A hard fork is not a software deployment. Binaries must be published for every platform, miners, pools, services and wallet holders must upgrade, and the activation height must be announced well in advance so the network converges. A node that has not upgraded ends up on a dead chain. That process takes weeks, and no amount of urgency compresses it.
If a real quantum threat emerged, the schedule would be compressed as far as it can go and communicated as an emergency — but the order of magnitude remains weeks, not hours. Any promise to the contrary would be dishonest.
6.2 · The trade-off we are making: a BQ spend is transparent
This point matters and was absent from previous revisions of this document.
HIDERING claims strong privacy, delivered by ring signatures (ring 32–64), stealth addresses and RingCT (amounts hidden behind Pedersen commitments). Those guarantees do not apply in the same way when you spend a BQ output.
Technically: a post-quantum input (txin_to_key_pq) carries no Pedersen commitment, so its value cannot be balanced by RingCT. The transaction is therefore built as v2 RCTTypeNull, which means:
- amounts are revealed in cleartext on chain, both inputs and outputs;
- there is no ring signature on the BQ input: the output being spent is named directly, with no decoys. Ring anonymity on that input is zero;
- authorisation rests on the per-output ML-DSA-65 signature and the bind tag, not on a ring.
In plain terms: spending from a BQ address is as transparent as a Bitcoin transaction. Full HIDERING privacy remains the property of classic B... addresses. BQ addresses buy quantum resistance at the cost of spend privacy.
What is still protected: receiving to a BQ address reveals no more than a classic receive — the output is stealthy and unlinkable to the published address. It is spending that output that is transparent.
A genuine post-quantum ring signature is an open research problem, and HIDERING does not claim to have solved it.
6.3 · Hybrid transactions — getting output amounts hidden again
Since 8 September 2026 a transaction may mix a transparent BQ input with classic ring inputs. Two consequences:
- Consolidation works. A wallet can finally spend B... and BQ... funds in one transaction, and pay more than either side holds on its own. Without it, anyone mid-migration had two watertight pots.
- More privacy, not less. A pure BQ spend is a fully transparent transaction (§6.2): every output amount is in cleartext. A hybrid is a real RingCT transaction — only the PQ inputs' amounts are revealed, and the outputs go back to being Pedersen commitments with range proofs.
How the balance closes: a transparent input of value a has no commitment, but a verifier can recompute one from public data with a zero mask (a·H). The RingCT equation becomes sum(pseudoOuts) + sum(a_pq)·H == sum(outputs) + fee·H — that is, transparent inputs behave exactly like a negative fee.
What stays true either way: the amount of a BQ input being spent is public. The hybrid does not hide what you spend from a BQ address; it hides what you send again. The guidance in §6.2 is unchanged.
Guidance while this trade-off stands: use classic B... addresses for everyday use. BQ addresses are for those whose threat model includes a quantum adversary and who knowingly accept revealed amounts and no ring on their spends.
7 · Fair Launch Distribution
Principle: 100% emission via RandomX PoW, no private sale, no seed round. Block 0 is a genesis with 157.14 HRG locked under a NUMS key (unspendable). From block 1 onward, rewards are distributed by pure PoW competition.
7.1 · Pre-public phase v2.0.0 (post-attack)
Shortly after the v1.x launch, HIDERING suffered a 51% attack (16 May 2026, v1.x chain at h≈3577): an external miner with more power than the rest of the network dominated the chain and caused a major reorganisation, orphaning every mined block. The v2.0.0 response is twofold:
- Network hard fork: the Network ID moved from
HRG\x01HIDERINGMAINtoHRG\x02HIDERINGMAIN(magic0x48524701→0x48524702), immediately isolating the malicious miner. - Pre-mining phase: before public opening, founder nodes mine on a private network to (1) harden the network from day one, (2) fund development — GUI wallet testing and the post-quantum work need real on-chain transactions — and (3) build a community reserve that will be redistributed to launch participants or partially burned.
The v2.0.0 pre-mining is a defensive shield and a development-funding lever, not an insider sale: all coins are produced by PoW. Once the network opens publicly, every miner competes under the same RandomX rules. The exact volume, duration and final destination of the reserve will be communicated publicly at launch.
8 · Pool Mining
HIDERING operates a public RandomX mining pool in production to lower the barrier to CPU mining.
| Parameter | Value |
|---|---|
| Stratum endpoint | pool.hidering.org:3333 |
| Algorithm | RandomX (rx/0) |
| Stack | cryptonote-nodejs-pool + Redis + Nginx |
| Starting difficulty | varDiff (auto-adjusted) |
| Block reward | 42.857142857143 HRG (era 1) |
Solo mining is fully supported via hideringd + hidering-wallet-cli. See the Mining guide for both paths. The v2.0.0 chain embeds checkpoint anchors (heights 2939, 5000, 11000, 16000, 20000, 25000, 80386) to aid initial synchronisation — consensus security still rests on cumulative RandomX PoW.
9 · Technical Specifications
| Ticker | HRG |
| Fork base | Monero v0.18.1 |
| Network ID | HRG\x02HIDERINGMAIN (v2.0.0) |
| Magic bytes | 0x48524702 (v2.0.0) |
| P2P port | 19740 |
| RPC port | 19741 |
| Address prefix | 60 → "B" |
| Decimals | 12 (10¹²) |
| Block time | 120 seconds |
| Ring size | 32–64 |
| Supply | 18,000,000 HRG |
| Initial reward | 42.857142857143 HRG / block |
| Halving | 210,000 blocks (~2.66 years) |
| Unlock window | 60 blocks |
| License | BSD 3-Clause (as Monero) |
| Repository | github.com/AB-lab113/hidering |
10 · Resources
- Website: hidering.org
- GitHub: github.com/AB-lab113/hidering
- Releases: github.com/AB-lab113/hidering/releases
- Block explorer: explorer.hidering.org
- Pool: pool.hidering.org:3333
- OTC desk: @HideringOTCBot
- Seed nodes: seed1.hidering.org · seed2.hidering.org
Whitepaper v1.4.2 — revised September 2026 (post-quantum activation timeline and the BQ transparency trade-off; earlier revisions: HFv16 implementation June 2026, June 2026 security audit). HIDERING is open-source software (BSD 3-Clause). The team gives no financial advice; HRG is an experimental asset, and users are responsible for compliance with their local laws.