Call for Feature Requests - Polygon PoS: Pilani Upgrade

Polygon PoS: Pilani Upgrade

Call for Technical Feature Requests

Polygon PoS developers have decided on a name for the upgrade following Ahmedabad. Now formally named Pilani, the upgrade will likely take place in Q4 of 2024 and provides an opportunity to add a range of new features and optimisations to the Polygon PoS chain.

What We’re Looking For

Community-driven innovation is at the core of Polygon PoS development. The network’s strength lies not just in its technology but also in the collective vision and contributions of its vibrant community of developers and users.

We want your feature requests across all aspects of the Polygon PoS network. Here are some areas where your ideas can make a significant impact:

1. User Experience:

  • Features that make the network more user-friendly and accessible.
  • Enhancements for wallets, explorers, and other user-facing tools.

2. Scalability Improvements:

  • Enhancements to transaction throughput and latency.
  • Solutions for handling network congestion and increased capacity.

3. Decentralisations/Security Enhancements:

  • Improvements to existing security protocols and mechanisms.

How to Submit Your Feature Requests

Simply comment below. We are not specifically looking for long-form answers here; that is what PIPs are for!

In a couple of sentences:

1. Identify the problem/area of improvement:

  • Define the problem or opportunity your feature addresses.

2. Propose a solution:

  • Outline your solution; relevant technical details are appreciated.

3. Explain the benefits:

  • Highlight how the feature will benefit the Polygon network and its users.

Whether you’re a developer, a user, or simply an enthusiast, your insights are invaluable in driving the development of the Polygon PoS chain.

I look forward to hearing your thoughts and encourage you to provide feedback however you see fit.


I propose PoS including the Point Evaluation precompile found at 0x00…0A on Ethereum Mainnet specified in EIP-4844 to further support EVM compatibility


I propose we get an AggLayer connection please!


I believe now is the time to considering a large upgrade to current functionality + an extension to PoS.

  1. PoS should upgrade to the Unified LxLy bridge, paving the way for connection to the AggLayer.
  2. PoS should include a new role which is able to post data to the Agglayer to perform bridge updates. To begin this can happen without any changes to PoS to use execution proofs, and can instead rely on the pessimistic proof + the existing pos finality guarantees.
  • Top feature needed is the move to zkEVM validium, we know this is coming but adding it here anyway as I think it should be a top priority (I’m sure it is already :slight_smile: ).

  • Improve polygonscan, especially the token approvals which is a pretty broken feature. Polygonscan may not be necessarily an in-house polygon issue, but it is something that would significantly enhance the user experience. Many people don’t know what they’re doing on-chain, and making the “reading the chain” process as simple as humanly possible can only be a benefit to new users. Outside of wallets, chain history is a major choke point for less tech savvy (or time constrained) potential users. This would also make it easier for content creators to amplify Polygon’s features. Built-in complex and simple analytic tools for all levels of those wanting to interact, contract analyzers, efficient audited contracts listings, ability for new contract creators to easily upload imagery to associate their contracts with their projects and to claim their contracts as part of their platform, more clear labeling for multi-step transactions involving dapps, etc. this could all be relayed to CDK chains and could be a strong basis for an AggLayer analyzer. This could really separate Polygon in the space.

  • Use the monad client, idea taken from JD originally, or learn from their approach. Per Samuel Furter on X “A simple TX tracer and slightly customized Trie implementation (if actually needed) would make it ZK provable as well”. I would imagine a zkMonad client would be insanely efficient under load.

  • A permissionless “building on POS” website, categorized and sub categorized by sector of web3, features, etc. teams could submit their own projects and project details, which would give them a marketing/visibility edge. this would be great as a basis for CDK chains and AggLayer integrations so their is easy access visibility about what’s being built, gives creators a great space to find projects of interest to amplify. Gives contract auditors a place to quickly find projects to sell services to. Could also include sections called “last called” and “exploited”, that shows when the last usage was to indicate if a product has gone ghost/defunct and when/how a project was exploited and if there was a fix. This could be lumped into the same site as chain analyzer.

  • CEXs offering direct Polygon on-ramps. Could also be included in the same website with the above items.

  • AggLayer integration (I know this is coming too).

  • Might add more later! Thanks for providing a forum for us to share ideas.

1 Like

Posting a community request for an ed25519 curve precompile.

h/t @pedrouid

1 Like

Linking a previous post from @sxtcat Support for BLS12-381 Curve Operations

1 Like

Bring Bor close to the upstream improvements made on Geth, especially PathDB. It enables efficient state management and pruning. #1, #2 and #3 are obvious and well documented.

1 Like


Corn from Yearn here. We’ve completed building a new product called Stake The Bridge (STB) and we’d like to have it considered for integration in the Pilani upgrade. This product was built for any Polygon CDK partner to integrate so they can earn yield natively and make even idle assets productive.

Native Yield is big meta right now, and STB allows a user to bridge from an L1 to the L2, while the asset is generating yield on the L1, and the user receives a vanilla token on the L2.

The idea is to take that yield on the L1 and make it productive. For instance, I propose we take that yield and buy back $MATIC tokens and put them into a grants treasury. We can do what we’d like with the yield.

Some strategies and assets we can start with are:


This product is built and ready for integration right now:

Design docs and code:


I propose upgrading heimdall’s tendermint fork with the newer CometBFT, coming in with enhanced ABCI++ features.


One improvement for heimdall is also to bump up cosmos-sdk version to latest (v0.50.x) in order to leverage the new set of functionalities available upstream


@ConstantinoTheGreat @pgpg @Web3corey sharing a new post from @pgo & Uma on Phase 1 of zkPoS connecting PoS to AggLayer

1 Like