Upgradeability

The Inverter Network employs a robust upgradability framework that ensures our contracts remain secure, efficient, and aligned with the latest technological advancements and community needs. This page outlines the types of upgrades, when and how these upgrades occur, and who is authorized to implement them.

Types of Upgrades

We defined two types of upgrade: Minor and Major Version Upgrades:

Minor Version Upgrades

Minor upgrades are non-breaking changes that improve functionality or correct issues without altering the contract's interface or core logic. These upgrades increment the minor version number (e.g., from 1.3 to 1.4) and are applied automatically to all contracts using the beacon proxy pattern. This ensures all workflows utilizing the updated module benefit from the latest improvements without manual intervention.

Major Version Upgrades

Major upgrades involve significant changes that may alter the contract's interface or internal logic. Unlike minor upgrades, major version upgrades are not automatically applied. Instead, a new module version is registered in the module factory starting with a major version that is incremented by one and starts with minor Version zero. Users can swap to these new Modules by adding them separately into their workflows.

Beacon Proxy Pattern

One goal for our modules was to simplify the maintenance of them significantly, enabling Inverter Protocol maintainers to easily deploy fixes to malfunctioning modules by updating the module implementation directly instead of each individual module.

To implement this we made use of a so called beacon proxy pattern. In this pattern a module stores the address of its implementation in a separate “beacon” contract. In a typical deployment setup, when the implementation needs to be upgraded, all of the contracts that use this implementation need to be updated. However, with the Beacon proxy pattern, only the beacon contract itself needs to direct the modules to the new implementation. This is very efficient when dealing with large quantities of modules and their implementations.

In addition to that we can use this structure in the Intervention Mechanisms too.

Authorization to Upgrade

Upgrades are governed by two multisig wallets:

• Community Multisig: Comprises team members, community representatives, and advisors. This group handles critical decisions, including approving major upgrades.

• Inverter Team Multisig: Consists of Inverter team members and is used for more routine tasks and minor upgrades.

For a detailed explanation of the governance process and multisig responsibilities, refer to our Governance Page.

Security Measures

To safeguard against unauthorized or abrupt changes, and to ensure community trust, we implement the following security measures:

• Timelock Mechanisms: All major upgrades are subject to a delay before activation, during which users can review and contest the changes.

• Beacon Proxy Pattern: Used for all contracts to allow efficient and secure upgrades by updating a single beacon contract rather than each individual proxy.

For more information on the security protocols and user options during upgrades, please visit our Security Guidelines.

Upgrade Timing

Upgrades are typically initiated under the following circumstances:

• Routine Maintenance and Improvements: Scheduled updates to enhance functionality or efficiency, adhering to the SemVer principles.

• Emergency Responses: In the event of a discovered vulnerability or bug that poses a risk to user funds or system integrity, an emergency upgrade may be initiated. For more details on emergency handling, see Emergency Protocol.

• Community Feedback and Requests: Based on user feedback or feature requests that align with the Inverter Network’s roadmap.

Before any upgrade is deployed to live networks, it is thoroughly tested on public testnets, and a public announcement is made for community feedback. The upgrade process includes a timelock delay to allow user verification and feedback.

---

For further details on our security practices and how we handle specific scenarios, please visit our Security Guidelines.