Every block is proved three ways and final in four seconds.

Xeris is a Layer 1 built in Rust. Proof-of-History sets the order, Scrypt Proof-of-Work produces the block and stake-weighted election picks the leader, all pipelined into one four-second slot. Post-quantum signatures start at the first block.

Slot finality
4s
TPS on testnet
10,000+
Consensus proofs
3
CertiK score
88AA
§ 01

Why it exists

We refused the compromise that other Layer 1s take for granted.

Today’s Layer 1s fall into two camps. Neither meets our two requirements: native orchestration of autonomous AI agents, and regulated tokenization of real-world assets with enforceable legal bindings.

Camp one

Speed comes at the cost of decentralization

High-throughput chains gain speed by narrowing the set of machines allowed to produce blocks, and the validator list ends up short.

Camp two

Security is proven and the chain is hard to build on

Proof-of-work chains have defended their ledgers for over a decade, and building a modern application on one means working around the chain.

BlockProof-of-Historyorders the slotProof-of-Workproduces the blockProof-of-Stakeelects the leader

Forging a block means defeating all three inside one slot.

The three proofs and the block they converge on

The Xeris position

Xeris layers three consensus mechanisms. Proof-of-History fixes local ordering without an external clock. Scrypt Proof-of-Work keeps block production memory-hard and mineable on commodity hardware. Stake-weighted election decides who leads each slot. To forge a block, an attacker has to defeat all three in the same four-second slot.

§ 02

Consensus architecture

Every four-second slot runs the same three-stage pipeline.

Each stage constrains the next, and the whole sequence has to complete inside the slot window or the slot is forfeit.

Consensus pipeline4-second slot window0s1s2s3s4sProof-of-HistorySHA-256 · nanosecond entropy4.0sLeader electionStake-weighted · ≥ 1,000 XRS~0.4sScrypt miningN=4,096 · r=4 · 2 MB/hash3.9s maxBlock finalityEd25519 + Dilithium3~0.4s
The 4-second slot window, stage by stage
  1. Proof-of-History

    Each hash input is the previous output plus nanosecond entropy from the validator’s monotonic clock. Slot boundaries come from the hash chain itself. No external clock or BFT round is needed to agree on the time.

  2. Leader election

    The eligible set is every validator with at least 1,000 XRS staked, sorted by public key so every node derives the same order. A weighted draw seeded from the previous block’s hash picks the leader. Producing that hash took work, so the leader cannot be predicted before that block is mined.

  3. Scrypt mining

    Block production is a memory-hard Scrypt puzzle. If mining runs past the 3.9-second ceiling, the slot is forfeit. Non-leaders may mine the same slot at 4× difficulty: the chain stays live if a leader stalls, and they cannot outrun the elected leader.

  4. Block finality

    The header commits to its transactions by Merkle root and carries two signatures: classical Ed25519 and post-quantum Dilithium3. Both must verify, so an adversary has no classical-only path to downgrade to.

Non-leader validators mine at 4× the difficulty target. Forward slot leaps are bounded by elapsed Proof-of-History time plus a two-slot skew tolerance, so a proposer cannot time-warp slot-gated logic such as unbonding.

§ 03

Protocol datasheet

These are the numbers the node enforces at runtime.

Each figure here is specified in the technical whitepaper. A block that violates any of them is rejected.

Consensus

Slot time4s
Finality1slot
Proof-of-WorkScryptN=4,096 r=4 p=1
Mining timeout3.9s
Validator minimum1,000XRS
Non-leader penalty4× difficulty

Throughput

Testnet throughput10,000+TPS
Transactions per block40,000max
Instructions per tx16max
Mempool depth100,000pending
Base fee0.001XRS
Blockhash validity150slots

Cryptography

Block signatureHybridEd25519·Dilithium3
PQ standardML-DSA-65FIPS 204
Hybrid mandatory fromSlot 1genesis
Zero-knowledgeGroth16BN254
ZK proofs per block64max
Instruction variants54typed

Supply & network

Hard cap700MXRS
Block reward10XRS
Halving interval25Mblocks
Staking rate7% / year
Unbonding period7days
Peers per node3,000max
§ 04

Native protocols

These protocols are built into the runtime as typed instructions.

Contracts on Xeris are 23 typed, protocol-defined primitives. The runtime executes no arbitrary bytecode, which rules out reentrancy, unchecked delegatecall and storage collisions. The protocols below are instruction variants in the same runtime that moves tokens, under the same fee accounting and replay protection.

  1. Alexandria

    Real-world assets · Ricardian contracts

    Each RWA token is bound to its off-chain legal document by cryptographic hash commitment, with compliance whitelists and jurisdiction tracking enforced on transfer.

  2. ARI

    Autonomous agents · Hierarchical delegation

    AI agents are registered as protocol objects with a per-transaction spend limit, a daily cap, a contract whitelist and a kill switch. An agent can sub-delegate within those bounds and cannot widen them.

  3. Zero-knowledge

    Cryptography · Groth16 · BN254

    Prove a statement and settle without revealing the data behind it. Verification is bounded: proofs are capped at 512 bytes, verifications at 64 per block, and encodings must consume their input exactly.

  4. Post-quantum

    Signatures · Ed25519 + Dilithium3

    Hybrid block signing is mandatory from slot 1 and permanent. The on-chain key registry binds each proposer to its lattice key, and rotation requires a signature from the current post-quantum key.

  5. Native DeFi

    Markets · AMM · bonding curves

    Constant-product pools, a bonding-curve launchpad, limit and DCA orders and a staked oracle registry are all protocol primitives.

  6. Governance

    Upgrades · Slot-activated

    Stake-weighted proposals tally on-chain over a minimum 24-hour voting window, and new consensus rules activate at a fixed slot number, with no hard fork or coordinated restart.

§ 05

Independently verified

CertiK audited the protocol and we closed every finding it raised.

All 70 findings, XWC‑01 through XWC‑70, are remediated in the current revision, and each fix is cited inline in the whitepaper.

CertiK Skynet score
88AA
Audit findings closed
70/ 70
Protocol revision
v1.5

Patent pending·US #63/887,511

Verify on CertiK Skynet (opens in a new tab)
§ 06

The token

Fees and staking run on XRS, and the runtime caps how much of it can exist.

XRS pays fees, secures the network through staking and rewards the validators that produce blocks. The runtime caps supply: mining, staking and attestation rewards draw from one fixed budget.

0M200M400M600MH1H2H3H4700M hard cap200M treasury0M25M50M75M100MBlock height
Cumulative supply against block height

Hard cap

700,000,000

Emission budget
500,000,000

Mining + staking + attestation · 71.4%

Treasury
200,000,000

Genesis allocation · 28.6%

Emission

10 XRS per block, halving every 25,000,000 blocks (about every 3.17 years at four seconds a slot). The series sums to exactly the 500M budget.

Staking

7% annually, distributed every 900 blocks to anyone staking 100 XRS or more. Rewards are liquid and restaking is manual.

Slashing

Signing two headers for one slot costs 10% of slashable balance. The reporter takes 5% of it as bounty. The remaining 95% burns.

XRS on Solana is the pre-mainnet token. At mainnet it swaps in at a fixed 5:1 for native XRS.

XRS on Solana—Native, implied—Live tracker

Solana contract

9ezFthWrDUpSSeMdpLW6SDD9TJigHdc4AuQ5QN5bpump

Read the specification that every number on this page comes from.

The whitepaper specifies the consensus pipeline, instruction set, contract taxonomy, cryptographic stack and governance model, with the audit remediations cited in place.