1 · Abstract
HIDERING (HRG) is a maximum-privacy cryptocurrency protocol derived from a snapshot of Monero's development branch (December 2025), combining advanced anonymity with a Bitcoin-style monetary model.
100% emission via RandomX proof-of-work, with an irrevocable supply cap of 18,000,000 HRG. The code contains no premine and no allocation; see §7.
Key innovations:
- Ring signatures of 32 members by default in the HIDERING wallets (CLI, RPC and GUI); consensus allows 32–64 (Monero: fixed 16)
- Network padding inherited from Monero (1024-byte granularity)
- 2500-byte internal
tx_extrapadding by the HIDERING wallet CLI and RPC (a wallet rule, not a consensus rule) - Transaction propagation via Dandelion++ stem/fluff (inherited from Monero)
- Confidential amounts via RingCT (Pedersen commitments)
- One-time stealth addresses (CryptoNote)
- Post-quantum resistance (target: 2027, not yet scheduled)
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 members by default, up to 64), one-time stealth addresses, RingCT. A larger ring includes more decoys per input, but the ring size is public on-chain, so a size that few people use makes a transaction easier to recognise; the default (32) is recommended.
- Network anonymity: Dandelion++ propagation (inherited from Monero). P2P traffic is not encrypted.
- Amount confidentiality: RingCT (Pedersen commitments), plus 2500-byte internal
tx_extrapadding by the HIDERING wallet CLI and RPC (a wallet rule, not a consensus rule) - Future resistance: post-quantum migration via hard fork (target: 2027, not yet scheduled)
3 · Technical Architecture
HIDERING is a fork of a snapshot of Monero's development branch (December 2025) (CryptoNote), inheriting RingCT (confidential amounts), Bulletproofs+ (compact proofs), RandomX (PoW designed to be CPU-friendly) and Dandelion++ (transaction diffusion).
| Component | Monero | HIDERING |
|---|---|---|
| Ring size | 16 | 32 by default (32–64 allowed) |
| TX padding | Variable | 2500 B tx_extra, wallet rule (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 HRG (exact sum 17,999,999.99999418 HRG: the reward is rounded down at each halving) — the genesis 157.14 HRG NUMS output is unspendable and not counted in emission, 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 (~292 days) |
| PoW algorithm | RandomX (CPU-optimised) |
| 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, no tail emission, 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 (target: 2027, not yet scheduled):
- 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, AI-assisted security reviews (no third-party audit). All PQ code remains inert. The current code carries a placeholder activation height (2,000,000) that is not the planned date; the real activation height will be set by a future release and announced before activation. 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). Target: 2027, not yet scheduled.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. HIDERING's post-quantum cryptography has undergone an AI-assisted review and a documented risk acceptance rather than a third-party audit (see M-11). HFv16 will not be activated until the remaining hardening work — constant-time verification and NIST ACVP test vectors — is delivered.
- Open functional gaps. BQ subaddresses are implemented in the wallet core and CLI (decision 4 / option B3, delivered 11 September 2026), but not yet exposed via wallet-rpc or the GUI wallet, and remain inert until HFv16. One open point remains: a view-only wallet cannot detect a BQ output. (Two related gaps were closed on 8 September 2026: cold-signing a BQ spend, 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 ahead of activation 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 · 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, every block reward goes to whoever mines it; the project's own nodes mine under the same rules as everyone else.
7.1 · v2.0.0 (post-attack)
After the 51% attack on the v1.x chain (16 May 2026, h≈3577), v2.0.0 moved to a new Network ID (HRG\x02HIDERINGMAIN), which separated the new network from the v1.x chain.
Before the public opening of v2.0.0, the founder nodes mined on a private network for a short period. When the network opened, that private chain was replaced by the public chain and the privately mined blocks were orphaned: no coins from that phase are part of the live chain. Earlier revisions of this document announced a reserve from that phase, with its volume and use to be disclosed at launch; that announcement is withdrawn.
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, 90000) to aid initial synchronisation — consensus security still rests on cumulative RandomX PoW. The public v2.0.3 binaries contain the first six (up to 25000).
9 · Technical Specifications
| Ticker | HRG |
| Fork base | a snapshot of Monero's development branch (December 2025) |
| 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 by default (32–64 allowed) |
| Supply | 18,000,000 HRG |
| Initial reward | 42.857142857143 HRG / block |
| Halving | 210,000 blocks (~292 days) |
| Unlock window | 60 blocks (mined coins) · 10 blocks (received outputs) |
| 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.3 — revised October 2026 (earlier revisions: post-quantum activation timeline and the BQ transparency trade-off September 2026, HFv16 implementation June 2026, June 2026 internal security review). 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.