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
4

Thank you for the feedback. @Thogard

This will become available as part of the new architecture.

This is mitigated in the short-term by limiting block producers to be operated only by known trusted entities where there are off-chain agreements to operate in an agreed manner with respect to transaction ordering / MEV.
In the long-term, it could be mitigated by running block producers in a TEE (trusted execution environment), and allow externals to verify the signature generated by the enclave. We could also consider embedding sequencing directly in consensus layer (heimdall) as an alternative solution.

5

Below is a back-of-the-envelope analysis to estimate the potential economic impact on validators transitioning to the proposed VEBloP architecture and associated economic model. It compares estimated operational costs and transaction fee earnings between the old and new systems for a hypothetical large validator.

Note: This is an illustrative analysis based on specific assumptions and estimations. Actual costs and earnings will vary based on numerous factors including real-time cloud pricing, network activity, total network stake, specific hardware choices, validator uptime, and future protocol parameters (like the commission rate).

Key Assumptions and Context for this Analysis:

  • Validator Profile: Calculations are based on a hypothetical large validator with 100 Million POL stake.
  • Network Parameters: Assumes a total network stake of 3.4 Billion POL and uses the average of monthly 1,409k POL (average from the past 6 months) as a baseline for calculating total fees.
  • Fee Growth: A crucial assumption is that the increased throughput enabled by VEBloP leads to increasing total network transaction fees compared to the baseline.
  • Commission Rate: A 10% commission rate for the block producer is assumed for the new architecture.
  • Reward distribution cap: The reward distribution cap is set to infinite in this example for simplification.
  • Validator Performance: The validator is assumed to have a 100% voting performance rate in the new model, thus receiving their full potential reward share.
  • Pricing Estimates: Hardware costs are estimates based on GCP on-demand pricing in a specific region (us-central1) and may vary depending on the actual infrastructure. The POL price is assumed to be $0.26 USD (at the time of writing).
  • Scope: This analysis focuses solely on estimated hardware costs and transaction fee revenue. It does not include other potential validator costs (e.g., personnel).

Illustrative Economic Comparison: Old vs. New Architecture

Metric Old Architecture (Baseline) New Architecture (VEBloP + Updated Economics) New Architecture (VEBloP + Updated Economics) New Architecture (VEBloP + Updated Economics) Notes
Hardware Specs (Validator) 16 vCPU, 64GB RAM, 6TB Storage 8 vCPU, 16GB RAM, 1TB Storage 8 vCPU, 16GB RAM, 1TB Storage 8 vCPU, 16GB RAM, 1TB Storage Significant reduction in new architecture
Network Egress 1MB/s 2MB/s 2MB/s 2MB/s Increased due to stateless witness in new architecture
Est. Monthly Hardware Cost (GCP) Total: $2,011, Hardware: $1761, Network: $250 Total: $929, Hardware: $429, Network: $500 Total: $929, Hardware: $429, Network: $500 Total: $929, Hardware: $429, Network: $500 Estimated savings of ~$1082/month.
Assumed Total Network + MEV Fees ~1,409k POL/month (Baseline) ~1,409k POL/month (1x Baseline) ~2,818k POL/month (2x Baseline) ~5,636k POL/month (4x Baseline) Key assumption: VEBloP enables a 6-10x increase in block capacity. Baseline taken from the past 6 months average.
Producer Commission Rate N/A 10% 10% 10% Applied to total pool before validator distribution.
Monthly Validator Commission from Checkpoint Rewards $9953 $9953 $9953 $9953 Calculated for a validator with 100M delegated POL. 3.4B total staked POL. 10% commission. 13015681 (monthly POL emission) / 34 * 0.1 ** $*0.26
Monthly Validator Fee Earnings $10771 $9694 $19388 $38776 Calculated for a validator with 100M delegated POL. 3.4B total staked POL. 100% participation in voting. Baseline calculation: 1408516 (average in the last 6 months) / 34 * $0.26. VEBloP calculation: 1408516 (average in the last 6 months) * (1 - 0.1) / 34 * $0.26
Estimated Monthly Profit $18713 $18718 $28412 $47800 Earnings - Est. Hardware Cost

Note: The architectural changes outlined in PIP-64 are designed to enable over a 6x improvement in block capacity. However for this analysis, we have taken a more conservative estimate at only a 2-4x growth over the short to medium term.

Summary

This illustrative analysis, under the specified assumptions (notably 2-4x fee growth and 10% commission), suggests the transition could be economically advantageous for this validator profile. The hardware cost savings provide a direct benefit, and the potential for significantly higher network fee volume (enabled by VEBloP) can lead to increased overall profitability despite the fee-sharing mechanism. Real-world outcomes will depend on actual network adoption and usage growth.

2 Likes
6

Thanks @jerry for the detailed breakdown. In our case as a validator with a 2M POL stake, I’ve run the numbers, or tried, under the assumptions of a 10 % producer commission like you proposed

So 3.4 billion POL total stake, 13 million POL/month emissions and ~1.4 million POL/month in fees:

Emission reward
13 000 000 POL × (2 000 000 / 3 400 000 000) × 10 % ≈ 760 POL/month

Fee reward (current fee levels)
1 400 000 POL × 90 % × (2 000 000 / 3 400 000 000) ≈ 750 POL/month

Total ≈ 1 510 POL/month

For Scaling scenarios

If fees 2x, fee reward ≈ 1 500 POL → total ≈ 2 260 POL/month

If fees 4x, fee reward ≈ 3 000 POL → total ≈ 3 760 POL/month

Assumptions:

  • 100 % uptime and correct voting
  • Commission = 10 % of total fees
  • “Fees/month” = aggregate transaction + MEV tips

Is this something we would expect approx per month?

Ty

1 Like
7

Hi @diminiko , yes, the calculation looks correct to me.

1 Like
8

PIP-65 proposes a fee redistribution model to support the VEBloP architecture introduced in PIP-64. It ensures fair compensation for both block producers and validators by splitting transaction and MEV fees between them. Producers receive a commission, while validators are rewarded based on stake and performance. The model aims to maintain network security, incentivize participation, and align validator rewards with network growth.