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
  • Multisig
  • Governor Contract
  1. Concepts
  2. Protocol Concepts

Governance

PreviousPrimary Issuance Markets (PIMs)NextSecurity

Last updated 11 months ago

The Inverter protocol uses governance mechanisms to control its crucial administrative functions, which are only executable by specific multisig addresses. This strategy boosts the system's security by ensuring that only authorized parties can implement significant changes.

Multisig

We have set up two different Multisigs, each with specific authorization levels to ensure security within our system.

Inverter Team Multisig

The Inverter Team Multisig is managed by our team members and primarily handles quick responses and maintenance tasks.

Community Multisig

The Community Multisig is managed by community members and primarily focuses on major decision-making and high-impact activities.

Multisg Addresses

Network Name
Chain ID
Multisig Permission
Address

Coming Soon

Coming Soon

Coming Soon

Coming Soon

Governor Contract

The Governor contract serves as the central hub for on-chain governance. It is the primary entry point through which crucial administrative functions are governed. The contract includes administrative functions that can only be executed by the previously mentioned multisig authorization levels. These functionalities are:

Beacon Upgrade

Authorization Level: Inverter Team & Community Multisig

Beacon Pauseability

Authorization Level: Inverter Team & Community Multisig

Forced Upgrades and Unpausing

Authorization Level: Community Multisig

The community multisig has the exclusive authority to lift a pause that was initiated in response to a fault in the system, ensuring that any updates or changes align with the community's consensus on the protocol's status.

RegisterModule in Factory

Authorization Level: Inverter Team & Community Multisig

Registering new Modules in the Module Factory can only be done through the Governor contract. As this process is considered a maintenance task, both multisig authorization levels are authorized to use this functionality.

Fee Setting

Authorization Level Overal Fees: Community Multisig

Authorization Level Workflow Fees: Inverter Team & Community Multisig

The fee settings, as a category of high-impact actions, are primarily governed by the Community Multisig. This governance includes:

  • Designating the Default Treasury Address, where all collected fees are directed.

  • Establishing a default fee applicable to all workflows unless a specific fee is assigned.

  • Implementing a maximum fee limit that cannot be exceeded for any fee adjustments.

The Beacon Upgrade functionality allows for the . Regular upgrades, categorized as maintenance tasks, can be initiated by either of the multisig authorization levels. After a specified time lock period has passed, these upgrades can be executed, providing users with the opportunity to review the upcoming changes in advance.

The Beacon Pauseability functionality allows for the . To quickly address faults in the system, both multisig authorization levels have the authority to pause the beacon systems.

In cases where specific fees are assigned to certain workflows (referred to as ), both multisig authorization levels are permitted to modify these fee values. However, these adjustments are still subject to the maximum fee cap previously mentioned.

upgrading of contracts at the protocol level
pausing of beacons and their respective contracts at the protocol level
Workflow Fees