PIP-65: Economic Model for VEBloP Architecture

Polygon Improvement Proposals Canonical PIPs
1

Title: PIP-65: Economic Model for VEBloP Architecture
Author: Jerry Chen ([email protected])
Description: Proposes an economic model and fee redistribution mechanism for the Validator-Elected Block Producer (VEBloP) architecture.
Status: Draft
Type: Core
Date: 2025-05-08

Disclaimer: This document outlines a proposed economic model to complement the Validator-Elected Block Producer (VEBloP) architecture. Specific parameters like the commission rate and implementation details of the distribution mechanism are subject to further analysis and refinement. It is important to note that this proposal specifically addresses the block production architecture and associated transaction fee distribution mechanism. The existing staking rewards earned by validators for their participation in proposing and signing checkpoints on Heimdall and L1 remain unaffected by these changes.

Abstract

This proposal defines an economic model designed to function alongside the Validator-Elected Block Producer (VEBloP) architecture proposed in PIP-64. Recognizing that VEBloP alters how transaction fees accrue, this PIP introduces a fee redistribution mechanism. The goal is to ensure continued economic viability for validators who perform crucial verification duties but no longer directly produce blocks, thereby maintaining the security and decentralization of the Polygon PoS network. The core proposal involves distributing network fees between the active block producer and the validator set.

Motivation

The introduction of the Validator-Elected Block Producer (VEBloP) architecture (detailed in PIP-64) focuses block production on specialized validators with the appropriate hardware requirements to enhance throughput and finality. A direct consequence is that transaction fees, traditionally collected by the producer of each block, would accrue solely to the single active block producer.

While VEBloP lowers hardware costs for non-producing validators through stateless validation, the loss of direct transaction fee revenue could negatively impact their economic incentive to participate in the network. Maintaining a robust, decentralized set of validators is critical for network security and integrity.

Therefore, a revised economic model is necessary to:

  1. Compensate Validators: Provide validators with fair rewards for their essential role in block verification, consensus participation, and data availability, even without producing blocks.
  2. Reward Block Producers: Provide a specific incentive for the entity undertaking the specialized, potentially higher-cost role of block production.
  3. Maintain Network Security: Align economic incentives with network health and security contributions (i.e., stake).
  4. Align Validator Incentives With Network Growth: Ensure that all validators are economically aligned with increasing the number of transactions (and associated fees) on the Polygon chain.

This proposal addresses these needs by explicitly defining how network fees should be distributed in the VEBloP era.

Specification

The proposed economic model introduces a mechanism for collecting and redistributing network fees generated on the Polygon PoS chain under the VEBloP architecture, while also incentivizing active validator participation.

  1. Fee Pooling: All relevant network fees (primarily transaction fees and potentially MEV fees) generated within a given period (e.g., per checkpoint) will be directed to a dedicated smart contract system.
  2. Distribution Mechanism: The pooled fees within the smart contract will be programmatically divided based on protocol parameters:
    • Total Fee: Total fee (T) collected in a checkpoint (Transaction Fees + MEV Fees)
    • Block Producer Commission Pool Calculation: An overall commission rate (C) determines the total pool allocated to block producers. (CommissionPool = T * C)
    • Producer Commission Distribution: This CommissionPool is further divided to reward individual producers (p) based on two factors:
      • An ‘Equal Share’ component (CommissionPool * E / Np where E is the equal share factor and Np is the number of active producers) distributed evenly among all designated producers for the period.
      • A ‘Proportional Share’ component (CommissionPool * P * (Bp / B_total) where P is the proportional share factor, Bp is blocks produced by p, and B_total is total blocks) distributed based on the number of blocks each producer contributed.
      • The sum of these components forms the commission reward (Rp_commission) for producer p. (Note: The producer’s total reward also includes any validator rewards Rv_bp earned separately if they participate in validation).
    • Validator Allocation Pool: The remaining portion of total fees forms the pool initially available for validator distribution (Pool_validators = T * (1 - C)).
  3. Validator Reward Calculation & Adjustment: Each validator’s potential reward from the validator allocation pool is calculated based on their proportional stake. This potential reward is then adjusted based on performance (Pv):
    • The Pool_validators is distributed among all participating validators. Each validator v’s share is determined by their “performance-weighted stake.” This is calculated based on their actual stake (Sv) multiplied by their performance score (Pv).
    • Validators with higher performance scores and/or higher stakes will receive a proportionally larger share of the Pool_validators. Conversely, if a validator’s performance (Pv) is low (e.g., due to missed participation or incorrect votes), their share of the pool will be correspondingly reduced. This effectively means that the portion of fees “unearned” by underperforming validators is automatically redistributed among the other validators based on their relative performance-weighted stakes.
  4. Commission Rate:
    • Initial Values: The overall base commission rate (C) and the split factors (E, P) will initially be fixed percentages (e.g., C=20%, E=60%, P=40%).
    • Future Configurability: Future upgrades may explore making this base commission rate adjustable via governance.
  5. Vote Tracking: The consensus layer (Heimdall) will need to track each validator’s milestone voting activity accurately over the distribution period. This participation data must be reliably provided to the fee distribution smart contract.
  6. Implementation: Requires new smart contracts for fee handling and distribution, incorporating logic for stake-weighting and participation scaling. Clients (Bor, Heimdall) need updates for fee redirection and vote tracking/reporting.

Reward Formulas

Symbol Definitions:

  • T: Total Fees collected in the period (Transaction Fees + MEV Fees)
  • C: Block Producer commission rate (e.g., 0.2 for 20%)
  • Sv: Total stake (including delegation) held by validator v
  • S: Total stake in the network (sum of all validators’ stakes)
  • Pv: Performance score of validator v (0 to 1, based on participation/correctness)
  • Np: Total number of designated Block Producers active during a checkpoint.
  • Bp: Number of blocks produced by a specific producer p during the checkpoint.
  • B_total: Total number of blocks produced by all producers during the checkpoint.
  • E: Factor for equal distribution portion (e.g., 0.6 for 60%).
  • P: Factor for proportional distribution portion (e.g., 0.4 for 40%). (E + P should equal 1).

Calculation Steps:

  1. Total Commission Pool (CommissionPool):CommissionPool = T * C
  2. Block Producer p’s Commission Reward (Rp_commission):
    • Equal Share: (CommissionPool * E) / Np
    • Proportional Share: (CommissionPool * P) * (Bp / B_total)
    • Total Commission: Rp_commission = [(CommissionPool * E) / Np] + [(CommissionPool * P) * (Bp / B_total)]
  3. Pool for Validators (Pool_validators):
    Pool_validators = T * (1 - C)
  4. Performance-Weighted Stake Calculations:
    • For each validator v: PerformanceWeightedStake_v = Sv * Pv
    • TotalPerformanceWeightedStake = sum(PerformanceWeightedStake_v for all validators v)
  5. Earned Reward for Validator v (Rv): Rv = (PerformanceWeightedStake_v / TotalPerformanceWeightedStake) * Pool_validators
  6. Total Reward for Producer p (Rp_total):Rp_total = Rp_commission + Rv_bp (where Rv_bp is the earned validator reward for producer p if they also act as a validator, calculated in step 5 using their S_bp and P_bp)

Example

Given Data:

  • Total Fees Collected (T): 1,200 POL
  • Base Producer Commission Rate (C): 20% (0.2)
  • Total Validator Stake (S_validators = S_v1 + S_v2 + S_v3): 6M POL
  • Validator 1 Stake: 1M POL
  • Validator 2 Stake: 2M POL
  • Validator 3 Stake: 3M POL
  • Validator 1 Performance (P_v1): 100% (1.0)
  • Validator 2 Performance (P_v2): 90% (0.9)
  • Validator 3 Performance (P_v3): 100% (1.0)
  • Block Producer: Validator 1

Calculations:

  1. Total Commission Pool (CommissionPool):CommissionPool = T * C = 1200 * 0.2 = 240 POL
  2. Block Producer (Validator 1)'s Commission Reward (Rp_commission_v1):
    Since Np=1 and Bp/B_total=1:
    Rp_commission_v1 = [(240 * 0.6) / 1] + [(240 * 0.4) * 1] = 144 + 96 = 240 POL
    (As expected, Validator 1 gets the full commission pool as the sole producer).
  3. Pool for Validators (Pool_validators):Pool_validators = T * (1 - C) = 1200 * (1 - 0.2) = 1200 * 0.8 = 960 POL
  4. Performance-Weighted Stake Calculations:
    • Validator 1 (BP): PWS_v1 = S_v1 * P_v1 = 1,000,000 * 1.0 = 1,000,000
    • Validator 2: PWS_v2 = S_v2 * P_v2 = 2,000,000 * 0.9 = 1,800,000
    • Validator 3: PWS_v3 = S_v3 * P_v3 = 3,000,000 * 1.0 = 3,000,000
    • TotalPerformanceWeightedStake = 1,000,000 + 1,800,000 + 3,000,000 = 5,800,000
  5. Earned Validator Reward (Rv) Calculations:
    • Validator 1 (BP) (Rv_v1):
      Rv_v1 = (PWS_v1 / TotalPerformanceWeightedStake) * Pool_validatorsRv_v1 = (1,000,000 / 5,800,000) * 960 = (10/58) * 960 = (5/29) * 960 = 165.517 POL
    • Validator 2 (Rv_v2):
      Rv_v2 = (PWS_v2 / TotalPerformanceWeightedStake) * Pool_validatorsRv_v2 = (1,800,000 / 5,800,000) * 960 = (18/58) * 960 = (9/29) * 960 = 297.931 POL
    • Validator 3 (Rv_v3):
      Rv_v3 = (PWS_v3 / TotalPerformanceWeightedStake) * Pool_validatorsRv_v3 = (3,000,000 / 5,800,000) * 960 = (30/58) * 960 = (15/29) * 960 = 496.552 POL
  6. Total Reward for Validator 1 (Block Producer):Rp_total_v1 = Rp_commission_v1 + Rv_v1 = 240 + 165.517 = 405.517 POL

Distribution Table

Role Stake (POL) Performance Reward (POL) Calculation
Validator 1 (Block Producer) 1M 100% 405.52 (1200*0.2) + [(1M*1.0 / 5.8M_PWS) * (1200*0.8)] (Commission + Validator Perf-Weighted Share)
Validator 2 2M 90% 297.93 [(2M*0.9 / 5.8M_PWS) * (1200*0.8)] (Validator Perf-Weighted Share)
Validator 3 3M 100% 496.55 [(3M*1.0 / 5.8M_PWS) * (1200*0.8)] (Validator Perf-Weighted Share)
Total 6M 1200.00

Rationale

This fee redistribution model is proposed because:

  • Maintains Validator Incentives: It provides a stake-weighted revenue stream for validators.
  • Incentivizes Active Participation: Scaling rewards by voting participation directly encourages validators to maintain high uptime and contribute reliably to consensus, enhancing network liveness and security.
  • Fairly Rewards Block Producers: Compensates producers through a direct commission for block production, plus standard validator rewards if they also contribute stake and participate in validation.
  • Aligns with Security: It links rewards to both stake (security deposit) and active contribution (voting).

Backwards Compatibility

  • This proposal is intended to be implemented concurrently with or immediately following the activation of the VEBloP architecture defined in PIP-64.
  • It is not backwards compatible with the current fee distribution model where producers directly receive fees.
  • Requires deployment of new fee handling smart contracts.
  • Requires updates to Bor clients to redirect fees and heimdall to store and provide milestone votes. Validators will claim rewards from the new contract system.

Security Considerations

  • Smart Contract Security: Audit requirements remain crucial.
  • Commission Rate: Considerations about the base rate C still apply.
  • Participation Gaming: Mechanisms should ensure that “voting” accurately reflects meaningful participation, preventing validators from trivially voting without performing actual validation if stateless validation is used.
  • MEV Centralization and Mitigation: While the VEBloP model enhances throughput, concentrating block production in a single entity, it also centralizes MEV (Maximal Extractable Value) extraction opportunities. There’s a risk that a producer could exploit this position maliciously (e.g., through excessive front-running or censorship). Mitigation strategies include:
    • Social Consensus & Off-Chain Coordination: In the immediate term, if a block producer is widely perceived by the validator set to be acting maliciously or unfairly exploiting MEV, validators can coordinate to trigger a producer rotation, effectively electing a new producer via Heimdall.
    • Future Automated Checks (Optional): Longer-term, the protocol could potentially incorporate basic MEV monitoring or heuristics during block validation. If detectable malicious MEV patterns exceeding defined thresholds are identified, the system could automatically trigger a producer rotation as an enforced protocol rule. Designing robust and manipulation-resistant automated checks remains an area for future research and development.

References

  • PIP-64: Validator-Elected Block Producer for Enhanced Throughput
2 Likes
2

This is the part that is key. It would be unfair for this upgrade to take fees away from the over 100 stakers that are currently securing the network. So it makes sense to change the economic model so they continue to earn by staking POL and running nodes.

More validators, more decentralization and increased security guarantees, while also increasing throughput. Let’s do it because those are all great things. In my opinion, VEBloP should not launch until this economic model is ready.

Lowering the cost to run a validator may make POL more appealing to LST network operators like Lido and Rocketpool as well. Supporting a more significant liquid staking ecosystem around POL should be part of this roll out too IMO. (as I’ve suggested here).

One thing i would flag for this: the reward is weighing the amount of POL staked equally with uptime. This creates a large incentive to centralize validators as bigger validators will earn more rewards even if their uptime is not as high, despite creating similar amount of security.

For example, consider if there is a 1,000 POL reward between 2 validators

Role Stake (POL) Performance Reward (POL) Calculation
Validator 1 2M 50% 500 POL [(2M * 0.5 / 5.8M_PWS) * (1000*0.8)] (Validator Perf-Weighted Share)
Validator 2 1M 100% 500 POL [(1M * 1.0 / 5.8M_PWS) * (1000*0.8)] (Validator Perf-Weighted Share)

Should these 2 validators get the same reward when one was down half the time, but had twice as much stake?

Maybe you earn 100% of the reward if your uptime is above 99% (I believe the average for current validators is over 99.8%)? I would put more weight on uptime in the calculation, and spending the time to simulate what would be the rewards for current validators based on current POL staked would be worth pursuing too.

3

Unfortunately this is not a viable model.
The less-significant issue is that stake weight / staked balances are not available on Polygon PoS’s execution layer. This would be a great feature and would unlock a lot in the MEV / LST space but it is my understanding after requesting it that it is not technologically feasible - both block rewards and MEV rewards cannot be mapped directly to stake or proportionally distributed by stake weight.

But the much, much bigger issue is that the entire model can be circumvented by out-of-band payments - something we saw manifest recently on Solana and that they had to perform a consensus hard fork to “undo.”

  • if I want to be included in a block I pay a priority fee
  • In this model I can pay that directly to a wallet that may or may not be owned by the block builder
  • Attribution of out-of-band priority gas fee payments is impossible to catch in flight - it can only be detected probabalistically by analyzing past data
  • MEV is even more difficult to handle.

This is a well-researched phenomenon. Fundamentally, the block builder cannot partially share block revenue - either validators need to produce the block locally or there must be a mechanism established to solve the fair exchange problem. The only successful mechanism that we’ve seen work in prod that doesn’t require validators to build blocks locally is Ethereum’s proposer builder separation, but PBS is far too slow for polygon (the delay between commit and reveal is equal to an entire polygon block) and I don’t think it’d be a good idea for polygon to slow down its own blocktime to accommodate it.

Candidly, I find this PIP and PIP-64 to both be steps in the wrong direction - they are attempting to make polygon more like a “rollup” but, in the process, are fundamentally undermining Polygon’s best advantage - its decentralization. If the goal is to increase the throughput of Polygon PoS, time would be better spent exploring the following:

  • pipelining consensus (its 2025 why are we still using 3 round tendermint?)
  • Asynchronous execution (if you don’t want validators to have to execute blocks then just stop requiring them to.)
  • Removing the base fee so that txs with a fee below the base fee don’t build up in the local mempools of some nodes and need to constantly be sorted and increase the size of the sorted array. (Go ahead and drop them after two minutes if not included imo).
  • integrate heimdall into bor (more of a performance optimization but figured I might as well ask :grin:)
1 Like