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 subsec_nanos() 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 system clock at nanosecond resolution.

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 protocol has evolved Scrypt parameters across three epochs:

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.

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 and a block proposed within the last 100 slots (the activity window). Eligible validators are sorted by public key for cross-node consensus, then a weighted random selection using the previous block's hash as entropy 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.

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.

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. The mempool holds a maximum of 100,000 pending transactions with O(1) signature deduplication via HashSet (LOW-2 fix, replacing an earlier O(n) scan).

3.1Instruction Set

XerisCoin defines a typed instruction set via the XerisInstruction enum. Each variant maps to a specific operation processed by the runtime. Legacy Solana-compatibleSystemInstruction::Transfer was sunset at slot 1,052,200 in favor of the native NativeTransfer variant with explicit signer enforcement.

3.2Fee Model & Replay Protection

Transaction fees activate at slot 1,030,000. 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 emission cap of 700,000,000 tokens. The supply is partitioned between a treasury pre-allocation and mining emissions, with staking rewards and attestation rewards counted against the same cap.

4.1Emission Schedule

The base block reward is 342.5 XRS, halving every 730,000 blocks. At 4 seconds per slot, each halving epoch spans approximately 34 days. The halving formula uses bit-shift arithmetic with overflow protection:

Remaining emission supply is tracked at runtime. When the cumulative mined supply approaches the 500M emission cap, block rewards are reduced to the remaining balance (L-10 fix). This prevents over-emission from rounding errors in the halving arithmetic.

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 (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.

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. Attestations are deduplicated by (block_slot, validator_pubkey) to prevent double-claiming. These rewards also count against the 700M emission cap (L-10).

5Smart Contract System

XerisCoin defines 25 typed contract primitives deployed 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.

Launchpad. Fair-launch bonding curve for new token creation. The creator receives a fixed 1% reward (100 bps) and the protocol collects 0.777% (77 bps). When the bonding curve reaches its target liquidity threshold, the contract automatically finalizes by deploying a Swap pool with the accumulated liquidity. Vesting controls — including cliff periods, daily unlock percentages, and sell restrictions — 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). Orders auto-expire after a specified slot and refund 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, claimants stake reputation, and verifiers (or oracle-verified conditions) confirm completion. Tasks carry category tags, skill requirements, and minimum reputation thresholds. Escrowed rewards count against the emission cap.

7Cryptographic Primitives

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

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.

PqKeyRegistry. Maps Ed25519 public keys to post-quantum CRYSTALS-Dilithium keys at the 128-bit security level. Key rotation is tracked with a rotation counter and last-rotation slot. Network-wide PQ adoption statistics are maintained to monitor migration progress. This registry enables a gradual migration path: users who register PQ keys can optionally provide dual signatures (Ed25519 + Dilithium) during the transition period, with the protocol enforcing PQ-only signatures after a governance-specified activation slot.

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.

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. Examples include fee activation (slot 1,030,000), legacy transfer sunset (slot 1,052,200), and Scrypt v1.2 (slot 1,052,478).

On-chain governance. The Governance contract supports proposal creation, token-weighted voting, and on-chain execution. Proposals require a minimum stake to submit, configurable voting periods, and quorum thresholds. Vote delegation is supported — a staker can delegate their voting weight to another address without transferring tokens. Governance locks track the locked amount per address to prevent double-voting.

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 designated arbitrators or governance vote). Bonds are redistributed based on the ruling outcome.

AAppendix

A.1 — Glossary

A.2 — Protocol Constants