This document provides a comprehensive overview of Rivellum's technical architecture, covering the intent-based model, Aurora Fabric sharding, Photon consensus, PoUW, and the Move VM integration.

System Layers

Rivellum's architecture is organized into distinct layers, each with specific responsibilities:

1. Application Layer

• User Intents: High-level expressions of desired outcomes
• dApps & SDKs: Application interfaces for intent submission
• Solvers: Off-chain agents that optimize intent execution

2. Intent Processing Layer

• Intent Mempool: FCFS (First-Come-First-Served) queue for pending intents
• Batching: Groups intents for efficient execution
• Intent Validation: Signature verification, nonce checking, balance validation

3. Execution Layer (Aurora Fabric)

• Multi-Shard Parallelism: Multiple execution shards process transactions concurrently
• Move VM: Resource-oriented smart contract execution per shard
• Cross-Shard Communication: Atomic operations across shard boundaries
• State Management: Merkle trees and deterministic state transitions

4. Consensus Layer (Photon)

• Committee-Based BFT: Fast finality through rotating validator committees
• Leader Election: Deterministic leader selection based on stake/reputation
• Block Proposal & Voting: Two-phase commit protocol
• Finality Guarantees: Byzantine fault tolerance up to 1/3 malicious nodes

5. Proof Layer (PoUW)

• ZK Proof Generation: Provers generate validity proofs for batches
• Proof Marketplace: Dynamic job allocation based on prover reputation
• Verification: On-chain proof validation
• Rewards: Economic incentives for proof generation

6. Storage Layer

• State Database: Persistent key-value store with Merkle trees
• Ledger: Append-only log of all finalized batches
• Audit Trail: Tamper-proof history for compliance and forensics

Intent-Based Architecture

What are Intents?

An intent is a user's declaration of a desired outcome rather than specific execution steps. For example:

Traditional Transaction:

// User must know exact steps
1. Approve token A
2. Call swap function with specific parameters
3. Handle slippage manually

Intent-Based:

{
  type: "swap",
  from: "tokenA",
  to: "tokenB", 
  amount: "100",
  minReceived: "95", // Solver handles optimal routing
}

Intent Lifecycle

User → Intent → Mempool → Batch → Execute → Prove → Finalize
  ↓                           ↓        ↓       ↓        ↓
Sign                       Order   MoveVM   PoUW   Consensus

1. Submission: User signs and submits intent to any node
2. Propagation: Intent propagates through P2P network
3. Queueing: Leader node adds to FCFS mempool
4. Batching: Periodic batch formation (size or time-based)
5. Execution: Move VM processes batch on assigned shard(s)
6. Proving: PoUW generates ZK proof of correct execution
7. Consensus: Photon committee votes on batch + proof
8. Finality: Batch committed to ledger, state updated

Intent Structure

pub struct Intent {
    pub intent_id: IntentId,
    pub from: Address,
    pub nonce: u64,
    pub payload: PayloadKind, // Plain or Encrypted
    pub signature: Signature,
    pub max_fee: u64,
}

pub enum PayloadKind {
    Plain(Vec<u8>),
    Encrypted(EncryptedPayload),
}

Aurora Fabric: Multi-Shard Architecture

Aurora Fabric enables horizontal scalability through parallel shard execution while maintaining consistency.

Shard Design

• Fixed Shard Count: Currently N shards (configurable)
• Per-Shard Move VM: Each shard runs independent Move VM instance
• Shared State Root: All shards contribute to unified Merkle root
• Cross-Shard Atomicity: Coordinator ensures atomic multi-shard operations

Shard Assignment

Accounts are deterministically assigned to shards:

shard_id = hash(address) % num_shards

This ensures:

• Locality: Account operations usually stay within one shard
• Load Balancing: Uniform distribution across shards
• Predictability: Same account always maps to same shard

Cross-Shard Communication

When an intent spans multiple shards:

1. Coordinator identifies all involved shards
2. Prepare Phase: Each shard validates and locks resources
3. Commit Phase: All shards apply changes atomically
4. Abort on Failure: Rollback if any shard fails

Intent: Transfer from Shard A to Shard B

┌─────────┐         ┌────────────┐         ┌─────────┐
│ Shard A │────────→│ Coordinator│────────→│ Shard B │
└─────────┘         └────────────┘         └─────────┘
   Lock                  2PC                   Lock
   Debit              protocol                Credit

Photon Consensus

Photon combines BFT consensus with PoUW for fast finality and security.

Committee Structure

• Rotating Committees: Validators rotate every N blocks
• Committee Size: Configurable (e.g., 100 validators)
• Selection Criteria: Stake, reputation, and randomness
• Leader Election: Deterministic based on block height + VRF

Consensus Flow

1. Leader proposes batch + PoUW proof
2. Committee members validate:
   - Intent signatures
   - Nonce consistency  
   - Execution correctness
   - PoUW proof validity
3. Members vote (approve/reject)
4. 2/3+ approval → Finality
5. State root updated, batch committed

Finality Guarantees

• Instant Finality: Blocks are final once committee approves (no reorgs)
• Byzantine Tolerance: Withstands up to 1/3 malicious committee members
• Liveness: Progress guaranteed with >2/3 honest validators online

Proof of Useful Work (PoUW)

PoUW replaces traditional mining with useful computational work: generating zero-knowledge proofs.

How PoUW Works

1. Job Creation: Each batch needs a validity proof
2. Job Market: Provers bid on jobs based on:
   • Batch complexity
   • Proof deadline
   • Their reputation score
3. Proof Generation: Selected prover generates ZK proof off-chain
4. Submission: Prover submits proof to leader
5. Verification: Consensus validates proof on-chain
6. Rewards: Prover receives tokens from fee pool

Reputation System

Provers build reputation through:

• Success Rate: % of valid proofs submitted
• Timeliness: Meeting proof deadlines
• Uptime: Availability for job selection

Poor reputation → fewer job assignments → lower rewards

Economic Model

Batch Fee Pool
     ↓
├─→ 40% Burned (deflationary)
├─→ 30% PoUW Rewards (provers)
├─→ 20% Treasury (development)
└─→ 10% Validators (consensus)

Move VM Integration

Rivellum uses the Move programming language for smart contracts.

Why Move?

• Resource Safety: Linear types prevent double-spending bugs
• Formal Verification: Mathematical correctness proofs
• Gas Efficiency: Optimized bytecode execution
• Composability: Module system enables code reuse

Native Modules

Rivellum provides built-in Move modules:

• 0x1::Coin: Native token operations
• 0x1::Account: Account management
• 0x1::Intent: Intent execution helpers
• 0x1::Shard: Cross-shard communication primitives

Contract Deployment

module 0xMyAddress::Counter {
    struct Counter has key {
        value: u64
    }
    
    public entry fun increment(account: &signer) acquires Counter {
        let counter = borrow_global_mut<Counter>(signer::address_of(account));
        counter.value = counter.value + 1;
    }
}

State Management

Merkle Trees

• Per-Shard Trees: Each shard maintains its own Merkle tree
• Unified Root: Combined root from all shard roots
• Efficient Proofs: Light clients can verify with minimal data

State Transitions

State(N) + Batch(N+1) → State(N+1)

Deterministic: Same batch always produces same state
Verifiable: ZK proof confirms correct execution

Privacy Layer

Rivellum supports optional privacy through encrypted intent payloads.

Encrypted Intents

pub struct EncryptedPayload {
    pub ciphertext: Vec<u8>,
    pub ephemeral_key: PublicKey,
    pub tag: AuthTag,
}

• Committee Decryption: Photon committee collectively decrypts
• Threshold Cryptography: Requires majority to decrypt
• Execution Privacy: Only committee sees intent details

Status: Privacy is currently a prototype feature and not production-ready.

Network Layer

P2P Communication

• LibP2P-based: Standard peer-to-peer networking
• Gossip Protocol: Intent and block propagation
• DHT: Peer discovery and routing
• Bandwidth Optimization: Bloom filters and compact representations

Node Types

• Full Nodes: Store complete state, participate in validation
• Light Nodes: Store headers only, query full nodes
• Archive Nodes: Store all historical state (for indexers)
• Prover Nodes: Generate PoUW proofs

Security Considerations

Threat Vectors

1. Intent Spam: Rate limiting and fee mechanisms
2. Double-Spend: Nonce system prevents replay
3. Sybil Attacks: PoS + reputation requirements
4. MEV: FCFS ordering and intent privacy reduce MEV surface
5. Cross-Shard Attacks: 2PC and atomic commits prevent inconsistency

Mitigations

• Anomaly Detection: ML-based monitoring for suspicious patterns
• Rate Limiting: Per-account and per-IP throttling
• Economic Security: High stake requirements for validators
• Formal Verification: Move contracts mathematically verified
• Audit Trail: Complete transaction history for forensics

Performance Characteristics

Throughput

• Per-Shard TPS: ~5,000 TPS
• Total TPS: N shards × 5,000 TPS
• Example: 10 shards = 50,000 TPS theoretical maximum

Latency

• Intent Confirmation: <500ms (batch formation)
• Batch Finality: 2-5 seconds (consensus + PoUW)
• Cross-Shard: +1-2 seconds for multi-shard operations

Storage

• State Growth: ~50 GB per million accounts
• Ledger Growth: ~10 MB per 1,000 batches
• Pruning: Archive mode optional, full nodes can prune old state

Future Roadmap

Short Term (Q1-Q2 2026)

• Production-grade PoUW with multiple ZK backends
• Enhanced cross-shard efficiency
• Light client implementations

Medium Term (Q3-Q4 2026)

• Privacy layer productionization
• DeFi-specific intent types (LP, lending, etc.)
• Advanced MEV protection

Long Term (2027+)

• zk-Rollup integration
• Interoperability bridges
• DAO governance automation

For implementation details, see:

• Consensus Deep Dive
• PoUW Technical Specification
• Move VM Integration