PIP: TBA
Title: Full ERC-20 Functionality for Validator Share Tokens
Author: Pete Kim - Polygon Community Treasury Board
Description: Enable full ERC-20 functionality for Polygon validator share tokens (including approve and permit), to simplify creation of POL liquid staking tokens (LSTs) and expand the utility of staked POL.
Status: Draft
Type: Contracts
Date: 2025-07-01
Abstract
This proposal outlines an upgrade to Polygon’s staking system to give validator share tokens full ERC-20 functionality. Currently, when users delegate POL tokens to a validator, they receive validator-specific share tokens (sometimes called VOL tokens) that represent their stake. However, these share tokens are non-tradable – in particular, the approve function is disabled – which makes them unusable in DeFi smart contracts. By removing this limitation and implementing standard ERC-20 features (including the permit extension for gasless approvals per EIP-2612), we enable share tokens to be freely transferred and integrated into other contracts. This change will make the creation of liquid staking derivatives (LSTs) for POL trivial, unlocking liquidity for currently dormant staked tokens. Ultimately, the goal is to vastly expand the utility of staked POL and boost liquidity in the Polygon PoS chains and AggLayer chains such as Katana.
Motivation
Liquid staking tokens (LSTs) have seen significant adoption in other ecosystems – for example, Lido’s stETH on Ethereum and Jito’s JitoSOL on Solana are widely used in DeFi. By contrast, Polygon’s liquid staking solutions have struggled to gain traction. Multiple third-party providers (Stader’s MaticX, Ankr, Lido’s stMATIC, etc.) launched POL/MATIC LSTs, but these saw limited adoption. In fact, Lido decided to sunset its stMATIC product in June 2025 due to low usage. As of July 2025, roughly one-third of all POL tokens (~3.7 billion, about 35% of the supply) are staked in the Polygon PoS network – representing on the order of hundreds of millions of dollars (~$670M) in value. If even a portion of these staked tokens became liquid, the market capitalization of POL LSTs could rival or exceed that of established LSTs like Coinbase’s CBETH or Benqi’s sAVAX (valued around $336M and $230M respectively), and would far outsize smaller LSTs such as ether.fi’s EETH or Swell’s swETH. This indicates a huge untapped opportunity for Polygon’s DeFi ecosystem: unlocking potentially hundreds of millions in liquidity currently tied up in staking.
One key reason for the lack of POL LST adoption to date is the complexity and trust requirements in existing solutions. Without a transferable share token standard, LST providers have had to create complex workflows and custodial setups. For example, Lido’s implementation on Polygon required validators to transfer ownership of their nodes to the Lido protocol, and users had to unbond from their chosen validator to re-stake through Lido’s contracts – a cumbersome and trust-dependent process. Other providers like Stader and Ankr similarly run their own validators and custody delegated funds within their contracts to issue LSTs. These approaches introduce friction and risk, limiting user adoption.
By contrast, if Polygon’s native validator share tokens were fully ERC-20 compliant, creating a POL liquid staking token could be as simple as deploying a smart contract that wraps these share tokens. No special validator permissions or complex custody would be required. Any user could delegate to a validator normally (through the stake manager) and receive standard ERC-20 share tokens representing their stake. A third-party protocol or even a simple open-source contract could then permissionlessly accept those tokens and mint a new unified LST. Because the native share tokens themselves encode the stake, the rewards and the slashing adjustments (if slashing of delegated POL were to be enabled in the future), the LST contract’s job becomes trivial bookkeeping, rather than the heavy lifting of managing actual staking operations. In short, making share tokens composable drastically lowers the barrier to creating and using POL LSTs.
Enabling liquid staking for POL has broader implications: it can increase staking participation by reducing the opportunity cost (users can stake without sacrificing liquidity), thereby improving network security. It would also catalyze DeFi activity on Polygon by injecting a large new source of collateral and tradable assets (staked POL in liquid form) across Polygon PoS chain and the upcoming AggLayer chains. In summary, the motivation for this PIP is to modernize Polygon’s staking token design in line with industry standards (fully fungible, DeFi-compatible tokens) to unlock these benefits.
Specification
Changes to ValidatorShare Token Contract
Each validator on Polygon has an associated ValidatorShare contract that issues ERC-20 share tokens to delegators. We propose the following modifications to the ValidatorShare contract implementation:
- Enable Standard ERC-20 Approval: Remove the inheritance of
ERC20NonTradable. Currently_approve()is overridden to revert ("disabled"), which prevents use ofapproveand consequentlytransferFrom. After this change, the share token should behave like a normal ERC-20: holders can callapprove(spender, amount)to grant allowances, and other contracts can calltransferFromon their behalf up to the approved amount. This change restores the crucialapprove/transferFromfunctionality that allows tokens to be used by smart contracts. - ERC-20 Metadata: Implement the standard
name(),symbol(), anddecimals()functions for the share token:symbol(): Return a symbol string in the formatdPOL[ID], where[ID]is the validator’s ID. For example, the share token for validator ID 1 would return"dPOL[1]". This clearly identifies the token as “delegated POL” tied to a specific validator.name(): Return a descriptive name such asDelegated POL [ID]. For validator 1, this would be"Delegated POL [1]". This makes it easy in interfaces to recognize the token as POL staked with a given validator.decimals(): Return 18, matching the industry standard and the POL’s decimal places.
- Permit (EIP-2612): Implement the
permitfunction as defined in ERC-2612. This function allows a holder to approve an allowance via an off-chain signature, enabling gasless approvals and one-transaction deposit flows. By supporting permit, dApps can seamlessly integrate share tokens with improved UX (no need for a separate approve transaction from users). - Preserve Automatic Reward-Claim on Transfer: Currently, whenever share tokens are transferred (e.g. when a delegator unstakes or moves tokens), the contract triggers a claim of any pending rewards for both the sender and recipient addresses. This behavior should be retained for all transfers, whether initiated by
transferortransferFrom. In practice, this means the overridden_transferfunction inValidatorSharewill continue to call the internal reward withdrawal routine for the sender and receiver before updating balances. Preserving this ensures that rewards aren’t “left behind” or unevenly distributed when shares move between addresses – it maintains the invariant that each address’s share balance corresponds to a fully updated claim on underlying POL at transfer time. Any smart contract that accepts deposits of share tokens MUST take this into account and handle balance changes in POL.
Aside from the above changes, the core logic of ValidatorShare remains the same. After this proposal, each validator’s share token will simply be a fully-fledged ERC-20, with the added convenience of permit. This aligns Polygon’s staking tokens with standard token conventions and DeFi expectations.
Rationale
Why enable transfers and approvals now?
When Polygon’s staking contracts were originally designed, validator share tokens were made non-transferrable avoid potential complications of potential fraud by a rogue validator and secondary trading. The share tokens were meant to be an invisible implementation detail. The very first implementation did not even allow simple transfers between EOAs, which was later enabled to allow key rotations. Given the maturity of Polygon’s ecosystem and its decentralized validator network, and the community’s interest in liquid staking, the benefits of making share tokens composable now clearly outweigh the original reasons for non-transferability.
Ease of creating POL LSTs
Enabling ERC-20 functionality allows for a very straightforward implementation of a POL liquid staking token (LST). We sketch one possible design (for illustration, not as a strict specification):
- Imagine a new token contract called sPOL (staked POL). This contract accepts deposits of any validator’s share tokens (
dPOL[ID]). When a user deposits, the contract mints sPOL equal in value to the current POL value of the share tokens. Note that the exchange rate is currently a one-to-one ratio, but that may change if slashing of delegated POL were to be enabled in the future. - The smart contract must account for the fact that, as specified, any pending rewards for both the user and the contract are claimed when the tokens are transferred. Therefore, an additional
transferFromand arestakecall may be required to handle newly claimed POL rewards. - The sPOL contract would hold the underlying share tokens in a pool. It could then periodically re-stake rewards on all those validator shares by calling each
restake()for the tokens it holds. This operation compounds the rewards back into the stake, increasing the value of the pool. The sPOL token itself could be designed as a rebasing token (similar to Lido’sstETH) that increases user balances as rewards accrue. The exchange rate for sPOL/POL should remain close to one-to-one. However, if slashing is enabled, the market rate may temporarily deviate when slashing occurs until the next rebase. - For broader usability, a wrapped version wsPOL could be provided, analogous to Lido’s wstETH. wsPOL would be a non-rebasing ERC-20 that represents a share in the sPOL pool (its price in sPOL/POL would increase as rewards accrue, rather than the quantity). This is often useful in DeFi contexts and can be more tax-efficient for users in certain jurisdictions. This is also similar to Rocket Pool’s rETH model. The deposit/redemption logic in the smart contract handles the exchange rate.
- The sPOL contract does not support converting sPOL back into validator share tokens. Instead, users can unstake and receive POL tokens. During the unbonding period, an NFT may be issued to represent the pending withdrawal until the final claim is made. The choice of which validator to unbond from is left to the implementation, but it is suggested to prioritize unbonding from the validator with the highest delegated amount — only up to the point it becomes the second highest — then continue in descending order to promote decentralization.
- The sPOL contract may receive airdrops, such as those from Polygon-incubated projects distributed to POL stakers. Ideally, the airdropping entity should account for LSTs and distribute tokens to LST holders in the same way as to ordinary delegators. However, the governing entity behind the LST should also be capable of managing airdrops received by the sPOL contract.
In this scenario, the heavy lifting is handled by Polygon’s core component itself, not the implementation of the LST. The sPOL contract doesn’t need special rights with validators or the stake manager – it simply holds transferable ERC-20 tokens and calls public functions like any user could. This is a much simpler and safer design than previous solutions that required complex trusted setup or voluntary participation of validators.
Ideally, the Polygon ecosystem will establish a community-governed, canonical implementation of an LST in order to avoid fragmentation.
Backwards Compatibility
From a protocol perspective, these changes are mostly additive. Existing delegators will simply find that their dPOL share tokens are now composable. If a user takes no action, their stake is unaffected – they continue earning rewards as before.
Contract Upgrade
A new ValidatorShare implementation contract will need to be deployed and the existing ValidatorShareProxy contract for each validator should point to the new implementation. The upgrade must ensure that all existing validator share contracts receive the new logic and the new implementation must ensure that the original storage layout remain unaffected.
Decimal Places
The previous contract lacked a decimals function, causing wallet frontends to display a huge number. This behavior only affects frontend display; the balance function will continue returning the same value after the upgrade. While this change is unlikely to impact existing integrations, it is noted here for completeness.
Security Considerations
Converting share tokens into freely transferable ERC-20s introduces new vectors to consider, mostly analogous to the risks of any fungible token in DeFi, but some specific to staking:
- Allowance Misuse: Once
approveis enabled, share token holders must exercise caution just as with any ERC-20 – approving a malicious contract could put their tokens at risk. If an attacker tricks a user into approving a large amount, the attacker could calltransferFromto take the user’s staked tokens (i.e., their share tokens). Users and dApps should treat share tokens with the same security precautions as they do POL itself and other ERC-20 tokens. - Slashing and Risk Exposure: Although slashing is currently disabled for Polygon staking, it could be enabled in the future. If that happens, LSTs derived from validator share tokens may need to socialize any resulting losses among holders, similar to how other LSTs handle such events.
- Governance: An LST smart contract may accumulate a significant amount of delegated POL, potentially giving it substantial influence in a token-based governance system. Any such governance mechanism should account for this possibility and ensure that voting rights are attributed to the LST holders, rather than the contract itself.
References
- Polygon Knowledge Base – Delegation via validator shares
- Polygon GitHub - ValidatorShare.sol
- Coingecko - Top Liquid Staking Coins by Market Cap
Copyright
All copyrights and related rights in this work are waived under CC0 1.0 Universal.