Consensus Mechanism
Pilier uses Proof of Authority (PoA) consensus, where trusted institutional validators secure the network through reputation rather than computational power or economic stake.
This design prioritizes efficiency, sustainability, and civic alignment over decentralization maximalism.
Overview
What is Consensus?
Consensus is the mechanism by which a blockchain network agrees on:
- ✅ Which transactions are valid
- ✅ The order of transactions
- ✅ The current state of the ledger
Without consensus: Every node could have a different version of truth → chaos.
With consensus: All honest nodes agree on the canonical chain → trust.
Why Proof of Authority?
Pilier's mission is to serve as a Civic Trust Layer for European supply chains and public institutions. This requires:
- Predictable costs (no gas price volatility)
- Energy efficiency (no wasteful mining)
- Institutional credibility (validators you can identify and trust)
- EU sovereignty (validators subject to European jurisdiction)
PoA delivers all four.
Pilier's PoA Model
Validators: 5-10 institutional entities (universities, NGOs, chambers of commerce)
Selection: Governance vote (tPIL-weighted) after technical audit
Incentives: Fee revenue + inflation subsidy (~€500/month target)
Accountability: Reputation, legal contracts (Validator Charter), insurance
No slashing: Validators risk institutional reputation, not tokens
Proof of Authority Explained
How PoA Works
Core principle: A small set of pre-approved, identified validators produce blocks in turns.
Validator set: [University-Lyon, NGO-WWF, Chamber-Paris, Pilier-Node-1, Pilier-Node-2]
Block 1000: University-Lyon produces
Block 1001: NGO-WWF produces
Block 1002: Chamber-Paris produces
Block 1003: Pilier-Node-1 produces
Block 1004: Pilier-Node-2 produces
Block 1005: University-Lyon produces (round-robin repeats)
Key properties:
- ✅ Deterministic (you know who produces next block)
- ✅ Fast (6-second block time)
- ✅ Efficient (no mining, minimal energy)
- ✅ Accountable (validators are known entities)
PoA vs. Other Consensus Mechanisms
| Feature | PoA (Pilier) | PoW (Bitcoin) | PoS (Ethereum) | DPoS (EOS) |
|---|---|---|---|---|
| Energy use | Minimal | Massive | Low | Low |
| Speed | 6s blocks | 10 min blocks | 12s blocks | 0.5s blocks |
| Finality | 2-3 blocks (~12s) | ~60 min | ~15 min | Instant |
| Validator identity | Known (institutions) | Anonymous | Pseudonymous | Elected delegates |
| Decentralization | Low (5-10 validators) | High (1000s miners) | Medium (100k+ stakers) | Low (21 delegates) |
| Plutocracy risk | None (governance, not wealth) | None | High (rich stake more) | High (vote buying) |
| Civic alignment | ✅ High | ❌ None | ❌ None | ⚠️ Depends |
| EU sovereignty | ✅ Yes | ❌ Global | ❌ Global | ❌ Global |
| Sybil resistance | Identity verification | Computational work | Economic stake | Voting |
Why not PoW?
- ❌ Energy waste (Bitcoin = ~150 TWh/year, equivalent to Argentina)
- ❌ Slow finality (transactions take ~60 minutes to be irreversible)
- ❌ No accountability (miners are anonymous)
Why not PoS?
- ❌ Plutocracy (validators with more tokens earn more rewards → rich get richer)
- ❌ Validator anonymity (don't know who secures the network)
- ❌ Complex slashing (institutional validators prefer legal contracts over on-chain penalties)
Why not DPoS?
- ❌ Vote buying (delegates bribe token holders)
- ❌ Cartel formation (top 21 validators collude)
- ❌ Still plutocratic (token-weighted voting)
Why PoA?
- ✅ Validators are identifiable institutions with real-world reputation at stake
- ✅ Efficiency matches Pilier's use case (DPP creation, not DeFi speculation)
- ✅ Aligns with Civic Trust Layer narrative (who do you trust more: anonymous miner or University of Lyon?)
Validator Set
Current Validators (Testnet)
| Validator | Operator | Location | Status |
|---|---|---|---|
| validator-core-01 | Pilier Foundation | Paris, FR | Active |
| validator-core-02 | Pilier Foundation | Lyon, FR | Active |
| validator-core-03 | Pilier Foundation | Tbilisi, GE | Active |
Mainnet target: 5-10 validators by Q4 2026
Institutional Validator Pipeline
In discussion:
- 🎓 University of Lyon (Computer Science Dept)
- 🌍 WWF France (supply chain transparency)
- 🏛️ Lyon Chamber of Commerce (SME support)
Future targets:
- Universities (research institutions)
- NGOs (environmental, social impact)
- Chambers of Commerce (business associations)
- Government agencies (post-maturity, 2028+)
Why Institutional Validators?
Reputation alignment:
Anonymous crypto miner:
├─ No reputation to lose
├─ Profit-maximizing behavior
└─ Can disappear anytime
University of Lyon:
├─ 150-year institutional reputation
├─ Public accountability
├─ Long-term research mission
└─ Cannot "exit scam"
Legal accountability:
Crypto validator:
├─ Anonymous
├─ No legal entity
└─ No recourse if malicious
Institutional validator:
├─ Registered legal entity
├─ Signed Validator Charter
├─ Insurance (€50k liability)
└─ Subject to French/EU law
Mission alignment:
DeFi validator: Maximize MEV, prioritize high-fee transactions
Civic validator: Support public good mission, prioritize
NGO timestamps, educational use cases
Validator Requirements
Technical Requirements
Hardware minimum:
CPU: 4 cores (8 recommended)
RAM: 16 GB (32 GB recommended)
Storage: 500 GB NVMe SSD (1 TB recommended)
Network: 100 Mbps symmetric (1 Gbps recommended)
Uptime: 99.5% SLA (target 99.9%)
Software:
OS: Ubuntu 22.04 LTS or 24.04 LTS
Runtime: Polkadot SDK node (compiled binary or Docker)
Monitoring: Prometheus + Grafana stack
Backups: Daily snapshots, 30-day retention
Estimated hosting cost: €200-€400/month (OVH, Hetzner, AWS)
Organizational Requirements
Legal entity:
- Must be registered organization (university, NGO, chamber, foundation)
- NOT: Individual, anonymous entity, offshore company
Validator Charter:
- Sign legally binding Validator Charter
- Commit to:
- 99.5% uptime SLA
- Execute governance decisions (unless security/legal conflict)
- Maintain infrastructure security
- Participate in emergency coordination
- Transparent communication with community
Insurance:
- Liability insurance (€50k minimum coverage)
- Covers validator negligence, infrastructure failure
Geographic diversity:
- Prefer validators in different EU countries
- Target: No more than 40% validators in single country
Application Process
Step 1: Expression of Interest
Submit EOI to validators@pilier.net:
- Organization details
- Mission alignment statement
- Technical capacity overview
Step 2: Technical Audit
Duration: 2-4 weeks
Pilier provides:
├─ Testnet access
├─ Configuration templates
└─ Monitoring setup guide
Validator demonstrates:
├─ Node setup (testnet)
├─ 30-day uptime (>99.5%)
└─ Security audit passed
Step 3: Governance Vote
Submit proposal to tPIL governance:
- Validator details
- Technical audit results
- Mission alignment case
Threshold: 75% approval + 20% quorum
Step 4: Onboarding
Duration: 30 days
Week 1-2: Mainnet sync, key generation
Week 3: Shadow validator (observe, don't produce)
Week 4: Full activation
Block Production
AURA Consensus
Pilier uses AURA (Authority Round) for block production:
How it works:
1. Validators take turns producing blocks (round-robin)
2. Each validator's turn lasts 6 seconds (one slot)
3. Validator signs block with their session key
4. Other validators verify signature
5. Block propagated to network
Block time: 6 seconds (deterministic)
Miss a slot? Skip to next validator (no penalty, but telemetry recorded)
Advantages:
- ✅ Predictable (transactions confirmed in ~12 seconds)
- ✅ Efficient (no mining competition, no wasted blocks)
- ✅ Simple (easy to reason about)
GRANDPA Finality
While AURA produces blocks, GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) provides finality:
What is finality? Finality means a block cannot be reverted. Once finalized, transactions are irreversible.
How GRANDPA works:
1. Validators vote on chains (not individual blocks)
2. If 2/3+ validators agree on a chain, all blocks in that chain are finalized
3. Typically finalizes in 2-3 blocks (~12-18 seconds)
Why this matters:
Bitcoin: ~60 minutes for finality (6 confirmations)
Ethereum: ~15 minutes for finality (32 slots)
Pilier: ~12 seconds for finality (2-3 blocks)
→ DPP created, finalized, legally binding in <20 seconds
Block Production Flow
Timeline:
t=0s: Transaction submitted
t=6s: Block produced (AURA)
t=12s: Block finalized (GRANDPA)
t=18s: Transaction irreversible ✓
Validator Economics
Income Sources
Validators earn revenue from two sources:
1. Transaction fees (primary)
Fee structure:
- DPP creation: 0.004 PIL
- Timestamp: 0.0025 PIL
- Agent action: 0.001-0.01 PIL
Fee distribution:
├─ 95% to validators (split equally)
└─ 5% burned (deflationary pressure)
Example (5 validators, 10k DPPs/month):
10,000 DPP × 0.004 PIL = 40 PIL fees
40 PIL × 95% = 38 PIL to validators
38 PIL / 5 validators = 7.6 PIL per validator
= ~€7.60/validator/month from fees
2. Inflation subsidy (bootstrap only)
Annual inflation: 2.5% (75,000 PIL/year)
Monthly emission: 6,250 PIL/month
Validator share: 100% (during bootstrap)
Example (5 validators):
6,250 PIL / 5 = 1,250 PIL per validator
= ~€1,250/validator/month from inflation
Total income (Year 1):
Fees: €7.60/month
Inflation: €1,250/month
Total: ~€1,257/month per validator
Target income: €500/month (comfortable margin in Year 1)
See Tokenomics for detailed economics.
Path to Self-Sustainability
Year 1 (2026): Low transaction volume
- Fee income: €10-€50/month
- Inflation subsidy: €1,200+/month
- Status: Fully subsidized
Year 2 (2027): Growing adoption
- Fee income: €200-€400/month
- Inflation subsidy: €300-€500/month
- Status: Partially subsidized
Year 3+ (2028+): Mature network
- Fee income: €500+/month
- Inflation subsidy: €0-€100/month (declining)
- Status: Self-sustaining
Goal: Validators earn €500/month from fees alone by end of Year 3.
Security Model
Byzantine Fault Tolerance
BFT assumption: Up to 1/3 of validators can be malicious or offline without compromising network integrity.
Pilier's validator set:
5 validators: Can tolerate 1 Byzantine
7 validators: Can tolerate 2 Byzantine
10 validators: Can tolerate 3 Byzantine
Example:
Scenario: 7 validators total, 2 go rogue
Byzantine validators (2):
├─ Produce invalid blocks
└─ Vote against finality
Honest validators (5):
├─ Reject invalid blocks (majority)
├─ Continue GRANDPA finality (>2/3)
└─ Network operates normally ✓
Result: Attack fails, honest chain prevails
Why No Slashing?
Most PoS chains: Validators lose staked tokens if they misbehave (double-signing, extended downtime).
Pilier's approach: No on-chain slashing. Instead, rely on:
1. Reputational risk
University validator caught misbehaving:
├─ Front-page news: "Lyon University hacks blockchain"
├─ Reputational damage: priceless
├─ Research funding at risk
└─ Public accountability
€500/month income << reputation value
2. Legal contracts
Validator Charter includes:
├─ SLA commitments (99.5% uptime)
├─ Liability clauses (€50k insurance)
├─ Termination conditions
└─ Dispute resolution (French law)
Breach = legal consequences, not just token loss
3. Governance removal
If validator consistently underperforms:
├─ Community submits removal proposal
├─ tPIL governance votes (75% threshold)
├─ Validator gracefully exits (30-day notice)
└─ Replacement validator onboarded
No tokens slashed, but validator removed from set
Why this works:
- Institutional validators have more to lose (reputation) than crypto-native validators (tokens)
- Legal accountability > economic penalties for regulated entities
- Simplifies operations (no complex slashing appeals, no accidental penalties)
Attack Scenarios & Mitigations
1. Validator Censorship
Attack:
Validator refuses to include certain transactions:
- Competitor's DPPs
- Transactions from blacklisted addresses
Mitigation:
AURA round-robin: Next validator includes transaction
Impact: Max 6-second delay (one missed slot)
If persistent:
├─ Community detects via telemetry
├─ Governance vote to remove validator
└─ Validator replaced
2. Validator Cartel
Attack:
3 out of 5 validators collude:
├─ Censor specific users
├─ Prioritize own transactions
└─ Vote to remove honest validators
Mitigation:
Diversity requirements:
├─ Geographic (different countries)
├─ Organizational (university, NGO, chamber)
└─ Mission-driven (not profit-maximizing)
Economic disincentive:
├─ Cartel benefits < reputational risk
├─ Universities don't collude for €500/month
Governance check:
├─ Requires 75% tPIL vote to remove validator
└─ Community (broader than validators) decides
3. Validator Downtime
Attack:
Validator hardware fails, ISP outage, DDoS attack
→ Validator offline for hours/days
Mitigation:
Immediate:
├─ AURA skips offline validator (network continues)
├─ Other validators maintain >2/3 majority for finality
└─ Impact: Slightly slower block production (if <5 validators)
Short-term:
├─ Validator monitoring alerts operator
├─ Backup/disaster recovery activated
└─ Back online within hours
Long-term:
├─ If downtime >24 hours: Community notified
├─ If downtime >7 days: Governance vote to remove
└─ Persistent downtime = Charter violation
4. Network Split
Attack:
Network partitioned (e.g., internet outage splits EU from rest):
├─ 3 validators in Partition A
├─ 2 validators in Partition B
└─ Both partitions try to produce blocks
Mitigation:
GRANDPA finality prevents split:
├─ Partition A (3 validators) = >2/3 majority → can finalize
├─ Partition B (2 validators) = <2/3 majority → cannot finalize
Result:
├─ Partition A continues producing finalized blocks
├─ Partition B produces blocks but cannot finalize
└─ When network heals, Partition B reorgs to Partition A
No permanent split, no double-spend ✓
Validator Onboarding
Become a Validator
Who should apply?
✅ Good fits:
- Universities with research alignment (supply chains, sustainability)
- NGOs with transparency mission (environmental, social impact)
- Chambers of Commerce supporting SMEs
- Foundations aligned with civic mission
❌ Poor fits:
- Anonymous entities
- Profit-maximizing crypto companies
- Individuals (no institutional backing)
- Offshore companies with unclear governance
Application Checklist
Before applying, ensure you have:
- Registered legal entity (university, NGO, foundation, chamber)
- Technical capacity (dedicated server or budget for hosting)
- Mission alignment (read Pilier's vision at pilier.org/about)
- Long-term commitment (minimum 2-year horizon)
- Budget for insurance (€50k liability coverage)
- Technical staff (DevOps or willingness to hire)
Timeline & Expectations
From application to mainnet validator:
Month 1: Application & initial review
├─ Submit EOI
├─ Technical capacity assessment
└─ Mission alignment interview
Month 2: Testnet validation
├─ Node setup (with Pilier support)
├─ 30-day testnet operation (>99.5% uptime)
└─ Security audit
Month 3: Governance & onboarding
├─ Submit governance proposal
├─ Community discussion & vote
└─ If approved: Mainnet onboarding (30 days)
Total: ~3-4 months from EOI to active mainnet validator
Support for New Validators
Pilier provides:
✅ Technical documentation:
- Node setup guides
- Configuration templates
- Monitoring dashboards (Prometheus + Grafana)
✅ Dedicated support:
- Slack channel for validators
- Monthly validator calls
- Emergency coordination procedures
✅ Financial assistance (optional):
- Infrastructure grants (€5k-€10k) for first year
- Available from Treasury (governance approval required)
FAQ
Why no slashing?
Institutional validators risk their reputation, which is more valuable than tokens. A university caught misbehaving faces public scandal, funding loss, and credibility damage. This is a stronger deterrent than losing €10k in tokens.
Additionally, legal contracts (Validator Charter + insurance) provide accountability without complex on-chain slashing logic.
Can validators censor transactions?
Technically: yes, for one block.
If a validator refuses to include your transaction, they can skip it during their 6-second slot. However:
- Next validator (6 seconds later) includes it
- Max delay: 6 seconds per censoring validator
- Persistent censorship triggers governance removal
Realistically: no.
Universities and NGOs won't risk reputation to censor a €0.004 DPP transaction.
What if a validator goes offline?
Short-term (minutes-hours): AURA skips their slot. Other validators continue. Network operates normally.
Medium-term (days): Validator alerted via monitoring. Backup systems activated.
Long-term (>7 days): Governance vote to remove validator. Replacement onboarded.
Impact on users: Negligible. You might experience one 6-second delay if transaction lands in offline validator's slot.
How decentralized is Pilier?
Validator count: 5-10 (low compared to Ethereum's 1M+ validators)
Geographic distribution: Europe-focused (validators in FR, DE, BE, etc.)
Why this trade-off?
Pilier prioritizes trust and efficiency over decentralization maximalism. For a civic infrastructure serving European SMEs and public institutions, having 10 known, accountable validators (universities, NGOs) is more trustworthy than 1,000 anonymous miners.
Comparison:
- Bitcoin: ~10 mining pools control >80% hashrate (functionally ~10 validators)
- Ethereum: 1M+ validators but majority stake held by Lido, Coinbase, Kraken (functionally ~5 entities)
- Pilier: 5-10 institutional validators (honest about centralization)
Can Pilier become more decentralized later?
Yes, via governance.
As the network matures and more institutions apply, tPIL governance can vote to:
- Increase validator set size (e.g., 10 → 20 validators)
- Expand to non-EU validators (after EU foundation solid)
- Lower technical barriers (enable smaller organizations)
Roadmap:
- 2026: 5-10 validators (bootstrap)
- 2027-2028: 15-20 validators (EU expansion)
- 2029+: 30+ validators (global, if community wants)
However, Pilier will never become anonymous/permissionless PoW/PoS. Institutional identity is core to the mission.
Why 6-second block time?
Trade-off between speed and network stability:
- Faster (e.g., 3s): Risk of network delays causing missed slots, temporary forks
- Slower (e.g., 12s): Unnecessarily slow for users (DPP creation feels sluggish)
6 seconds is the sweet spot:
- Fast enough for good UX ( less than 10s to finality)
- Slow enough for stable propagation (validators across Europe)
Real-world impact:
User uploads document → DPP created
Block produced: 6s
Block finalized: 12s
Legal timestamp: Immutable in <20 seconds ✓
How does GRANDPA finality work?
Simple explanation:
GRANDPA is a finality gadget. While AURA produces blocks, GRANDPA votes on chains (not individual blocks).
Validators vote: "I agree that Block 1000 and all ancestors are correct"
If 2/3+ validators agree → entire chain up to Block 1000 is finalized
Why this is powerful:
Traditional blockchains finalize one block at a time. GRANDPA finalizes hundreds of blocks in one vote.
Impact: Even if network temporarily lags (slow validators, network issues), when GRANDPA finalizes, it catches up instantly (finalizes all pending blocks in one round).
Can validators collude to change history?
No, even with 100% validator collusion.
Once a block is finalized by GRANDPA, it's irreversible. Validators cannot reorg finalized blocks without:
- Releasing a new client with different finality rules
- Convincing all users to upgrade
- Essentially creating a new blockchain (hard fork)
In practice: If all validators tried to rewrite history, users would reject the malicious chain. Validators would lose reputation, be removed via governance, and replaced.
Bottom line: Finalized = immutable, even against validator collusion.
Next Steps
For Users
Nothing to do! Consensus is fully transparent. Your transactions are included, finalized, and secured automatically.
Want to track? Use explorer.pilier.net to see:
- Recent blocks (6-second updates)
- Which validator produced each block
- Finality status (finalized in ~12 seconds)
For Institutions Interested in Validating
- Read the Validator Charter → Validator Charter
- Assess technical capacity → Technical Requirements
- Submit Expression of Interest → validators@pilier.net
- Join the conversation → Validator Telegram
For Developers
Query consensus state:
# Get current validator set
curl https://rpc.pilier.net \
-d '{"method":"consensus_validators"}'
# Get latest finalized block
curl https://rpc.pilier.net \
-d '{"method":"chain_getFinalizedHead"}'
# Get block author
curl https://rpc.pilier.net \
-d '{"method":"chain_getBlock", "params":["BLOCK_HASH"]}'
Monitor consensus:
Questions? Join the discussion:
- Forum: forum.pilier.net/consensus
- Validators: t.me/pilier_validators
- Docs: docs.pilier.net/validators