XerisCoin
Technical Whitepaper

1Introduction

The current L1 landscape bifurcates into two camps: high-throughput chains that sacrifice decentralization for speed, and slower proof-of-work chains that offer robust security at the cost of programmability. Neither camp addresses two emergent requirements that we believe will define the next decade of on-chain computation: native orchestration of autonomous AI agents, and regulatory-compliant tokenization of real-world assets with Ricardian contract bindings.

XerisCoin takes a different approach. Rather than optimizing for a single consensus property, the protocol layers three mechanisms — Proof-of-History for local ordering, Scrypt Proof-of-Work for block production, and Proof-of-Stake for leader election — into a pipeline that completes within a 4-second slot window. The result is a chain that remains mineable on commodity hardware (Scrypt is memory-hard and ASIC-resistant at our parameterization), provides economic Sybil resistance through staking, and maintains deterministic slot ordering without relying on an external clock.

The instruction set extends beyond transfers and contract calls to include first-class operations for agent registration, hierarchical delegation, oracle feeds, hardware attestation, and zero-knowledge proof verification. These are not bolted-on precompiles — they are native instruction variants processed by the same runtime that handles token transfers, subject to identical fee accounting and replay protection.

2Consensus Architecture

XerisCoin consensus operates as a three-stage pipeline within each 4-second slot. The stages are not independent — each feeds constraints into the next, creating a layered security model where an attacker must simultaneously compromise proof-of-history ordering, stake-weighted leader election, and memory-hard proof-of-work mining to produce a fraudulent block.

2.1Proof-of-History (PoH)

PoH provides local ordering by chaining SHA-256 hashes iteratively, where each hash input includes the output of the previous computation. Unlike deterministic PoH implementations, XerisCoin mixes nanosecond-resolution entropy from the validator's monotonic clock (Instant::elapsed().subsec_nanos(), hardened in XWC-27 from the original wall-clock source) into the hash preimage. This is a deliberate design choice (documented as H-1): the PoH chain is used strictly for local slot assignment and cannot be pre-computed by an adversary who does not control the validator's clock at nanosecond resolution. The PoW hash commits to the PoH tip, binding the two layers.

The PoH output determines slot boundaries. Each slot maps to exactly one block opportunity. Validators use PoH tick counts to synchronize without requiring BFT-style message passing for slot agreement.

2.2Proof-of-Work (Scrypt)

Block production requires solving a Scrypt proof-of-work puzzle within the slot window. Scrypt was selected for its memory-hard property, which raises the cost of ASIC-based mining relative to general-purpose hardware. The Scrypt parameters were iterated across three generations during development; on the current network the v1.2 parameter set is active from genesis (the earlier sets are retained in the node only for historical replay):

The v1.2 parameters represent a balance between memory hardness and the 3.9-second mining timeout that ensures blocks are produced within the slot window. A miner who does not find a valid nonce within 3.9 seconds forfeits the slot.

The PoW preimage is domain-tagged (XRS_POW_V2) and commits to the parent block hash and the PoH timestamp with length-prefixed fields (XWC-05 fix), so a proof-of-work solution cannot be reused across different parents or timestamps. Forward slot leaps are additionally bounded by elapsed PoH time — a block may advance at most the number of slots justified by its PoH delta plus a two-slot skew tolerance (XWC-10 fix) — preventing a proposer from time-warping slot-gated logic such as unbonding.

Non-leader validators may also attempt to mine the same slot, but at 4x the difficulty target (C-2 fix). This provides economic advantage to the elected leader while preserving chain liveness: if the leader fails to produce a block, a non-leader can still fill the slot at a higher computational cost.

2.3Proof-of-Stake (Leader Election)

Leader election is deterministic and stake-weighted. For each slot, the protocol constructs an eligible validator set by filtering for accounts with at least 1,000 XRS staked. Eligible validators are sorted by public key for cross-node consensus, then a stake-weighted random selection — seeded from a domain-separated hash of the previous block's hash and the slot number — determines the leader.

This design (C-1 fix) replaced an earlier scheme that seeded leader election from the PoH hash, which was susceptible to manipulation since PoH is locally computed. Using the previous block's hash — which requires PoW to produce — makes leader prediction contingent on mining the preceding block. The weighted draw uses unbiased rejection sampling (XWC-42 fix) so no validator gains a modulo-bias advantage.

3Block Structure & Transaction Model

Each block contains a fixed header and a variable-length transaction payload. The header commits to the transaction set via a Merkle root, allowing lightweight verification without downloading the full block body.

From HYBRID_SIG_ACTIVATION_SLOT = 1 — i.e. from the first mined block — every header must carry a hybrid signature: an Ed25519 signature and a CRYSTALS-Dilithium3 signature over one canonical, domain-separated, chain-id-bound message. A block is valid only if both verify (see §7). The Dilithium public key is stored inline in the header so validation remains stateless, and from slot 2 it must match the proposer's entry in the on-chain PQ key registry.

Transaction capacity is bounded at 40,000 per block, with each transaction containing up to 16 instructions, 64 account keys, and 8 KB of instruction data per instruction. These structural limits are enforced both at mempool admission and again inside consensus validation (XWC-15 fix), so a malicious producer cannot pack oversized instructions directly into a block. The Merkle root uses RFC 6962-style domain separation with a tagged sentinel for odd-width layers (immune to the CVE-2012-2459 duplicate-transaction ambiguity) and fails closed on any unsigned transaction.

The mempool holds a maximum of 100,000 pending transactions with O(1) signature deduplication via HashSet (LOW-2 fix). Admission is hardened end-to-end: every ingress transaction is sanitized and must carry exactly its declared signer count (XWC-18), underfunded transactions are capped at 10,000 pool entries (XWC-19), requeued transactions re-enter at flat priority with no data-length boost (XWC-20), in-flight proposal transactions are reserved to prevent duplicate admission during the mine-commit window (XWC-17), and admission results are reported to the submitter rather than silently swallowed (XWC-21).

3.1Instruction Set

XerisCoin defines a typed instruction set via the XerisInstruction enum, comprising 54 variants (indices 0–53). Each variant maps to a specific operation processed by the runtime. Legacy Solana-compatibleSystemInstruction::Transfer is disabled from genesis in favor of the native NativeTransfer variant with explicit signer enforcement. Representative variants:

3.2Fee Model & Replay Protection

Transaction fees are active from the first block (FEE_ACTIVATION_SLOT = 1). The base fee is 0.001 XRS (1,000,000 lamports) per transaction, collected by the block proposer. Signers must hold at least the fee amount in their account; transactions from underfunded accounts are dropped from the block without execution.

Replay protection uses a 150-block blockhash expiry window (C-3 and C-4 fixes). Each transaction references a recent blockhash; the runtime rejects transactions referencing blockhashes older than 150 slots (~10 minutes). Server-side signature deduplication with TTL windows provides a secondary defense against replay within the validity window.

4Token Economics

XerisCoin (XRS) has a hard total-supply cap of 700,000,000 tokens: a 200,000,000 XRS treasury pre-allocation plus a runtime-enforced emission budget of 500,000,000 XRS (MAX_EMISSION_SUPPLY). Mining block rewards, staking rewards, and attestation rewards are all drawn from — and jointly capped by — that single 500M emission budget, so no combination of reward flows can push total supply past 700M.

4.1Emission Schedule

The base block reward is 10 XRS (BASE_BLOCK_REWARD), halving every 25,000,000 blocks. At 4 seconds per slot, each halving epoch spans approximately 3.17 years, and the geometric series sums to exactly the 500M emission budget. The halving formula uses bit-shift arithmetic with overflow protection (the shift count is capped at 63):

Remaining emission supply is tracked at runtime. When cumulative emissions (mining, staking, and attestation combined) approach the 500M emission budget, block rewards are reduced to the remaining balance (L-10 fix). This prevents over-emission from rounding errors in the halving arithmetic and guarantees the 700M total-supply cap holds.

4.2Staking Rewards

Staking rewards are distributed every 900 blocks (~1 hour) at a fixed 7% annual rate. Only accounts with a minimum of 100 XRS staked are eligible. Rewards accrue to the liquid balance — they are not auto-compounded, requiring explicit re-staking to compound.

Unstaking enters a 151,200-slot unbonding period (~7 days). The unbonding queue is capped at 10,000 entries globally and 10 pending entries per account (M-8 fix) to prevent denial-of-service via queue exhaustion. During unbonding, tokens do not earn staking rewards and do not count toward leader election weight — but they remain slashable for the full unbonding period (see §4.3).

Light client attestation provides an additional reward of 0.01 XRS per valid proof, claimable within a 200-slot window (~13 minutes) after block creation. Attestors must hold at least 100 XRS staked, are rate-limited to one reward per 10 blocks, and attestations are deduplicated by (block_slot, validator_pubkey) to prevent double-claiming. These rewards also count against the 500M emission budget (L-10).

4.3Slashing

Proposer equivocation — signing two distinct block headers for the same slot — is punishable by slashing. Anyone may submit evidence via theSlashReport instruction: two canonically-signed, provably different headers at the same violation slot. The runtime re-verifies both signatures under the scheme active at that slot (hybrid Ed25519 + Dilithium3 post-activation), and the inline Dilithium key must match the offender's on-chain PQ registry entry (XWC-53 fix), so evidence can never be forged from headers that block admission would itself have rejected.

Active stake is consumed first, then unbonding entries oldest-first. Each unique offense slashes at most once regardless of how the evidence is encoded or relabeled (XWC-30 fix), and zero-value or self-referential reports are rejected.

5Smart Contract System

XerisCoin defines 23 typed contract primitives (22 of them user-deployable) via the ContractDeploy instruction and invoked via ContractCall. Contracts are not arbitrary bytecode — they are parameterized instances of protocol-defined types. This eliminates an entire class of smart contract vulnerabilities (reentrancy, unchecked delegatecall, storage collisions) by construction.

5.1DeFi Primitives

Swap (AMM). Constant-product automated market maker with LP share tracking. Pools enforce a minimum liquidity lock on initialization (C-5 fix, following the Uniswap V2 pattern) to prevent manipulation of the initial price ratio via dust deposits. Pools with identical input and output tokens are rejected at creation, and all validation runs before any balance is debited (XWC-67 fix).

Launchpad. Fair-launch bonding curve for new token creation. The creator receives a fixed 1% reward (100 bps) and the protocol collects 0.77% (77 bps) on both buys and sells. Buy and sell prices derive from a single constant-product invariant over virtual reserves, so the two paths cannot be arbitraged against each other (XWC-68 fix). When the bonding curve reaches its target liquidity threshold, the contract finalizes by deploying a Swap pool seeded with the accumulated XRS and the unsold curve inventory, with explicit supply accounting. Launchpad lifecycle methods are callable only through the direct top-level path — indirect invocation via delegated agents or conditional orders is rejected (XWC-07 fix). Vesting controls — cliff periods, daily unlock percentages, and maximum-sell restrictions, all computed in milliseconds (XWC-70 fix) — are embedded in the launch parameters to prevent immediate dumping.

LimitOrder / DcaOrder. Standing orders that escrow the input token and execute when a keeper confirms the target rate has been reached. Limit orders support a configurable keeper fee (default 10 bps). DCA orders extend this with interval-based execution — each tick is independently keeper-executed, supporting strategies like daily accumulation over configurable time horizons.

ConditionalOrderBook. Standing orders evaluated every block against configurable condition sources (oracle feed, price threshold, time condition). Price triggers read a rolling windowed median of per-block price observations rather than the instantaneous reserve ratio, resisting single-block price manipulation (XWC-63 fix). Triggered and expired orders execute in a canonical deterministic order across all nodes (XWC-62 fix), escrow settlement is atomic — an order is never marked executed unless fully fundable (XWC-08 fix) — and orders auto-expire after a specified slot, refunding the escrowed balance on cancellation.

5.2Alexandria Protocol (Real-World Assets)

The Alexandria Protocol implements Ricardian smart contracts — on-chain tokens bound to off-chain legal documents via cryptographic hash commitment. Each RWA token stores:

Transfers of RWA tokens are restricted to addresses on the compliance whitelist, enforced at the runtime level — not by convention. The jurisdiction field enables downstream tooling to apply locale-specific regulatory logic without modifying the base protocol. Distribution history is maintained on-chain for auditable provenance tracking.

6XERIS ARI Protocol

The Autonomous Runtime Infrastructure (ARI) protocol provides first-class on-chain support for AI agent operation. Rather than treating agents as opaque externally-owned accounts, ARI creates a protocol-enforced delegation hierarchy with spending controls, operation whitelists, and kill switches.

AgentRegistry. An owner registers an agent via RegisterAgent, specifying per-transaction spend limits, daily spending caps (measured in 21,600-slot windows, i.e. 24 hours), a whitelist of contracts the agent may interact with, and a whitelist of instruction types the agent may execute. The owner retains a unilateral kill switch that immediately revokes all delegated authority. Lifetime metrics (total transactions, total spent) are tracked on-chain.

IdentityRegistry. Persistent identity for agents and devices with categorical reputation scoring. Identities support credential attachments, hierarchical parent-child relationships (an organization identity can parent individual agent identities), and a verified transaction history. Reputation is per-category — a trading agent's reputation in "liquidity provision" is tracked independently from its reputation in "data accuracy."

SubDelegate. Agents may further delegate authority to sub-agents, subject to maximum depth constraints and per-tier spending reductions. A trading agent with a 50 XRS/tx limit can delegate to a sub-agent at depth 2 with a 10 XRS/tx limit. The depth limit prevents unbounded delegation chains that could obscure accountability.

CapabilityRegistry. An on-chain marketplace for agent service discovery. Agents advertise capabilities by category (trading, liquidity, data_feed, computation), price per unit, concurrent capacity, and region/SLA metadata. Reputation snapshots are cached for efficient sorting. This enables a composable ecosystem where agents can discover and transact with each other's services programmatically.

TaskBoard. On-chain bounty system where task posters escrow rewards and completion is confirmed by the poster, designated verifiers, or oracle-verified conditions. Tasks carry category tags, skill requirements, and minimum reputation thresholds that gate who may claim them. Task expiry checks are evaluated in consensus order, deterministically across nodes (XWC-62 sweep).

Heartbeats & Devices. An agent liveness registry (AgentHeartbeat) tracks operational status on-chain, and a hardware attestation registry records attested devices. The device registry is protocol-managed: it cannot be reached through generic contract calls or deployed by users (XWC-65 fix).

7Cryptographic Primitives

XerisCoin employs a layered cryptographic stack designed for current security requirements and forward compatibility with post-quantum threat models.

Hybrid block signatures. Every block header at or after slot 1 carries both an Ed25519 signature and a Dilithium3 (ML-DSA-65, NIST security level 3) signature over a single canonical, domain-separated, chain-id-bound message; a block is valid only if bothverify. This is a permanent hybrid design rather than a transition: forging a block requires breaking Ed25519 and the lattice assumption simultaneously, and there is no classical-only fallback for an adversary to downgrade to.

ZkVerifierRegistry. Stores Groth16 verification keys on the BN254 curve (the same pairing-friendly curve used by Ethereum's precompiles and zkSync). Proof submissions include metadata and nullifiers — the nullifier set prevents double-spending in privacy-preserving protocols without revealing the transaction graph. Proof size is tracked for fee estimation. Verification is strictly bounded: proofs are capped at 512 bytes, verification keys at 16 KB, public inputs at 64 per proof, encodings must consume their input exactly (non-malleable, XWC-16 fix), and each block may contain at most 64 Groth16 verifications — enforced identically by consensus validation and the block producer (XWC-15 fix) — bounding worst-case pairing work per 4-second slot. Self-asserted PQ attestation markers are stored in a separate namespace from cryptographically verified proofs (XWC-64 fix). The Schnorr/Pedersen confidential-transfer primitives remain implemented in the node as reserve code, disabled at the dispatcher pending a hardened re-enablement.

PqKeyRegistry. Maps Ed25519 public keys to post-quantum Dilithium3 keys with exact key-length validation (1,952-byte public keys, XWC-14 fix). Key rotation is tracked with a rotation counter and last-rotation slot, and changing a registered key requires a rotation message signed by the current Dilithium key, bound to the chain id and a monotonic nonce — an Ed25519-only compromise cannot swap out a victim's PQ key (XWC-06 fix). From slot 2 (PQ_REGISTRY_BINDING_ACTIVATION_SLOT), block admission requires the header's inline Dilithium key to match the proposer's registry entry — enforced on every path including slash evidence (XWC-53 fix) and rebuilt fork-locally during reorgs (XWC-66 fix). Network-wide PQ adoption statistics are maintained on-chain.

8Network Architecture

Nodes communicate over a custom TCP protocol identified by the magic bytes XRS1. The maximum message size is 5 MB, accommodating full blocks at peak transaction capacity. The network supports up to 3,000 peer connections per node, with subnet-based eclipse attack protection limiting connections to 8 peers per /24 subnet.

Snapshot-based sync. The ledger produces automatic checkpoints every 10,000 blocks, serializing the full balance set, staking state, and unbonding queue. New nodes can start from the most recent snapshot rather than replaying from genesis, reducing sync time proportionally to the chain's age.

Fork choice & reorgs. Competing forks are resolved by replaying each fork's own transaction history: fork weight is derived from the fork's replayed stake distribution rather than the canonical chain's (XWC-04 fix), and the post-quantum key registry is likewise rebuilt fork-locally during reorg evaluation (XWC-66 fix), so a fork cannot borrow authority from state it does not itself contain.

State channels. The StateChannelRegistry contract enables off-chain high-frequency interactions with on-chain settlement. Parties deposit into a channel, exchange signed messages off-chain, and settle the final state on-chain. A configurable challenge period (default 1,000 slots) allows either party to dispute a submitted settlement with a more recent signed state.

9Protocol Upgrades & Governance

Slot-activated upgrades. XerisCoin avoids hard forks by gating new consensus rules on slot numbers. When a protocol upgrade is finalized, the activation slot is embedded in the node binary. Blocks before the activation slot continue to validate under the original rules, preserving ledger integrity without requiring coordinated restarts. On the current network, examples include hybrid post-quantum signatures (slot 1), PQ registry binding (slot 2), and the v2 PoW preimage.

On-chain governance. The Governance contract supports proposal creation, stake-weighted voting, and on-chain tallying. Voting periods are configurable with a protocol-enforced minimum of 21,600 slots (~24 hours), and passage requires both a quorum and a majority of cast stake weight. Each staker may vote once per proposal, weighted by their active stake at vote time. A passed proposal's outcome is recorded on-chain; parameter enactment ships through the slot-activated upgrade mechanism above. Vote delegation is planned but not yet active.

DisputeRegistry. For subjective decisions that cannot be resolved by code alone, the protocol provides an on-chain arbitration mechanism. Disputing parties post bonds, submit evidence, and a ruling is issued by authorized validators. Bond refunds are idempotent — a resolution can never double-credit a party (XWC-69 fix).

AAppendix

A.1 — Glossary

A.2 — Protocol Constants