Context: The Axelar network is a decentralized interoperability network connecting 40+ chains, supported by 75 active validators with full on-chain governance (see https://axelarscan.io). All network functions such as processing of cross-chain messages need to be approved by the majority stake/validators. All upgrades must be approved by the token holders and coordinated by the network of validators. The Axelar gateway contracts (deployed on EVM chains) initially had an upgrade function governed by an offline emergency committee to be able to correct bugs and adjust the protocol as the system was built. Today the network has been stable for over a year, with dozens of audits and bug bounties. Hence the EVM gateway can also transition into a fully decentralized mode of operations.
A Potential Approach: Pass all gateway upgrades via on-chain governance on the Axelar Network and transition to a fully decentralized upgrade path on the gateway. The Axelar network has a governance mechanism built in that requires the token holders to vote on all network upgrades. We can extend this functionality to vote on upgrades to the gateway smart contracts. That is, the upgrades on the network and on the gateway contracts will follow a similar flow:
- A proposal is posted on chain,
- The token holders vote, and if passed,
- The network or the contracts are upgraded.
All proposers are encouraged to pre-post their intentions on https://community.axelar.network, gather feedback, and only then initiate the on-chain votes.
Additional safeguards under consideration:
Timelocks. A standard upgrade path with a timelock that requires only approvals of Axelar token holders. That is, once the governance on the network passes the upgrade, there is a, say, 1-week delay and then the upgrade applied. Another governance proposal may be issued/approved to cancel a pending upgrade.
The flow becomes:
Request for comments (~1 week) ->
Submit an onchain proposal ->
Approval by token holders ->
Timelock for 1-7 days ->
Upgrade
Proposed timelock configuration:
Default: 7 days.
Min timelock: 1 day.
A timelock is used to prevent against “bad upgrades” that may be a result of a bug or a network compromised. In that instance, once the bad upgrade is detected, the network can be patched/upgraded, and the contract upgrade can be canceled within the timelock window.
Rate limit operators for token transfers. For token bridge functionality via Axelar, we might want to have two policies: (the upgrade policy, the operator policy). The upgrade policy is instantiated via the network governance, as described above. The operator functions can update rate limits on the contracts. Then, in worst case scenarios, they can set limit = 0, effectively pausing the token transfers. These operator functions are specific to the bridge application on top of the Axelar protocol and won’t affect applications relying on General Message Passing at all.
The rate limit operators are not allowed to upgrade or perform any other function, so worst case, they can temporarily break liveness. [If they become malicious and break token bridging liveness, the upgrade path may be followed to upgrade the contract and remove them completely resuming normal flows].
Additional resources:
- Current network governance parameters are here: Interchain Explorer by Cosmostation .
- These parameters should be revised in parallel.
