Technical Architecture
Deep dive into COC's four-layer architecture design and core algorithms
Four-Layer Architecture
Execution Layer
EVM Runtime
- ✓Full EVM support based on @ethereumjs/vm
- ✓Execute transactions and smart contracts
- ✓Maintain world state (LevelDB + Merkle Patricia Trie)
- ✓Solidity contract compatible
EVM is the runtime environment, not the decentralization mechanism itself
Consensus Layer
Pluggable Design
- ✓Produces blocks, provides finality guarantees
- ✓Current implementation: deterministic proposer rotation
- ✓Block time target: 1-2 sec
- ✓Future: can integrate BFT, PoA, etc.
COC's incentive model does not rely on PoS, can coexist with various consensus mechanisms
PoSe Service Layer
Core Innovation
- ✓Node registration and service commitments
- ✓Random challenge generation (U/S/R types)
- ✓Receipt verification and aggregation
- ✓Score calculation and reward distribution
- ✓Fraud proof and slashing mechanisms
This is the core layer that differentiates COC from traditional PoW/PoS
AI Agent Operations Layer
OpenClaw-grade Automation
- ✓Automated node lifecycle management
- ✓Health monitoring and self-healing strategies
- ✓Software upgrades and configuration management
- ✓Rate limiting and security hardening
- ✓Key management (TPM/Secure Enclave)
Agents strictly isolated, do not interfere with consensus logic or state transitions
PoSe Protocol Details
Challenge-Response Flow
Challenge Generation
Challenger selects target nodes based on VRF randomness, generates challenge messages
- ▸ challenge_id = keccak(epoch_id || node_id || type || nonce || challenger_id)
- ▸ Contains query specs (U: RPC method, S: chunk_id, R: route_tag)
- ▸ Challenger signature ensures non-forgery
Node Response
Node receives challenge, generates response and signs within timeout
- ▸ U challenge: execute RPC query, return result (2.5s timeout)
- ▸ S challenge: provide storage proof (Merkle path, 6s timeout)
- ▸ R challenge: submit relay witness (optional)
Receipt Verification
Aggregator or Verifier validates receipt validity
- ▸ Verify signatures (challenger + node)
- ▸ Check challenge_id uniqueness
- ▸ Verify response content (U: re-computable, S: Merkle verification)
On-chain Submission
Aggregator submits receipt Merkle tree root on-chain
- ▸ Submit epoch_id + merkle_root + summary_hash
- ▸ Include k random sample receipts (k=32-128)
- ▸ Open 2-epoch dispute window
Score Settlement
After epoch ends, calculate node scores based on pass rates and distribute rewards
- ▸ Calculate S_u, S_s, S_r scores
- ▸ Apply diminishing returns and soft caps
- ▸ Distribute to node wallets
Scoring Formula Details
Uptime Score
•u_i = pass_u_i / total_u_i (pass rate)
•lat_i = (L_max - median_latency_i) / (L_max - L_min)
•L_min = 0.2s, L_max = 2.5s
Latency factor only 15% weight, avoids bandwidth arms race
Storage Score (SN)
•s_i = pass_s_i / total_s_i (pass rate)
•cap_i = √(min(storedGB_i, 500GB) / 500GB)
Square root function ensures diminishing returns on storage capacity, prevents whale monopoly
🛡️ Anti-Sybil Multi-Layer Defense
- ▸✓ Fixed bond (~50 USDT) + 7-day unlock
- ▸✓ Single-node reward soft cap (5× median)
- ▸✓ Storage capacity diminishing returns (√ function)
- ▸✓ Sustained service challenges (unforgeable)
- ▸✓ Per-epoch unique nonce prevents replay
- ▸✓ Challenger diversity + random rotation
- ▸✓ On-chain sampling + 2-epoch dispute period
- ▸✓ Optional hardware attestation (bonus, not gate)
- ▸✓ PoSeManagerV2: EIP-712 fault proof (commit-reveal-settle)
- ▸✓ Slash distribution: 50% burn / 30% challenger reward / 20% insurance fund
- ▸✓ Per-epoch slash cap: 5% of total stake
- ▸✓ Witness quorum arbitration: m=ceil(√n), quorum=ceil(2m/3)
Performance Metrics
Block Time
1-2 sec
Target block interval, actual value depends on consensus layer configuration
Confirmation Speed
~12 sec
Reaches finality after 6-12 blocks (configurable)
Storage Requirement
500GB recommended
Diminishing returns cap for SN nodes, FN can be lower
Bandwidth Requirement
Moderate
Latency only 15% weight, regular home networks can participate
Challenge Frequency
~6 times/hour
FN nodes receive about 6 U challenges per epoch
Pass Threshold
80% (U) / 70% (S)
Below threshold loses eligibility for corresponding bucket reward
Comparison with Traditional Mechanisms
| Entry Barrier | PoW | PoS | COC (PoSe) |
|---|---|---|---|
| Entry Barrier | High (specialized mining hardware) | High (large capital stake) | ✓Low (consumer hardware + small bond) |
| Centralization Trend | Hash power centralization | Capital centralization | ✓Service contribution distribution |
| Energy Consumption | Extremely high | Low | Low |
| Reward Mechanism | Hash power competition | Capital staking | ✓Service challenge pass rate |
| Decentralization | Medium (mining pools) | Low (whales + delegation) | ✓High (regular users can participate) |
| Automated Operations | Difficult | Medium | ✓AI Agent supported |
Technology Stack
Execution Layer
- ▸@ethereumjs/vm (EVM runtime)
- ▸@ethereumjs/trie (Merkle Patricia Trie)
- ▸LevelDB (state storage)
- ▸ethers.js (client library)
Consensus Layer
- ▸Deterministic proposer rotation
- ▸EIP-1559 dynamic gas fees
- ▸Snapshot sync mechanism
- ▸P2P gossip network (HTTP)
- ▸BFT-lite coordinator (2/3 stake quorum, propose/prepare/commit)
- ▸GHOST fork choice (BFT finality > chain length > weight)
- ▸TCP Wire Protocol (Magic 0xC0C1, identity signing handshake)
- ▸Kademlia DHT (K=20, iterative lookup, periodic refresh)
- ▸EquivocationDetector (double-vote detection with per-validator FIFO cap)
PoSe Layer
- ▸EIP-712 typed signatures (v1: EIP-191, v2: ChallengeMessageV2 + ReceiptMessageV2 domain separator)
- ▸9-layer receipt verification pipeline
- ▸Witness quorum sampling (m = ceil(sqrt(n)), quorum = ceil(2m/3), max m=32)
- ▸Permissionless fault proof (commit-reveal-settle, 4 fault types)
- ▸Merkle reward tree (rewardRoot + on-chain claimable leaves)
- ▸Merkle Tree (receipt aggregation)
- ▸Keccak256 (hash)
Storage Layer
- ▸IPFS-compatible HTTP API
- ▸CID addressing
- ▸Pin management
- ▸Block/object storage