Neoxa
Technical Whitepaper

Abstract

Neoxa is a Layer 1 cryptocurrency network. It uses a memory-hard proof-of-work consensus (KawPoW) for block production, a Dash-derived smartnode tier (DIP-3) for instant transaction finality and chain-reorganization protection, and a Ravencoin-derived native asset protocol for first-class token issuance at the consensus layer. The reference implementation is a fork of the Bitcoin Core C++ codebase, inheriting the UTXO transaction model, Script execution environment, and JSON-RPC interface.

Every block pays a fixed reward of 5,000 NEOX, distributed by consensus rules to the block's miner (45%), to the next-in-queue smartnode (45%), and to a development wallet (10%). The reward halves every 2,100,000 blocks, producing a geometric series that converges to a maximum supply of 21,000,000,000 NEOX.

The chain launched on May 1, 2022 from a single 5,000 NEOX genesis coinbase. There was no premine.

1. Introduction

Bitcoin established that a UTXO ledger combined with proof-of-work consensus is sufficient to enable a peer-to-peer electronic cash system [1]. Subsequent networks have extended that base by either (a) modifying the consensus algorithm to broaden the participant base, (b) layering deterministic incentivized nodes on top of mining to offer additional services, or (c) embedding token and asset semantics into the transaction validator. Neoxa combines all three.

The design goals at the protocol level are:

1. Open mining. Block production is permissionless and accessible to consumer-grade GPUs, the same population that secures Ravencoin and similar memory-hard chains.
2. Deterministic instant finality. A second tier of always-online nodes provides smartnode-signed transaction locks (InstantSend) and chain-tip locks (ChainLocks), eliminating the probabilistic confirmation model for users that accept the trust assumption.
3. Native asset issuance. Tokens, sub-assets, and unique (non-fungible) assets are first-class chain objects with consensus-enforced uniqueness, supply, and ownership. There is no smart-contract execution layer; asset semantics live in the script validator.
4. Fixed supply. Issuance is fully programmatic, with no governance-level minting outside the block subsidy schedule.

2. Lineage

Neoxa is a fork of the Dash codebase [5], which is itself a fork of Bitcoin Core [3]. From its Dash ancestry it retains the deterministic smartnode list (DIP-3), Long-Living Masternode Quorums (LLMQs), the InstantSend transaction lock primitive, ChainLocks chain-reorganization protection, the on-chain governance system, and the spork feature-flag mechanism.

Two protocol layers are imported from Ravencoin [2]: the KawPoW proof-of-work algorithm [4] in place of Dash's X11 work function, and the native asset protocol implemented at the script-opcode level. Both are integrated into the Dash-derived consensus and network code rather than being layered as separate modules.

The result is a Bitcoin-derived UTXO chain that takes its second-tier validator set, instant-finality primitives, and governance from Dash, and takes its work function and native asset semantics from Ravencoin.

3. Proof of work (KawPoW)

Neoxa uses KawPoW as its block validation function. KawPoW is a customization of ProgPoW [6] developed for Ravencoin, designed to keep specialized ASIC hardware at a structural disadvantage by being memory-hard and tied to a periodically-regenerated dataset.

KawPoW operates on a directed acyclic graph (DAG) that is rebuilt at each epoch boundary. Memory bandwidth, not raw arithmetic throughput, dominates the cost function. The intent is to keep GPU mining economically competitive with any specialized hardware that could be designed for the algorithm.

At the protocol level, KawPoW is the function that maps a block header to a 256-bit hash. A block is valid if (and only if) that hash, interpreted as a big-endian integer, is less than the current difficulty target. There is no other branching consensus rule for block acceptance.

4. Block time

Neoxa targets a 60-second average block interval. With Bitcoin's 10-minute target [1] as a reference point, Neoxa's parameters trade settlement frequency for ten-times-longer transaction history per unit of UTXO state. The block size and transaction format are inherited from Bitcoin Core.

Genesis was mined on 2022-05-01. As of block 2,076,xxx (May 2026), the empirical average is within 1% of the target, computed as (t_now − t_genesis) / height.

5. Difficulty retarget

Difficulty retargets every block. This contrasts with Bitcoin's 2,016-block retarget [1] and reflects the shorter block interval: a 60-second chain that retargeted on the same epoch schedule as Bitcoin would react to hashrate shocks an order of magnitude more slowly.

The retarget algorithm is inherited from the Dash codebase's Dark Gravity Wave family, which uses a weighted moving average of recent block solve times to compute the next target. The mechanism handles both rapid hashrate growth and rapid hashrate departure without the difficulty death-spiral problem that affects fixed-epoch retarget chains.

6. ChainLocks

Bitcoin-family consensus provides only probabilistic finality: a block is final only to the extent that an attacker would need to expend more proof-of-work than the network has applied since it was produced. The probability of a successful reorganization decreases exponentially with confirmation depth, but never reaches zero.

ChainLocks replaces the probabilistic model at the tip of the chain. After a block is produced, a Long-Living Masternode Quorum (LLMQ) signs the block's hash. Any node that observes the signed hash and the LLMQ membership rejects any alternative chain that does not extend the signed tip. The effect is that, once ChainLocked, a confirmed block cannot be reorganized regardless of how much proof-of-work an attacker accumulates on a competing chain.

ChainLocks is enabled at the protocol level on Neoxa via SPORK_19. The signing quorum is drawn from the deterministic smartnode list (see Section 13).

7. Block reward

The base block reward is exactly 5,000 NEOX, paid by the coinbase transaction of every block. The reward is fixed within each halving epoch and changes only at scheduled epoch boundaries.

Mathematically, the reward at block height h is:

R(h) = 5,000 / 2^⌊h / H⌋   NEOX

where H = 2,100,000 (halving interval in blocks)

This is structurally identical to Bitcoin's halving model [1], with the base reward and halving interval scaled for Neoxa's 60-second block time and 21B maximum supply.

8. Halving schedule

Halvings occur every 2,100,000 blocks, which at the 60-second target block time corresponds to approximately 3.99 years per epoch. The first four epochs:

The cumulative-supply column accounts for the genesis block, which itself paid a single 5,000 NEOX coinbase. The +5,000 offset propagates through every subsequent epoch end.

9. Supply asymptote

Total emission over all halving epochs is the geometric series:

S∞ = Σ (H · R₀ / 2^k)   for k = 0, 1, 2, …
   = H · R₀ · Σ (1/2)^k
   = H · R₀ · 2
   = 2,100,000 · 5,000 · 2
   = 21,000,000,000   NEOX

The series converges to exactly 21,000,000,000 NEOX. The chain cannot mint above this bound under any code path the validator accepts.

In practice, the actual circulating supply tracks slightly below the schedule because the asset issuance protocol burns NEOX on every new asset (Section to be added: Asset protocol). Each main asset issuance removes 500 NEOX from circulation; each sub-asset removes 100; each unique asset removes 5. These burns are paid to consensus-recognized burn addresses and are unspendable.

10. Coinbase distribution

The coinbase transaction of every Neoxa block contains three explicit value outputs, totaling R(h):

All three outputs are written into the coinbase by consensus. A block with any other distribution is invalid and is rejected by every validating node.

At the base reward of 5,000 NEOX, the per-block values are 2,250 / 2,250 / 500 NEOX. The three-way split has been the consensus rule since the activation of the DIP-3 smartnode list at block 628,992. Before that activation point, smartnodes were not yet eligible for payment and the coinbase split was 85% / 15% between the block's miner and the development wallet. The 45 / 45 / 10 structure described here was verified empirically against post-DIP-3 blocks (block 1,500,000, 2,000,000, and 2,076,315) during the drafting of this document.

The 10% coinbase output is a single consensus-recognized address fixed in chainparams.cpp. Once that output is paid by consensus, the team operationally allocates the funds off chain: approximately half funds the Neoxa Gaming play-to-earn reward pool (paid out off chain by the gaming platform), and approximately half funds development. The off-chain allocation is not enforced by consensus; the chain only enforces that the 10% slice is paid to the consensus address.

11. Transactions and addresses

Neoxa inherits the Bitcoin Core transaction format. Transactions consist of a version field, a vector of inputs (each referencing a previous transaction's output by (txid, vout)), a vector of outputs (each carrying a value in satoshis and a scriptPubKey), and a lock time. The execution model is the same UTXO-based stack machine that Bitcoin uses [1, 3].

Standard output types are P2PKH, P2SH, multisig, and OP_RETURN data carriers. Neoxa does not have SegWit activated: its bip9_softforks set contains only assets, messaging_restricted, transfer_script, enforce, coinbase, and dip0003. P2WPKH and P2WSH outputs are therefore not part of the protocol. One non-Bitcoin output type is introduced by the asset protocol (Section 12).

Addresses are Base58Check encodings of { version byte || hash160 || 4-byte checksum }. The version byte for Neoxa P2PKH addresses is 0x26 (decimal 38), which produces the leading character G in every standard address. Verification by direct decoding of two arbitrary P2PKH addresses observed on chain:

Address: GcmKXqWrFrbDnywuY8F3orEnNR5L1g2mZQ  →  version 0x26
Address: GfmH3wc9xncwvp9Z6xEhZ8nxC8ub4E6wKh  →  version 0x26

The default minimum relay fee is 0.01 NEOX per kilobyte and the incremental fee is 1e-5, as reported by getnetworkinfo. Mempool eviction follows standard Bitcoin Core policy.

12. Native asset protocol

The asset protocol is inherited from Ravencoin [2] and embedded directly in the script validator. Issuance, transfer, and reissuance are not smart-contract calls; they are consensus rules enforced at script execution time.

12.1 The opcode. A single new opcode, OP_NEOX_ASSET, marks an output as carrying an asset payload. The full scriptPubKey of an asset output is a standard P2PKH script followed by OP_NEOX_ASSET and a length-prefixed payload:

OP_DUP OP_HASH160 <hash160> OP_EQUALVERIFY OP_CHECKSIG OP_NEOX_ASSET <payload>

The first five opcodes are a standard P2PKH script that determines who can spend the output. OP_NEOX_ASSET and the payload bind asset-specific data to the same output. Wallets that don't implement the asset protocol still treat the output as a regular zero-value P2PKH and ignore the trailing data.

12.2 Payload encoding. The payload is a length-prefixed byte string with the following structure:

<varlen>            // total payload length (1 byte for short payloads)
"rvn" (3 bytes)     // protocol marker, inherited from Ravencoin
<type> (1 byte)     // 'q' new asset, 'o' owner asset, 't' transfer
                    // (reissue uses a distinct marker; verified by inspecting
                    // chain data is left as future work)
<name-len>          // 1 byte
<name>              // asset name string
<amount> (8 bytes)  // satoshi-style integer, little-endian (omitted for owner tokens)
<units> (1 byte)    // decimal precision 0 to 8 (omitted for owner tokens)
<reissuable> (1 byte) // 0 or 1 (omitted for owner tokens and unique)
<has_ipfs> (1 byte) // 0 or 1
[ipfs_hash]         // 34 bytes if has_ipfs == 1

Type bytes 0x71 ('q') and 0x6f ('o') were verified by decoding the issuance transaction of asset 001 in block 18,284. The transfer marker 0x74 ('t') was verified by decoding a transfer-asset output in block 2,076,000.

Empirical verification against block 18,284 (the issuance of asset 001) decodes its asset output payload as rvn / q / "001" / 100000000 / units=1 / reissuable=1 / has_ipfs=0, paired with an owner-token output carrying the payload rvn / o / "001!".

The "rvn" marker is intentional. Neoxa preserves Ravencoin's payload header so any tooling that decodes Ravencoin asset transactions can decode Neoxa asset transactions without modification.

12.3 Asset namespace. Asset names follow Ravencoin's naming convention. The following type-distinguishing separators encode the asset kind in the name itself:

• Main asset: NAME. Uppercase alphanumeric plus . and _.
• Sub-asset: PARENT/CHILD. The chain validator requires the issuer to control the parent's owner token (PARENT!).
• Unique asset: PARENT#TAG. Non-fungible, quantity exactly 1, non-reissuable by chain rule. Requires control of PARENT!.
• Owner token: NAME!. Generated automatically as a paired output of every main or sub-asset issuance. Quantity 1. Holding it grants reissue and sub-asset rights for its namespace.
• Message channel: NAME~CHANNEL. Used to broadcast messages to holders of the parent asset.

Uniqueness of asset names is a consensus rule: an issuance transaction with a name that already exists is rejected by every validating node.

12.4 Issuance fees (NEOX burns). Each issuance type pays a fixed burn fee to a consensus-recognized burn address. The burn addresses are hard-coded in chainparams.cpp in the reference implementation and are distinct per issuance type. The corresponding NEOX is permanently removed from circulating supply.

Reissuance of an existing reissuable asset also incurs a burn fee paid to a separate consensus burn address; the exact amount is fixed in the reference implementation.

13. Smartnode protocol

The smartnode tier is a Dash-derived second layer of validators that operate alongside, but independently of, the miners producing blocks. Smartnodes provide three protocol-level services: (a) round-robin block reward payments to themselves under consensus, (b) LLMQ signing for InstantSend and ChainLocks, and (c) on-chain governance voting.

13.1 Collateral. A smartnode is identified by a single unspent transaction output of exactly 1,000,000 NEOX. The collateral remains in the operator's own wallet at all times; the chain merely indexes it as part of the deterministic smartnode list. Spending the collateral output automatically deregisters the smartnode in the next block.

13.2 DIP-3 deterministic list. Smartnodes are registered through DIP-3 [5], the deterministic masternode list standard. The state of the list at any block height is a pure function of the chain history up to that height; every node can independently reconstruct the same list from the same chain data without consulting any external service.

13.3 Five-key model. Each smartnode binds five distinct addresses or keys:

• Collateral address. Holds the 1,000,000 NEOX UTXO.
• Owner address. Authorized to update or revoke the registration on chain.
• Voting address. Authorized to cast governance votes. Can be delegated separately from the owner key.
• Payee address. Receives the 45% smartnode share when this node is paid. Can be the same as the collateral address or any other.
• Operator BLS key. Held by the running daemon on the smartnode's server. Used to sign LLMQ messages.

Separating these roles enables cold-storage operators: the collateral and owner key can remain on an offline desktop wallet while the operator BLS key (alone insufficient to spend funds) lives on the VPS running the daemon.

13.4 Registration and updates (ProTx family). Registration and lifecycle changes are performed via a family of special transactions exposed under the protx RPC namespace. The verified subcommands are:

• register creates and sends a ProRegTx (Provider Register) that encodes the five addresses and keys.
• register_fund, register_prepare, and register_submit split the same registration into separate funding, preparation, and signing-and-broadcast steps for cold-storage operators.
• quick_setup performs prepare, sign, and submit in one RPC call.
• update_service sends a ProUpServTx to change the operator-side IP, port, or BLS key.
• update_registrar sends a ProUpRegTx to change the voting or payee address.
• revoke sends a ProUpRevTx to revoke the registration.

The registration transaction must spend the collateral UTXO as an input or reference it as an external collateral. After confirmation and successful LLMQ participation, the smartnode is admitted to the active payee queue.

13.5 LLMQ formation. Long-Living Masternode Quorums are groups of smartnodes selected deterministically from the active list. Membership in each quorum is computed from the chain tip's hash and the smartnode list at that height, so every node agrees on quorum membership without coordination. Quorums sign InstantSend locks (Section 14) and ChainLocks (Section 6). The DKG (Distributed Key Generation) protocol is enabled at the chain level via SPORK_17.

13.6 Proof of Service (PoSe). Each smartnode accumulates a PoSe score when it fails to respond to network-level checks (missed quorum signings, missed heartbeats). The score increments are deterministic, computed by every validating node from the same observed evidence. When a smartnode's PoSe score crosses the chain's threshold, it is marked POSE_BANNED and removed from the active payee queue. The operator clears the ban by submitting a ProUpServTx (via protx update_service) that re-announces the node's address and operator key.

At the time of drafting, the live smartnode list contains 5,907 registered nodes total: 4,280 ENABLED and 1,627 POSE_BANNED. Only those two status values are observed in the current list.

13.7 Round-robin payment selection. The chain enforces a deterministic queue over the active smartnode set. At each block, the next-in-queue smartnode receives the 45% block reward share via the coinbase's second value output (Section 10). Selection prioritizes smartnodes that have been waiting longest since their last payment, ensuring the queue cycles through every active node before any node is paid twice. With N active smartnodes and 1,440 blocks per day, the expected interval between payments to any one node is N / 1,440 days.

14. InstantSend

InstantSend is a transaction-locking protocol that uses smartnode Long-Living Masternode Quorums (LLMQs) to make a transaction's funds final before its containing block is confirmed.

The signing flow is, in outline:

1. A wallet broadcasts a transaction flagged for InstantSend.
2. The flagged transaction is observed by the LLMQ scheduled to sign InstantSend locks at the current chain tip. Quorum membership is computed deterministically from the tip's hash and the smartnode list (Section 13.5).
3. The quorum runs a threshold-signature protocol over the transaction's inputs and produces a single aggregated signature.
4. The signed lock is broadcast across the network. Any node that observes the lock and recognizes the quorum considers the inputs of that transaction permanently committed and rejects any conflicting transaction that attempts to double-spend them.

The lock is independent of block confirmation: a wallet that accepts the trust assumption of the LLMQ can treat InstantSent funds as final the moment the lock is broadcast, typically within seconds of the original transaction. The next block confirmation is purely the standard chain-level commitment.

Three sporks gate the protocol on Neoxa as of drafting:

• SPORK_2 (INSTANTSEND_ENABLED): ACTIVE. The signing path is enabled.
• SPORK_16 (INSTANTSEND_AUTOLOCKS): OFF. Automatic locking of non-flagged transactions is disabled, so InstantSend must be explicitly requested by the broadcasting wallet.
• SPORK_17 (QUORUM_DKG_ENABLED): ACTIVE. The Distributed Key Generation protocol that constructs the quorum's threshold key is enabled. SPORK_17 is also a prerequisite for ChainLocks (Section 6).

15. Governance

Neoxa includes the Dash governance subsystem: a chain-level mechanism for submitting proposals, casting one-vote-per-smartnode votes, and (optionally) paying winning proposals from a periodic budget block called a superblock.

15.1 Lifecycle. A proposal proceeds through four phases:

1. Prepare. The proposer constructs a governance object describing the proposal (subject, amount, payment address, URL) and signs the object with the proposer's key.
2. Submit. The proposer submits a transaction containing the prepared object and paying the on-chain proposal fee. This is the gobject submit RPC.
3. Vote. Smartnode operators cast yes/no/abstain votes via gobject vote-alias, vote-conf, or vote-many over the voting cycle. One vote per smartnode.
4. Outcome. At the end of the cycle, votes are tallied. Proposals that meet the minimum quorum and a positive vote balance are recorded as passed.

15.2 Parameters. The system parameters reported by getgovernanceinfo at drafting:

15.3 Superblocks and funding. A superblock is a block at a fixed interval (every 16,616 blocks) whose coinbase carries additional outputs paying the winning proposals. The superblock mechanism is gated by SPORK_9 (SUPERBLOCKS_ENABLED), which is currently OFF. The voting layer is still live and proposals can still be submitted and tallied; only the automatic payout via superblock is paused at the protocol level. SPORK_9 can be activated by the network without a hard fork.

15.4 RPC surface. The full gobject subcommand set: check, prepare, submit, deserialize, count, get, getcurrentvotes, list, diff, vote-alias, vote-conf, vote-many.

16. Network parameters

Consolidated reference of the protocol-level constants and feature flags. All values were sampled from a running Neoxa Core 5.1.1.4 node during drafting.

Network

Addresses

Fees

BIP9 softforks

All six BIP9 softforks reported by getblockchaininfo are active:

Sporks

Sporks are chain-level feature flags that can be flipped on or off by the spork key without a hard fork. The current state on mainnet:

17. Comparison

Neoxa's design choices, summarized against the chains it descends from (Bitcoin and Ravencoin) and the chain whose secondary protocol layer it borrowed (Dash).

In summary: Neoxa is a Dash-based UTXO chain that adopts Ravencoin's KawPoW work function, emission schedule, and native asset protocol, while inheriting Dash's deterministic smartnode tier, InstantSend, ChainLocks, and on-chain governance.