Inverter Documentation
GithubDiscordTwitterLinks
  • Getting Started
  • Concepts
    • What is Inverter Network
    • The Inverter Protocol
    • Protocol Concepts
      • Workflow Model
        • Factories
        • Orchestrator
        • Authorizer
        • Funding Manager
        • Payment Processor
        • Logic Module
      • Module Library
        • Authorizers
          • Role Authorizer
          • Single Vote Governance Module
          • Token Gated Role Authorizer
        • Funding Managers
          • PIMs
            • Bancor Based PIM: Virtual Supply
            • Bancor Based PIM: Virtual Supply Buy Restriction
          • Deposit Vault Funding Manager
        • Payment Processors
          • Streaming Payment Processor
          • Simple Payment Processor
        • Logic Modules
          • Bounty Manager
          • Recurring Payment Manager
          • KPI Rewarder
          • Staking Manager
      • Primary Issuance Markets (PIMs)
      • Governance
      • Security
        • Upgradeability
        • Emergency Protocol
        • Audits
        • Bug Bounties
      • Fees
  • SDK's
    • TypeScript SDK
      • Deploy a Workflow
      • Operate a Workflow
      • Deploy a Contract
    • React SDK
      • Deploy a Workflow
      • Operate a Workflow
      • Deploy a Contract
      • Query the Indexer
      • Subscribe to the Indexer
    • Graphql SDK
    • Workflow Guides
      • Grant/Revoke Roles
      • Bounty Manager
      • Bonding Curve
      • Deposit Vault
    • API
      • Inverter
      • getDeployWorkflowOptions
      • deployWorkflow
      • getModule
      • getWorkflow
      • deploy
  • Contracts
    • Technical Specification
    • Security Guidelines
    • Deployment Addresses
    • Technical Reference
      • Factories
        • Interfaces
          • IModuleFactory_v1.sol
          • IOrchestratorFactory_v1.sol
        • ModuleFactory_v1.sol
        • OrchestratorFactory_v1.sol
      • Orchestrator
        • Abstracts
          • ModuleManagerBase_v1.sol
        • Interfaces
          • IModuleManagerBase_v1.sol
          • IOrchestrator_v1.sol
        • Orchestrator_v1.sol
      • Modules
        • Authorizer
          • Role
            • Interfaces
              • IAUT_EXT_VotingRoles_v1.sol
              • IAUT_TokenGated_Roles_v1.sol
            • AUT_EXT_VotingRoles_v1.sol
            • AUT_Roles_v1.sol
            • AUT_TokenGated_Roles_v1.sol
          • IAuthorizer_v1.sol
        • Base
          • IModule_v1.sol
          • Module_v1.sol
        • Funding Manager
          • Deposit Vault
            • FM_DepositVault_v1
            • Interfaces
              • IFM_DepositVault_v1
          • Bonding Curve
            • Abstracts
              • BondingCurveBase_v1.sol
              • RedeemingBondingCurveBase_v1.sol
              • VirtualCollateralSupplyBase_v1.sol
              • VirtualIssuanceSupplyBase_v1.sol
            • Formulas
              • BancorFormula.sol
              • Utils.sol
            • Interfaces
              • IBancorFormula.sol
              • IBondingCurveBase_v1.sol
              • IFM_BC_Bancor_Redeeming_VirtualSupply_v1.sol
              • IRedeemingBondingCurveBase_v1.sol
              • IVirtualCollateralSupplyBase_v1.sol
              • IVirtualIssuanceSupplyBase_v1.sol
            • FM_BC_Bancor_Redeeming_VirtualSupply_v1.sol
            • FM_BC_Restricted_Bancor_Redeeming_VirtualSupply_v1.sol
            • FM_BC_Tools
          • IFundingManager_v1.sol
        • Logic Module
          • Abstracts
            • ERC20PaymentClientBase_v1.sol
            • Oracle Integrations
              • UMA Optimistic Oracle V3
                • Optimistic Oracle V3
                  • Interfaces
                    • OptimisticOracleV3CallbackRecipientInterface.sol
                    • OptimisticOracleV3Interface.sol
                  • AncillaryData.sol
                  • ClaimData.sol
                • IOptimisticOracleIntegrator.sol
                • OptimisticOracleIntegrator.sol
          • Interfaces
            • IERC20PaymentClientBase_v1.sol
            • ILM_PC_Bounties_v1.sol
            • ILM_PC_KPIRewarder_v1.sol
            • ILM_PC_PaymentRouter_v1.sol
            • ILM_PC_RecurringPayments_v1.sol
            • ILM_PC_Staking_v1.sol
          • LM_PC_Bounties_v1.sol
          • LM_PC_KPIRewarder_v1.sol
          • LM_PC_PaymentRouter_v1.sol
          • LM_PC_RecurringPayments_v1.sol
          • LM_PC_Staking_v1.sol
        • Payment Processor
          • Interfaces
            • IPP_Streaming_v1.sol
          • IPaymentProcessor_v1.sol
          • PP_Simple_v1.sol
          • PP_Streaming_v1.sol
        • Lib
          • LibMetadata.sol
          • LinkedIdList.sol
          • SafeMath.sol
      • External
        • Fees
          • Interfaces
            • IFeeManager_v1.sol
          • FeeManager_v1.sol
        • Forwarder
          • Interfaces
            • ITransactionForwarder_v1.sol
          • TransactionForwarder_v1
        • Governance
          • Interfaces
            • IGovernor_v1.sol
          • Governor_v1.sol
        • Reverter
          • InverterReverter_v1.sol
        • ERC20Issuance
          • Interfaces
            • IERC20Issuance_v1.sol
          • ERC20Issuance_v1.sol
        • Interfaces
          • IERC2771Context.sol
      • Proxies
        • Interfaces
          • IInverterBeacon_v1.sol
          • IInverterProxyAdmin_v1.sol
          • IInverterTransparentUpgradeableProxy_v1.sol
        • InverterBeacon_v1.sol
        • InverterBeaconProxy_v1.sol
        • InverterProxyAdmin_v1.sol
        • InverterTransparentUpgradeableProxy_v1.sol
  • Apps
  • Support
Powered by GitBook
On this page
  • Types of Upgrades
  • Beacon Proxy Pattern
  • Authorization to Upgrade
  • Security Measures
  • Upgrade Timing
  1. Concepts
  2. Protocol Concepts
  3. Security

Upgradeability

PreviousSecurityNextEmergency Protocol

Last updated 11 months ago

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 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.

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.

Upgrade Timing

Upgrades are typically initiated under the following circumstances:

  • 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 a detailed explanation of the governance process and multisig responsibilities, refer to our .

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

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

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

Governance Page
Security Guidelines
SemVer
Security Guidelines
Intervention Mechanisms