32. Multi-Chain Integration Architecture: How Each Chain Secures RandProof

RandProof is not merely deployed on multiple chains, each chain actively contributes to the security, entropy, and payment integrity of the entire protocol. This section answers three questions for each chain: (1) what is deployed on that chain, (2) how does that chain's native properties secure RandProof, and (3) how does payment and settlement flow without a token.

The key architectural insight: RandProof is not just smart contracts on multiple chains. Each chain plays a distinct role in a layered security model where the failure of any single chain, or even several chains simultaneously, cannot compromise the protocol's randomness, payments, or liveness.

32.1 What Is Actually Deployed on Each Chain: And What Is Not

This is the most important clarifying question. The answer is: not the same thing on every chain. RandProof uses a layered deployment model with three tiers:

• Tier 1: Full Protocol Deployment: KeeperCoordinator contract + RandProofRNG + staking registry + BLS verifier + full fee distribution. Clients on this chain can request and receive PoFR events natively. Keepers can register, stake, and earn on this chain independently. Chains: Base, Optimism, Arbitrum, Linea, Ethereum, Polygon, BNB Chain, Avalanche, Moonbeam, World Chain, HyperEVM

• Tier 2: Native Runtime Deployment: Chain-native program/contract implementing the full PoFR standard in the chain's native language. Same functionality as Tier 1 but adapted to the chain's execution model (Rust/Anchor, Tact, Plutus, Move, ink!). Entropy is sourced from chain-native consensus mechanisms. Chains: Solana (Anchor), TON (Tact), Cardano (Plutus V3), Sui (Move), Polkadot (ink! / pallet_revive)

• Tier 3: Entropy-Only Contribution: No client-facing contract deployed. The chain contributes block hash entropy to the 15-source aggregation pool via keeper oracle fetching. Clients on these chains cannot request PoFR events directly but their chain's entropy strengthens every RandProof produced on Tier 1 and Tier 2 chains. Chains: Bitcoin (Merkle Root), Ethereum RANDAO (Source 6: separate from ETH Tier 1 deployment), Polkadot BABE VRF (Source 11: even on chains without Tier 2 deployment)

💡 **KEY INSIGHT:** RandProof is not 'just deploying smart contracts' on each chain. On EVM chains it deploys Solidity contracts. On Solana it deploys Rust/Anchor programs. On Cardano it deploys Plutus validators. On TON it deploys Tact contracts. On Sui it deploys Move modules. On Polkadot it uses ink! contracts or native pallets. Each chain's deployment uses that chain's native security model, execution environment, and consensus-layer entropy. This is fundamentally different from Chainlink, which uses EVM-centric infrastructure and wraps non-EVM chains in adapters.

32.2 Ethereum & EVM L2s: Base, Optimism, Arbitrum, Linea, Polygon, World Chain, HyperEVM

32.2.1 What Is Deployed

• KeeperCoordinator.sol: Immutable Solidity contract. Handles stake registration (ERC-20 and ETH), BLS aggregate signature verification (BN254 pairing via EIP-197 precompile), fee distribution, and RandProof storage. Deployed identically across all EVM chains from a single codebase.

• BLSVerifier.sol: Standalone BLS12-381 / BN254 verification library. Uses the bn256 precompile (address 0x08) available on all EVM chains. Verifies that the aggregated keeper signature is valid against the registered public key set.

• RandProofRegistry.sol: Stores all RandProof artifacts on-chain: eventId, seed, signers, entropy source hashes, fulfillment block. Permanently queryable by any party.

• FeeVault.sol: Holds USDC and native ETH/token balances for pending payouts. Implements pull-payment pattern (per Audit Finding S-01) for keeper withdrawals and protocol treasury transfers.

32.2.2 How Ethereum's Properties Secure RandProof

• PREVRANDAO (Source 6, 5% weight): Every Ethereum block's PREVRANDAO value is produced by the aggregate of 1M+ validator BLS signatures on the beacon chain. No single validator can predict or bias this value by more than one bit. RandProof's keeper nodes read PREVRANDAO at the request block and include it in the entropy aggregation. Ethereum's validator set, the most valuable and decentralized PoS network in existence, is directly contributing to the security of every RandProof event on any chain.

• EIP-197 BN254 Precompile: Pairing operations for BLS aggregate signature verification cost ~45,000 gas on EVM chains (vs. millions without the precompile). This makes on-chain BLS verification economically practical at $0.05–$0.25 per fulfillment. Without this Ethereum innovation, keeper threshold signatures could not be verified on-chain affordably.

• L2 Finality as Fast Confirmation: Base, OP, ARB, and Linea produce blocks every 2 seconds with soft finality, and achieve Ethereum-level security within ~7 days via fraud/validity proof settlement. RandProof fulfillments on L2s are fast (2s confirmation) but secured by Ethereum's full validator set at the settlement layer.

• USDC via CCTP V2: Circle's Cross-Chain Transfer Protocol V2 is natively supported on Base, OP, ARB, Ethereum, and Polygon. Keepers earn USDC that is natively issued by Circle, not bridged or wrapped, on any of these chains. Protocol treasury on Base aggregates USDC from all CCTP-supported chains without bridge risk.

• Immutable Contract Deployment: EVM contracts with no admin key on fulfill() (per design) cannot be upgraded or manipulated after deployment. Ethereum's immutability guarantees that the KeeperCoordinator cannot be altered by anyone, including the RandProof team.

32.2.3 Payment Flow on EVM Chains

Client calls requestRandomness{value: fee}(userSeed), fee paid in ETH (native) or via ERC-20 approve + transferFrom (USDC). FeeVault holds the fee. Upon fulfillment, _distributeFee() credits keeper balances in the pendingWithdrawals mapping. Keepers call withdraw() to claim USDC or ETH to their registered address. Protocol treasury (20%) transfers to Base via CCTP V2 burn-and-mint.

32.3 Solana: Speed, Cost, and Slot VDF Entropy

32.3.1 What Is Deployed

• RandProof Anchor Program: A Rust/Anchor program deployed to Solana mainnet. Account-based architecture: one global Config account (keeper registry, fee params), per-event EventAccount (request, entropy, fulfillment state), per-keeper StakeAccount (stake amount, BLS pubkey, earnings). Uses Program-Derived Addresses (PDAs) for deterministic account addressing.

• BLS Verification: Solana's ed25519 and secp256k1 native program handles signature verification. BLS aggregation is performed off-chain by keeper nodes; the on-chain program verifies the aggregate using Solana's sysvar-based instruction introspection.

• SPL Token Integration: USDC on Solana is a native SPL token (Circle-issued, CCTP V2 supported). Fee payments and keeper earnings are denominated in SPL USDC. The program holds USDC in a Program-Owned Token Account (PDA vault).

32.3.2 How Solana Secures RandProof

• Slot VDF (Verifiable Delay Function) as Entropy Source: Solana's Proof-of-History (PoH) mechanism produces a VDF-based timestamp for every slot (~400ms). The slot hash, a SHA-256 hash of the PoH sequence, is unpredictable before the slot is produced and immediately verifiable after. RandProof uses the slot hash at the request slot as Source 2 (Chain-Native VRF, 15% weight) on Solana. An attacker would need to control Solana's leader schedule and manipulate PoH to bias this, effectively requiring a 66%+ stake attack on Solana.

• 400ms Block Times = Sub-Second Fulfillment: Solana produces a block every ~400ms. RandProof events on Solana can be fulfilled in under 1 second end-to-end, the fastest fulfillment of any chain in the network. This makes Solana the preferred chain for latency-sensitive use cases (gaming, live auctions, real-time raffles).

• Low Transaction Cost: Solana transactions cost ~$0.00025. The $0.05 base fee per PoFR event covers ~200 transactions worth of Solana compute, making even high-frequency gaming use cases economically viable. A game triggering 10,000 RandProof events per day pays $500/day in fees.

• Turbine Block Propagation: Solana's Turbine protocol propagates blocks to all validators in ~150ms. This means keeper nodes receive fulfillment confirmations nearly simultaneously, eliminating race conditions in the BLS aggregation gossip layer for Solana-based events.

32.3.3 Payment Flow on Solana

Client calls the Anchor program's request_randomness instruction with USDC transferred to the PDA vault. Keepers detect via WebSocket subscription to program logs. After fulfillment, the fulfill_randomness instruction distributes USDC proportionally to keeper token accounts (SPL transfer). No withdrawal step needed, direct SPL token transfer to keeper accounts on fulfillment. Protocol treasury 20% sent to Base via native CCTP V2 burn-and-mint (no third-party bridge; Solana has native CCTP V2 support).

32.4 Cardano: Academic-Grade Security and Ouroboros Praos VRF

32.4.1 What Is Deployed

• Plutus V3 Validators: Cardano uses the UTXO model, there is no mutable state in a single contract account. RandProof on Cardano consists of three Plutus V3 validator scripts: KeeperRegistryValidator (controls stake UTXOs at a script address), EventValidator (holds fee ADA and validates fulfillment proofs), and RandProofDatumValidator (stores the RandProof artifact in transaction metadata and on-chain datum).

• eUTXO Architecture: Each PoFR event is represented as a UTXO at the EventValidator script address, carrying the request parameters in its datum. Fulfillment consumes this UTXO (providing the proof in the redeemer) and produces two new UTXOs: one to the winner/callback address, one to the keeper fee address. This is fundamentally different from EVM account-based state, it is inherently parallel and cannot have reentrancy vulnerabilities.

• Native Token Staking: Keeper stakes are held in UTXOs at the KeeperRegistryValidator address, locked with a BLS public key hash in the datum. Slashing burns the UTXO (ADA is sent to the protocol treasury address). No wrapping, no bridges, pure ADA at a script address.

32.4.2 How Cardano Secures RandProof

• Ouroboros Praos VRF (Source 2, 15% weight on Cardano): Every Cardano block producer runs a VRF function to determine if they are elected as the slot leader. The VRF output is included in the block header and is publicly verifiable. RandProof reads the VRF proof from the block header at the request slot. This is one of the most rigorously peer-reviewed VRF constructions in blockchain, Cardano's Ouroboros Praos was formally verified in an academic paper with cryptographic proofs. An attacker needs to control >50% of all staked ADA to bias this entropy.

• eUTXO Eliminates Reentrancy: The UTXO model means RandProof's fee handling on Cardano has zero reentrancy risk by construction. The Audit Finding S-01 (transfer() loop reentrancy) cannot exist in a UTXO-based architecture. Every payment is an independent UTXO spend, atomic and isolated.

• Formal Verification via Plutus: Plutus is based on Haskell, a statically-typed functional language with strong correctness guarantees. Plutus validators can be formally verified using Agda or Coq. RandProof's Cardano validators are designed to be formally verifiable, providing a level of correctness assurance not achievable with Solidity.

• Slow Finality as a Feature: Cardano achieves probabilistic finality in ~10 seconds and absolute finality in ~5 minutes. For RandProof, this means Cardano events take longer to fulfill (~60 seconds minimum) but the finality guarantee is among the strongest in the ecosystem. Suitable for high-value, non-latency-sensitive selections (government lotteries, grant allocation, clinical trials).

32.4.3 Payment Flow on Cardano

Client sends ADA to the EventValidator script address with a request datum. Keeper detects the new UTXO via Blockfrost API or direct node RPC. After entropy aggregation, keeper submits a transaction consuming the event UTXO (providing the seed and BLS proof in the redeemer) and producing: (1) callback UTXO to the client, (2) 70% ADA to keeper address, (3) 20% ADA to treasury address, (4) 10% ADA to gas reserve address. All in a single atomic Cardano transaction. No separate withdrawal step.

32.5 TON (The Open Network): Telegram Scale and Masterchain Entropy

32.5.1 What Is Deployed

• Tact Smart Contracts: RandProof on TON is implemented in Tact, TON's high-level smart contract language. Three contracts: KeeperRegistry (stores keeper public keys and stake balances in a TON HashMap), EventManager (handles DrawRequest messages and fulfillment), and FeeDistributor (implements 70/20/10 split via TON's native message-passing model).

• TON Actor Model: TON contracts communicate via asynchronous messages, there is no synchronous call stack. RandProof's TON contracts use a message-passing flow: client sends a DrawRequest message to EventManager, which replies with an eventId, then on fulfillment sends separate messages to each keeper address and the treasury. Each message is an independent transaction, making the system naturally non-blocking.

• Telegram Mini App Integration: TON5050 (the BIT5050 deployment on TON) runs as a Telegram Mini App. RandProof on TON exposes a Telegram Bot API endpoint that allows any Telegram bot to request PoFR events and receive results via webhook, unlocking a 900M+ user distribution channel for verifiable randomness.

32.5.2 How TON Secures RandProof

• Masterchain Hash as Entropy (Source 2 on TON): TON's masterchain coordinates all workchain activity and produces a block hash that aggregates state from all shards. This hash is deterministic and unpredictable before the block is produced. RandProof reads the masterchain block hash at the request block as the chain-native entropy source. Compromising this requires controlling TON's masterchain validators.

• Infinite Sharding Paradigm: TON can shard infinitely, a heavily-loaded workchain splits into sub-shards automatically. This means RandProof on TON can handle massive event volume (millions per day) without congestion, as each shard handles a subset of events independently. No gas spikes during peak demand.

• 5-Second Finality: TON achieves finality in ~5 seconds. RandProof fulfillments on TON complete in 5–10 seconds, suitable for Telegram-based games and mini-apps where users expect near-instant responses.

• Distribution via Telegram: TON's native integration with Telegram provides access to 900M+ users. Any Telegram-based draw, contest, or selection can use RandProof via the Telegram Mini App or Bot API interface without users ever touching a wallet or understanding blockchain. RandProof becomes invisible infrastructure for mass-market fairness proofs.

32.5.3 Payment Flow on TON

Client sends TON (or jUSDT) to the EventManager contract address with a DrawRequest message body. TON's actor model processes the message asynchronously. On fulfillment, FeeDistributor sends three separate internal messages: 70% TON to keeper address, 20% to treasury address, 10% to gas reserve. Each message is processed independently. Treasury holds and accounts for this 20% in native TON on-chain rather than bridging to USDC on Base (AV-49 policy, no third-party bridge in the treasury settlement path).

32.6 Sui: Object-Centric Speed and sui::random

32.6.1 What Is Deployed

• Move Modules: RandProof on Sui is implemented in Move, Sui's object-centric smart contract language. Three Move modules: keeper_registry (manages Capability objects for keeper registration), pofr_event (shared object per event, handling request and fulfillment state), fee_vault (holds SUI and USDC Coin objects, distributes on fulfillment).

• Shared Object Architecture: The PoFR event is a Sui Shared Object, accessible by multiple transactions simultaneously without locks. The fulfillment transaction takes the shared event object, validates the BLS aggregate, extracts the seed, calls back to the client object, and distributes Coin objects to keeper addresses. All in a single atomic Sui transaction with programmable transaction blocks.

• sui::random Module: Sui has a native on-chain randomness module (sui::random) that provides a cryptographically secure random seed per transaction, produced by Sui's validators using a threshold BLS DKG protocol. RandProof integrates this as a native entropy input, using Sui's own randomness as one of the 15 sources.

32.6.2 How Sui Secures RandProof

• sui::random as Chain-Native Entropy (Source 2 on Sui): The sui::random module produces per-transaction randomness via Sui's validator DKG (Distributed Key Generation) protocol. This is one of the most sophisticated chain-native randomness mechanisms available on any blockchain, validators cooperate using threshold BLS to produce a shared random value that no single validator can predict or bias. Using sui::random as a Source 2 input means Sui's own validator security model directly contributes to every RandProof event on Sui.

• Sub-Second Finality: Sui achieves finality in ~400ms–800ms. RandProof events on Sui are fulfilled in under 1 second, matching Solana as the fastest fulfillment chain. Sui's parallel execution engine (Narwhal/Bullshark consensus) means high event volume does not cause congestion or gas price spikes.

• Object Ownership Eliminates Custody Risk: In Sui's object model, Coin objects are owned by addresses, they cannot be locked in contracts without explicit transfer. RandProof's fee vault holds Coin objects that are owned by the vault address but can only be extracted by the fee distribution logic. This provides cleaner asset custody than EVM's account-balance model.

• Programmable Transaction Blocks: Sui's PTBs allow RandProof to batch all fulfillment operations (verify BLS, compute seed, callback client, distribute fees) into a single atomic transaction with zero intermediate state. If any step fails, the entire fulfillment reverts. This eliminates the partial-fulfillment failure mode present in EVM contracts.

32.6.3 Payment Flow on Sui

Client calls the pofr_event Move module with a SUI Coin or USDC Coin object as fee payment. The shared event object is updated. On fulfillment, the keeper submits a PTB that (1) verifies BLS proof, (2) calls back to the client module, (3) splits the fee Coin object into three parts (70/20/10), (4) transfers each part to the appropriate address. No separate withdrawal, Coin objects are transferred atomically in the fulfillment PTB.

32.7 Polkadot: Shared Security and BABE VRF Entropy

32.7.1 What Is Deployed

• ink! Smart Contracts (pallet_revive): RandProof on Polkadot is deployed as an ink! contract on Asset Hub or via pallet_revive (the EVM-compatible pallet on Polkadot). ink! is a Rust-embedded DSL for Substrate smart contracts with near-Rust performance. The contract architecture mirrors the EVM implementation but uses Substrate's native storage, event emission, and cross-contract call model.

• Substrate Runtime Integration: Keeper nodes running on Polkadot interact with the Substrate runtime directly via polkadot.js RPC. The BABE epoch randomness (Source 11) is read from the Substrate randomness_collective_flip or babe pallet at the randomness storage slot, no oracle required, pure on-chain native access.

• XCM Fee Settlement: Polkadot's Cross-Consensus Messaging (XCM) allows DOT and USDC (via Asset Hub) to move between parachains. RandProof uses XCM to route keeper earnings from Polkadot to Asset Hub (the USDC-native parachain), which is a native transfer within the Polkadot ecosystem, not a third-party bridge. Treasury funds are held and accounted for in USDC on Asset Hub (or DOT) rather than bridging onward to Base via Wormhole (AV-49 policy).

• Moonbeam as EVM Entry Point: Moonbeam (Polkadot parachain) provides full EVM compatibility. The Solidity KeeperCoordinator.sol is deployed on Moonbeam, giving EVM-native clients access to Polkadot's BABE entropy without needing to use ink! or Substrate directly.

32.7.2 How Polkadot Secures RandProof

• BABE VRF (Source 11, 5% weight globally): As detailed in Section 3.3, BABE's per-slot VRF outputs are aggregated into an on-chain epoch randomness pool that is announced 2 epochs (~8 hours) before use. Polkadot's ~300 active validators each contribute a VRF output. RandProof reads this epoch randomness directly from the Substrate runtime storage, no third-party oracle, no HTTP fetch. Polkadot's validator set is completely independent from Ethereum's, providing genuine cross-network entropy diversification.

• Shared Security (Parachain Model): All Polkadot parachains (including Moonbeam and Asset Hub) are secured by Polkadot's relay chain validators. A single attack on Polkadot would need to compromise the relay chain, which shares security with all parachains simultaneously. This means RandProof's Moonbeam and Asset Hub deployments inherit Polkadot's full validator set security without any additional infrastructure.

• DOT as High-Value Stake Asset: DOT is a high-value, liquid asset with deep market depth. Keeper stakes in DOT provide strong economic security guarantees. A keeper slashed 100% of their DOT stake suffers a meaningful financial loss, more so than most other chain stake assets at the same USD floor.

• Governance as Upgrade Path: Polkadot's on-chain governance (OpenGov) provides a structured upgrade path for RandProof's Substrate runtime integration. If BABE VRF parameters change or a new Substrate randomness primitive emerges, RandProof can upgrade via governance without disrupting the keeper network.

32.8 Combining Chain Properties for Maximum Security, Speed, and Reliability

Each chain's native properties contribute to a different security dimension. The following table shows how chain features combine across the protocol:

• Entropy Diversity: Ethereum RANDAO + Solana Slot VDF + Cardano Ouroboros Praos + Sui sui::random + Polkadot BABE VRF + TON Masterchain Hash, Six independent consensus VRF mechanisms from six independent validator sets. An attacker must simultaneously compromise all six to bias the chain-native entropy layer.

• Finality Speed (Latency): Solana (400ms) + Sui (600ms) + TON (5s) + Ethereum L2s (2s soft / 7-day hard) + Cardano (60s soft / 5min hard) + Polkadot (12s), Fast chains (Solana, Sui) serve latency-sensitive use cases. Slow chains with strong finality (Cardano, Ethereum mainnet) serve high-value, audit-critical use cases. The same PoFR standard applies to both.

• Payment Settlement Diversity: Native USDC via CCTP V2 (Ethereum, Base, OP, ARB, Solana, HyperEVM) + Native XCM USDC (Polkadot Asset Hub) + Native asset settlement with no bridge involved (Sui: SUI, BNB Chain: BNB, Avalanche: AVAX, Moonbeam: GLMR, Cardano: ADA, TON: TON), RandProof does not route protocol or keeper revenue through any third-party bridge such as Wormhole (AV-49 policy). If CCTP V2 experiences an outage, chains settling in native assets are unaffected, since they have no bridge dependency to begin with. Keeper earnings on any chain are unaffected by payment rail failures on other chains.

• Smart Contract Safety Models: Solidity/EVM (battle-tested, auditable) + Rust/Anchor (memory-safe, compiled) + Plutus/Haskell (formally verifiable) + Move (object-safe, resource-typed) + Tact (actor-model, message-based) + ink!/Rust (Substrate-native), A vulnerability class that exists in one execution environment may be structurally impossible in another. EVM reentrancy cannot exist in Cardano's UTXO model. Move's resource type system prevents asset duplication by construction. Rust's borrow checker eliminates memory-safety bugs in Anchor and ink!.

• Geographic / Validator Decentralization: Ethereum validators (global, 1M+) + Solana validators (1,900+, US/EU/Asia) + Cardano stake pools (3,000+, global) + Polkadot validators (297 active, multi-continent) + TON validators (300+) + Sui validators (100+), No geographic region, government, or institution can shut down RandProof by attacking one validator set. Each chain's validator geography is independent.

• Consensus Mechanism Diversity: Ethereum PoS (Gasper/LMD-GHOST) + Solana PoH + Cardano Ouroboros Praos + Polkadot BABE/GRANDPA + TON BFT + Sui Narwhal/Bullshark, A systemic flaw in one consensus design (e.g., a new PoS attack vector) cannot simultaneously compromise chains using fundamentally different consensus mechanisms. RandProof's entropy stack is protected by consensus diversity in addition to validator independence.

32.9 The Combined Security Thesis

RandProof's multi-chain architecture is not additive, it is multiplicative. Each chain adds an independent security dimension that compounds with all others:

To manipulate a single RandProof event, an attacker must simultaneously:

• Compromise Ethereum's 1M+ validators (to bias RANDAO)

• Compromise Solana's slot VDF (to bias slot hash entropy)

• Compromise Cardano's Ouroboros Praos (to bias block VRF)

• Compromise Sui's validator DKG (to bias sui::random)

• Compromise Polkadot's BABE epoch randomness

• Compromise TON's masterchain validators

• Compromise DRAND's League of Entropy (22 global operators)

• Compromise NIST's quantum randomness beacon

• Compromise the Bitcoin hash rate (Merkle Root)

• Compromise the Tor network (9 directory authorities)

• Compromise ANU QRNG hardware (physically isolated academic lab)

• Control a majority of commit-reveal participants in the specific event

The combined cost of compromising all twelve listed chain and infrastructure components simultaneously exceeds $100B by any reasonable estimate. This reflects the diversity of the underlying chains and entropy sources at full Phase 4 deployment, not a claim that no more expensive-to-attack system could exist. And critically: none of these chains need to trust each other. Each contribution is independently verifiable. The failure, compromise, or shutdown of any single chain strengthens the relative weight of the remaining 11 sources without breaking the protocol.

32.10 No-Token Payment Architecture: How USDC and Native Assets Flow

RandProof operates with no protocol token. All payments, stake, and settlements use USDC (primary) or each chain's native asset (fallback). This is a deliberate design choice that eliminates token volatility risk for node operators, reduces regulatory complexity, and makes the protocol immediately accessible to enterprise and institutional users who cannot hold governance tokens.

32.10.1 Payment Flow Summary Per Chain

• Base / OP / ARB / Linea / Polygon / World Chain: Fee: USDC (native, CCTP V2) or ETH | Stake: ETH | USDC: Native Circle USDC, no bridge, no wrap | Treasury: Stays on Base (home chain of protocol treasury)

• Ethereum Mainnet: Fee: USDC (native, CCTP V2) or ETH | Stake: ETH (0.01 ETH min) | USDC: Native Circle USDC | Treasury: CCTP V2 burn-and-mint to Base

• Solana: Fee: SPL USDC (native, CCTP V2) or SOL | Stake: SOL (0.5 SOL min) | USDC: Native Circle USDC on Solana | Treasury: CCTP V2 burn-and-mint to Base

• BNB Chain / Avalanche / Moonbeam: Fee: native (BNB/AVAX/GLMR) | Stake: BNB / AVAX / GLMR | USDC: not used, no native (non-bridged) Circle USDC on these chains | Treasury: held and accounted in native asset on-chain; no bridge to Base (AV-49 policy, bridge dependency removed; native-asset volatility exposure accepted and disclosed)

• Cardano: Fee: ADA only | Stake: ADA (50 ADA min) | USDC: not used, no native (non-bridged) Circle USDC on Cardano | Treasury: held and accounted in ADA on-chain; no bridge to Base (AV-49 policy)

• TON: Fee: TON only | Stake: TON (10 TON min) | USDC: not used, jUSDT is a bridged Tether representation, not native USDC, and is excluded under AV-49 policy | Treasury: held and accounted in TON on-chain; no bridge or swap to Base

• Sui: Fee: SUI only | Stake: SUI (5 SUI min) | USDC: not used, Wormhole USDC on Sui is bridged, excluded under AV-49 policy | Treasury: held and accounted in SUI on-chain; no bridge to Base

• Polkadot / Asset Hub: Fee: USDC via XCM + Asset Hub or DOT | Stake: DOT (5 DOT min) | USDC: USDC on Polkadot Asset Hub via XCM (native to the Polkadot ecosystem, not a third-party bridge) | Treasury: held and accounted in USDC on Asset Hub or DOT; no further bridge to Base (AV-49 policy, the prior XCM-then-Wormhole consolidation leg to Base is removed; only the native XCM transfer within the Polkadot ecosystem remains)

• HyperEVM: Fee: USDC (native) or HYPE | Stake: HYPE or ETH | USDC: Circle USDC (native, via CCTP V2) | Treasury: CCTP V2 to Base (no bridge, native USDC transfer; AV-49 policy)

32.10.2 Protocol Treasury Consolidation on Base

All protocol revenue (20% of every PoFR fee) flows to Base as the canonical treasury chain. Base is chosen because:

• Native USDC (Circle-issued, not bridged), highest stablecoin security guarantee

• Lowest EVM gas costs for treasury management operations

• Coinbase institutional custody integration for treasury safekeeping

• CCTP V2 hub, can receive USDC from 5+ chains without bridge risk

• BIT5050 (genesis client) is primarily deployed on Base, operational alignment

• Deep Coinbase ecosystem integration for fiat on/off ramp and institutional access

32.10.3 Keeper Earnings Without a Token: Why This Works

The no-token model creates a cleaner economic incentive structure than token-based protocols:

• No token inflation risk: Keeper earnings are USDC, their real value does not depend on the protocol's token price. A token-based reward system where the token drops 80% effectively cuts keeper earnings 80%. USDC earnings are stable.

• No regulatory uncertainty: Protocol governance tokens are subject to securities classification risk in multiple jurisdictions. USDC and native assets are not. Enterprises and institutions can pay for RandProof services without regulatory compliance concerns about holding a protocol token.

• No circular dependency: Token-based protocols often require keepers to buy the token to stake and earn the token as rewards, creating a circular dependency where node operator economics are tied to token liquidity. RandProof keepers stake ETH/SOL/ADA/etc. (liquid, deep markets) and earn USDC (stable, immediately usable).

• Direct fee-for-service economics: Every PoFR event generates real revenue (USDC or native asset payment from a client who needs the service). This is product revenue, not token inflation. The keeper network is self-sustaining from day one with real paying clients (starting with BIT5050 17-chain deployment).

Disclaimer

This whitepaper is for informational purposes only. RandProof Network is under active development. Technical specifications, supported chains, fee structures, and timelines are subject to change. Participation as a keeper node operator involves financial risk. Nothing constitutes investment advice or an offer to buy/sell securities.