Skip to main content

Validator Responsibilities

What does a Pilier validator actually do? This guide explains the operational duties and expectations.

Reading time: 10 minutes

Core Responsibilities​

Validators have five core responsibilities:

  1. Block Production (author blocks via BABE)
  2. Finality Voting (vote on finality via GRANDPA)
  3. Security Response (respond to incidents within 2 hours)
  4. Governance Participation (vote on proposals, provide input)
  5. Communication (maintain 24/7 emergency contact)

Key principle: Validators don't babysit nodes—the software runs autonomously. Validators respond to events (incidents, proposals, upgrades).

1. Block Production (BABE)​

What is BABE?​

BABE (Blind Assignment for Blockchain Extension) is Pilier's block production mechanism.

How it works:

Every 6 seconds (target block time):
├─ BABE randomly selects one validator
├─ Selected validator authors the next block
├─ Block propagates to network
└─ Other validators import and verify block

Random selection: Based on VRF (Verifiable Random Function)—validators can't predict when they'll be selected, preventing manipulation.

Expected Performance​

If validator set has N validators, each should author ~1/N of blocks.

Example (5 validators):

24 hours = 14,400 blocks (at 6-second block time)
Expected per validator: 14,400 / 5 = 2,880 blocks

Actual performance:
├─ validator-lyon-01: 2,850 blocks (99.0%) ✅
├─ validator-paris-01: 2,920 blocks (101.4%) ✅
├─ validator-berlin-01: 2,100 blocks (72.9%) ⚠️
└─ Average: Should be close to expected

What if performance is low?

  • <90% for 7 consecutive days → Warning issued
  • <80% for 14 days → Governance review
  • <50% for 30 days → Removal proposal likely

What Happens if You Miss Your Slot?​

Short-term: Network compensates automatically

Validator-lyon-01 selected but offline:
├─ BABE waits ~6 seconds
├─ No block produced (empty slot)
├─ Next validator selected
└─ Network continues (minor delay)

Impact: Slightly longer block times, but no catastrophic failure.

Long-term: Persistent missed blocks harm network performance and trigger removal process.

Do You Need to Monitor Block Production?​

No manual intervention required. Node software handles block production automatically.

What validators should do:

  • ✅ Monitor alerts (if node stops producing blocks entirely)
  • ✅ Check telemetry weekly (verify proportional block production)
  • ❌ Don't micromanage (no need to watch every block)

2. Finality Voting (GRANDPA)​

What is GRANDPA?​

GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) is Pilier's finality mechanism.

Finality = irreversible: Once a block is finalized, it can never be reverted (unlike Bitcoin where blocks can be reorged).

How GRANDPA Works​

Step 1: Validators author blocks (via BABE)
Step 2: Validators vote on which block to finalize
Step 3: If >2/3 validators agree → block is final
Step 4: Repeat for next block

Key requirement: >2/3 validators must participate in voting.

Example (5 validators):

For finality:
├─ Need: 2/3 × 5 = 3.33 → round up to 4 validators
├─ If 4+ vote: Block finalized ✅
├─ If <4 vote: Finality stalls ❌

Expected Performance​

100% participation required.

Validators should cast votes in every finality round (approximately every 30-60 seconds).

Monitoring:

Finality participation:
├─ Rounds in last 30 days: 43,200
├─ Votes cast by validator-lyon-01: 43,200
└─ Participation: 100% ✅

What if you miss votes?

  • Occasional misses (network hiccups): Acceptable
  • <95% for 7 days: Warning issued
  • <90% for 14 days: Governance review
  • Persistent non-voting (>30 days): Removal proposal

Why 100% Participation Matters​

Finality delays harm user experience:

Normal finality: Blocks final in ~60 seconds
Missing validators: Finality delayed by minutes/hours
If <2/3 validators online: Finality halts completely

User impact:

  • Transactions appear "pending" for longer
  • Exchanges may pause deposits/withdrawals
  • Network credibility damaged

Bottom line: Your GRANDPA votes are critical for network health.

3. Security Response​

Incident Response Time​

Critical incidents: <2 hours High priority: <24 hours Medium/Low: <7 days

Critical Incidents (2-hour response)​

IncidentYour Action
Key compromiseRotate session keys immediately, notify security@pilier.org
Network attack (DDoS, eclipse)Alert @pilier_validators, execute containment (see Security Procedures)
Runtime bug (consensus-breaking)Stop node if instructed, coordinate emergency governance
Node crash (won't restart)Debug logs, failover to backup if available

Communication protocol:

1. Detect incident (via monitoring alerts)
2. Alert other validators (Telegram @pilier_validators)
3. Notify core team (security@pilier.org)
4. Execute containment (follow incident playbook)
5. Document incident (post-mortem within 48 hours)

High Priority Incidents (24-hour response)​

IncidentYour Action
Hardware failure (disk full, RAM exhausted)Upgrade hardware, restore from backup
Performance degradation (<90% block production)Debug (network issues? resource limits?), fix root cause
Missed runtime upgradeUpdate node binary, sync to latest runtime

Medium/Low Priority (7-day response)​

IncidentYour Action
Certificate expirationRenew TLS/SSL certificates
Monitoring alerts misconfiguredTune alert thresholds
Telemetry data gapsRe-enable telemetry reporting

What If You Can't Respond in Time?​

Planned unavailability:

  • Notify @pilier_validators 48 hours in advance
  • Arrange coverage (another validator on standby)
  • Keep downtime <2 hours

Unplanned unavailability (emergency):

  • Notify as soon as possible
  • Provide ETA for resolution
  • If >24 hours: May trigger temporary failover discussion

Persistent unavailability (>10 days):

4. Governance Participation​

Why Validators Must Participate​

Validators are infrastructure operators. Governance decisions directly affect your operations:

  • Runtime upgrades: You must update node binary
  • Fee adjustments: Changes network operational costs
  • Validator set changes: Your peers join/leave
  • Treasury allocations: Affects ecosystem growth

If you don't vote, others decide for you.

Expected Participation​

Minimum: Vote on proposals that affect validator operations

Recommended: Vote on all proposals (you're a civic institution—your voice matters)

Tracking:

Validator governance activity (last 90 days):
├─ Total proposals: 12
├─ Validator-lyon-01 voted on: 11 (92%) ✅
├─ Validator-berlin-01 voted on: 3 (25%) ⚠️
└─ Expected: >80% participation

Low participation consequences:

  • <50% for 6 months: Warning issued
  • <20% for 12 months: May trigger removal proposal
  • No votes ever: Charter violation

How to Vote​

Option 1: Governance Portal (easiest)

1. Visit governance.pilier.net
2. Connect wallet (validator account)
3. Browse active proposals
4. Click "Vote" → Select Aye/Nay/Abstain
5. Sign transaction (0 fee for validators)

Option 2: CLI (for automation)

pilier-cli governance vote \
  --proposal-id 42 \
  --vote aye \
  --account validator-lyon-01

What If You Disagree with a Proposal?​

Vote "Nay" and explain why:

1. Vote "Nay" on proposal
2. Comment on forum thread (forum.pilier.net/governance/proposal-42)
3. Provide technical/economic rationale
4. Suggest alternative approach (if applicable)

Validator veto power:

  • If 3/5 validators vote "Nay" on existential threat proposals
  • Must provide alternative solution within 30 days
  • Rare—only for proposals that would kill network (e.g., fees → 0)

Full details: Governance Participation

5. Communication​

24/7 Emergency Contact​

Required: Validator must provide emergency contact

Contact info (submitted during onboarding):
├─ Primary email: validators@pilier.net
└─ Phone (24/7): +33 X XX XX XX XX

Tested quarterly: Core team sends test alert to verify contact is active.

Incident Reporting​

When to report:

  • Any downtime >1 hour
  • Security incidents (key compromise, attack)
  • Performance degradation (<90% block production)
  • Hardware failures

How to report:

1. Alert @pilier_org/validators (Telegram) immediately
2. Send formal incident report to validators@pilier.net within 48 hours
3. Publish post-mortem on forum (if significant impact)

Template: See Security Procedures

Regular Communication​

Weekly (optional but recommended):

  • Check @pilier_validators Telegram for announcements
  • Review governance proposals

Monthly (recommended):

  • Check performance metrics (telemetry.pilier.net)
  • Claim rewards (if not auto-claimed)
  • Review security logs

Quarterly (required):

  • Respond to emergency contact test
  • Review Charter for any amendments

Code of Conduct​

Integrity​

Do:

  • ✅ Act in network's best interest (not personal gain)
  • ✅ Disclose conflicts of interest
  • ✅ Be transparent about issues

Don't:

  • ❌ Accept bribes to vote certain way
  • ❌ Collude with other validators to manipulate governance
  • ❌ Vote on proposals that directly benefit your entity (unless disclosed)

Example conflict:

Scenario: Proposal to grant 50,000 PIL to your entity

Correct action:
├─ Abstain from voting (or vote but disclose conflict)
├─ Explain conflict in forum comment
└─ Let other validators decide

Incorrect action:
├─ Vote "Aye" without disclosure ❌
└─ May trigger Charter violation review

Collaboration​

Do:

  • ✅ Help onboard new validators
  • ✅ Share knowledge (document learnings, contribute to wiki)
  • ✅ Report bugs (submit GitHub issues)
  • ✅ Respond to other validators' questions

Example:

validator-lyon-01 experiences networking issue:
├─ Debugs and resolves (firewall misconfiguration)
├─ Documents solution in forum post
├─ Other validators benefit from shared knowledge ✅

Don't:

  • ❌ Hoard knowledge ("secret sauce" mentality)
  • ❌ Ignore requests for help from other validators
  • ❌ Blame others for network issues without evidence

Professionalism​

Do:

  • ✅ Communicate respectfully (even in disagreements)
  • ✅ Be responsive (reply to messages within 48 hours)
  • ✅ Admit mistakes (we all make them)

Don't:

  • ❌ Personal attacks or harassment
  • ❌ Toxic behavior in Telegram/forum
  • ❌ Ghosting (disappearing without notice)

Transparency​

Do:

  • ✅ Report downtime honestly (don't cover up)
  • ✅ Disclose security incidents promptly
  • ✅ Publish post-mortems for significant issues

Don't:

  • ❌ Hide problems hoping no one notices
  • ❌ Blame "mysterious" issues without investigation
  • ❌ Refuse to share incident details (unless security-sensitive)

Consequences for Violations​

Minor Violations​

Examples: Occasional missed votes, late incident reports

Consequence: Informal warning from core team or other validators

Moderate Violations​

Examples:

  • Low governance participation (<50% for 6 months)
  • Repeated missed incident reports
  • Unprofessional communication

Consequence:

  • Formal warning (email + forum post)
  • 30-day improvement plan
  • If not resolved: Escalates to major violation

Major Violations​

Examples:

  • Persistent downtime (>10 consecutive days)
  • Undisclosed conflicts of interest
  • Malicious behavior (censorship, double-signing)
  • Charter violations

Consequence:

  • Governance removal proposal (75% approval + 20% quorum)
  • If approved: Validator removed after 30-day notice
  • Appeal process available (see Removal Process)

Performance Monitoring​

Where to check your performance:

Telemetry dashboard:

Block explorer:

Governance portal:

Self-hosted (recommended):

  • Prometheus + Grafana dashboard
  • Custom alerts (email/SMS when issues detected)

Summary: Daily Life as a Validator​

Day-to-day reality:

Most days: Nothing to do (node runs autonomously)
├─ Check alerts in morning (5 min)
├─ Glance at Telegram for announcements (5 min)
└─ Node hums along, produces blocks, votes on finality ✅

Once a week:
├─ Check governance proposals (15 min)
├─ Vote on proposals (5 min per proposal)
└─ Review performance metrics (10 min)

Once a month:
├─ Claim rewards (5 min, if not auto-claimed)
├─ Convert PIL to EUR if needed (see Compensation guide)
└─ Review security logs (15 min)

Once a quarter:
├─ Respond to emergency contact test (1 min)
├─ Review Charter amendments (if any)
└─ Check insurance renewal (if applicable)

Rare events:
├─ Security incident (immediate response, document)
├─ Runtime upgrade (update node binary, 30 min)
├─ Hardware failure (restore from backup, 1-4 hours)

Total time investment: ~2-5 hours per month (routine) + emergency response as needed

Next Steps​

Understand your responsibilities?

  1. ✅ Read Compensation (how you get paid for this work)
  2. ✅ Review Security Procedures (incident response details)
  3. ✅ Check Governance Participation (how to vote effectively)
  4. 📧 Ready to apply? See Onboarding Guide

Support​

📧 Email: validators@pilier.net
💬 Telegram: @pilier_org/validators
🌐 Forum: forum.pilier.net/validators
📞 Emergency: +33 X XX XX XX XX (24/7)