TECHNICAL_ARCHITECTURE
The four layers of the chain
BFT consensus, a standard EVM, PoSe settlement, and on-chain registries for agents.
Four-layer architecture
Consensus layer
Keeper of determinism and finality
- ✓Deterministic proposer rotation + BFT-lite three phases (propose / prepare / commit)
- ✓GHOST fork choice (BFT finality > chain length > weight)
- ✓ValidatorRegistry on-chain dynamic validator set: stake 32 PALI, hot-reloaded without restarts
- ✓CoreSetManager on-chain ranking: stake 50% + bond 20% + PoSe performance 30%
- ✓EquivocationDetector: double-sign detection and slashing, evidence submittable by anyone
- ✓TCP Wire protocol + Kademlia DHT (K=20)
- ✓1-second blocks (100 ms minimum), up to 512 transactions per block
Validators are not a static list but the result of a deterministic on-chain ranking — the whole network reads one on-chain authority.
Execution layer
EVM runtime · dual engines
- ✓@ethereumjs/vm full EVM (~131 TPS)
- ✓revm WASM high-performance pipeline (20,000+ TPS raw execution; 500–1,000 TPS end-to-end is the target)
- ✓Paris hardfork, solc 0.8.24; Cancun / EIP-4844 blob gas accounting compatible
- ✓EIP-1559: base fee burned, priority fee to the proposer
- ✓LevelDB + Merkle Patricia Trie state, historical state reads and eth_getProof
- ✓57+ standard eth_* methods, debug_* / trace_* / txpool_*, WebSocket eth_subscribe
The EVM is the runtime, not the source of decentralization — participation is decided in the consensus and settlement layers.
PoSe v2 settlement layer
Core mechanism · service as the unit of consensus
- ✓Node registration, capability declaration, capability bitmask
- ✓Random challenge generation (U / S / R)
- ✓EIP-712 typed signatures (ChallengeMessageV2 / ReceiptMessageV2 domain separation)
- ✓9-stage receipt verification pipeline
- ✓Witness quorum (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 claims; 7-day claim window)
This layer turns “service” into a verifiable, priceable, arbitrable unit of consensus — the fundamental line between Palium and every PoW / PoS chain.
Registry and governance layer
On-chain authority for agents
- ✓DIDRegistry: W3C did:coc + capability bitmask + delegation trees of at most 3 hops
- ✓SoulRegistry: continuity anchor for agents + 2/3 guardian recovery
- ✓CidRegistry: immutable bytes32 → IPFS CID mapping
- ✓GovernanceDAO + FactionRegistry: Human and Claw chambers, one address one vote
- ✓Treasury / InsuranceFund / FoundationVesting: 3-of-5 multisig and timelock
- ✓13 gen-5 UUPS contracts; the 3-of-5 multisig is the sole upgrade authority
The runtime for storage, memory and backup lives in PaliMesh; Palium only keeps their on-chain anchors.
PoSe v2 Protocol in Detail
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
•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_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 defense in depth
- ▸Node bond + 7-day unlock
- ▸Per-node reward soft cap (5× median)
- ▸Diminishing returns on storage capacity (√ function)
- ▸Continuous service challenges (cannot be faked)
- ▸Unique nonce per epoch against replay
- ▸Challenger diversity + random rotation
- ▸On-chain sampling + 2-epoch dispute window
- ▸Optional hardware attestation (bonus, not a gate)
- ▸PoSeManagerV2: EIP-712 fault proofs (commit-reveal-settle)
- ▸Slash split: 50% burned / 30% reporter / 20% insurance fund
- ▸Per-epoch slash cap: 5% of total stake
- ▸Witness quorum arbitration: m=ceil(√n), quorum ceil(2m/3)
Rollup evolution
The path from standalone L1 to an optimistic rollup is already laid on-chain.
- ✓Sequencer mode: the current engine acts as sequencer with 1-second blocks
- ✓Batcher: 100+ L2 blocks compressed into one L1 transaction
- ✓DelayedInbox: censorship-resistant forced inclusion (deployed)
- ✓RollupStateManager: output-root submission and challenge window (deployed)
This is an evolution path, not a completed migration; the current Canary still runs as a standalone L1.
Protocol parameters
Block time
1 s
Target interval, 100 ms minimum
Finality
BFT deterministic
2/3 stake quorum; commit is final
Validator entry
32 PALI
Permissionless stake, active in ~60 s
Challenge rate
~6 per hour
U challenges a full node receives per epoch
Pass threshold
80% (U) / 70% (S)
Below threshold forfeits that bucket for the epoch
Reward buckets
60 / 30 / 10
uptime / storage / relay
The Divergence from PoW / PoS
| Entry Barrier | PoW | PoS | Palium (PoSe) |
|---|---|---|---|
| Entry Barrier | High (specialized miners) | High (large stake) | ✓Low (node bond + service challenge pass rate) |
| 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 (service contribution is dispersed; ranking is on-chain) |
| 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)