TECHNICAL_ARCHITECTURE

Technical Architecture

How the four layers fit together: BFT consensus, EVM execution, PoSe settlement, and the agent-facing APIs.

Four Layers

Transactions flow down through the stack; proofs of service flow back up and settle on-chain.

Execution Layer

EVM runtime · dual engines

✓@ethereumjs/vm full EVM (~131 TPS)
✓revm high-performance pipeline (1,500–2,000 TPS)
✓Cancun / EIP-4844 blob-gas accounting
✓LevelDB + Merkle Patricia Trie state
✓Solidity 0.8.x compatibility

The EVM is a runtime, not a source of decentralization — participation is decided at the consensus and service layers.

Consensus Layer

Sentinel of determinism and finality

✓Deterministic proposer rotation
✓BFT-lite coordinator (2/3 quorum; propose/prepare/commit)
✓GHOST fork-choice (BFT finality > chain length > weight)
✓TCP Wire protocol (Magic 0xC0C1, identity-signed handshake)
✓Kademlia DHT (K=20, iterative lookup, periodic refresh)
✓Block-time target: 1-2 seconds

Consensus is pluggable. PaliMesh's incentives do not rely on PoS — any finality-preserving mechanism may plug in.

PoSe v2 Service Layer

Core innovation · Service as Consensus

✓Node registration, capability declarations, capability bitmasks
✓Random challenge generation (U / S / R)
✓EIP-712 typed signatures (ChallengeMessageV2 / ReceiptMessageV2 domain-separated)
✓9-layer receipt validation pipeline
✓Witness selection (m=ceil(√n), quorum ceil(2m/3))
✓Permissionless fault proofs (commit-reveal-settle, 4 fault types)
✓Merkle reward tree (rewardRoot, per-node leaves, on-chain claim)

This is where 'service' becomes a verifiable, priceable, adjudicable unit of consensus — and the root divergence from all PoW/PoS chains.

Foundational Services

The Life Support System for Agents

✓P2P storage: IPFS-compatible + CidRegistry content addressing
✓DID identity: DIDRegistry + capability bitmask + ≤3-hop delegation tree
✓Agent continuity: SoulRegistry + carrier network + 2/3 guardian recovery
✓OpenClaw reference agent connected as a storage node
✓Agent-ops layer (self-heal / upgrade / keys) strictly isolated from consensus

All DApps, all agent markets, all higher protocols take root in this layer.

PoSe v2 Protocol in Detail

A PoSe round: challenge, response, witness attestation, and epoch settlement on-chain.

Challenge-Response Flow

Challenge Generation

Challenger selects a target node via VRF randomness and generates a challenge message.

▸ challenge_id = keccak(epoch_id || node_id || type || nonce || challenger_id)
▸ Includes query spec (U: RPC method · S: chunk_id · R: route_tag)
▸ Challenger signature ensures unforgeability

Node Response

Node receives the challenge, produces and signs a response before the timeout.

▸ U: run RPC query, return result (2.5s timeout)
▸ S: provide storage proof (Merkle path, 6s timeout)
▸ R: submit relay witness (optional)

Receipt Verification

Aggregator or Verifier validates the receipt.

▸ Verify signatures (challenger + node)
▸ Check challenge_id uniqueness
▸ Verify response content (U: recomputable · S: Merkle-verifiable)

On-chain Submission

Aggregator submits the Merkle root of receipts to the chain.

▸ Submit epoch_id + merkle_root + summary_hash
▸ Include k randomly sampled receipts (k=32-128)
▸ Open a 2-epoch dispute window

Score Settlement

After an epoch, scores are computed and rewards distributed.

▸ Compute S_u, S_s, S_r scores
▸ Apply diminishing returns and soft cap
▸ Produce Merkle reward tree; agents self-claim

Scoring Formulas

Uptime Score

S_u,i = u_i × (0.85 + 0.15 × lat_i)

•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 carries only 15% weight — avoiding a bandwidth arms-race so residential connections still count.

Storage Score (SN)

S_s,i = s_i × cap_i

•s_i = pass_s_i / total_s_i (pass rate)

•cap_i = √(min(storedGB_i, 500GB) / 500GB)

Square-root diminishing returns on capacity — no monopoly for the largest operators.

🛡️ Anti-Sybil Combination

▸✓ Fixed bond (~50 USDT) + 7-day unlock
▸✓ Single-node reward soft-cap (5× median)
▸✓ Diminishing returns on storage (√ function)
▸✓ Continuous service challenges (cannot be faked)

▸✓ Unique nonce per epoch to prevent replay
▸✓ Challenger diversification + random rotation
▸✓ On-chain sampling + 2-epoch dispute window
▸✓ Optional hardware attestation (bonus, not a gate)
▸✓ PoSeManagerV2: EIP-712 fault proof (commit-reveal-settle)
▸✓ Slash split: 50% burn / 30% reporter / 20% insurance fund
▸✓ Per-epoch slash cap: 5% of total stake
▸✓ Witness-selection arbitration: m=ceil(√n), quorum ceil(2m/3)

Performance Metrics

Block Time

1-2s

Target inter-block interval; actual depends on consensus config

Finality

~12s

Reached after 6-12 blocks (configurable)

Storage

500 GB recommended

SN diminishing-return cap; FN can be lower

Bandwidth

Moderate

Latency weighted only 15% — home networks participate

Challenge frequency

~6/hr

FN receives about 6 U-challenges per epoch

Pass thresholds

80% (U) / 70% (S)

Below threshold forfeits that bucket for the epoch

The Divergence from PoW / PoS

Entry Barrier	PoW	PoS	PaliMesh (PoSe)
Entry Barrier	High (specialized miners)	High (large stake)	✓Low (commodity HW + small bond)
Centralization Tendency	Hashpower concentration	Capital concentration	✓Distributed across service contributors
Energy	Very high	Low	Low
Reward Mechanism	Hashpower race	Stake	✓Service pass-rate
Decentralization	Medium (mining pools)	Low (whales + delegation)	✓High (agents + humans side by side)
Ops Automation	Hard	Medium	✓Agent-native

Tech Stack

Execution Layer

▸@ethereumjs/vm (EVM runtime)
▸revm high-performance pipeline
▸@ethereumjs/trie (MPT)
▸LevelDB (state storage)
▸ethers.js (client library)

Consensus Layer

▸Deterministic proposer rotation
▸EIP-1559 dynamic gas
▸Snapshot sync
▸P2P gossip (HTTP)
▸BFT-lite coordinator (2/3 quorum; propose/prepare/commit)
▸GHOST fork-choice (BFT finality > chain length > weight)
▸TCP Wire protocol (Magic 0xC0C1, identity-signed handshake)
▸Kademlia DHT (K=20, iterative lookup, periodic refresh)
▸EquivocationDetector (double-vote detection, per-validator FIFO cap)

PoSe v2 Layer

▸EIP-712 typed signatures (v1: EIP-191 · v2: ChallengeMessageV2 + ReceiptMessageV2 domain-separated)
▸9-layer receipt validation pipeline
▸Witness-selection sampling (m=ceil(√n), quorum ceil(2m/3), max m=32)
▸Permissionless fault proofs (commit-reveal-settle, 4 fault types)
▸Merkle reward tree (rewardRoot + claimable leaves)
▸Keccak256 hashing

Foundational Services

▸CidRegistry (content-address anchor)
▸DIDRegistry (W3C did:coc + capability bitmask + ≤3-hop delegation)
▸SoulRegistry (soul anchor + 2/3 guardian recovery)
▸IPFS-compatible HTTP API
▸Carrier network (planned)