</Bandwidth-Backed Digital Currency>
The world's first DAG-based ledger that rewards real network infrastructure. KnexCoin uses Proof-of-Bandwidth (PoB) with VRF-selected challengers, checkpointed Bandwidth Scores, and deterministic finality to create a truly decentralized, scalable, and auditable cryptocurrency. KNEX is the settlement layer (100M fixed supply). UBX is the transactional layer — an elastic bearer instrument built on top.
A creates a send block, debiting balance and referencing recipient B.B creates a receive block, crediting balance by referencing A's send block hash.O(1) time without waiting for network-wide blocks.Features
KnexCoin reimagines blockchain from the ground up, combining bandwidth verification with economic incentives to create a truly decentralized network.
Validators are rewarded based on actual network throughput. No wasted energy, no plutocracy—just real infrastructure contributions.
Bandwidth subsidization eliminates fees entirely. Microtransactions and IoT payments become economically viable at any scale.
6-layer security: Sybil resistance, VRF challenger selection, 100% slashing for spoofing/double-voting, diversity constraints, checkpoint determinism, and real-time anomaly detection.
DAG block-lattice architecture enables unlimited horizontal scaling - each account processes transactions independently.
Time-weighted voting prevents whale dominance. Every participant has a meaningful voice in protocol decisions.
REST and gRPC APIs, comprehensive documentation, and testnet faucets make building on KnexCoin straightforward.
Technology
A revolutionary incentive mechanism that rewards actual network infrastructure rather than energy consumption or capital concentration.
Continuous DAG ledger with 5-minute checkpoint intervals. Deterministic finality with Merkle-anchored BS snapshots.
k=7 challengers (default) from diverse geographic/AS locations verify bandwidth using VRF selection—impossible to game or spoof.
BS(v) = BS_scale × F_T(v) × U(v) × S(v) × D(v) — throughput, uptime, stability, and diversity factors with EWMA smoothing.
Bandwidth spoofing or double voting = entire stake slashed + permanent ban. Attacks are economically irrational.
Technical Blueprint
Traditional blockchains serialize all transactions into sequential blocks, creating bottlenecks. A DAG allows parallel transaction processing - each account maintains its own chain, enabling unlimited horizontal scaling.
BLOCKCHAIN (Sequential) DAG / BLOCK-LATTICE (Parallel)
───────────────────── ────────────────────────────────
┌───┐ ┌───┐ ┌───┐ Account A: ●──●──●──●──●
│ 1 │──▶│ 2 │──▶│ 3 │ Account B: ●──●──●──●──●
└───┘ └───┘ └───┘ Account C: ●──●──●
▼ Account D: ●──●──●──●
All txns wait ↑ ↑ ↑
for blocks Independent chains
Parallel processing
Inspired by Nano's block-lattice architecture. Each account has its own chain (account-chain) in the DAG. Transactions only touch the sender and receiver chains.
pub struct Block { // Block identification hash: [u8; 32], // Blake2b hash of block previous: [u8; 32], // Previous block in account-chain // Account info account: [u8; 32], // Account public key representative: [u8; 32], // Voting representative balance: u128, // Account balance after block // Block type specific block_type: BlockType, // Send | Receive | Change | Bandwidth link: [u8; 32], // Destination or source block hash // Proof-of-Bandwidth (KnexCoin specific) bandwidth_proof: Option<BandwidthProof>, // Signature signature: [u8; 64], // Ed25519 signature work: u64, // Anti-spam PoW (minimal) }
BLOCK-LATTICE STRUCTURE
═══════════════════════
Alice's Chain Bob's Chain Carol's Chain
──────────── ─────────── ─────────────
│ │ │
┌────┴────┐ │ │
│ GENESIS │ │ │
│ 1000 K │ │ │
└────┬────┘ │ │
│ ┌────┴────┐ │
│ │ GENESIS │ │
│ │ 500 K │ │
│ └────┬────┘ │
┌────┴────┐ │ │
│ SEND │────────────────┼──────────────┐ │
│ -100 K │ │ │ │
│ 900 K │ │ ▼ │
└────┬────┘ │ ┌────┴────┐ │
│ │ │ RECEIVE │ │
│ │ │ +100 K │ │
│ │ │ 100 K │ │
│ │ └────┬────┘ │
│ ┌────┴────┐ │ │
│ │ SEND │─────────┼───────┼──▶ Pending
│ │ -50 K │ │ │
│ │ 450 K │ │ │
│ └────┬────┘ │ │
▼ ▼ ▼ ▼
Bandwidth is difficult to prove trustlessly. Unlike PoW (verifiable computation) or PoS (verifiable stake), bandwidth proofs can be spoofed, colocated, or gamed. Our solution uses multiple verification vectors.
pub struct BandwidthProof { // Challenge data challenge_hash: [u8; 32], // Hash of random challenge data challenge_size: u64, // Size of data transferred (bytes) timestamp_start: u64, // Challenge initiated (ms) timestamp_end: u64, // Challenge completed (ms) // Verification challenger_nodes: Vec<[u8; 32]>, // Nodes that issued challenge attestations: Vec<Attestation>, // Peer confirmations // Computed metrics measured_bandwidth: u64, // Calculated Mbps latency_avg: u32, // Average latency (ms) // VDF commitment (prevents pre-computation) vdf_output: [u8; 32], vdf_proof: [u8; 64], }
Validators earn a Bandwidth Score (BS) that determines their voting weight and rewards eligibility:
// Bandwidth Score (BS) combines multiple factors BS = (BW_measured × W_throughput) + (1/Latency × W_latency) + (Uptime × W_uptime) + (Attestations × W_reputation) // Where: // BW_measured = Verified bandwidth in Mbps (capped at 10 Gbps) // Latency = Average response time in ms // Uptime = Percentage online over rolling 30 days // Attestations = Weighted peer reputation score // Weights (tunable via governance): W_throughput = 0.40 // 40% weight on raw bandwidth W_latency = 0.25 // 25% weight on low latency W_uptime = 0.20 // 20% weight on reliability W_reputation = 0.15 // 15% weight on peer attestations
Adapted from Nano's ORV consensus, but voting weight is determined by Bandwidth Score instead of stake alone:
Square root of stake prevents whale domination while still requiring skin-in-the-game. A node with 100x more stake only gets 10x more base weight, which must still be multiplied by their bandwidth contribution.
CONSENSUS FLOW
══════════════
1. BROADCAST 2. VOTE 3. CONFIRM
─────────── ────── ─────────
┌─────────┐ ┌───────────────┐ ┌──────────┐
│ User │ │ Representatives│ │ Quorum │
│ creates │─────▶│ receive & vote │─────▶│ reached │
│ block │ │ based on weight│ │ (67%) │
└─────────┘ └───────────────┘ └──────────┘
│ │ │
│ ┌───────┴───────┐ │
│ │ │ │
│ ┌───┴───┐ ┌───┴───┐ │
│ │Rep A │ │Rep B │ │
│ │W: 150 │ │W: 200 │ │
│ │Vote:✓ │ │Vote:✓ │ ▼
│ └───────┘ └───────┘ ┌─────────┐
│ │CONFIRMED│
│ ┌───────┐ ┌───────┐ │ <1 sec │
│ │Rep C │ │Rep D │ └─────────┘
│ │W: 100 │ │W: 180 │
│ │Vote:✓ │ │Vote:✓ │
│ └───────┘ └───────┘
│
Weight = sqrt(Stake) × BandwidthScore
fn calculate_voting_weight(validator: &Validator) -> u128 { // Get stake (minimum 10,000 KNEX required) let stake = validator.staked_amount; if stake < MIN_STAKE { return 0; } // Square root of stake (prevents whale domination) let stake_factor = (stake as f64).sqrt(); // Bandwidth score (0-1000 range) let bandwidth_score = validator.bandwidth_score; // Combined weight let weight = stake_factor × (bandwidth_score as f64); weight as u128 } // Example: // Whale: 1,000,000 KNEX stake, 500 BS → sqrt(1M) × 500 = 500,000 // Normal: 10,000 KNEX stake, 800 BS → sqrt(10K) × 800 = 80,000 // Ratio: 6.25x (not 100x like pure stake would give)
Unlike single-transaction systems, KnexCoin uses an asynchronous two-phase model:
| Step | Action | Time | State |
|---|---|---|---|
| 1 | Alice creates SEND block | ~0ms | Block created locally |
| 2 | Block broadcast to network | ~50ms | Propagating |
| 3 | Representatives vote | ~100-300ms | Voting |
| 4 | Quorum reached (67%) | ~200-500ms | SEND confirmed |
| 5 | Bob creates RECEIVE block | ~0ms | Block created locally |
| 6 | RECEIVE confirmed | ~200-500ms | Transaction complete |
Full transaction confirmation (send + receive) completes in under 1 second with no fees. Compare to Bitcoin (~60 min), Ethereum (~15 min), or even Solana (~400ms for single tx).
Security
KnexCoin is the first DAG ledger built with NIST-standardized post-quantum cryptography from Genesis. No migration needed—your assets are protected against quantum attacks from the moment you create your wallet.
FIPS 206 (FALCON)
Lattice-based signatures with smallest post-quantum footprint. 897-byte public keys, 666-byte signatures.
FIPS 203 (Kyber)
Quantum-safe key exchange for encrypted node-to-node communication across the network.
FIPS 204 (Dilithium)
Governance-switchable fallback using different lattice structure for defense in depth.
FIPS 202
Quantum-resistant hashing for addresses and Merkle trees. Unaffected by Grover's algorithm.
FIPS 203, 204, 205 published
FIPS 206 + HQC finalized
PQC from day one
Legacy chains vulnerable
All KnexCoin addresses begin with knexq1 indicating quantum-safe cryptography. Your funds are protected against harvest-now-decrypt-later attacks from the moment of Genesis.
How It Works
Acquire a minimum of 10,000 KNEX and stake them to the network. Your stake represents your economic commitment and determines your base selection probability.
Connect your validator node with at least 100 Mbps sustained bandwidth. VRF-selected challengers measure your throughput, latency, and stability each epoch to compute your Bandwidth Score (BS).
Your reward weight is W_r(v) = BS(v) / Σ BS(u). Rewards decay smoothly via BDC formula: R_tx = (1 - S/Cap)^BDC. No halving shocks—predictable economics as you strengthen the network.
Tokenomics
100,000,000 KNEX — fixed supply, zero inflation. No burns, ever. Dual-layer system with UBX transactional currency.
Validator rewards & network security (90%)
Fixed supply — zero inflation
Ecosystem development & operations (10%)
KNEX and UBX are live on the Stellar DEX. Price discovery happens through real commerce and DEX trading: KNEX/XLM and KNEX/USDC pairs provide liquidity, while merchant adoption drives organic demand through the UBX transactional layer.
Dual Currency System
Two layers, one network. KNEX handles settlement and reserve — fixed supply, long-term value storage. UBX handles daily transactions — elastic supply, local currency reference. Economic gravity flows value upward from circulation to reserves.
Value flows from high-velocity circulation (UBX) toward low-velocity reserves (KNEX). As merchants accumulate UBX and convert surplus to KNEX, effective UBX circulation decreases while KNEX concentration strengthens the settlement layer.
Join the Network
The KnexCoin mainnet launches in 2026. Read the whitepaper with complete PoB specification, explore the UBX dual-currency protocol, run a validator, and become part of the bandwidth-backed economy.