KnexCoin Whitepaper

Current System Failures

Existing financial and blockchain infrastructure presents structural limitations that constrain both institutional adoption and everyday utility:

• Transaction fees — Card processing costs 1.5–3.5% per transaction. Cross-border remittances cost 6–10%. Blockchain gas fees fluctuate unpredictably with congestion. These costs make micro-transactions economically impractical.
• Discretionary governance — Protocol changes in existing systems are determined by core development teams, foundation votes, or miner/validator signaling with no deterministic activation criteria. This creates unpredictable rule changes that undermine institutional confidence.
• Settlement latency — Traditional batch settlement introduces counterparty risk and delays ranging from hours to days. Even blockchain finality varies from minutes (Ethereum) to an hour (Bitcoin).
• System fragility — Proof-of-Work centralizes around hardware manufacturers. Proof-of-Stake creates plutocratic reward loops. Both models concentrate power over time rather than distributing it.
• Rigid emission — Fixed halving schedules reduce issuance regardless of actual network conditions, creating potential instability when supply reduction collides with demand changes.

The Solution

KnexCoin addresses these failures through four integrated mechanisms: a feeless block-lattice DAG that eliminates transaction costs while maintaining anti-spam protection through minimal proof-of-work; deterministic governance (CORE) that gates all protocol changes behind measurable stability thresholds, removing human discretion from protocol evolution; counter-cyclical emission (NAI) that dynamically adjusts token release rates based on real network conditions with reserve horizon protection; and streaming settlement that enables continuous value transfer without per-transaction overhead or batch delays.

Design Philosophy

The protocol operates on a foundational principle: the system has rules. Governance decisions are not made by committees, foundations, or developer teams. They are determined by measurable system readiness across four domains (network, economic, security, governance) evaluated against predetermined thresholds. This is not a philosophical aspiration — it is an engineering constraint enforced at the consensus layer.

What KnexCoin Is / Is Not

KnexCoin IS	KnexCoin IS NOT
An open-source software protocol	A bank or financial institution
Distributed ledger infrastructure	A custodian of user funds
Non-custodial by design	An investment product or security
A deterministic governance model	A stablecoin or pegged currency
A dual-currency economic system	A promise of returns or appreciation
Transparent accounting infrastructure	A debt forgiveness mechanism

Who This Is For

The protocol is designed for three initial audiences: merchants in commerce environments where card processing fees erode margins and cash-only operations create security risk; individuals in remittance corridors where transfer costs and settlement delays represent a measurable economic burden; and infrastructure builders (fintechs, neobanks, payment aggregators) seeking programmable, feeless settlement with deterministic protocol guarantees. Current operations focus on Colombia, with architecture designed for global deployment.

Core Layer (Genesis)

These components are required for protocol operation and are active from the first block:

• Block-lattice DAG — Account-chain architecture enabling parallel transaction processing without global ordering
• SPVT Consensus — Stake-proportional validation tiers gating transaction eligibility by validator stake relative to transaction value
• Proof-of-Bandwidth — Reward distribution based on demonstrated network capacity, not staked collateral
• NAI Emissions — Counter-cyclical emission dampening with horizon protection
• Base Asset Accounting — KNEX fixed-supply settlement and UMX elastic bearer instrument
• CORE Governance — Deterministic, stability-gated protocol evolution across four tiers
• SAFE_MODE — Automatic system stabilization during detected instability
• Ed25519 Signatures — Classical cryptographic identity and transaction authorization

Optional Modules (Post-Genesis)

These components are planned integrations that do not affect consensus-critical operation at launch:

• ML-DSA-65 Post-Quantum — Hybrid PQ signature binding for forward quantum security
• Streaming Payments — Off-chain cumulative voucher settlement for continuous value streams
• UMX Credit System — Collateral-backed overdraft facilities on the elastic bearer instrument
• DATE — Debt Amortized Time-Bound Extinguishment accounting layer
• QORA Treasury — Protocol-level micro-taxation for public goods funding
• NFC Bearer Cards — Physical card-based bearer instruments with MPC threshold verification
• ISO 20022 Mapping — Optional compliance layer for traditional financial infrastructure
• DEX — On-chain decentralized exchange with D-prefix account tracking
• Cross-Chain Bridge — Framework for bridging assets to external ledger networks

Feature Map

Feature	Why It Exists	Launch Phase
Block-lattice DAG	Parallel processing, sub-second finality, feeless transactions	Genesis
SPVT	Prevent wealth-based reward centralization	Genesis
Proof-of-Bandwidth	Decouple rewards from stake magnitude	Genesis
NAI	Counter-cyclical emission, reserve protection	Genesis
CORE Governance	Eliminate discretionary protocol changes	Genesis
SAFE_MODE	Automatic stabilization during instability	Genesis
Dual Currency (KNEX/UMX)	Isolate settlement stability from commerce elasticity	Genesis
Streaming Payments	Continuous settlement without per-transaction overhead	v1
UMX Credit	Collateral-backed commerce credit extension	v1
DATE	Transparent debt retirement accounting	v1
QORA Treasury	Protocol-funded public goods	v1
NFC Bearer Cards	Physical cash-like instruments for unbanked commerce	v1
ML-DSA-65 PQ	Forward quantum security	v1
DEX	On-chain exchange with NAI-tracked volume	v2
ISO 20022	Traditional financial infrastructure compatibility	v2
Cross-Chain Bridge	Interoperability with external networks	v2

Modularity

The protocol is modular by design. Optional components do not increase consensus-critical complexity at genesis. Each optional module can be activated independently via CORE governance (minimum T2 Amendment, threshold 0.70) only when the network demonstrates sufficient readiness. Failure or deactivation of any optional module does not affect base-layer operation.

Motivation

Existing distributed ledger systems present fundamental limitations that constrain practical utility. Proof-of-Work protocols require substantial energy expenditure and centralize mining among entities with specialized hardware. Proof-of-Stake protocols, while energy-efficient, concentrate validation power and rewards proportionally to stake magnitude, creating plutocratic governance dynamics. Transaction fees in existing systems make micro-transactions economically impractical and fluctuate unpredictably with network congestion.

Emission schedules in existing protocols are rigid. Fixed halving mechanisms reduce issuance regardless of actual network utilization, creating potential economic instability. Post-quantum cryptographic readiness remains absent from major protocols, leaving existing signature schemes theoretically vulnerable to advances in quantum computation.

Design Objectives

• Eliminate transaction fees entirely while maintaining spam resistance
• Separate validation eligibility from reward magnitude to prevent wealth-based reward centralization
• Implement counter-cyclical emission that responds to real network conditions
• Provide post-quantum cryptographic readiness without requiring account migration
• Enable protocol-level multisignature enforcement compatible with lightweight client applications
• Support continuous value streams without per-transaction overhead
• Establish a dual-currency architecture isolating settlement stability from elastic utility

KnexCoin incorporates a deterministic governance and activation system known as CORE (Consensus Optimization & Readiness Engine). Protocol changes do not activate immediately upon approval. Instead, changes become active only when system stability conditions are met. This approach eliminates discretionary governance and ensures that protocol evolution occurs only when the network demonstrates sufficient operational readiness.

Technology Classification

Dual-Currency Architecture

KNEX is the protocol’s fixed-supply base settlement unit. Its total supply is permanently capped at 100 million tokens. KNEX is used for staking, governance participation, and validator reward denomination. It cannot be elastically expanded, credit-extended, or taxed by the QORA mechanism. KNEX provides the settlement stability foundation of the protocol.

UMX (Lumero, Ł) is an elastic bearer instrument designed for daily commerce and retail utility. UMX supply adjusts through share-based rebase mechanics. It supports credit extension (collateralized by staked KNEX), QORA micro-taxation for public goods funding, and NFC card provisioning for physical bearer instruments. UMX absorbs the volatility and flexibility demands of a commerce layer while KNEX remains invariant.

This separation isolates base settlement stability from elastic utility demand. Credit risk in UMX cannot propagate to KNEX balances. The two currencies serve complementary roles within a single protocol.

Counter-Cyclical Emissions

The Network Activity Index (NAI) adjusts token emission rates based on real-time network conditions. When network activity is high, the NAI reduces emission to conserve reserves and avoid pro-cyclical inflation. When activity is low, it increases emission to incentivize validator participation and maintain network security. The dampening range is bounded between 0.25× and 3.0× the base emission rate.

A horizon protection mechanism prevents reserve depletion below 15 years regardless of dampening calculations. This ensures that short-term activity spikes cannot accelerate the emission schedule beyond sustainable limits.

How Emissions Respond: Example Scenario

Stability Design

The economic architecture is designed to avoid three failure modes common in existing protocols: (1) pro-cyclical inflation where fixed emission schedules amplify boom-bust dynamics, (2) fee-based validator incentives that make micro-transactions economically impractical, and (3) unbounded elastic supply that erodes long-term value stability. Counter-cyclical emission via NAI addresses the first. Feeless transactions with PoB rewards address the second. Share-based UMX accounting with KNEX invariance addresses the third.

Common Misunderstandings

• “KNEX is a stablecoin.” — Incorrect. KNEX has no peg, no backing asset, and no price guarantee. It is a fixed-supply protocol settlement unit whose value is determined by market dynamics.
• “UMX elasticity is inflation.” — Incorrect. UMX uses share-based accounting. Rebase operations adjust total supply but individual account shares remain proportional. This is a unit-of-account adjustment, not dilutive inflation.
• “Feeless means costless.” — Incorrect. Each transaction requires a minimal proof-of-work computation for anti-spam protection. There are no monetary fees, but computational work is required.
• “NAI predicts markets.” — Incorrect. NAI responds to observed on-chain metrics (transaction volume, active accounts, validator count, DEX volume). It is a reactive dampening system, not a predictive model.
• “The credit system is fractional reserve banking.” — Incorrect. Every UMX credit extension is fully collateralized by staked KNEX. Default triggers automated collateral seizure. There is no unbacked credit creation.
• “DATE eliminates debt.” — Incorrect. DATE acquires debt instruments at market prices and retires them through time-bound processes. It does not forgive, erase, or eliminate debt by declaration. Performance depends on market conditions.

Block-Lattice DAG

The protocol organizes the ledger as a block-lattice directed acyclic graph (DAG). Each account in the network maintains an independent, append-only chain of blocks. Unlike linear blockchain architectures that serialize all transactions into globally ordered blocks, the block-lattice structure enables each account to append blocks independently, providing massive parallelism with zero contention between unrelated accounts.

Two-Phase Transactions

Value transfer requires two blocks: a Send block appended to the sender's chain (debiting the balance and creating a pending receivable), and a Receive block appended to the recipient's chain (crediting the balance and claiming the pending entry). This asynchronous model decouples sender and receiver operations temporally and computationally.

Block Structure

Each block contains the following fields:

Field	Size	Description
block_type	u8	Block type identifier (14 types defined)
account	32 bytes	Account Ed25519 public key
previous	32 bytes	Hash of previous block in account chain
representative	32 bytes	Voting delegate public key
balance	u128	Post-transaction account balance (raw units)
link	32 bytes	Multipurpose: destination pubkey (send) or source hash (receive)
amount	u128	Transfer amount (raw units)
timestamp	u64	Unix epoch seconds
work	u64	Anti-spam proof-of-work nonce
memo	0-256 bytes	Typed memo envelope (optional)
hash	32 bytes	SHA-256 of deterministic JSON block representation
signature	64 bytes	Ed25519 signature over hash
cosignatures	variable	Transport-only: M-of-N cosigs (excluded from hash)

Deterministic Hashing

The block hash is computed by applying SHA-256 to a deterministic JSON representation of block fields, excluding the hash, signature, and cosignatures fields. Field ordering is fixed across all implementations, including the Progressive Web Application (PWA) wallet.

Block Types

Byte	Type	Function
0x00	Send	Transfer funds, create pending receivable
0x01	Receive	Claim pending entry, credit account
0x02	Change	Update voting representative
0x03	Bandwidth	Record Proof-of-Bandwidth proof
0x04	StreamOpen	Initiate streaming payment session
0x05	StreamSettle	Batch settle off-chain vouchers
0x06	StreamClose	Finalize stream, reclaim remaining funds
0x07	PqBind	Bind ML-DSA-65 post-quantum public key
0x08	Stake	Lock collateral to validator
0x09	Unstake	Initiate 21-day unbonding
0x0A	MultisigSetup	Configure M-of-N multisig policy
0x0B	TokenMint	Create or mint tokens
0x0C	TokenSend	Transfer tokens
0x0D	TokenReceive	Claim pending token transfer
0x0E	MultisigApprove	Collect co-signatures, execute at M threshold
0x0F	GovernancePropose	Create QORA governance proposal
0x10	GovernanceVote	Cast quadratic governance vote
0x11	StealthSend	Ephemeral key derivation, stealth output
0x12	StealthReceive	Scan and claim stealth payment
0x13	NfcRegister	Register NFC bearer card UID
0x14	NfcSpend	Tap-to-pay with NFC attestation
0x15	NfcSweep	Sweep NFC card balance to recovery wallet
0x16	SlashingEvidence	On-chain slashing evidence record with automated triggers
0x17	BirthRegister	Centennial Maturity Fund registration
0x18	MaturityClaim	Claim maturity tranche at age milestone
0x19	TrustFundBump	Deposit UMX to minor’s trust fund

Anti-Spam PoW

Each block must include a proof-of-work nonce satisfying a minimum difficulty threshold. The PoW computation is trivial for legitimate use (sub-second on modern hardware) but economically impractical for sustained spam attacks at scale.

Genesis Account Lock

A genesis account is established at network initialization containing the total supply. The genesis account is permanently locked after one initial distribution transaction. Any subsequent send attempts from the genesis account are rejected. Send transactions addressed to the genesis public key are also rejected, preventing accidental supply burns.

Fixed Supply

The protocol enforces an immutable total supply that cannot be increased, decreased, or burned by any protocol operation.

Genesis Distribution

Supply Invariant

Emission Schedule

Year	Annual Release (KNEX)	Cumulative	% of Reserve
1	4,500,000	4,500,000	5.0%
5	4,500,000	22,500,000	25.0%
10	4,500,000	45,000,000	50.0%
15	4,500,000	67,500,000	75.0%
20	4,500,000	90,000,000	100.0%

Actual emission is modulated by the NAI dampening factor (Section 09). After year 20, no new KNEX is created. The protocol operates on existing circulating supply with zero fees.

Overview

SPVT is a two-phase consensus mechanism that separates validation eligibility from reward magnitude. Phase one applies tier-based eligibility filtering: a validator may validate only those transactions whose transfer amount does not exceed the validator's staked balance. Phase two applies VRF-based committee selection from the eligible pool, requiring a supermajority for confirmation.

Tier Classification

Tier	Name	Min Stake	Reward Mult.	Attack Cost (67%)
T1	Mega	10,000 KNEX	10.0x	201,000 KNEX
T2	Large	1,000 KNEX	5.0x	20,100 KNEX
T3	Standard	100 KNEX	2.0x	2,010 KNEX
T4	Small	10 KNEX	1.0x	201 KNEX
T5	Micro	1 KNEX	0.5x	20.1 KNEX

Amount-Ceiling Validation Rule

The defining characteristic of SPVT is the amount-ceiling constraint: a validator is eligible for a transaction only if its stake meets or exceeds the transaction amount.

VRF Committee Selection

When the eligible pool exceeds the committee cap, a Fisher-Yates shuffle seeded with the block hash selects a bounded committee.

Supermajority Threshold

Attack Cost Analysis

Voting Power Ramp

New validators undergo a linear voting power ramp to prevent sudden large-stake entries from immediately dominating consensus.

Design Principle

PoB decouples reward magnitude from stake concentration. Stake determines WHETHER a validator may participate (Sybil resistance via SPVT). Bandwidth determines HOW MUCH the validator earns. This breaks the positive feedback loop present in traditional PoS systems where the wealthiest validators earn the most rewards.

Challenge-Response Lifecycle

The PoB lifecycle proceeds in seven stages per epoch:

Stage	Name	Description
1	Epoch Tick	Challenge generation triggered every EPOCH_DURATION seconds
2	Challenge	1 MB data transfer challenge issued to validator
3	ACK	Validator acknowledges within ACK_TIMEOUT (30s)
4	Data Transfer	Validator completes transfer within DATA_TIMEOUT (120s)
5	Attestation	K VRF-selected observers measure bandwidth, sign attestations (0-100 confidence)
6	Proof Assembly	Validator assembles BandwidthProof with ceil(K/2) attestations
7	Reward Mint	Bandwidth block submitted to ledger; validator credited reward

Challenge Parameters

Observer Selection

Reward Formula

Where:

• EPOCH_RELEASE_BASE = 513.6986... KNEX (Eq. 8)
• tier_multiplier(v) = reward multiplier for validator v's tier (0.5x to 10.0x)
• NAI_damping = current Network Activity Index dampening factor (0.25 to 3.0)
• N_active = total validators who submitted valid bandwidth proofs in the epoch

Damped Epoch Release

Anti-Spoofing Validation Pipeline

Every bandwidth proof passes through a 6-step validation pipeline before the validator receives an epoch reward. These checks are enforced at the ledger level and cannot be bypassed by any network participant.

Step	Check	Threshold
1	VDF output verification	min 2,000ms duration, timestamp sanity (end > start, within 30s skew)
2	Attestation count	≥ ceil(K/2) = 4 attestations required
3	Calculated variance	≤ 10% (tightened from 20%)
4	Attestor variance	≤ 15% per attestation (tightened from 30%)
5	Confidence thresholds	Average ≥ 65, per-attestation floor ≥ 50
6	Statistical anomaly detection	Anomaly score ≤ 0.8 (checks historical patterns)

Independent Observer Verification

Observers independently estimate the target validator’s bandwidth using latency data from the peer registry, rather than blindly trusting the challenger’s self-reported measurement. Confidence is assigned dynamically based on the divergence between the observer’s estimate and the challenger’s claim:

Divergence	Confidence Range	Action
≤ 15%	85–95	Attest with high confidence
≤ 30%	60–75	Attest with moderate confidence
≤ 50%	40–55	Attest with low confidence
> 50%	0	Refuse to attest

Statistical Anomaly Detection

The protocol maintains a measurement history per validator (stored in CF_BANDWIDTH_HISTORY). After 5+ measurements, each new proof is checked against 4 anomaly detection rules:

Rule	Detection	Indicator
1	Impossibly consistent	Coefficient of variation < 0.02 across 10+ measurements
2	Sudden jumps	New measurement > 3× historical median
3	Perfect round numbers	Identical bandwidth values reported repeatedly
4	Temporal regularity	Suspiciously uniform time intervals between proofs

Each rule contributes a weighted score. If the composite anomaly score exceeds 0.8, the proof is rejected. If it exceeds 0.9, an automated slashing event is triggered via BlockType::SlashingEvidence.

Purpose

The NAI implements counter-cyclical emission dampening: during high network activity (indicating strong demand), emission is slowed to conserve the reserve. During low activity, emission is accelerated to incentivize participation. This produces automatic economic stabilization without manual intervention.

Component Metrics

Weight	Metric	Value	Description
w_tx	Transaction Volume	0.40 (40%)	Total send/receive blocks per epoch
w_aa	Active Accounts	0.20 (20%)	Unique transacting accounts per epoch
w_vc	Validator Count	0.10 (10%)	Active registered validators
w_dx	DEX Volume	0.30 (30%)	D-prefix account transactions per epoch

Composite Score Computation

Each metric is normalized against its rolling average over the observation window:

Dampening Factor Mapping

The NAI score is mapped to a dampening factor within bounded limits. The mapping is inverse: high NAI score (high activity) produces low dampening (slow emission), and low NAI score (low activity) produces high dampening (accelerated emission).

Horizon Protection

The horizon protection mechanism prevents sustained high dampening from exhausting the reserve ahead of schedule.

Bootstrap Period

Fixed-Point Arithmetic

NAI damping is stored as fixed-point integers to avoid floating-point determinism issues:

Hash Functions

Algorithm	Usage	Output
Blake2b-256	Block hashing, ledger integrity	256 bits
SHA-256	Address checksums, PWA compatibility, block hash for signing	256 bits
SHA3-256	P2P operations, attestation hashing, proof-of-work	256 bits

Ed25519 Classical Signatures

ML-DSA-65 Post-Quantum Signatures (FIPS 204)

ML-DSA-65 (Module-Lattice Digital Signature Algorithm, security level 3) provides resistance against both classical and quantum computer attacks. Accounts bind a PQ key via the PqBind block type without migrating funds or altering existing history.

Hybrid Security Model

All on-chain blocks use Ed25519 for compact signatures. Accounts may optionally bind ML-DSA-65 keys for future dual-signature verification.

Address Format

Amount-Based Threshold Design

The protocol enforces multisignature requirements based on transaction amount. Transactions below a configurable threshold require only the account owner's signature. Transactions at or above the threshold require M-of-N cosignatures from designated cosigners.

Policy Parameters

Parameter	Constraint
N (cosigners)	1 to 7 Ed25519 public keys
M (threshold)	1 <= M <= N
amount_threshold	> 0 raw units
Duplicates	Rejected at setup

MultisigSetup Memo Payload

Transport-Only Cosignature Architecture

Cosignature Verification

Asynchronous Coordination

The coordination API enables:

1. Owner submits a proposed send block
2. Each cosigner independently verifies and signs
3. Upon reaching threshold M, the system automatically attaches cosignatures and submits the block
4. WebSocket notifications inform all parties of progress

Cumulative Voucher Model

Streaming payments enable continuous value transfer using off-chain cumulative vouchers with periodic on-chain settlement. Each voucher represents the total amount owed from session start, not an incremental amount. Only the most recent voucher matters, eliminating ordering dependencies.

Session Lifecycle

Phase	Description
StreamOpen (0x04)	Lock funds from sender, establish rate and expiration
Off-chain vouchers	Sender generates signed cumulative vouchers
StreamSettle (0x05)	Recipient settles latest voucher on-chain
StreamClose (0x06)	Final settlement, reclaim remaining locked funds

Accrual Computation

Settlement Constraints

Voucher Signature

Token-Specific Rules

Currency	Streaming Policy
UMX (elastic bearer)	Permitted for retail streaming
KNEX (base settlement)	Restricted to protocol-level operations only
Protocol streams	Validator rewards, treasury vesting

Supply Policies

The protocol supports two token supply policies: Fixed (1:1 share-to-balance) and Elastic (share-based accounting with rebase capability).

Fixed Supply Tokens

Elastic Supply Tokens

Multisig-Controlled Rebase

A MultiSigPolicy controller (M-of-N Ed25519 signers) authorizes all supply changes for elastic tokens, preventing unilateral supply manipulation.

Token ID Ranges

ID Range	Category	Policy	Examples
1-100	Reserved stablecoins	Fixed	USDX, EURX, GBPX, COPX, JPYX, CNYX, BRLX, MXNX, INRX, KRWX
101-1000	Custom tokens	Fixed	User-created tokens
1001-2000	Elastic bearer instruments	Elastic	UMX (Lumero) at ID 1001

KNEX: Base Settlement Unit

KNEX is the protocol settlement and accounting unit with an immutable fixed supply. KNEX is used for staking, validator rewards, consensus participation, and protocol governance. KNEX never supports negative balances, overdraft, or credit extension of any kind.

UMX (Lumero): Elastic Network Utility Token

UMX (Lumero, token ID 1001) operates as an elastic bearer instrument with share-based accounting. The UMX supply can expand or contract via authorized rebase operations without modifying individual account balances. UMX is used for retail streaming payments, everyday interaction within the ecosystem, and credit extension.

Risk Isolation

The dual-currency architecture enforces a strict risk isolation boundary between layers:

Collateral-Backed Overdraft

Users who have staked KNEX may overdraw their UMX balance up to a configurable percentage of their staked KNEX value. This creates a credit line collateralized by locked stake.

Credit Score

Event	Score Adjustment
On-time repayment	+15
Late payment	-30
Default	-100

Credit Tiers

Tier	Score Range	Overdraft Multiplier
Excellent	800-1000	1.20x - 1.50x
Good	650-799	0.90x - 1.19x
Fair	400-649	0.50x - 0.89x
Poor	200-399	0.10x - 0.49x
Bad	0-199	0.00x (no credit)

Overdraft Calculation Example

A user with 1,000 KNEX staked and a credit score of 850 (Excellent, 1.3x multiplier):

Default and Collateral Seizure

If a user fails to repay within the window, the protocol seizes the proportional KNEX collateral from their staked balance. The credit score is adjusted by -100, and the credit line is recalculated with the reduced score and reduced stake.

Risk Constraints

• Credit extension is available ONLY for elastic bearer instruments (UMX)
• KNEX never supports negative balances or overdraft
• Minimum stake required: 1 KNEX
• Maximum overdraft: determined by tier multiplier applied to base percentage
• Credit score is owner-disclosed and private by default
• Interest rate: zero (time-limited repayment only)

16.1 Overview

DATE (Debt Amortized Time-Bound Extinguishment) is a transparent accounting architecture that converts incoming fiat capital into the acquisition, amortization, and permanent extinguishment of sovereign and consumer debt through deterministic, time-bound processes. DATE does not eliminate debt by declaration. It acquires debt instruments at market prices and retires them through structured lifecycle management.

16.2 Core Principles

• Forward-only accounting — no reversals, no retroactive modifications to lifecycle records
• Timestamped lifecycle — every debt unit carries immutable timestamps for each stage
• Deterministic allocation — capital is distributed according to rule-based policy, not discretionary decisions
• Transparent tracking — all face-value retirements, multipliers, and interest savings are publicly auditable
• No guaranteed outcomes — system performance depends entirely on market conditions, debt availability, and regulatory environment

16.3 System Flow

Each unit of absorbed capital follows a four-stage lifecycle. Every stage is permanently recorded.

The lifecycle is linear and irreversible. Once a debt instrument reaches T_exp, the corresponding face value is permanently retired from the economic system.

16.4 Absorption Units

Every fiat deposit creates an Absorption Unit (AU) equal to the deposited amount. Each AU is allocated according to the system’s governance-configurable allocation policy.

16.5 Allocation Policy

Absorbed capital is distributed across three debt categories according to a rule-based allocation. These percentages are governance-configurable via CORE (minimum T2 Amendment, threshold 0.70).

Category	Default Allocation	Description
Sovereign Debt	50%	Government treasury instruments purchased at market price
Distressed Consumer Debt	40%	Consumer debt portfolios acquired at market discount (typically 2–20% of face value)
Medical / Social Relief	10%	Medical debt and social relief obligations targeted for retirement

16.6 Debt Acquisition Economics

Sovereign debt is purchased at market price. The face value retired equals the purchase amount divided by the bond’s market price.

Distressed consumer debt trades at deep discounts, typically 2–20% of face value. This is the primary multiplier effect of the DATE system.

16.7 Extinguishment Multiplier

The Extinguishment Multiplier (M) measures the ratio of face value retired to fiat absorbed. This is the core efficiency metric of the DATE system.

Asset Type	Typical M Range
Sovereign Treasuries	1.0 – 1.1
Investment-Grade Debt	1.1 – 1.5
Distressed Consumer Debt	5 – 50

16.8 Time-Bound Amortization

Each acquired asset enters a deterministic lifecycle based on its type:

• Sovereign debt — held to maturity or retired early at market value
• Consumer debt — immediate forgiveness, restructured low-interest repayment, or time-bound settlement (where legally permitted)

Each lifecycle record includes: acquisition timestamp (T₁), amortization duration, and extinguishment timestamp (T_exp). All records are immutable once created.

16.9 Public Metrics

DATE operates on a principle of radical transparency. The following metrics are tracked and publicly auditable:

• Total fiat absorbed (cumulative AU)
• Total face value extinguished
• System-wide extinguishment multiplier (M_total)
• Total interest avoided
• Sovereign vs. consumer vs. social breakdown
• Average time to extinguishment

Transparency replaces promises. System performance is measured by observed outcomes, not projections.

16.10 Risk Factors

Dual Transport

Protocol	Default Port	Purpose
QUIC (RFC 9000)	7077/UDP	Primary P2P with TLS 1.3 and PQ key exchange
TCP/TLS 1.3	7078/TCP	Fallback when UDP is blocked

Post-Quantum Key Exchange

Wire Protocol

All P2P messages are serialized using bincode for compact binary encoding.

Byte Range	Category	Description
0x01-0x02	Handshake	Protocol version, node identity
0x10-0x13	Block Propagation	Publish, request, batch blocks
0x20-0x25	Frontier Sync	Account state, pending receivables
0x30-0x31	Peer Exchange (PEX)	Decentralized discovery (max 100 peers/response)
0x40-0x41	Voting	Consensus attestation propagation
0x60-0x65	Bandwidth Challenges	PoB lifecycle messages
0x70-0x72	Validator Sync	Registry announcements, bulk sync
0xF0-0xF1	Diagnostics	Connection health probes

Network Parameters

DDoS Defense

Staking Mechanics

A Stake block transfers funds from available balance to a locked stake entry. An account may stake to multiple validators simultaneously. Staked funds cannot be transferred until unstaked and the unbonding period completes.

Operator Key Delegation

Validators may delegate an operator key (hot key) for PoB signing while keeping the staking key (cold key) offline. The operator key cannot move funds or modify stake.

Slashing Schedule

Violation	Slash %	Cooldown	Ban
Double voting	100%	Permanent	Yes
Bandwidth spoofing	100%	Permanent	Yes
Attestation collusion	75%	90 days	No
Attestation fraud	50%	30 days	No
Extended downtime (>48h)	5%/week	Continuous	No
Stale proofs	0%	N/A	Reputation only

Zero-Burn Redistribution

Cumulative Downtime Slashing

On-Chain Slashing Evidence

BlockType::SlashingEvidence (byte 0x16) provides an immutable on-chain record of slashing events. Only active, non-banned validators may submit evidence blocks. The evidence payload is a structured memo envelope (TYPE_SLASHING_EVIDENCE, 0x11) containing the violation type and target validator public key.

Evidence blocks do not transfer funds — they serve as audit records. The actual stake slash and redistribution is executed by the existing execute_slash() machinery, which calculates proportional penalties and redistributes 100% of slashed funds to honest validators.

Automated Slashing Triggers

Three conditions trigger automated slashing without manual intervention. Pending slashes are queued and processed at each epoch tick:

Trigger	Condition	Mapped Violation	Slash %
Anomaly Detection	Statistical anomaly score > 0.9	BandwidthSpoofing	100%
Observer Divergence	Collective observer estimate < 50% of claim	BandwidthSpoofing	100%
Repeated Proof Failure	3+ consecutive proof rejections	AttestationFraud	50%

Each automated trigger creates a SlashingEvidence block on-chain, providing a permanent audit trail. The penalty is executed immediately via the standard slashing pipeline.

Supply Conservation

Double-Process Prevention

Each block hash is stored upon successful processing. Resubmission of a previously processed block is rejected. Fork detection (two blocks with the same previous link) is enforced at the account chain level.

Genesis Protection

Rate Limiting

Layer	Limit
API writes	20 requests/min per IP
API reads	100 requests/min per IP
P2P connections	10 connections/min per IP
P2P handshakes	20 concurrent global cap
Auto-ban	3 violations = 5-minute ban

Key Security

• Private keys never printed to stdout
• Sensitive memory zeroized on exit (zeroize crate)
• Key files auto-set to 0600 permissions (owner-only)
• Terminal and scrollback cleared after key generation

Network Security

CORS restrictions limit API access to allowlisted origins. Cloudflare-aware rate limiting inspects CF-Connecting-IP and X-Forwarded-For headers. Admin endpoints are restricted to localhost access only.

Threat Matrix

Scenario	What Happens	Detection	Protocol Response	Residual Risk
Whale Stake Capture	Single entity accumulates >50% of staked KNEX, gaining disproportionate validation weight	Stake concentration drift metric in CORE readiness scoring (Security domain)	SPVT caps validation eligibility proportional to transaction value, not total stake. PoB rewards are bandwidth-proportional, not stake-proportional. VRF committee selection caps at 30 validators.	A whale can validate high-value transactions but cannot monopolize rewards or censor low-value traffic
Validator Cartel / Censorship	Coordinated validators refuse to validate specific transactions or accounts	Participation entropy metric detects voting pattern uniformity; NAI active account anomalies	VRF-selected committees rotate per epoch. Censoring validators lose PoB rewards for non-participation. Extended non-validation triggers downtime slashing (5% per week).	Temporary censorship possible within a single epoch; sustained censorship is economically irrational
PoB Gaming / Fake Bandwidth	Validator fabricates bandwidth measurements to inflate rewards	6-step validation pipeline: VDF floor (2s min), tightened variance (10%/15%), confidence floors (65 avg, 50 per-attestation), independent observer bandwidth estimation via latency analysis, statistical anomaly detection (4 rules across measurement history)	Observers independently estimate bandwidth — divergence >50% results in attestation refusal. Anomaly score >0.9 triggers automated SlashingEvidence block. Bandwidth spoofing = 100% slash + permanent ban. All slashed funds redistributed to honest validators.	Collusion of 4+ observer nodes in a single epoch; mitigated by VRF rotation and independent bandwidth estimation
NAI Manipulation	Artificial inflation of network activity metrics (wash trading, fake accounts) to manipulate emission dampening	NAI uses a 90-day rolling window with four weighted metrics; short-term spikes are diluted. DEX volume (30% weight) tracked via D-account prefix.	Feeless transactions make wash trading cheap but PoW anti-spam adds computational cost per transaction. Dampening bounds (0.25×–3.0×) cap manipulation impact. Horizon protection prevents reserve acceleration.	Sustained manipulation over 90+ days is theoretically possible but economically costly with limited payoff due to dampening bounds
Governance Deadlock	No proposals reach activation threshold; protocol evolution stalls	Governance participation rate and vote polarization metrics in CORE readiness scoring	Time-bounded activation windows automatically expire stalled proposals. Lower tiers (T1 Path, threshold 0.60) remain accessible for routine changes. SAFE_MODE allows Path-level fixes during instability.	High-tier (T3/T4) changes may be delayed indefinitely if consensus cannot be reached; this is by design
SAFE_MODE Abuse	Attacker intentionally destabilizes network to trigger SAFE_MODE, freezing governance to block legitimate proposals	SAFE_MODE triggers are objective (block production drop, fork rate >5%, invalid blocks >2%, slashing spike ≥10, churn >15%)	SAFE_MODE preserves Path-level governance (T1), so corrective proposals can still activate. Destabilization attacks are themselves detectable and result in slashing. Exit requires sustained readiness ≥0.70.	Short-term governance freeze during destabilization; T1 corrective path remains open
Emergency T0 Misuse	Attempt to use emergency powers (T0) for non-emergency protocol changes	T0 is scope-locked to: consensus-critical fixes, denial-of-service mitigation, and critical security vulnerabilities only	Requires dual supermajority (80% validators AND 90% stake). 6–12 epoch voting window. Emergency changes are temporary and must be ratified within 7–30 days via standard governance or they expire.	If 80% of validators and 90% of stake collude for misuse, the network has a systemic trust failure beyond protocol scope
Network Partition	Sustained split of the validator set into disconnected subgroups	Fork rate metric, validator churn detection, latency variance monitoring	Block-lattice architecture is partition-tolerant by design (each account is an independent chain). Consensus falls back to monitor-only mode during partition. TCP fallback activates if QUIC transport fails. SAFE_MODE triggers if fork rate exceeds 5%.	Transactions during partition may lack full consensus confirmation until partition heals
Key Compromise / PQ Migration	Private key exposure or confusion during post-quantum signature upgrade	Anomalous account activity patterns; PQ binding blocks create verifiable upgrade chain	PqBind blocks retroactively bind ML-DSA-65 keys to existing Ed25519 accounts without migration. Compromised classical keys can be superseded by PQ binding. No account history is modified.	If both classical and PQ keys are compromised simultaneously, account is lost; standard cryptographic assumption
Bridge Exploit	Cross-chain bridge vulnerability allows fraudulent minting or asset extraction	Bridge is a planned integration, not a genesis feature. When implemented: on-chain bridge balance tracking, oracle attestation requirements.	Bridge operates as an optional module with no consensus-critical dependencies. Bridge failures cannot affect base-layer KNEX or UMX balances. CORE governance controls bridge activation and parameter changes.	Bridge-specific assets at risk; base protocol isolated by design
Credit System Cascade	Mass UMX defaults trigger cascading collateral seizures, destabilizing the credit market	Credit tiers bound maximum exposure per account. Collateral-to-credit ratios enforced on-chain.	Every credit line is fully collateralized by staked KNEX. Default triggers automated seizure — no contagion to uncollateralized accounts. UMX credit risk is contained within the elastic bearer instrument layer; KNEX base settlement is unaffected.	Mass defaults reduce available credit but cannot create unbacked UMX; system invariant preserved
QORA Treasury Drain	Governance capture targeting treasury pool allocations or disbursement rules	Treasury changes require CORE governance (minimum T2 Amendment, threshold 0.70). Pool allocation changes require active pools to always sum to 10,000 BPS.	Emergency scope-lock explicitly excludes treasury and tax changes from T0 powers. Higher-tier changes (T3/T4) require extended monitoring and multi-epoch stability. All treasury balances and disbursements are on-chain and auditable.	Slow governance capture over multiple tiers theoretically possible but requires sustained supermajority consensus

21.1 Overview

Traditional blockchain governance relies on human coordination, emergency intervention, or implicit social consensus. These mechanisms introduce ambiguity, discretionary power, and operational risk.

KnexCoin replaces discretionary governance with a deterministic system-state model. CORE (Consensus Optimization & Readiness Engine) evaluates network conditions continuously and permits protocol changes only when objective stability criteria are satisfied.

21.2 Activation Guard

A protocol proposal progresses through three stages:

1. Governance approval — stakeholder vote passes the required threshold
2. Pending state — proposal enters the activation queue
3. Readiness evaluation — CORE monitors system conditions continuously

Activation occurs only when:

• Readiness score ≥ tier threshold
• Stability maintained continuously for the required window
• Activation window has not expired

If stability drops below threshold at any time, the stability timer resets.

If the readiness window completes successfully, the proposal activates. If the activation window expires before sustained readiness is achieved, the proposal is discarded and may be resubmitted through governance.

21.3 Four-Tier Constitutional Model

Tier	Type	Threshold	Stability Window	Expiration
T1	Path	0.60	72 epochs	3–7 days
T2	Amendment	0.70	720 epochs	30 days
T3	Protocol	0.85	2160 epochs	90 days
T4	Constitutional	0.95	4320 epochs	180–365 days

Higher tiers require longer sustained stability and represent increasingly structural changes to the protocol. Proposals that cannot achieve sustained readiness within their expiration window are automatically discarded and must be resubmitted through governance. This creates predictable risk, eliminates zombie proposals, and enforces natural governance selection.

21.4 Readiness Domains

CORE computes a composite readiness score readiness_score ∈ [0,1] from four system domains:

Network Stability

• Validator churn rate
• Latency variance across peers
• Fork rate
• PoB success distribution

Economic Stability

• Network Activity Index (NAI) behavior
• Velocity stability
• Liquidity dispersion

Security Integrity

• Slashing anomalies
• Stake concentration shifts
• Attack indicators

Governance Participation Quality

• Participation entropy
• Vote distribution variance

The final readiness score is a weighted composite of these domains. An entropy root derived from recent blocks is included in the computation to prevent prediction or manipulation of the readiness score.

21.5 SAFE_MODE

When system instability exceeds defined thresholds, the network enters SAFE_MODE.

In SAFE_MODE:

• No new Protocol (T3) or Constitutional (T4) proposals may be submitted
• Only Path-level (T1) fixes are permitted
• Economic dampening mechanisms are activated

SAFE_MODE exits only after a sustained stability window is restored.

Emergency voting (T0) may be restricted to activation only when SAFE_MODE is triggered by specific observable conditions:

• Block production halt
• Critical fork divergence
• Invalid block acceptance
• Consensus failure
• Severe slashing anomaly

This gating is a governance-configurable parameter that keeps emergency powers rule-based.

21.6 Emergency Security (T0)

Critical security conditions may require immediate intervention. Emergency activation requires a dual supermajority:

Validator Count Threshold:

(V_yes / V_total) ≥ 80%

Stake Threshold:

(S_yes / S_total) ≥ 90%

Participation Floors:

• Validators ≥ max(50, 25% of total)
• Stake participation ≥ 50%

Emergency voting window: 6–12 hours. Optional execution delay: 0–30 minutes. If thresholds are not reached within the window, the emergency proposal expires.

Allowed Scope:

• Consensus validation fixes
• Critical bug repair
• Chain halt recovery
• Cryptographic failure response
• DoS / spam mitigation
• Double-spend prevention

Not Allowed (scope-locked):

• Supply or emissions changes
• Treasury or tax changes
• Governance structure changes
• Economic tuning (unless directly required for exploit mitigation)
• CORE threshold changes

21.7 Forward-Only Evolution

CORE enforces a forward-only model. The protocol never:

• Reverts blocks
• Rolls back ledger state
• Rewrites history

If instability occurs after activation:

• Enter SAFE_MODE
• Apply forward stabilization
• Allow Path-level corrective updates

History remains immutable.

21.8 Operational Philosophy

CORE establishes two operating modes:

• Slow Evolution — stability-gated governance for protocol advancement
• Fast Survival — bounded emergency protection for critical threats

21.9 High-Tier Observation (Model C)

For Protocol (T3) and Constitutional (T4) changes:

• Extended monitoring windows
• Shadow observation period
• Multi-epoch sustained stability requirement

Externally this is presented as a sustained readiness requirement.

21.10 Post-Emergency Ratification

All emergency (T0) changes are temporary until ratified through standard governance.

Ratification deadlines:

Severity	Ratification Window
Critical	7–14 days
High	Up to 30 days

If an emergency change is not ratified within its deadline:

• The emergency behavior is disabled
• The system returns to the last ratified rule set
• No ledger rollback occurs — the forward-only constraint is preserved

21.11 On-Chain CORE Envelope

Every CORE decision is recorded on-chain in a deterministic envelope format that all nodes independently verify:

CORE|v1|
  tier=<T0–T4>|
  proposal=<hash>|
  epoch=<n>|
  score=<float>|
  threshold=<float>|
  validators_yes=<count>|
  stake_yes=<amount>|
  v_ratio=<float>|
  s_ratio=<float>|
  safe_mode=<bool>|
  result=<ALLOW|DEFER|EXPIRE>|
  context_hash=<entropy_root>

The envelope includes all inputs to the CORE decision function. Any node can recompute the result from the same inputs, ensuring full determinism and auditability. The context_hash anchors the computation to the entropy state of recent blocks, preventing replay or prediction attacks.

21.12 Failure Scenario Safeguards

Attack Vector	Mitigation
Whale control	Validator count threshold
Sybil control	Stake threshold
Governance deadlock	Expiration windows
Activation gaming	Stability reset on drop
Emergency abuse	Scope lock + ratification
Hidden control risk	Full determinism

21.13 Emergent Decision Intelligence

CORE decisions depend on:

• Rolling stability windows derived from live network state
• Multi-epoch confirmation across independent time boundaries
• Entropy sourced from recent system state

Because network conditions cannot be forced or reliably predicted, protocol changes that successfully pass through CORE appear aligned with future system stability. This is emergent behavior — not prediction.

21.14 Final Governance Law

Protocol changes activate only when:

readiness ≥ threshold
AND stability maintained for required time
AND activation window not expired

Emergency changes activate only when:

dual supermajority achieved
AND scope constraints satisfied

22.1 Overview

QORA (Quadratic Open Readiness Architecture) is the protocol-level micro-taxation system that funds public goods infrastructure. Every UMX (Lumero, Ł) commerce transaction above the minimum threshold contributes a small percentage to a transparent treasury. These funds are distributed across seven public goods pools that collectively serve the network and its participants.

QORA is not optional for individual transactions. It is a protocol invariant: commerce funds infrastructure. The tax rate is governance-configurable but CORE-protected — emergency actions cannot modify treasury parameters or tax rates (Section 21.6).

22.2 Commerce Tax

Only elastic bearer tokens are taxed. KNEX is never subject to QORA taxation. Tax is deducted at source during UMX sends and NFC card spends. The net amount received by the recipient is amount − tax.

22.3 Public Goods Pools

Tax revenue is distributed proportionally across seven public goods pools. Active pool allocations must sum to exactly 10,000 BPS (100%).

Pool	Name	Allocation	BPS
1	Medical	20.0%	2,000
2	Education	16.0%	1,600
3	Public Safety	12.0%	1,200
4	Infrastructure	12.0%	1,200
5	Digital Commons	8.0%	800
6	Community	13.0%	1,300
7	Maturity Fund	19.0%	1,900
	Total	100.0%	10,000

22.4 Universal Maturity Fund

The Maturity Fund receives 19% of all QORA tax revenue — the single largest pool. It implements a universal trust fund: every child registered on the network receives one share of the pool, claimable at maturity.

Birth registration requires a 3-of-5 oracle threshold attestation (Ed25519) verifying both a birth certificate and a DNA commitment. The DNA commitment is a double hash that ensures biological uniqueness without exposing genetic data:

Registration must occur within 1 year of birth. Duplicate registrations (same DNA commitment) are rejected. Each registration is assigned a monotonically increasing share index.

22.5 Maturity Claims

Registered individuals claim their share in two tranches:

Tranche	Age	Share	BPS
1	21 years	60%	6,000
2	40 years	40%	4,000

Each claim requires oracle re-attestation of the DNA commitment (3-of-5 threshold). Tranche 2 cannot be claimed before Tranche 1. Revoked registrations (governance action for verified fraud) cannot claim. Once both tranches are claimed, the registration status is finalized.

22.6 Trust Fund Contributions

Anyone may deposit additional Lumero (Ł) to any active registration, increasing that child's eventual payout beyond the per-share pool value.

The 60/40 split applies to bump contributions regardless of when they were deposited. This prevents gaming: contributing immediately before Tranche 2 does not bypass the age-gated distribution. Trust fund contributions are the network's mechanism for voluntary intergenerational wealth transfer.

Adoption Wedges

Wedge	User	Problem	Why KnexCoin	MVP Feature Set
Remittance Corridors	Diaspora workers sending value to family	6–10% transfer fees; 2–5 day settlement; opaque FX rates	Feeless transfers, sub-second finality, streaming payments for recurring sends	Wallet app, send/receive, streaming vouchers
Micro-Merchant POS	Street vendors, small merchants, informal commerce	Card processing fees erode thin margins; cash-only operations create security risk	Feeless NFC card payments, QORA public goods return, Lumero (Ł) denomination familiar to local users	NFC cards, merchant terminal app, QORA treasury visibility
Institutional Settlement	Fintechs, neobanks, payment aggregators	Batch settlement introduces counterparty risk and latency; reconciliation overhead	Streaming payments for continuous settlement, protocol-level multisig, deterministic governance (no discretionary rule changes)	REST/JSON-RPC API, streaming SDK, multisig enforcement

Primary Wedge: Micro-Merchant POS

The initial deployment focus is micro-merchant point-of-sale in Colombia. This selection is based on three factors: (1) DLT’s existing operational presence in Colombia and familiarity with local commerce patterns, (2) the QORA public goods mechanism creates a tangible value return to communities where merchants operate, providing a differentiated narrative versus fee-based payment alternatives, and (3) NFC card provisioning infrastructure is production-ready, enabling physical bearer instrument deployment without requiring smartphone adoption.

The micro-merchant wedge also serves as a validator recruitment pipeline. Merchants who operate NFC terminals have a natural incentive to run validator nodes for PoB rewards, building network decentralization from commerce participation rather than speculative staking.

Deployment Roadmap

Phase	Timeline	Scope	Objective
0	Current (Testnet)	Protocol development, test coverage, security audit preparation	Validate consensus safety, economic invariants, and cryptographic integrity across 1,124 tests
1	Q4 2026 (Pilot)	Mainnet launch, limited merchant pilot in Colombia, NFC card provisioning	Demonstrate feeless POS operation, validate PoB reward economics, measure QORA treasury accumulation
2	2027+ (Scale)	Remittance corridor expansion, institutional API partnerships, streaming settlement rollout	Grow validator set, activate cross-border corridors, enable institutional settlement integrations

Success Metrics

Metric	Phase 1 Target	Phase 2 Target
Active validators	≥20	≥100
Merchant pilots	≥50	≥500
Sustained throughput	≥100 tx/s	≥1,000 tx/s
Avg confirmation	<1 second	<1 second
Streaming sessions	≥10 active	≥1,000 active
QORA revenue generated	Measurable	Sustaining public goods disbursements

These targets are operational milestones, not guarantees. Actual performance depends on network adoption, validator participation, and market conditions.

Why Now

Three structural trends create favorable conditions for protocol adoption. First, cost pressure: global payment processing fees remain between 1.5–3.5% for card transactions and 6–10% for cross-border remittances, creating sustained demand for feeless alternatives. Second, settlement appetite: fintech and neobank growth has accelerated demand for real-time, continuous settlement rather than batch processing, a gap that streaming payments address directly. Third, governance demand: repeated instances of discretionary protocol changes in existing blockchain ecosystems have increased institutional appetite for deterministic, rule-based governance systems where protocol evolution is predictable and stability-gated.

Token Block Type Processing

Block types TokenMint (0x0B), TokenSend (0x0C), and TokenReceive (0x0D) are defined in the protocol but do not yet have ledger processing, database column families, or API endpoints. Implementation will follow the existing Send/Receive pattern adapted for token-specific balances and pending entries.

UMX Credit Ledger Integration

The credit system foundation structures (CreditPolicy, CreditScore, CreditTier, CreditLine) are implemented and tested. Ledger integration allowing negative UMX balances, automated collateral seizure upon default, and repayment processing is planned.

Observability and Telemetry

Phase	Scope
Sprint 1	Structured logging via tracing crate on every ledger, P2P, and API operation
Sprint 2	WebSocket event bus expansion to all protocol events; real-time statistics endpoints
Sprint 3	Separate analytics collector service with time-series storage, anomaly detection, and admin dashboard

Additional Planned Integrations

• Streaming Security Hardening — Voucher forgery/replay, settlement injection, double-settlement prevention, cross-session signature swapping, rate/accrual overflow attacks
• Dishonest Validator Simulation — Fabricated bandwidth attestations, colluding validators, liveness attacks, double voting detection, VRF seed manipulation
• ISO 20022 Compliance Layer — Optional mapping of protocol operations to ISO 20022 message formats for traditional financial infrastructure integration
• Decentralized Exchange (DEX) — D-prefix accounts already tracked by NAI; full on-chain order book planned
• NFC Card Integration — NFC Card memo type (0x08) defined with 7-byte UID and 3-byte counter payload
• Cross-Chain Bridge — Framework for bridging assets between KnexCoin and external distributed ledger networks

Company Classification

Distributed Ledger Technologies (DLT) is a software and distributed network infrastructure company. DLT develops distributed ledger technology, blockchain and DAG-based systems, network infrastructure for digital value transfer, and non-custodial software tools and protocols.

Non-Custodial Architecture

DLT does not custody, manage, or control user funds. All systems are designed so that users maintain control of their private keys. The company cannot access or transfer user assets. No pooled customer funds exist. No accounts are held on behalf of users. DLT operates solely as a software and infrastructure provider.

Digital Asset Classification

No Financial Services

DLT does not provide:

• Banking services
• Payment processing on behalf of users
• Money transmission or remittance services
• Custody of digital assets
• Investment products or portfolio management
• Financial advisory services
• Lending or borrowing services

Risk Disclosure

Jurisdiction

DLT currently focuses operations in Colombia. Certain services or distributions may not be available in specific jurisdictions. DLT does not target or solicit users in jurisdictions where digital asset activities may require regulatory authorization. Users are responsible for ensuring compliance with local laws.

Current Status

The protocol is in development and pre-mainnet phase. Testnet is operational at testnet-api.knexcoins.com. Current operations focus on technology development and infrastructure preparation.

Frequently Asked Questions

1. What is KnexCoin?

KnexCoin is an open-source distributed ledger protocol built on a block-lattice DAG architecture. It is software infrastructure for feeless digital value transfer with deterministic governance. It is not a company, a bank, or an investment product.

2. Is KNEX a cryptocurrency or investment?

KNEX is a protocol settlement and accounting unit — a functional component of the software enabling interaction with the distributed network. It does not represent equity, ownership, a security, or a claim on company assets. No guarantees of value are provided.

3. How are transactions free?

Each transaction includes a minimal computational proof-of-work that serves as anti-spam protection. There are no transaction fees. Validators are compensated through protocol-level Proof-of-Bandwidth (PoB) rewards funded by the emission schedule, not by user fees.

4. What is the difference between KNEX and UMX?

KNEX is a fixed-supply (100M) base settlement unit used for staking, governance, and validator rewards. UMX (Lumero, Ł) is an elastic bearer instrument designed for daily commerce, retail transactions, and credit extension. They serve complementary roles: KNEX provides settlement stability, UMX provides elastic utility.

5. What is the NAI and why does it matter?

The Network Activity Index (NAI) is a counter-cyclical emission dampening system. When network activity is high, it reduces token emission to conserve reserves. When activity is low, it increases emission to incentivize participation. This prevents pro-cyclical inflation and protects the reserve depletion horizon (minimum 15 years).

6. How does staking work?

Validators stake KNEX to participate in consensus. Five tiers exist based on stake magnitude (1 KNEX minimum to 10,000+ KNEX). Staking determines validation eligibility and reward multipliers but does not determine reward magnitude directly — that is governed by demonstrated bandwidth (PoB). The unbonding period is 21 days.

7. What is Proof-of-Bandwidth?

Proof-of-Bandwidth (PoB) measures demonstrated network capacity through periodic challenges. Validators prove bandwidth via data transfer tests attested by a quorum of observer nodes (4-of-7 minimum). Observers independently estimate target bandwidth using latency analysis rather than trusting the challenger’s claim. A 6-step anti-spoofing validation pipeline enforces VDF duration floors, tightened variance thresholds, confidence floors, and statistical anomaly detection. Rewards are proportional to measured bandwidth, not staked collateral, breaking the positive feedback loop of traditional stake-proportional reward systems.

8. Is KnexCoin quantum-resistant?

The protocol implements hybrid classical (Ed25519) and post-quantum (ML-DSA-65, FIPS 204) cryptographic signatures. Post-quantum keys are used for P2P node identity and can be retroactively bound to existing accounts without migration. This provides forward security against advances in quantum computation.

9. What happens if validators collude?

The protocol detects collusion through attestation analysis and bandwidth verification quorums. Double voting results in 100% stake slash and permanent ban. Attestation collusion triggers a 75% slash with 90-day cooldown. Slashed funds are redistributed to honest validators — no funds are burned.

10. Can the governance system be captured?

CORE (Consensus Optimization & Readiness Engine) uses a four-tier constitutional model with escalating thresholds (0.60 to 0.95). Higher-tier changes require extended monitoring windows and multi-epoch sustained stability. Emergency powers (T0) require dual supermajority (80% validators AND 90% stake) and are scope-locked to consensus-critical fixes only. SAFE_MODE freezes high-tier changes during instability.

11. What is SAFE_MODE?

SAFE_MODE is an automatic system stabilization protocol triggered by network instability indicators (block production drops, fork rate spikes, slashing anomalies). It freezes all governance changes above Path-level (T1), applies economic dampening, and allows only forward-corrective updates until stability metrics recover.

12. What is DATE?

DATE (Debt Amortized Time-Bound Extinguishment) is a transparent accounting architecture for acquiring and permanently retiring debt instruments through deterministic, time-bound processes. It converts fiat capital into the purchase of sovereign and distressed consumer debt at market prices. Performance depends entirely on market conditions — no specific outcomes are guaranteed.

13. How does the credit system work?

The UMX credit system provides collateral-backed overdraft facilities. Credit lines are fully collateralized by staked KNEX, bounded by configurable credit tiers. Default triggers automated collateral seizure. This is not fractional reserve banking — every credit extension is backed by locked collateral.

14. What is QORA?

QORA (Quadratic Open Readiness Architecture) is the protocol-level micro-taxation system. A 0.50% tax on UMX (Lumero, Ł) commerce funds seven public goods pools including medical, education, public safety, infrastructure, digital commons, community programs, and a Universal Maturity Fund. Pool allocations are governance-configurable and tracked on-chain.

15. Where can I use KnexCoin?

The protocol is currently in testnet phase with mainnet targeted for September 2026. Initial operations focus on Colombia. DLT does not target or solicit users in jurisdictions where digital asset activities may require regulatory authorization. Users are responsible for compliance with local laws.

Glossary

Term	Definition
AU	Absorption Unit. A unit representing fiat capital deposited into the DATE system, equal to the deposited amount.
Block-Lattice	A DAG architecture where each account maintains its own blockchain. Transactions are asynchronous two-phase operations (send on source chain, receive on destination chain).
BPS	Basis Points. 10,000 BPS = 100%. Used for tax rates, pool allocations, and tranche splits throughout the protocol.
CORE	Consensus Optimization & Readiness Engine. The deterministic governance system that gates protocol changes behind stability-verified readiness thresholds.
Cosignature	A transport-only multisignature that does not modify block hash computation, enabling protocol-level multisig compatible with lightweight clients.
DAG	Directed Acyclic Graph. The underlying data structure of the block-lattice, allowing parallel transaction processing without global ordering.
DATE	Debt Amortized Time-Bound Extinguishment. A transparent accounting architecture for acquiring and permanently retiring debt instruments through deterministic processes.
Dampening Factor	The NAI-derived multiplier (0.25× to 3.0×) applied to base emission rates. Values below 1.0 reduce emission; values above 1.0 increase it.
DLT	Distributed Ledger Technologies. The software and infrastructure company developing the KnexCoin protocol. Not to be confused with the generic term “distributed ledger technology.”
Ed25519	The classical elliptic-curve digital signature algorithm used for on-chain account signatures (32-byte public key, 64-byte signature).
Elastic Bearer Instrument	A token whose supply adjusts through share-based rebase mechanics. UMX (Token ID 1001–2000 range) is the protocol’s elastic bearer instrument.
Epoch	A time window of 3,600 seconds (1 hour) used for PoB challenge scheduling, NAI calculation, and governance evaluation windows.
Extinguishment Multiplier (M)	The ratio of face value retired to fiat absorbed. M = Face_value_retired / Fiat_absorbed. Ranges vary by asset type and market conditions.
Horizon Protection	An NAI safeguard that caps the dampening factor at 1.0× if projected reserve depletion falls below 15 years, preventing accelerated emission.
KNEX	The fixed-supply (100M) base settlement unit of the protocol. Used for staking, governance participation, and validator reward denomination.
Lumero (Ł)	The display name and symbol for UMX. 1 Ł = 100,000,000 lumi (raw units). Token ID 1001. The elastic bearer instrument for daily commerce.
ML-DSA-65	Module-Lattice Digital Signature Algorithm (FIPS 204). The post-quantum signature scheme used for P2P node identity (1,952-byte public key).
NAI	Network Activity Index. A composite metric of network health (tx volume 40%, active accounts 20%, validator count 10%, DEX volume 30%) used for counter-cyclical emission dampening.
NFC	Near Field Communication. Physical card-based bearer instruments using NTAG 424 DNA chips with AES-128 encryption and MPC threshold verification.
PoB	Proof-of-Bandwidth. A reward distribution mechanism measuring demonstrated network capacity through periodic challenges attested by observer quorums.
QORA	Quadratic Open Readiness Architecture. The protocol-level 0.50% micro-tax on UMX commerce funding seven public goods treasury pools.
Raw Units	The smallest indivisible unit of a token. For UMX: 1 Ł = 100,000,000 raw units (8 decimal places). For KNEX: 1 KNEX = 100,000,000 raw units.
SAFE_MODE	An automatic stabilization protocol freezing high-tier governance changes during network instability. Allows only Path-level (T1) corrective updates.
SPVT	Stake-Proportional Validation Tiers. A five-tier consensus mechanism where validation eligibility is gated by validator stake relative to transaction value.
Streaming Payment	Off-chain cumulative voucher settlement allowing continuous value streams. Settled on-chain periodically via StreamOpen, StreamSettle, and StreamClose blocks.
T0–T4	CORE governance tiers. T0: Emergency (dual supermajority). T1: Path (0.60). T2: Amendment (0.70). T3: Protocol (0.85). T4: Constitutional (0.95).
UMX	The elastic bearer instrument for daily commerce and retail utility. Also known as Lumero (Ł). Token ID 1001. Supports credit extension, QORA taxation, and NFC card provisioning.
Unbonding Period	The 21-day waiting period after a validator initiates unstaking before staked KNEX becomes transferable.
VRF	Verifiable Random Function. Used for deterministic, unpredictable selection of PoB challengers and validation committees (capped at 30 validators).