lekho.eth
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.
Cross-Chain Multisig (CCM) introduced as a key component of Gearbox Permissionless framework acts similarly to most multisig contracts with some notable distinctions:
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:
RecoveryMode message to enable Recovery Mode on Avalanche after batch 0x2d8e...0b2b.0xac3e...cbe9, 0x5e8a...20aa and 0x043b...5747 on Avalanche in Recovery Mode.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 |
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.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:
0xca8974d71c9fe6e01aa56b8e8d1e8078c8f0d8d0fbc795b06debe3f4ba9c87ee that disables recovery mode on Avalanche after failing batches are skipped;0x8d70fc995166013e41387ad4f390455dfc3bb1c53d19bcac1fa124790ed4d095 that performs the first part of Avalanche setup (allows system contracts and deploys core contracts);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.