Authors

lekhovitsky, desnake

Summary

[GIP-230] outlined the vision and design for Gearbox v3.1 and the Permissionless update. This proposal presents the first actionable steps to implement that plan, seeking DAO approval for key actions to deploy and configure the Permissionless system.

Specification

The v3.1 Permissionless system is audited by ChainSecurity (audits are already public and can be seen here).

Among the key contracts of Permissionless system are Cross-Chain Multisig deployed at 0xcCcccCcCC78ed81c09A9415c7B836e3a4Ea381De, Instance Manager deployed at 0x77777777dC70963123bf5A6ED99663fEB824c03A, and Bytecode Repository deployed at 0x9700a405AFF956f0BAafC0a7eC57b71e656d5D9B (these addresses are identical for all chains).

Cross-Chain Multisig consists of the same signers as existing Technical Multisig and is currently owned by Technical Multisig (in future, ownership shall passed to an on-chain voting system). Instance Manager is owned by Cross-Chain Multisig with ownership to be passed to chain-specific Instance Owners upon activation of each instance. Bytecode Repository is configured by Cross-Chain Multisig.

Add auditors to bytecode repository

Note: adding auditors is a chain-agnostic transaction, meaning that after being signed by Cross-Chain Multisig it can be executed on any chain (that is active now or will be activated in the future).

Bytecode Repository stores smart contract bytecodes and audit details, enabling permissionless deployment and validation across the Gearbox protocol. Bytecodes and auditor signatures can be uploaded permissionlessly, encouraging external collaboration.

The initial list of whitelisted auditors' addresses to be added via addAuditor function of Bytecode Repository is as follows:

• Decurity: 0xF8b42E1FbcFAe22a37C4e3956Cd532a4E57516F9
• ChainSecurity: 0x9A4Ff94eC9400698cD7fbe28b1Dc0d347a05310d
• MixBytes: 0xc9E0D8DcEBf7323437DC952B92d6fdFCD4e3DA57
• WatchPug: 0x192bDD30D272AabC2B1c3c719c518F0f2d10cc60

Add public domains

Note: adding public domain is a chain-agnostic transaction, meaning that after being signed by Cross-Chain Multisig, it can be executed on any chain (that is active now or will be activated in the future).

There are two kinds of contract domains: public and system.

• Public-domain contracts can be deployed once their bytecode is signed by at least one authorized auditor.
• System-domain contracts contain the core logic of the Gearbox protocol and require DAO approval on top of the auditor signature.

Below is proposed initial list of public domains to be created using addPubicDomain function of Bytecode Repository:

• "ADAPTER"
• "BOT"
• "DEGEN_NFT"
• "IRM"
• "LOSS_POLICY"
• "PRICE_FEED"
• "RATE_KEEPER"
• "ZAPPER"

New public domains can only be added by DAO, to avoid cybersquatting and other misuse.

Allow system and public contracts

Note: allowing contracts is a chain-agnostic transaction, meaning that after being signed by Cross-Chain Multisig it can be executed on any chain (that is active now or will be activated in the future).

The list of contracts initially uploaded to the Bytecode Repository can be seen here.

It is proposed to allow the 24 contracts listed in _getCoreContracts function as system contracts using allowSystemContract function of Bytecode Repository.

For completeness, it is also proposed to allow remaining contracts from this file as public in the same batch using allowPublicContract function of Bytecode Repository even though it doesn't require Cross-Chain Multisig permissions.

Deploy key system contracts

Note: deploying system contracts is a chain-agnostic transaction, meaning that after being signed by Cross-Chain Multisig it can be executed on any chain (that is active now or will be activated in the future).

Some system contracts are required to be deployed from the day-0, below is the list to be deployed using deploySystemContract function of Instance Manager.

• BotListV3
• GearStakingV3 (note that this contract isn't redeployed for chains with existing using existing v3.0 staking contract)
• PriceFeedStore
• MarketConfiguratorFactory
• CreditFactory
• PoolFactory
• PriceOracleFactory
• InterestRateModelFactory
• RateKeeperFactory
• LossPolicyFactory

Set USDT postfix

Some contracts require different implementations for interacting with specific tokens. For example, existing Pools and Credit Managers for USDT use implementation that accounts for USDT-specific transfer fees.

It's proposed to add USDT-specific postfix on Mainnet using setTokenSpecificPostfix function of Bytecode Repository.

Set global addresses

Note: adding global addresses is a chain-agnostic transaction, meaning that after being signed by Cross-Chain Multisig it can be executed on any chain (that is active now or will be activated in the future).

It is proposed to save some global addresses for easier discovery by off-chain services via setGlobalAddress function of the Instance Manager contract.

Compressors

Compressors are periphery contracts not intended for on-chain usage and mostly used by Gearbox SDK and services that are reliant on it allowing to get useful data in an easy to work with format. The list of compressors to be saved can be found here.

Router

Router is another periphery contract that builds routes to enter into and exit from positions and is used extensively by front-end as well as liquidation bots.

Legacy router

For chains with existing v3.0 markets it's also proposed to store the address of a legacy router contract:

• Mainnet: 0xA6FCd1fE716aD3801C71F2DE4E7A15f3a6994835
• Optimism: 0x89f2E8F1c8d6D7cb276c81dd89128D08fc8E3363
• Arbitrum: 0xF26186465964ED3564EdFE0046eE65502a6Ac34D
• Sonic: 0x9Fae6aA45aF0fcf94819fCE4f40416C76ce0928b

Activate instances

Gearbox DAO approves operations of the Protocol by activating Instance for a particular chain using activate function of Instance Manager.

The list of instances to activate is as follows:

• Mainnet:
  • Instance Owner: 0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
  • WETH: 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2
  • GEAR: 0xBa3335588D9403515223F109EdC4eB7269a9Ab5D
  • Treasury: 0x3E965117A51186e41c2BB58b729A1e518A715e5F
• Arbitrum:
  • Instance Owner: 0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
  • WETH: 0x82aF49447D8a07e3bd95BD0d56f35241523fBab1
  • GEAR: 0x2F26337576127efabEEc1f62BE79dB1bcA9148A4
  • Treasury: 0x2c31eFFE426765E68A43163A96DD13DF70B53C14
• Optimism:
  • Instance Owner: 0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
  • WETH: 0x4200000000000000000000000000000000000006
  • GEAR: 0x39E6C2E1757ae4354087266E2C3EA9aC4257C1eb
  • Treasury: 0x1ACc5BC353f23B901801f3Ba48e1E51a14263808
• Sonic:
  • Instance Owner: 0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
  • WETH: 0x039e2fB66102314Ce7b64Ce5Ce3E5183bc94aD38
  • GEAR: 0x0fDbce271bea0d9819034cd09021e0bBE94be3Fd
  • Treasury: 0x74028Cf1cBa6A4513c9a27137E7d0F3847833795
• Avalanche:
  • Instance Owner: 0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
  • WETH: 0xb31f66aa3c1e785363f0875a1b74e27b85fd66c7
  • GEAR: 0x0000000000000000000000000000000000000000
  • Treasury: 0xef78F5FfD8c6c5aa45bCAb7f4BA638B0A4fbc7A1
• BNB Chain:
  • Instance Owner: 0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
  • WETH: 0xbb4CdB9CBd36B01bD1cBaEBF2De08d9173bc095c
  • GEAR: 0x0000000000000000000000000000000000000000
  • Treasury: 0xef78F5FfD8c6c5aa45bCAb7f4BA638B0A4fbc7A1

Proposed instance owner is 4/12 multisig that consists of existing members of Technical Multisig, except that Mikko is replaced with desnake.

As described in [GIP-230], Instance Owners' goal is to ensure that Risk Curator are equipped with sufficient list of available price feeds. Instance Owners' sole goal is to serve as a preliminary protection layer against misconfigurations and malicious actions.

Once ownership of Instance Managers is given to an Instance Owner, DAO fully passes decision-making power to an IO to further act without additional DAO approvals.

Note: GEAR token is not present on Avalance and BNB Chain, hence its address is not set upon activation. Should the token ever be added there at some later stage, it can be set by Cross-Chain Multisig using setGlobalAddress function of the Instance Manager contract.

Implementation

Upon DAO approval via this GIP, transactions will be submitted to the Cross-Chain Multisig for signing by Technical Multisig members. All actions are designed to align with the audited v3.1 Permissionless system, ensuring security and decentralization.

To speed up implementation, this GIP doesn't include the list of transactions, hashes of bytecode to allow and addresses of compressors and router which undergo rigorous testing at this very moment. Instead, it just lists steps to be executed by the Cross-Chain Multisig in a descriptive manner. Taken that these transactions set up new entities and their configs, no existing positions and funds are affected by its correctness.