Payments and settlement
The permanent MAINNET chain combines proof-of-work ordering with independently verified payment and masternode certificates.
| Component | Role | Operating boundary |
|---|---|---|
| GX9 proof of work | Orders valid transactions into blocks | Target spacing is 150 seconds; this is not a fixed inclusion or settlement time. |
| Public payments | Explicit transaction inputs, outputs and amounts | Transaction data is visible on the chain. |
| Private payments | Proofs validate hidden payment data | Transparent funding, fees and network observations can still reveal information. Private delivery and network-origin protection are separate. |
| Transaction locks | A verified certificate reserves a transaction against conflicting spending | Requires the applicable quorum service; a lock is separate from block inclusion. |
| Chain finality | A certificate finalizes the relevant chain state | Recipients independently verify their receipt and chain evidence. Static committee settings do not prove current quorum availability. |
Protocol description reviewed October 4, 2026. Finality and transaction locks require at least 30 eligible masternodes. See Network for service requirements.
Authorization and applications
Native authorization, bounded public contracts and research directions have distinct scopes.
| Capability | Scope | Availability |
|---|---|---|
| Native authorization | Multisignature signing and validation | Implemented; wallet workflow and network compatibility still apply. |
| Public contracts | A bounded transaction interpreter for supported programs and state | Implemented with activation at block 13,824. This is not an Ethereum-compatible general-purpose VM. |
| Private assets | BTCX-native issuance, private transfers and burns | Advanced public desktop Terminal tools. Private-history rescan and durable submission recovery shipped in 0.2.9; live asset-workflow validation remains separate. |
| General private contracts / Layer 2 | Private execution, channels and rollups with separately defined settlement and exit rules | Research; no deployed general-purpose system is claimed. |
Activation heights describe consensus rules. They do not establish that a particular wallet, peer or service has upgraded.
Terminal
Included in the public wallet. Ordinary conversations and game moves use encrypted relay delivery outside the chain.
| Capability | Public scope | Boundary |
|---|---|---|
| Chat | Encrypted one-to-one messages, queued delivery and contact identity verification | Contacts can be found by legacy or hybrid addresses. Address binding identifies a key, not a person. Terminal message encryption remains classical. |
| Wallet tools | Queries and contact payments that open wallet review | A relay acknowledgement does not confirm a payment. Fund-moving actions require wallet approval. |
| Games | Game invitations and saved sessions through Terminal | No paid-game settlement or unrestricted third-party marketplace is claimed. |
Windows public wallet 0.2.18 and Android 0.2.5. Advanced desktop contract/asset submission recovery is not yet equivalent on the phone.
Post-quantum protection
Spending protection activates by chain height. Connection encryption is already available between supporting peers.
| Component | Schedule / scope | Boundary |
|---|---|---|
| Hybrid address spending | Ed25519 + ML-DSA-44 from block 22,464 | Current wallets adopt protected receiving/change/mining and new masternode payout defaults after activation. Existing miners need a restart; older addresses remain valid. |
| Masternode keys and certificates | Hybrid registry/finality support; key deadline at block 39,744 | Operation requires an eligible quorum and the corresponding selected keys. |
| Wallet migration | Move and consolidation controls in current public desktop and phone releases | Available after activation; no older-address retirement height is set. Live moves were not exercised in the release record. |
| Network connections | X25519 + ML-KEM-768 when both peers support it | Enabled by default on current nodes; operators can disable it. Older peers can use plaintext. The exchange does not authenticate peer identity. |
| Private payments and messages | Current private-detail and Terminal message encryption remain classical | ML-KEM private-payment encryption is in development. Private proofs still rely on elliptic curves; hash commitments and accounted pool-balance limits add safeguards, not post-quantum proofs. |
Reviewed October 4, 2026, at MAINNET height 21,858, before activation. Calendar estimates are not activation conditions.
Light verification and witness retention
Wallet verification, node storage and archival history serve different purposes.
| Component | Purpose | Limit |
|---|---|---|
| Mobile light client | Verifies chain and wallet evidence | Requires verified headers, relevant proofs and completed wallet scanning before funds are ready. |
| Witness retention | Profile permits pruning after finality with a 576-block retention margin | Depends on finality and does not remove all historical chain data or wallet recovery needs. |
| Archive nodes | Retain full witnesses | Long-term history storage remains a separate operational role. |
The 64 MiB active block envelope and 256 MiB schedule ceiling are capacity limits, not measured throughput or fixed daily storage consumption.
Mining correctness
GX9 hash, arithmetic and block-validation tests.
| Test | Recorded result | Coverage |
|---|---|---|
| CPU / GPU agreement | 20,487 exact matches | 7 fixed vectors + 20,480 repeatable test cases |
| Integrated mining | 1,000 blocks · zero GPU/reference mismatches | Miner and node integration · August 29, 2026 |
| Arithmetic checks | 200,000 comparisons · zero mismatches | Exact FP32 and FP64 operations |
| OpenCL agreement | 64/64 matching hashes per device | RTX 5080 and Intel Graphics · September 5, 2026 |
| Block verification | Independent node verification | Hash and target checked before acceptance |
| Intel Core i5-14400F verification | 4.38 ms at the 99th percentile | 20,000 verifications · one thread · cached header context |
CUDA and arithmetic tests: August 28–29, 2026. OpenCL tests: September 5, 2026.
Hardware benchmarks
| Hardware / miner | Measured rate | Window / date |
|---|---|---|
| NVIDIA GeForce RTX 5080btcx-miner 0.1.0 | 93,890.4 H/s | 60 s2026-09-04 |
| Intel Core Ultra 9 285Kbtcx-cpuminer 0.1.0 | 12,860.9 H/s | 60.2 s2026-09-04 |
Recorded release runs. All measured mining performance →
ASIC resistance testing
GX9 uses dependent arithmetic operations to limit specialized-hardware advantage. The estimate combines GPU power measurements and circuit synthesis.
| Check | Result | What it establishes |
|---|---|---|
| Estimated ASIC advantage in hashes per joule | 3.002× under the stated assumptions | Includes statistical uncertainty and power-sensor accuracy |
| Physical ASIC comparison | Not performed | Fabricated hardware is needed to verify the estimate |
| Power accuracy allowance | ±5 W | Applied in favor of the specialized implementation |
| Measurement controls | Clocks observed; not locked | No calibrated inline board-power meter was used |
Calculated August 28, 2026.
SHA3 / GX9 construction
| Component | Specification |
|---|---|
| Header binding | Domain-separated SHA3-256 of the header without its nonce |
| Nonce input | 32-byte header binding + 64-bit nonce |
| Initialization | SHA3-512; SHAKE256 expands the master tape |
| Mutable tape | 8,192 bytes · 512 sixteen-byte entries · fresh copy per nonce |
| Logical working state | 9,948 bytes |
| Serial work | 1,536 macrosteps × 8 payload stages = 12,288 stages |
| Arithmetic | MULHI · FFMA32 · DFMA64 · IMMA INT8 |
| Internal mixing | Specified raw-Keccak duplex reinforced every 128 macrosteps |
| Final digest | 32 bytes |
| Persistent dataset | None |
GX9 specification: August 28, 2026. Byte order, arithmetic and padding determine consensus.
Calculation and assumptions
The calculation assigns no overhead cost to the ASIC and uses the more favorable of two cost comparisons.
| Input | Value | Role in the calculation |
|---|---|---|
| MULHI coefficient | 1.537929 | Instruction-family upper coefficient |
| FFMA32 coefficient | 1.539041 | Instruction-family upper coefficient |
| DFMA64 coefficient | 1.055397 | Instruction-family upper coefficient |
| IMMA INT8 coefficient | 1.128208 | Instruction-family upper coefficient |
| Serial-chain coefficient | 1.8975 | 1.65 × 1.15 |
| Payload energy fraction | 0.632007639 | Lower bound after the power-accuracy allowance |
| Conservative denominator | 0.333073855 | Smaller result from the two cost comparisons |
| Upper efficiency estimate | 3.002337126× | Reciprocal of the conservative denominator |
A = 1 / min(Σ(sⱼ / cⱼ), s_payload / 1.8975). sⱼ is each instruction family’s energy share; cⱼ is its upper coefficient.
Power measurement conditions
An instrumented run measuring serial-work energy, separate from the optimized-miner benchmark.
| Measurement | Recorded value |
|---|---|
| Serial lengths exercised | 0, 4, 8 and 12 · consensus setting: 8 |
| Warmup | Two 90-second windows |
| Measurement windows | Four 30-second repeats per setting, in counterbalanced order |
| Accepted load samples | 830 |
| Rate at consensus setting | 43,962.343 H/s |
| Board power at consensus setting | 106.735241 W |
| Energy before idle subtraction | 2,427.883 microjoules per hash |
| Idle-bracket drift | 0.362036% |
August 28, 2026. These power readings do not apply to the faster September miner benchmark.
Masternode finality
Masternodes certify valid chain state. Finality activates separately from mining.
| Mainnet parameter | Protocol setting |
|---|---|
| Selected committee | 10 masternodes |
| Certificate threshold | 7 signatures |
| Signature scheme | Ed25519; hybrid ML-DSA-44 support scheduled at block 22,464 |
| Bond per masternode | 2,500 BTCX |
| Minimum eligible population | 30 masternodes |
| Epoch length | 576 blocks |
| Masternode compensation | 40% of post-burn transaction fees when activated |
| Additional block subsidy | None |
| Slashing / delegation / governance voting | Not part of the current design |
Safety assumes no more than three faulty or malicious committee members. Valid proof of work and independent node verification remain required. Conflicting valid certificates halt finality.
Mainnet monetary parameters
| Parameter | Current specification |
|---|---|
| Supply policy | 21 million + Security Tail |
| Block interval | 150 seconds |
| Difficulty adjustment | ASERT · one-hour half-life |
| Active block limit | 268,435,456 weight units (64 MiB under current accounting) |
| Protocol capacity ceiling | 1,073,741,824 weight units (256 MiB); not an active throughput claim |
| Emission ramp | 17,280 blocks |
| Initial full block subsidy | 12.5 BTCX |
| Halving interval | 840,000 blocks |
| Security tail starts | Block 4,200,000 |
| Long-term issuance | Below 0.45% of gross scheduled supply per target year |
| Genesis allocation / presale | No founder allocation at genesis; no presale |
| Mining before public opening | Earlier coins on the permanent chain are retained |
| Foundation allocation | Separate lifetime funding policy; see Foundation policy |
For gross scheduled supply G, annual tail issuance is max(9 × 10¹², floor(3G / 700)) base units over 210,240 target blocks.