Skip to main content
This page is for developers and researchers who want to understand the cryptographic and technical foundations of NEXUS. If you just want to build, check out the Quick Start instead.

​
Security Model Overview

NEXUS uses different verification mechanisms optimized for each chain:
ChainProof SystemVerificationFinality
BitcoinZK-STARKBitVM2 fraud proofs~7 days (challenge period)
ZcashGroth16Native on-chain~30 min (instant after proof)
DogecoinZK-STARKFraud proofs~24 hours (challenge period)

​
Key Terms

BitVM is a fraud proof system for Bitcoin that enables optimistic verification of arbitrary computations. NEXUS uses BitVM2 for Bitcoin verification:
  • How it works: Prover posts a bond + state commitment. Anyone can challenge if they believe the state is invalid.
  • Bisection game: A binary search protocol that narrows down to a single disputed computation step (~20 rounds for 1M steps).
  • On-chain verification: The disputed step is verified using Bitcoin Script that emulates RISC-V operations.
  • Security: Economic (prover loses bond if wrong) + permissionless (anyone can challenge).
  • Timeline: 144 blocks challenge period, 72 blocks per bisection round.
Prover commits state → Challenge window opens
       ↓
Challenger disputes → Bisection game begins
       ↓
~20 rounds of bisection → Single step identified
       ↓
Bitcoin Script verifies step → Loser loses bond
Groth16 is a zero-knowledge proof system used by Zcash. NEXUS leverages Zcash’s native Groth16 verification:
  • Trusted setup: Uses Zcash’s Sapling MPC ceremony (largest trusted setup in crypto history with 90+ participants).
  • Native verification: Zcash L1 can verify Groth16 proofs directly on-chain - no fraud proofs needed.
  • Proof size: ~200 bytes, constant regardless of computation size.
  • Verification time: ~10ms on-chain verification.
  • Why Zcash: Only UTXO chain with native ZK proof verification capability.
NEXUS executes contracts → Generates Groth16 proof
       ↓
Proof submitted to Zcash L1
       ↓
Zcash nodes verify proof natively
       ↓
Invalid proofs rejected by consensus (instant finality)
ZK-STARK (Zero-Knowledge Scalable Transparent ARgument of Knowledge) proofs used for Bitcoin and Dogecoin:
  • No trusted setup: Unlike Groth16, STARKs don’t require a trusted ceremony.
  • Post-quantum secure: Resistant to quantum computer attacks.
  • Larger proofs: ~50-100KB vs Groth16’s 200 bytes.
  • Used with fraud proofs: Since Bitcoin/Doge can’t verify STARKs natively, we use optimistic verification with BitVM.
  • Prover time: Seconds to minutes depending on computation complexity.
NEXUS is a metaprotocol, not an L2:
AspectL2 (Rollup)Metaprotocol (NEXUS)
ConsensusSeparate chainUses L1 consensus
SequencerCentralized riskNo sequencer
DataPosted to L1Lives on L1
StateSeparate stateInterprets L1 state
  • Key insight: NEXUS interprets L1 transactions with additional semantics. Your vault transaction on Bitcoin IS your NEXUS state.
  • No separate chain: No new consensus mechanism, no sequencer centralization risk.
Every vault is a 2-of-2 multisig with escape hatch:
Vault Script:
├── Normal Path: User + Protocol signatures
│   └── Instant withdrawal when both agree
│
└── Escape Path: User signature + Timelock
    └── User can exit unilaterally after 2 weeks
Pre-signed exit transactions: At vault creation, user receives a pre-signed transaction that lets them withdraw after the timelock. This transaction is valid even if NEXUS goes offline.Timelock periods:
  • Bitcoin: 2016 blocks (~2 weeks)
  • Zcash: 576 blocks (~1 day)
  • Dogecoin: 1440 blocks (~1 day)

​
Proof Systems Deep Dive

​
Bitcoin: BitVM2 Fraud Proofs

NEXUS on Bitcoin uses optimistic verification with BitVM2: 
┌─────────────────────────────────────────────────────────────────┐
│                    BitVM2 Verification Flow                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. Prover executes NEXUS state transition                      │
│                    ↓                                             │
│  2. Prover posts bond (e.g., 1 BTC) + state commitment          │
│                    ↓                                             │
│  3. Challenge window opens (144 blocks)                         │
│                    ↓                                             │
│  4a. No challenge → State finalized, bond returned              │
│                                                                  │
│  4b. Challenge received:                                        │
│      ├── Challenger posts counter-bond                          │
│      ├── Bisection game (~20 rounds)                            │
│      ├── Single disputed step identified                        │
│      ├── Bitcoin Script verifies step                           │
│      └── Loser's bond goes to winner                            │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
Bisection Protocol:
  1. Prover claims execution trace of N steps
  2. Challenger disputes
  3. Each round: “Is the midpoint correct?”
  4. After log₂(N) rounds, single step identified
  5. That step verified on-chain via Bitcoin Script

​
Zcash: Native Groth16

NEXUS on Zcash achieves true trustless verification: 
┌─────────────────────────────────────────────────────────────────┐
│                    Groth16 Verification Flow                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. NEXUS executes WASM contracts                               │
│                    ↓                                             │
│  2. Generates Groth16 proof of correct execution                │
│     - Uses Zcash's Sapling parameters (BLS12-381 curve)         │
│     - Proof size: ~192 bytes                                    │
│                    ↓                                             │
│  3. Submits proof in Zcash transaction                          │
│     - Embedded in OP_RETURN or custom field                     │
│                    ↓                                             │
│  4. Zcash nodes verify proof on-chain                           │
│     - Native BLS12-381 pairing check                            │
│     - ~10ms verification time                                   │
│                    ↓                                             │
│  5. Invalid proofs rejected by Zcash consensus                  │
│     - No challenge period needed                                │
│     - Instant finality after confirmation                       │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
Why this matters: On Zcash, invalid states are mathematically impossible. The chain itself rejects invalid proofs - no economic games, no challenge periods.

​
Dogecoin: Optimistic with Fast Finality

Similar to Bitcoin but with faster parameters:
  • Challenge period: 1440 blocks (~24 hours vs Bitcoin’s ~7 days)
  • Bond requirements: 1000 DOGE
  • Faster block times mean quicker finality

​
EIP-1559 Fee Market

NEXUS implements Ethereum’s EIP-1559 fee mechanism: 
Base Fee Adjustment:
├── Block > 40% full → base_fee increases (up to 12.5%)
├── Block < 40% full → base_fee decreases (up to 12.5%)
└── Block = 40% full → base_fee unchanged

Transaction Fee = gas_used × (base_fee + priority_fee)
Fee tiers:
TierPriority FeeExpected Wait
Slow0.5× avg~6 blocks
Standard1× avg~2 blocks
Fast2× avg~1 block
Instant5× avgNext block

​
State Commitments

NEXUS posts state roots to L1 periodically: 
Bitcoin Block 800000: NEXUS State Root 0xabc123...
Bitcoin Block 800100: NEXUS State Root 0xdef456...
Bitcoin Block 800200: NEXUS State Root 0x789abc...
Commitment format (OP_RETURN): 
NXUS (4 bytes) - Magic bytes
Version (1 byte)
prev_state_root (32 bytes)
new_state_root (32 bytes)
block_height (8 bytes)
tx_count (4 bytes)
proof_data (variable)

​
WASM VM Architecture

┌─────────────────────────────────────────────────────────────────┐
│                      NEXUS WASM VM                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                   Host Functions                         │    │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐        │    │
│  │  │ Storage │ │ Crypto  │ │ Events  │ │  XCC    │        │    │
│  │  │ get/set │ │ hash    │ │  emit   │ │  call   │        │    │
│  │  └─────────┘ └─────────┘ └─────────┘ └─────────┘        │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                   Gas Metering                           │    │
│  │  - Instruction counting                                  │    │
│  │  - Memory allocation costs                               │    │
│  │  - Storage read/write costs                              │    │
│  │  - Cross-contract call costs                             │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                   Determinism                            │    │
│  │  - No floating point                                     │    │
│  │  - No randomness                                         │    │
│  │  - No external calls                                     │    │
│  │  - Bounded execution                                     │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

​
Cross-Contract Calls (XCC)

// Direct call
let result = xcc::call(target_contract, "method", &args, gas_limit);

// Delegate call (execute in caller's context)
let result = xcc::delegate_call(target_contract, "method", &args, gas_limit);

// Deploy from template
let new_contract = xcc::deploy_template("amm_pair", &init_args, &salt);
Gas forwarding: 63/64 of remaining gas forwarded to callee (EIP-150 style).

​
Node Architecture

┌─────────────────────────────────────────────────────────────────┐
│                       NEXUS Node                                 │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │    RPC      │  │   Gateway   │  │   Sync      │              │
│  │   Server    │  │   (REST)    │  │   Service   │              │
│  └─────────────┘  └─────────────┘  └─────────────┘              │
│                                                                  │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │   WASM      │  │   Vault     │  │  Watchtower │              │
│  │   VM        │  │   Manager   │  │             │              │
│  └─────────────┘  └─────────────┘  └─────────────┘              │
│                                                                  │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │   Bitcoin   │  │   Zcash     │  │  Dogecoin   │              │
│  │   Scanner   │  │   Scanner   │  │  Scanner    │              │
│  └─────────────┘  └─────────────┘  └─────────────┘              │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                      Storage (RocksDB)                    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
Node modes:
  • Primary: Produces blocks, commits state to L1
  • Replica: Syncs from primary, serves read queries
  • Archive: Full history, no pruning

​
Hardware Requirements

ComponentMinimumRecommended
CPU2 cores4+ cores
RAM4 GB8+ GB
Storage50 GB SSD200+ GB NVMe
Network10 Mbps100+ Mbps
Zcash advantage: No heavy proof generation hardware needed. Zcash L1 handles verification natively. Estimated throughput:
  • t3.medium (2 vCPU): ~100-300 TPS
  • t3.xlarge (4 vCPU): ~500-800 TPS
  • c6i.xlarge (compute): ~1000+ TPS

​
Further Reading

Architecture

Full system architecture diagrams

Comparisons

How NEXUS compares to other protocols

Security Analysis

Formal security analysis and audits

BitVM Paper

Original BitVM whitepaper