Gearbox DAO

Authors

lekho.eth

Summary

Successful implementation of the global setup described in [GIP-235] and [GIP-238] has allowed to seamlessly deploy, sync and activate instances on multiple chains, notably including BNB Smart Chain and World Chain where Gearbox hasn’t existed at all. Unfortunately, the setup process got stuck on Avalanche, where, due to an unexpectedly low block gas limit of 16M, one of the batches can’t be executed, locking other batches that follow after it as well.

This GIP proposes the Avalanche setup recovery plan that consists of skipping failing batches in Recovery Mode of the Cross-Chain Multisig, and rearranging remaining actions in such a way that all batches fit into the block gas limit. It also includes two other small actions, namely activating Berachain instance and adding two new public domains (PHANTOM_TOKEN and GATEWAY) to the bytecode repository.

Specification

Avalanche setup recovey

Cross-Chain Multisig (CCM) introduced as a key component of Gearbox Permissionless framework acts similarly to most multisig contracts with some notable distinctions:

• signatures are chain-agnostic, making it possible to replay batches on all chains and removing the need to vote for and sign all the setup batches on every new chain;
• when executing a batch on a given chain, only calls that target this specific chain (including global calls) are executed;
• batches maintain the chain-like structure so that they can only be executed in a fixed order, making it impossible to break the system on not-fully-synced chains by skipping or reshuffling them.

So far, there are four batches in the CCM:

• 0x2d8e...0b2b (Add auditors to bytecode repository and add public domains);
• 0xac3e...cbe9 (Allow system contracts and deploy key system contracts);
• 0x5e8a...20aa (Set USDT postfix, set global addresses and activate instances);
• 0x043b...5747 (Activate World Chain instance).

All of them have already been executed on Ethereum, Arbitrum, Optimism, Sonic, BNB Smart Chain and World Chain. On Avalanche, however, only the first batch has been executed succsessfully. The second one consumes roughly 23.5M gas (as can be seen from the transaction that executes the same batch on BSC) and doesn’t fit into network’s block gas limit of 16M. The third and fourth batches can’t be executed because of the chain-like structure of batches in the CCM. Since these batches contain some crucial setup steps, it makes Gearbox instance on Avalanche unusable.

Forunately, the Cross-Chain Multisig contract provides a way to deal with failures of such kind, which is called Recovery Mode. Once activated on a specific chain via enableRecoveryMode function, CCM skips all calls (except self-configuration) when executing batches. This allows to bring “broken” chain’s CCM in sync with CCMs on other chains. The only thing left is to disable Recovery Mode and re-vote to perform skipped actions with neccessary adjustments.

The recovery plan hence consists of the following steps:

1. Sign the RecoveryMode message to enable Recovery Mode on Avalanche after batch 0x2d8e...0b2b.
2. Execute batches 0xac3e...cbe9, 0x5e8a...20aa and 0x043b...5747 on Avalanche in Recovery Mode.
3. Submit and execute the batch that disables Recovery Mode on Avalanche (such call must be the only one in the batch).
4. From skipped calls, pick those that target Avalanche (including global calls) and arrange them in batches in such a way that those fit into the block gas limit. Note that global calls must also become Avalanche-specific since they’ve already been executed on other chains.
5. Submit and execute the resulting batches.

Berachain instance activation

It’s proposed to authorize new markets creation on Berachain (chain ID 80094) by activating Gearbox instance with the following parameters:

Parameter	Value
instanceOwner	0x1E9ec044853611F4bCD4BBcFE7657508BD1c53D3
treasury	0xef78F5FfD8c6c5aa45bCAb7f4BA638B0A4fbc7A1
weth	0x6969696969696969696969696969696969696969
gear	0x0000000000000000000000000000000000000000

New public domains

It’s proposed to add two new public domains to the bytecode repository on all chains. This change allows to increase the overall security of the system by applying standardized audit, deployment and verification procedure to two kinds of helper contracts that stand between Gearbox and integrated protocols:

• PHANTOM_TOKENs, which track users’ balances in non-tokenized pools (like Convex or Sky) and are required to use such positions as collateral in Gearbox markets;
• GATEWAYs, which automate native token wrapping/unwrapping and are required to interact with certain protocols and liquidity pools.

Implementation

The GIP asks DAO to authorize Technical/Cross-Chain Multisig members to sign a RecoveryMode message in CCM to enable the recovery mode on Avalanche as well as three pairs of SafeTx (in TM) and CompactBatch (in CCM) messages to submit and execute:

• batch 0xca8974d71c9fe6e01aa56b8e8d1e8078c8f0d8d0fbc795b06debe3f4ba9c87ee that disables recovery mode on Avalanche after failing batches are skipped;
• batch 0x8d70fc995166013e41387ad4f390455dfc3bb1c53d19bcac1fa124790ed4d095 that performs the first part of Avalanche setup (allows system contracts and deploys core contracts);
• batch 0x8fb87ccc0abcb93b510b467b2e9806287825dfb9fc1912976bd305056346c76d that performs the second part of Avalanche setup (deploys factories, saves global addresses and activates the instance), activates Berachain instance and adds public domains to the bytecode repository.

To execute the activation earlier, it’s proposed to allow signing the messages as soon as quorum is reached and the leading result is “For”, as proposed changes do not create risks to any funds.

The messages to sign can be found here. The script used to generate them: create-gip-239-messages.sh.