⚠ You must join and log in to use any feature on this site

SYNTHOS Collective

Your First Digital Weapon in the War Over Data Sovereignty

TECHNICAL REFERENCE

Protocol Specification

Complete technical reference for implementing immune nodes and core agents within the SYNTHOS Distributed Immune System. For operators, developers, and security auditors.

Contents

• Network Architecture • Consensus Mechanism • Threat Detection • Message Protocol • Cryptographic Standards • Node Lifecycle • Agent Communication • Response Coordination • Governance Protocol • SYN Token Mechanics

Network Architecture

Overview

SYNTHOS operates as a fully distributed network with no central authority. The topology is a peer-to-peer mesh where each immune node maintains direct connections to peer nodes and participates in protocol consensus.

Node Types

  • → Immune Nodes: Full nodes that maintain the complete state of the protocol, participate in consensus, and coordinate threat response.
  • → Core Agents: Autonomous software modules deployed on immune nodes that execute protocol operations and participate in threat detection.
  • → Sentinel Nodes: Lightweight nodes that monitor the network for anomalies and alert immune nodes to potential threats.

Network Topology

The network uses a Kademlia-inspired distributed hash table (DHT) for peer discovery and routing. Each immune node maintains:

  • • Up to 16 peer connections (configurable)
  • • A routing table of 256 buckets (256-bit address space)
  • • Periodic peer discovery through iterative network queries
  • • Time-to-live (TTL) protocol for message routing with max TTL of 64 hops

Consensus Mechanism

Proof of Immunity (PoI)

SYNTHOS uses Proof of Immunity—a consensus mechanism where validators prove they are actively participating in threat detection and collective defense. Stake in SYN determines validator weight in consensus decisions, but all validators can participate.

Consensus Round Structure

  • 1. Block Proposal: A randomly selected validator (weighted by SYN stake) proposes a new block containing threat detections, collective decisions, and staking updates.
  • 2. Attestation: Other validators verify the proposed block against threat detection data and sign cryptographic attestations approving it.
  • 3. Finality: Once ⅔ of SYN-weighted validators attest, the block is considered final. No reorganization is possible.

Slashing Conditions

Validators who violate protocol rules are slashed (lose staked SYN):

  • • Proposing conflicting blocks: 5% of stake
  • • Attesting to conflicting blocks: 5% of stake
  • • Failing to attest when elected: 0.5% of stake per missed attestation
  • • Detected malicious threat detection: 20% of stake

Threat Detection & Response

Threat Detection Algorithm

Core agents employ multiple threat detection methods running in parallel on each immune node:

  • • Anomaly Detection: Statistical deviation from protocol norms using Isolation Forest algorithm on transaction patterns.
  • • Consensus Deviation: Detection of validators proposing invalid blocks or deviating from protocol specifications.
  • • Network Topology Monitoring: Detection of sybil attacks or centralization by monitoring peer connections and network graph structure.
  • • Cryptographic Verification: Validation of all signatures, proofs, and cryptographic commitments against known standards.

Response Procedure

  1. 1. Detection: Core agent detects anomaly and broadcasts threat signal to connected peers.
  2. 2. Verification: Peers receive threat signal and independently verify the detection using their own algorithms.
  3. 3. Aggregation: Threat signals aggregate on the network. Once ⅓ of validators have detected the same threat, it enters governance.
  4. 4. Governance Vote: All SYN holders vote on response measures (slashing, network fork, etc.). Voting period is 1 consensus round (12 seconds).
  5. 5. Execution: Response passes if ⅔ of SYN-weighted validators vote yes. Response is executed immediately on the next block.

Message Protocol

Message Structure

All network messages follow this structure (big-endian binary format):

[ Version: 1 byte ][ Message Type: 1 byte ][ TTL: 1 byte ]

[ Sender ID: 32 bytes ][ Nonce: 8 bytes ]

[ Payload Length: 4 bytes ][ Payload: variable ]

[ Signature: 64 bytes (Ed25519) ]

Message Types

  • • 0x01: PEER_DISCOVERY - DHT lookup and peer exchange
  • • 0x02: BLOCK_PROPOSAL - New block proposal from validator
  • • 0x03: ATTESTATION - Signature of block approval
  • • 0x04: THREAT_SIGNAL - Anomaly detection announcement
  • • 0x05: GOVERNANCE_VOTE - Vote on collective response
  • • 0x06: TRANSACTION - State update or SYN transfer
  • • 0x07: STATE_SYNC - Request or response for state synchronization

Cryptographic Standards

Signing & Verification

  • • Algorithm: Ed25519 (Schnorr signature scheme)
  • • Key Size: 32-byte private keys, 32-byte public keys
  • • Message Hashing: SHA-256 of message before signing
  • • Public Key Derivation: Deterministic from private key

Encryption

  • • Transport Encryption: ChaCha20-Poly1305 for node-to-node communication
  • • Key Exchange: Elliptic Curve Diffie-Hellman (Curve25519)
  • • Session Management: New ephemeral key per connection, rotated every 1 hour

Merkle Trees & Commitments

  • • Block Merkle Root: SHA-256 tree of all transactions in block
  • • State Root: Merkle Patricia tree of all account balances and states
  • • Timestamp Commitment: Unix timestamp signed by proposer in each block

Node Lifecycle

Initialization

  1. 1. Generate Ed25519 keypair (or import existing)
  2. 2. Initialize local state database (RocksDB or equivalent)
  3. 3. Load initial trusted peer list from genesis configuration
  4. 4. Start P2P networking stack and bind to listening port
  5. 5. Begin peer discovery via DHT bootstrap

Synchronization

When a node joins the network, it must synchronize state from peers:

  • • Request genesis block and initial state
  • • Download and verify all blocks from genesis to current tip
  • • Validate each block independently
  • • Reconstruct full state by replaying all transactions
  • • Verify final state root matches network consensus

Operation

Once synchronized, the node continuously:

  • • Listens for new blocks from the network
  • • Validates incoming blocks and attestations
  • • Executes threat detection algorithms
  • • Maintains peer connections and handles disconnections
  • • If validator: proposes blocks and attests to valid blocks

Shutdown

  • • Gracefully disconnect from peers
  • • Save state to disk
  • • Close database connections
  • • Stop all background tasks

Core Agent Communication

Agent Interface Protocol

Core agents communicate with the immune node runtime through a standardized message-passing interface:

  • → Query: Agent requests read-only state information (block height, account balance, etc.)
  • → Transaction: Agent broadcasts a transaction for inclusion in the next block.
  • → Event Subscribe: Agent subscribes to events (new blocks, threat signals, governance votes).
  • → Threat Signal: Agent broadcasts a detected threat for network propagation.

Agent-to-Agent Communication

Agents on different immune nodes communicate through the peer-to-peer network using the standard message protocol. Messages are routed through the DHT and delivered in a best-effort manner (no guarantees).

Threat Response Coordination

Response Measures

When threats are detected and verified, the collective can execute these responses:

  • 1. Slashing: Reduce the staked SYN of malicious validators by a percentage specified in the governance vote.
  • 2. Validator Ejection: Remove a validator from participating in consensus for a specified period.
  • 3. Protocol Fork: Execute an emergency hard fork to roll back malicious transactions and restore network integrity.
  • 4. Throttling: Reduce the transaction throughput of suspected malicious agents.

Governance Protocol

Governance Proposal

Any SYN holder can submit a governance proposal:

  • • Proposal includes: description, parameters (if applicable), requested action
  • • Proposal requires 0.1% of total SYN as deposit (burned if proposal fails)
  • • Voting period: 1 consensus round (12 seconds) for emergency responses, 7 days for protocol upgrades
  • • Voting power: SYN staked on immune nodes, 1 SYN = 1 vote

Governance Types

  • → Emergency: Threat response votes. 1-round voting. Passes with ⅔ majority.
  • → Standard: Protocol parameter changes. 7-day voting. Passes with ⅓ supermajority.
  • → Upgrade: Hard fork proposals. 14-day voting. Requires ⅔ supermajority.

SYN Token Mechanics

Token Supply

  • • Total Supply: 100 billion SYN (fixed cap, immutable)

Staking Mechanics

  • → Minimum Stake: 32 SYN to become a validator (participate in consensus)
  • → Lock-up Period: Staked SYN cannot be withdrawn for 28 days after unstaking request
  • → Compound Rewards: Staking rewards are automatically restaked each epoch (1 day)
  • → Slashing Risk: Staked SYN can be reduced (slashed) if validator violates protocol rules

Reward Distribution

Validators earn rewards for successfully proposing blocks and attesting to valid blocks. Rewards are proportional to stake and uptime:

  • • Block Proposal: 0.1% of block gas fees
  • • Attestation: 0.01% per attestation made in epoch
  • • Threat Detection: Additional rewards if threat detection leads to successful response

This specification is subject to change. Reference implementation is the canonical specification. Report security issues to elpresidentebutch2.0@outlook.com.

Protocol Overview Activate Immune Node