Skip to main content

Architecture Overview

High-level overview of Pilier's blockchain architecture and core components.

Reading time: 8 minutes

Introduction​

Pilier is a Substrate-based blockchain designed for European product compliance and supply chain transparency.

Key design principles:

  • 🇪🇺 EU Sovereignty: Institutional validators (universities, NGOs, public bodies)
  • 🔄 Forkless Upgrades: Governance-driven protocol evolution (no hard forks)
  • 💚 Public Utility: Sponsored transactions for civic participants
  • 🔒 Security First: Proof-of-Authority with reputation-based accountability

Use cases:

  • Digital Product Passports (DPPs) for EU regulations
  • Immutable document timestamping supply chain traceability
  • AI agent orchestration (coming 2026)

High-Level Architecture​

Core Components​

1. Node Layer (Execution Environment)​

What it is: Binary executable running on validator hardware.

Responsibilities:

  • P2P Networking: Connect to other validators (libp2p)
  • Block Production: Author new blocks when selected (BABE consensus)
  • Finality Voting: Vote on which blocks are final (GRANDPA consensus)
  • Storage Management: Read/write state to RocksDB
  • RPC Server: Expose API endpoints for clients

Technology:

  • Language: Rust
  • Framework: Substrate (Parity Technologies)
  • Runtime: Hosts WASM runtime (sandboxed execution)

Key insight: Node is the "operating system" — handles infrastructure, networking, consensus. Business logic lives in Runtime.

2. Runtime Layer (Business Logic)​

What it is: Blockchain's state transition function (compiled to WebAssembly).

Responsibilities:

  • Transaction Validation: Check if transactions are valid
  • State Transitions: Execute transactions, update state
  • Event Emission: Notify clients of state changes
  • Hooks: Execute on block initialization/finalization

Technology:

  • Language: Rust
  • Compilation: WebAssembly (WASM)
  • Architecture: Modular pallets (reusable components)

Pilier-specific pallets:

PalletPurposeLink
pallet-dppDigital Product Passports (DPPs)Docs
pallet-documentsImmutable document timestampingDocs
pallet-agentsAI agent orchestration (coming 2026)Docs

System pallets (from Substrate):

  • pallet-balances — Account balances (PIL tokens)
  • pallet-timestamp — Block timestamps
  • pallet-session — Validator session keys
  • pallet-authorship — Track block authors

Key insight: Runtime is upgradeable without hard forks (forkless upgrades). See Runtime Upgrades.

3. Storage Layer (Persistent State)​

What it is: Database storing blockchain state (accounts, DPPs, documents).

Architecture:

State Trie (in-memory)
├─ Patricia-Merkle tree
├─ Fast lookups (O(log n))
└─ Cryptographic proofs (light clients)

RocksDB (on-disk)
├─ Key-value store
├─ Persistent storage
└─ Configurable retention (pruning)

Storage types:

  • State storage: Current blockchain state (accounts, balances, DPPs)
  • Block storage: Historical blocks (headers, extrinsics, receipts)
  • Trie storage: Merkle tree nodes (for light client proofs)

Pruning strategies:

ModeDescriptionDisk UsageUse Case
ArchiveKeep all historical state~500GB+ (growing)Block explorers, auditors
PrunedKeep only recent state (last 256 blocks)~50GBValidators (default)

Key insight: Validators typically run pruned nodes (efficient). Archive nodes available for historical queries.

4. Network Layer (P2P Communication)​

What it is: Peer-to-peer networking protocol (libp2p).

Responsibilities:

  • Peer Discovery: Find other validators (bootnodes, Kademlia DHT)
  • Block Gossip: Propagate new blocks to network
  • Transaction Gossip: Propagate transactions to validators
  • Finality Messages: Broadcast GRANDPA votes

Technology:

  • Framework: libp2p (modular P2P stack)
  • Transport: TCP + WebSocket
  • Discovery: Bootnodes + DHT

Network topology:

┌─────────────┐         ┌─────────────┐
│ Validator A │◄───────►│ Validator B │
└─────────────┘         └─────────────┘
      ▲                       ▲
      │                       │
      │    ┌─────────────┐    │
      └───►│ Validator C │◄───┘
           └─────────────┘
                  ▲
                  │
           ┌──────┴──────┐
           │   Bootnode  │
           │ (discovery) │
           └─────────────┘

Key insight: Decentralized networking (no single point of failure). Validators self-organize.

👉 Network configuration: Network Specs

How Components Interact​

Example: User Creates a DPP​

Step-by-step flow:

1. User submits transaction
   └─ POST /api/v1/dpp/create (REST API)
   └─ Converted to extrinsic: dpp.create(product_id, metadata)

2. Node receives transaction
   └─ RPC endpoint receives extrinsic
   └─ Node validates signature (is user authorized?)
   └─ Transaction enters pool (mempool)

3. Validator produces block
   └─ BABE randomly selects validator for next slot
   └─ Validator picks transactions from pool
   └─ Executes transactions via Runtime

4. Runtime processes transaction
   └─ pallet-dpp.create() called
   └─ Validates: Does product_id already exist?
   └─ If valid: Write DPP to storage (state trie)
   └─ Emit event: DppCreated(product_id, owner, timestamp)

5. Block propagated
   └─ New block gossiped to network (libp2p)
   └─ Other validators import block
   └─ All validators update local state

6. Finality achieved
   └─ GRANDPA validators vote on finality
   └─ If >2/3 vote "yes" → Block finalized
   └─ DPP is now irreversible ✅

7. User receives confirmation
   └─ WebSocket event: DppCreated(...)
   └─ Or: Poll RPC: dpp.get(product_id) → returns DPP

Timing:

  • Transaction submitted → Block included: ~6-12 seconds (1-2 blocks)
  • Block included → Finalized: ~60 seconds (GRANDPA finality)
  • Total user wait time: ~90 seconds for irreversible confirmation

Consensus Mechanisms​

Pilier uses hybrid consensus (block production + finality):

BABE (Block Production)​

Purpose: Decide which validator produces the next block.

How it works:

Every 6 seconds (target block time):
├─ BABE randomly selects one validator (VRF - Verifiable Random Function)
├─ Selected validator authors block
├─ Block propagated to network
└─ Other validators import and verify

Key properties:

  • Probabilistic selection (validators can't predict when they'll be selected)
  • Parallel block production possible (forks resolved by GRANDPA)
  • Performance: ~6-second block times

GRANDPA (Finality)​

Purpose: Determine which blocks are irreversible.

How it works:

Validators vote on finality:
├─ Round 1: Prevote (suggest which block to finalize)
├─ Round 2: Precommit (commit to finalize if >2/3 agree)
├─ If >2/3 precommit → Block finalized ✅
└─ Finality rounds every ~30-60 seconds

Key properties:

  • Byzantine-fault-tolerant (works even if <1/3 validators malicious)
  • Asynchronous (network delays don't break finality)
  • Performance: Finality within ~60 seconds

👉 Detailed consensus explanation: Consensus Mechanisms

Substrate Framework​

Why Substrate?​

Pilier is built on Substrate (Parity Technologies' blockchain framework) because:

FeatureBenefit
Forkless UpgradesUpgrade blockchain without hard forks (runtime is WASM)
Modular PalletsReusable components (don't reinvent the wheel)
Battle-TestedUsed by Polkadot, Kusama, 100+ parachains
Built-In ConsensusBABE + GRANDPA included (no custom implementation)
Rust EcosystemMemory-safe, high-performance

What Substrate Provides​

Out-of-the-box:

  • P2P networking (libp2p)
  • Consensus (BABE, GRANDPA, AURA, PoW, etc.)
  • Storage (RocksDB + state trie)
  • RPC server (JSON-RPC, WebSocket)
  • Telemetry (metrics, monitoring)

What we customize:

  • Business logic (custom pallets: pallet-dpp, pallet-documents)
  • Governance model (tPIL voting instead of standard democracy pallet)
  • Economic model (PIL tokenomics, sponsored transactions)
  • Validator selection (Proof-of-Authority, not Proof-of-Stake)

Pilier-Specific Customizations​

1. Proof-of-Authority (Not Proof-of-Stake)​

Standard Substrate: Validators selected by financial stake (more tokens = more power).

Pilier: Validators selected by governance vote (institutional reputation, not money).

Why?

  • Validators = trusted institutions (universities, NGOs, public bodies)
  • Aligns with EU sovereignty mission
  • No slashing (reputation-based accountability instead)

2. Custom Pallets​

pallet-dpp: Digital Product Passports

// Create DPP for product
dpp.create(product_id, metadata)

// Update DPP lifecycle state
dpp.update_state(product_id, new_state, proof)

// Query DPP
dpp.get(product_id) → DPP data

pallet-documents: Immutable Timestamping

// Register document hash
documents.register(document_hash, metadata)

// Verify document exists
documents.verify(document_hash) → bool

pallet-agents: AI Agent Orchestration (Coming 2026)

// Deploy AI agent
agents.deploy(agent_config, permissions)

// Trigger agent execution
agents.execute(agent_id, input_data)

👉 Pallet documentation: Business Logic Pallets

3. Sponsored Transactions (Free Tier)​

Standard Substrate: Every transaction pays gas fee (paid by sender).

Pilier: Some transaction types are free for eligible users (paid by treasury).

How it works:

User creates DPP:
├─ Check: Is user eligible for sponsorship? (NGO, university, public body)
├─ If yes: Treasury pays gas fee (from User Credits & Civic Pool)
├─ If no: User pays gas fee (from their PIL balance)
└─ Transaction executes normally

Who qualifies:

  • NGOs with verified on-chain identity
  • Universities participating in research pilots
  • Public bodies (municipalities, prefectures)
  • Any entity with civic sponsorship (voted by tPIL holders)

👉 Free transaction policy: Governance Participation

4. PIL/tPIL Tokenomics​

PIL: Utility token (pay transaction fees, 1 PIL ≈ €1)

tPIL: Governance token (earned by locking PIL, non-transferable, 1 tPIL = 1 vote)

Unlike most blockchains:

  • PIL not traded on exchanges (operational token only)
  • tPIL requires time commitment (max 5× multiplier for 48-month lock)
  • Governance focused on protocol health, not speculation

👉 Full tokenomics: PIL Token Economics | Governance

Runtime Upgrades (Forkless)​

Traditional blockchains: Hard forks required for protocol upgrades (risky, contentious).

Pilier (Substrate-based): Forkless upgrades via governance.

How it works:

1. New runtime developed (Rust code)
2. Compiled to WASM (WebAssembly bytecode)
3. Governance proposal: "Upgrade runtime to v1.2.0"
4. If approved: New WASM uploaded to chain
5. All validators apply new runtime (no node restart)
6. Network seamlessly transitions to new logic ✅

Benefits:

  • No network split (everyone upgrades automatically)
  • No contentious forks (governance decides democratically)
  • Fast iteration (new features deployed in weeks, not months)

👉 Upgrade process: Runtime Upgrades

Security Model​

Validator Security​

Key properties:

  • Validators are institutional entities (universities, NGOs, public bodies)
  • No slashing (Proof-of-Authority, not Proof-of-Stake)
  • Reputation-based accountability (removal via governance if misbehave)
  • Charter obligations (99% uptime, 2-hour incident response)

Attack scenarios:

AttackMitigation
Validator compromisedSession keys rotated, governance removes validator if needed
<1/3 validators offlineNetwork continues (GRANDPA requires >2/3 for finality)
>2/3 validators colludePossible, but unlikely (institutional validators have reputations)
DDoS attack on validatorOther validators compensate, attacked validator mitigates

👉 Security procedures: Validator Security

Runtime Security​

Substrate's security features:

  • WASM sandboxing: Runtime executes in isolated environment (can't access filesystem, network)
  • Deterministic execution: Same inputs → same outputs (no random behavior)
  • Metered execution: Gas limits prevent infinite loops
  • Type safety: Rust prevents memory bugs (no buffer overflows)

Audits:

  • Runtime audited before mainnet launch
  • Continuous security reviews (quarterly)
  • Bug bounty program (coming Q2 2026)

👉 Security audits: Security

Performance Considerations​

Throughput​

Current capacity:

  • Block time: ~6 seconds
  • Block size: ~5 MB (configurable)
  • Transactions per block: ~500-1,000 (depends on transaction size)
  • Theoretical throughput: ~100-150 TPS (transactions per second)

Real-world performance:

  • DPP creation: ~0.5 KB per transaction → ~10,000 DPPs per block
  • Document timestamp: ~0.2 KB per transaction → ~25,000 timestamps per block

Optimization strategies:

  • Batching (submit multiple transactions in one extrinsic)
  • Off-chain storage (large metadata on IPFS/Arweave, only hash on-chain)
  • Parathread/Parachain (future: Polkadot integration for higher throughput)

Latency​

Transaction finality:

  • Submitted → Included in block: ~6-12 seconds (1-2 blocks)
  • Included → Finalized: ~60 seconds (GRANDPA finality)
  • Total: ~90 seconds for irreversible confirmation

Optimizations for better UX:

  • Show "pending" status after submission (instant feedback)
  • Show "included" status after block import (~10 seconds)
  • Show "finalized" status after GRANDPA finality (~90 seconds)

Scalability​

Current limits (Phase 1: Testnet/Early Mainnet):

  • Validators: 3-5 (PoA consensus)
  • Transactions: ~100 TPS (sufficient for target market)
  • Storage: ~50 GB pruned, ~500 GB archive

Future scaling strategies:

  • Increase validator count (5 → 10+ validators)
  • Parachains (Polkadot integration for 1,000+ TPS)
  • Layer 2 solutions (rollups for high-frequency operations)

Deep Dive: Learn More​

Want to explore specific components?

Blockchain Core​

Business Logic​

For Validators​

For Developers​

Summary​

Pilier's architecture in 60 seconds:

┌─────────────────────────────────────────────────┐
│ Substrate-based blockchain                      │
├─────────────────────────────────────────────────┤
│ Node Layer: BABE + GRANDPA consensus            │
│ Runtime Layer: Custom pallets (DPP, documents)  │
│ Storage Layer: RocksDB + state trie             │
│ Network Layer: libp2p P2P                       │
├─────────────────────────────────────────────────┤
│ Key Features:                                   │
│ • Forkless upgrades (WASM runtime)              │
│ • Proof-of-Authority (institutional validators) │
│ • Sponsored transactions (public utility)       │
│ • tPIL governance (time-weighted voting)        │
└─────────────────────────────────────────────────┘

Next steps: