Authors

0xMikko, lekhovitsky, desnake

Summary

The GIP is to introduce the "Permissionless" update to DAO and ask preliminary approval for starting the Gearbox V3.1 and associated Permissionless setup rollout.

Motivation

Scaling Gearbox

The primary goal of this upgrade is to enable Gearbox to scale its services effectively and sustainably. This is achieved through two key approaches:

Embracing Permissionlessness:

The upgrade shifts Gearbox from an application to platform by introducing:

• Permissionless Market Curation: Anyone can curate markets, fostering innovation and adaptability.
• Permissionless Deployment: Gearbox contracts deployments aren't required to be executed by DAO.

Uniswap’s explosive growth serves as a powerful example. Its permissionless design allowed countless parties to build on it, meeting their own needs while expanding the protocol’s reach. Gearbox aims to replicate this dynamic.

The proposed setup was was designed with thousands of chains in mind: something that's impossible for other protocols without having 500-person operations team.

Enhancing Decentralization:

The upgrade further decentralizes Gearbox by:

• Specializing and Isolating Roles: Clearly defined responsibilities improve efficiency and security.
• Distributing Rights: Spreading authority reduces reliance on single points of failure, boosting system stability.

Specialized roles streamline operations by leveraging the expertise of ecosystem participants, while distributed rights enhance resilience. Together, these changes lay the groundwork for scalable, robust growth.

Establishing Credit Accounts as a Standard

• Credit Accounts as a Public Good: Much like foundational tools such as Deterministic Deployer, Multicall3, or UniswapV2Factory have become staples across EVM ecosystems, Gearbox envisions CAs as a universal building block for DeFi.

• A "Credit Card" for DeFi: From its inception, Gearbox has viewed Credit Accounts as the DeFi equivalent of a credit card (see one of the first versions of Gearbox UI) — complementing general-purpose smart wallets, which can be perceived as "debit cards". The vision is bold: a DeFi landscape where CAs are as ever-present as credit cards in traditional finance, with Gearbox serving as a foundational service provider — akin to Visa in this analogy.

Specification

Protocol Roles

This upgrade introduces strictly defined roles with programmatically enforced permissions embedded in smart contracts—no assumptions, just code. Here’s how they break down:

• Gearbox DAO

  • Scope:
    • Deliver new versions of core protocol contracts.
    • Expand Gearbox’s ecosystem through partnerships with Risk Curators, chains, and protocols.
    • Activate instances and appoint Instance Owners.
  • Notes:
    • The DAO cannot alter or reverse decisions made by Instance Owners or Risk Curators.
    • Post-upgrade, the DAO’s current responsibilities (e.g., managing markets, price feeds, and integrations) will become obsolete. These duties will transition to Chaos Labs as Risk Curators for all existing markets, except those already managed by K3.

• Instance Owners DAO representatives on specific chains.

  • Scope:
    • Whitelist tokens usable on their chain and assign approved Price Feeds for each.
    • Maximize token and price feed options for flexibility while conducting adequacy checks to protect users from exploits caused by oracle misconfigurations.
  • Notes:
    • Once assigned, the Instance Owner role cannot be revoked by the DAO.
    • Instance Owners cannot interfere with existing users or markets within their instance.

• Risk Curators

  • Scope:

    • Create money markets for in-demand collaterals and DeFi integrations, leveraging Gearbox platform to grow their business.
    • Configure owned markets using MarketConfigurator.

  • Notes:

    • Security checks for Gearbox-specific contracts are handled cryptographically by the Bytecode Repository, freeing curators to focus on optimizing risk parameters.

• Auditors

  • Scope:
    • Sign audited contract bytecode to be further submitted to the Bytecode Repository for reuse across Gearbox.
  • Notes:
    • Auditors operate independently from the DAO. The DAO does not guarantee the functionality or safety of contracts in the repository.

• External Developers

  • Scope:
    • Build plugins, adapters, and integration contracts reusable across the Gearbox ecosystem.
    • Collaborate with trusted auditors to publish audited code to the Bytecode Repository.
  • Notes:
    • The Bytecode Repository is a permissionless plugin storage, empowering integrators to benefit from Gearbox’s flexibility and composability.

Core Protocol Contracts

The key logic of Markets and Credit Accounts remains unchanged, V3.1 focuses on improving governance.

• Cross-Chain Multisig A DAO-controlled contract that executes transactions signed by the DAO.
  • Purpose: Acts as the DAO’s voice, broadcasting decisions passed via voting on Ethereum Mainnet to any EVM-compatible chain.
  • Functions: Activate instances with InstanceManager.activate, ensuring the DAO’s strategic interests are upheld across chains via CrossChainMultisig.submitBatch.
  • Note: After activating V3.1 and the Permissionless setup, governance will enter a transitional phase. Instance activation proposals (GIPs) will be voted on via Snapshot, and the existing Technical Multisig will serve as the Cross-Chain Multisig owner until fully on-chain DAO governance is implemented.
• Bytecode Repository A contract storing bytecode of audited contracts, signed by trusted auditors.
  • Purpose: The backbone of permissionless deployment, ensuring all ecosystem contracts match their audited versions.
  • Functions: Automates validation of deployed contracts, making secure, permissionless cross-chain deployments practical. If signed by an auditor, audit can be submitted by anyone via BytecodeRepository.submitAuditReport.
• Price Feed Store A contract managing lists of Price Feeds for token pricing within a specific instance.
  • Purpose: Provides the first line of defense against misconfiguration. Controlled by Instance Owners, it adds an external verification layer for risk-critical components that cannot be programmatically checked.
  • Functions: Configured by Instance Owner with addPriceFeed, allowPriceFeed and other functions.
• Market Configurator A Risk Curator-specific contract with permissions to configure underlying markets.
  • Purpose: Serves as the interface for Risk Curators to manage markets.
  • Functions: Controls markets' parameters through addPool, setPoolLimit, setPriceOracle and other methods (most are timelocked for users' safety).
  • Feature: Enforces a minimum 24-hour delay for configuration changes, ensuring stability and transparency.

Execution

The execution process is scheduled to commence approximately one week from now, pending the completion of the audit by core developers and ChainSecurity. Following the audit, the first actionable GIP will be submitted, with the anticipated roadmap comprising the following steps:

• Step 1: Deployment of Global Contracts Deploy global contracts, including Cross-Chain Multisig, Instance Manager, and other foundational components, and configure the system without integrating existing markets.
• Step 2: Deployment of V3.1 Price Feeds Deploy V3.1 price feeds and register them in the Price Feed Store.
• Step 3: Transition of Price Feeds in PriceOracleV3 Replace existing V3 price feeds in PriceOracleV3 with the V3.1 price feeds deployed in Step 2.
• Step 4: Completion of Migration Finalize the migration by deploying V3.1 contracts and granting them write access, upgrading PriceOracle and Credit Suite to V3.1, implementing the new loss policy, and transferring ownership of current markets to Chaos Labs.

The rollout is structured as a multi-step process to enable thorough testing of each component of the upgraded system, utilizing both internal tools and mainnet validations following each phase. All safety-critical transactions will be executed by the Technical Multisig, subject to the approval of dedicated GIPs via voting.