CONTEXT Whitepaper

1. Abstract

CONTEXT is an open decentralized P2P messaging network built on top of the libp2p protocol using Ed25519 cryptography and Noise Protocol transport encryption. The system eliminates the single point of failure of traditional messengers: messages are replicated across a network of independent relay nodes, whose operation is incentivized by the native CTX token.

Key properties of the system:

• No central server: all participants are equal; there is no infrastructure owner
• Cryptographic identity: PeerID = hash of Ed25519 public key
• E2E-compatible: payload is transmitted encrypted at the application layer
• Economic incentives: relay operators receive CTX rewards proportional to uptime
• Censorship resistance: Tor transport, Circuit Relay v2, DHT-discovery without central DNS
• Blockchain verifiability: every message is registered on-chain (without payload)

---

2. Introduction & Motivation

2.1 The Problem of Centralized Messengers

Modern communication platforms (Telegram, WhatsApp, Signal) store metadata and/or message content on the company's servers. This creates systemic risks:

2.2 Limitations of Existing Decentralized Solutions

Existing decentralized solutions (Matrix, Session, Briar) have their own trade-offs:

• Matrix: federated, but not P2P; the homeserver stores all data
• Session: onion network with high latency; complex UX
• Briar: works without internet via Bluetooth, but limited in scalability
• XMPP: decentralized, but the federated model reproduces server trust

2.3 The CONTEXT Approach

CONTEXT uses a relay architecture: specialized nodes (relays) accept messages from clients, temporarily store them, and replicate among themselves. Relays are not "servers" in the traditional sense — anyone can run their own node, and the network economy motivates operators toward honest behavior through staking and slashing mechanisms.

Client A → Relay-1 ↔ Relay-2 ↔ Relay-3 → Client B
                 ↕ DHT Discovery ↕
               (Kademlia / mDNS)

---

3. System Architecture

3.1 Network Topology

The CONTEXT network consists of three types of nodes:

Key topology constraints:

• Client ↔ Client: direct connection forbidden — all traffic goes through relays
• Client connects simultaneously to 1–3 relay nodes
• Client pool must contain at least 1 public relay

3.2 Relay Node Multi-Layer Architecture

┌────────────────────────────────────────────────────┐
│                    Layer 1: Transport               │
│   TCP + QUIC │ AutoNAT │ Circuit Relay v2 │ Tor      │
├────────────────────────────────────────────────────┤
│                    Layer 2: Discovery               │
│   Kademlia DHT │ mDNS (LAN) │ GossipSub │ PubSub    │
├────────────────────────────────────────────────────┤
│                    Layer 3: Protocol                │
│   /ctx/1.2  │  Framing  │  Stream Mux  │  Noise     │
├────────────────────────────────────────────────────┤
│                  Layer 4: Business Logic            │
│  Message Handler │ Replicator │ Auth Module │ VClock │
├────────────────────────────────────────────────────┤
│                    Layer 5: Storage                 │
│   SQLite │ Unit of Work │ Message Repo │ Tombstones  │
└────────────────────────────────────────────────────┘

3.3 Component Diagram

[libp2p Host]
     │
     ├─ [CTX Protocol Handler /ctx/1.2]
     │        ├─ [Auth Verifier] ← Ed25519 sig check
     │        ├─ [Rate Limiter] ← Token Bucket / PeerID
     │        ├─ [Unit of Work] ← transactionality
     │        └─ [Replicator] → other relays
     │
     ├─ [DHT Module] ← Kademlia peer discovery
     ├─ [GossipSub] ← pub/sub topics
     ├─ [AutoNAT] ← NAT type detection
     ├─ [Health Server] ← HTTP /health /ready
     └─ [Blockchain Node] ← Phase 2
              ├─ [TxPool]
              ├─ [BFT Validator]
              ├─ [EmissionService]
              ├─ [UptimeTracker]
              └─ [ContractEngine]

3.4 Message Lifecycle

1. Client composes a message:
   - Generates UUID
   - Computes SHA-256(payload) → hash_sum
   - Signs Ed25519(privkey, message_hash)

2. SEND /ctx/1.2 → Relay-1:
   - Relay validates signature
   - Checks hash_sum
   - Rate-limit check (Token Bucket)
   - Validates timestamp ± 5 min (replay protection)

3. Relay-1 saves to SQLite:
   - UnitOfWork.Begin()
   - MessageRepo.Save(msg)
   - UnitOfWork.Commit()
   - ACK → Client

4. Eager Push replication:
   - Relay-1 → Relay-2, Relay-3 asynchronously
   - REPLICATE action (relay→relay)
   - Deduplication by MessageID on receiving side

5. Push notification (Phase 3):
   - Relay sends APNS/FCM/Huawei push
   - Recipient receives offline notification

6. Recipient online:
   - FETCH /ctx/1.2 → any Relay in the pool
   - Retrieves messages since_ts
   - Decrypts payload locally

7. Blockchain registration (Phase 2):
   - TxTypeMessageRegistration (without payload)
   - FullMessageHash = SHA-256(entire message with payload)
   - Verifiability without content disclosure

---

4. CTX Protocol v1.2

4.1 Transport Specification

CTX operates on top of libp2p streams with the identifier /ctx/1.2/{ReceiverPeerID}.

Framing: each message is preceded by a 4-byte big-endian length prefix:

┌──────────────┬─────────────────────────────────────┐
│   4 bytes    │           N bytes                    │
│  Big-Endian  │         JSON Payload                 │
│    Length    │                                      │
└──────────────┴─────────────────────────────────────┘

---

5. Cryptography & Security

5.1 Node Identity

Each relay and client is identified through an Ed25519 keypair:

Ed25519 keypair → PeerID = multihash(SHA-256(pubkey))
Multiaddr: /ip4/{IP}/tcp/{PORT}/p2p/{PeerID}

The keypair is generated on first launch and saved to the identity.key file. Loss of the key means loss of identity.

5.2 Transport Encryption

Noise Protocol (XX handshake pattern) provides:

• Mutual authentication of both parties
• Perfect Forward Secrecy (PFS)
• MITM attack protection

Noise is built into libp2p as the default security transport — all connections in the CONTEXT network are automatically encrypted.

5.3 Message Integrity

Each message contains:

• hash_sum = SHA-256(payload) — verified by relay upon receipt
• signature = Ed25519(privkey, message_bytes) — verifies the sender

5.4 Connection Gater

Connection Gater operates at the TCP/QUIC connection level:

• Blocklist PeerIDs that have committed repeated violations
• Blocking occurs before libp2p stream establishment
• Minimal computational cost for rejection

5.5 Anti-Fraud (7 levels) — Phase 2

When blockchain mode is activated, a 7-level anti-fraud system is added:

---

6. Privacy Models

6.1 Public Mode

In public mode, the relay accepts and replicates any messages without additional checks. Transport is encrypted (Noise), payload may be encrypted by the application, but the relay imposes no restrictions.

Public channels always operate in public mode — their messages are distributed across the entire network.

6.2 Private Mode

Private mode is activated at the relay level via RELAY_PRIVATE_MODE=true. It operates on group authentication with three keys:

Receiving relay verification:

Verify(AUTH_SERVICE_PUBKEY_src, ID_dst, NETSIGN_stored) = True

Client verification:

Verify(AUTH_SERVICE_PUBKEY_relay, ID_client, NETSIGN_relay) = True

6.3 Private Message Routing Rules

Client sends IsPrivate=true → only to verified private relays
Relay receives IsPrivate=true → replicates only within the private cluster
Public relay receives IsPrivate=true → rejects when PRIVATE_MODE=true

6.4 Chat Types

---

7. Blockchain Core

7.1 Concept

CONTEXT uses a linear blockchain (not DAG, not sharded in Phase 2) with the following characteristics:

• Block every 1 second
• Up to 10,000 transactions per block
• Proof of Stake consensus with BFT validation
• Minimum stake: 100 CTX

Storage separation principle:

• SQLite (data/peer.db) — messages and peers (Phase 1, unchanged)
• Pebble (data/blockchain/, data/state/, data/contracts/) — blockchain (Phase 2)

7.2 Block Structure

Block {
  Height:       uint64          // Monotonic number
  Timestamp:    int64           // Unix nanoseconds
  PrevHash:     [32]byte        // SHA-256 of previous block
  TxRoot:       [32]byte        // Merkle root of transactions
  StateRoot:    [32]byte        // Merkle root of balances
  ContractRoot: [32]byte        // Merkle root of contracts
  Transactions: []*Transaction  // Ordered list
  ProposerAddr: Address         // Proposer validator address
  Signatures:   []BlockSig      // BFT validator signatures (≥⅔)
  Hash:         [32]byte        // SHA-256 of block (without Signatures)
}

7.3 Transaction Types

7.4 Transaction Structure

Transaction {
  Hash:      [32]byte  // SHA-256(all fields except Signature)
  Type:      uint8     // Transaction type
  Timestamp: int64     // Unix nanoseconds
  Sender:    [20]byte  // Address from Ed25519 pubkey
  Recipient: [20]byte  // Recipient address
  Amount:    uint64    // In smallest units (1 CTX = 10^8)
  Nonce:     uint64    // Sequence number (anti-replay)
  Data:      []byte    // Protobuf data (depends on Type)

  // TxTypeMessageRegistration:
  MessageID:       string   // Message UUID
  FromPeer:        string   // libp2p PeerID
  FullMessageHash: [32]byte // SHA-256(full message with payload)
  IsPrivate:       bool
  LifeTime:        int

  // Signature:
  SenderPubKey: []byte  // Ed25519 pubkey (32 bytes)
  Signature:    []byte  // Ed25519 signature (64 bytes)
}

7.5 BFT Consensus

CONTEXT uses Byzantine Fault Tolerant consensus:

Validators = top-N relays by stake size
Proposer = deterministic selection from validators (round-robin)
Commit = ≥⅔ validator signatures for the block
Resilience: network continues operation with ≤⅓ malicious nodes

Checkpoint is created every N blocks and contains:

• Merkle root of transactions
• Merkle root of state (balances)
• Merkle root of contracts
• Ed25519 signatures of authority nodes

7.6 Message Registration on Blockchain

Each message is registered on the blockchain without payload to save space:

TxTypeMessageRegistration:
  ✓ MessageID     → message UUID
  ✓ FromPeer      → sender
  ✓ FullMessageHash → SHA-256(full message with payload)
  ✗ Payload       → NOT written to blockchain

FullMessageHash allows verifying message integrity during replication without storing content in the public ledger.

---

9. CTX Tokenomics

8.1 Token Parameters

8.2 Emission Mechanism (Uptime Rewards)

Epoch = 24 hours. Emission is distributed proportionally to uptime:

reward_i = emission_per_epoch × (uptime_i / total_uptime_eligible_peers)

Conditions for receiving rewards:

• Uptime ≥ 1 hour (3,600 seconds) per epoch
• Active stake position ≥ 100 CTX
• No active slash sanctions

If no eligible peers during an epoch — emission is burned (sent to Burn Address).

8.3 Halving Schedule

After 24 years, emission is fixed at a symbolic 2 CTX/day as an incentive for maintaining infrastructure.

8.4 Staking

Minimum stake:          1000 CTX
Lock-up period:         Epoch (24 hours)
Stake withdrawal:       After epoch completion without violations
Slashing (double-sign): -100% of stake (burned)
Slashing (downtime):    -5% of stake when downtime > 1 hour

8.5 Burn Mechanism

Burn creates deflationary pressure and ensures utilization of undistributed emission:

Burn Address — deterministic address with no known private key:

BurnAddress = SHA-512("CTX-Burn-Address-v1")[:20]

Any tokens sent to this address are permanently removed from circulation. Attempts to spend funds from the Burn Address are rejected at the validator level.

8.6 Economic Incentives

Network growth scenario (year 1):
  Emission:              +46,720 CTX
  Burn (transfers):      -500 CTX (estimated)
  Burn (contracts):      -300 CTX (estimated)
  Burn (slashing):       -200 CTX (estimated)
  Net inflation:         ≈ +45,720 CTX

Mature network scenario (year 10):
  Emission:              +11,680 CTX
  Burn (all channels):   -3,000 CTX (estimated)
  Net inflation:         ≈ +8,680 CTX

---

9. Smart Contracts

9.1 Concept

CTX smart contracts are deterministic, non-Turing-complete constructs for managing service sessions. Unlike EVM contracts:

• No arbitrary executable code
• No loops or complex VM
• Fixed operation types (escrow, settle, dispute)
• Stored in Pebble, registered via transactions

9.2 Service Node Types

9.3 Session Lifecycle

Provider publishes ServiceContract:
  └─ TxTypeContractDeploy → blockchain
     - ServiceType, Name, PricePerUnit
     - MinDeposit, SessionTTL
     - ProviderAddr, ProviderPubKey

User opens session:
  └─ TxTypeContractCall → blockchain
     - DepositTxHash (freezes CTX in escrow)
     - UserAddr, UserPubKey
     - ContractID

Service usage:
  - User interacts with the service node
  - Provider tracks consumption (UnitsConsumed)

Session close:
  └─ TxTypeContractSettle → blockchain
     - Provider receives: Amount - 10% burn
     - User receives: Deposit - Amount
     - BurnAddress receives: 10% of Amount

Dispute resolution:
  └─ DisputeContract (oracle or validator voting)

9.4 Contract Registry

All active service contracts are stored in the Registry:

• Search by ServiceType, ProviderAddr, PeerID
• Sort by reputation, price, uptime
• Automatic removal of expired contracts

---

10. Fraud Protection

10.1 Uptime Anti-Fraud

Uptime Tracker implements 7-level heartbeat message verification to prevent activity time falsification:

Level 1: Signature     — Ed25519 heartbeat signature
Level 2: Sequence      — Monotonic counter (anti-replay)
Level 3: Timestamp     — Delta validation (Clock Skew ≤ 30s)
Level 4: Challenge     — Random challenge-response
Level 5: PoW micro     — Light hashcash for Sybil protection
Level 6: Attestation   — Verification via other nodes
Level 7: Auto-ban      — Violator exclusion

10.2 Double-Sign Protection

If a validator signs two different blocks at the same height:

1. BFT validators detect the double signature
2. TxTypeSlash transaction → 100% of stake burned
3. PeerID added to blocklist

10.3 Downtime Slashing

On heartbeat absence for more than 1 hour with active stake:

• Uptime Tracker records the violation
• -5% of stake → TxTypeBurn
• Operator notified via healthcheck endpoint

---

11. Desktop Wallet

11.1 Technology Stack

CTX Wallet — desktop application with the following architecture:

• Backend: Go
• Native: macOS, Windows, Linux

11.2 Cryptographic Standards

Mnemonic (12/24 words BIP-39)
         ↓ SLIP-0010
Ed25519 Master Key
         ↓ Derivation Path m/44'/CTX'/0'/0/0
Ed25519 Account Key → CTX Address (20 bytes)

11.3 Functionality

• Create and import wallets (mnemonic / keystore JSON)
• View balance and transaction history
• CTX transfers with Ed25519 signature
• Staking management (stake/unstake)
• View relay operator status and uptime

---

12. Comparative Analysis

---

13. Roadmap

Phase 1 — Basic Infrastructure ✅ Completed

• Relay servers on go-libp2p with /ctx/1.2 protocol
• SQLite storage with migration system
• Ed25519 keypair authentication
• Kademlia DHT and Circuit Relay v2 for NAT traversal
• Docker Compose cluster for deployment

Phase 2 — Security & Replication ✅ Completed

• Private mode with NETSIGN verification
• Inter-node eager-push replication
• Queues with retry logic
• Rate-limiting and Connection Gater
• Vector Clock for causal ordering

Phase 3 — Push & Mobile Clients ✅ Completed

• APNS, FCM, and Huawei Push Kit integration
• Flutter iOS/Android client (ctx_mobile)
• Tombstone replication for deletions
• Prometheus metrics and monitoring
• Public channels via GossipSub

Phase 4 — Blockchain & Tokenomics 🔵 In Development

• Linear BFT blockchain with Merkle trees
• Staking, slashing, and CTX emission
• Smart contracts: Payment, Session, Dispute
• Desktop wallet on Wails + Svelte
• Exchange API with WebSocket and webhooks

Phase 5 — Ecosystem ○ Planned

• BLE (Bluetooth Low Energy) offline mode
• Public testnet
• SDK for third-party app integration
• Open registry of public relay operators
• Governance — network management via CTX

---

14. Tech Stack

14.1 Key Architectural Decisions

---

15. Conclusion

CONTEXT presents an architecturally complete solution for decentralized communications, combining several key innovations:

1. Relay architecture eliminates the single point of failure while maintaining practicality (push notifications, offline delivery)
2. Cryptographic identity based on Ed25519 gives users full sovereignty over their identity without dependence on phone numbers or email
3. CTX tokenomics creates a sustainable economic model for infrastructure operators through an uptime-rewards mechanism with halving and deflationary burn
4. Blockchain verifiability provides transparent auditing without disclosing message content
5. Multi-layer security from transport level (Noise) to application level (Ed25519 signatures, private mode) protects against various attack classes

The project is developed openly under the MIT license. Community participation is welcome at all levels: from running relay nodes to contributing to the protocol.

---

16. References

• go-libp2p: https://github.com/libp2p/go-libp2p
• libp2p Specifications: https://github.com/libp2p/specs
• Noise Protocol Framework: https://noiseprotocol.org/noise.html
• Kademlia DHT: Maymounkov & Mazières (2002), "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric"
• BFT Consensus: Castro & Liskov (1999), "Practical Byzantine Fault Tolerance"
• Ed25519: Bernstein et al. (2011), "High-speed high-security signatures"
• BIP-39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
• SLIP-0010: https://github.com/satoshilabs/slips/blob/master/slip-0010.md
• Circuit Relay v2: https://docs.libp2p.io/concepts/nat/circuit-relay/
• GossipSub: https://github.com/libp2p/specs/blob/master/pubsub/gossipsub
• Wails: https://wails.io
• Flutter: https://flutter.dev