|
| 1 | +## Network upgrade overview |
| 2 | + |
| 3 | +This page provides hardfork activation timestamps along with links to detailed specifications. It also outlines the hardfork release process, versions, network and node i.,e bor/heimdall. The network upgrade naming scheme follows the order in which the release happened on the Polygon network. |
| 4 | + |
| 5 | +## Activations |
| 6 | + |
| 7 | +On the Polygon Network, upgrades are activated based on timestamps. If you fail to update your Polygon client software before the specified timestamp, it may result in chain divergence, requiring a full resynchronization. |
| 8 | + |
| 9 | + |
| 10 | +| Upgrade | Forum | PIP | Activation | |
| 11 | +| ------------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | |
| 12 | +| Delhi Hardfork | [Link](https://forum.polygon.technology/t/pip-7-delhi-hardfork/10904/2) | [PIP-7](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-07.md) | Block >= `38,189,056` on Polygon Mainnet (Bor) | |
| 13 | +| Indore Hard Fork | [Link](https://forum.polygon.technology/t/pip-13-indore-hard-fork12272) | [PIP-13](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-13md) | Block >= `44,934,656` on Polygon Mainnet(Bor) | |
| 14 | +| Aalborg Hard Fork | [Link](https://forum.polygon.technology/t/aalborg-upgrade-mainnet-timeline-update/12960)| [PIP-21](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-21.md) | Block >= `15,950,759` on Polygon Mainnet (Heimdall) | |
| 15 | +| Agra Hard Fork | [Link](https://forum.polygon.technology/t/pip-28-agra-hardfork/13067) | [PIP-28](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-28.md) | Block >= `50,523,000` on Polygon Mainnet (Bor) | |
| 16 | +| | | | Block >= `41,874,000` on Polygon Mumbai (Bor) | |
| 17 | +| Napoli Hardfork | [Link](https://forum.polygon.technology/t/pip-33-napoli-upgrade/13405) | [PIP-33](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-33.md) | Block >= `54,876,000` on Polygon Mainnet (Bor) | |
| 18 | +| | | | Block >= `5,423,600` on Polygon Amoy (Bor) | |
| 19 | +| Ahmedabad Hardfork | [Link](https://forum.polygon.technology/t/pip-37-ahmedabad-hardfork/13885) | [PIP-37](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-37.md) | Block >= `62,278,656` on Polygon Mainnet (Bor) | |
| 20 | +| | | | Block >= `11,865,856` on Polygon Amoy (Bor) | |
| 21 | +| Jorvik Hardfork | [Link](https://forum.polygon.technology/t/pip-53-jorvik-hardfork/20357) | [PIP-53](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-53.md) | Block >= `22,393,043` on Polygon Mainnet (Heimdall) | |
| 22 | +| | | | Block >= `5,768,528` on Polygon Amoy (Heimdall) | |
| 23 | +| Danelaw Hardfork | [Link](https://forum.polygon.technology/t/pip-56-danelaw-hardfork/20511) | [PIP-56](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-56.md) | Block >= `22,393,043` on Polygon Mainnet (Heimdall) | |
| 24 | +| | | | Block >= `6,490,424` on Polygon Amoy (Heimdall) | |
| 25 | + |
| 26 | + |
| 27 | + |
| 28 | + |
| 29 | +## Upgrade process |
| 30 | + |
| 31 | +Network upgrades follow this general process in which the features included in the upgrade are put into a release version cut from the develop branch and then the software is deployed on production networks. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | + |
| 36 | + |
| 37 | +### 1. Proposal & Governance Approval |
| 38 | +Polygon is governed by the polygon governance, where any significant protocol changes, including hardforks, must be proposed and approved through a governance and community discussion on forum. The process includes: |
| 39 | + |
| 40 | + - Submitting an Polygon Improvement Proposal (PIP). |
| 41 | + - Community discussion and feedback. |
| 42 | + - On-chain voting to pass the proposal. |
| 43 | + |
| 44 | + ### 2. Development & Testing |
| 45 | + Once a proposal is approved, developers implement and test the changes: |
| 46 | + |
| 47 | +- Code is developed and reviewed. |
| 48 | +- Extensive testing is conducted on Devnets and testnets to ensure security and stability. |
| 49 | +- Smart contracts and Layer 2 infrastructure are upgraded. |
| 50 | + |
| 51 | +### 3. Node & Software Upgrades |
| 52 | +Once the development is done, announcement is done for validators and node operators. |
| 53 | + |
| 54 | +- Node operators and validators must update their software before the hardfork activation timestamp. |
| 55 | +- Failure to upgrade could result in a chain split or desynchronization. |
| 56 | + |
| 57 | +### 4. Hardfork Activation |
| 58 | + |
| 59 | +- The upgrade is scheduled at a specific block height or timestamp. |
| 60 | +- If all nodes update in time, the upgrade is seamless. |
| 61 | +- If some nodes fail to update, they risk being left on an outdated chain. |
| 62 | + |
| 63 | +### 5. Post-Hardfork Monitoring |
| 64 | + |
| 65 | +- After activation, the network is monitored for stability. |
| 66 | +- Any bugs or issues are addressed quickly through patches if needed. |
0 commit comments