From 432449d7b330ec6edf5a8e0746644a253486ca87 Mon Sep 17 00:00:00 2001 From: Milap Sheth <milap@interoplabs.io> Date: Wed, 20 Nov 2024 13:55:45 -0500 Subject: [PATCH] docs(evm): add integration requirements for multisig accounts (#209) --- contracts/gateway/INTEGRATION.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/contracts/gateway/INTEGRATION.md b/contracts/gateway/INTEGRATION.md index 968a6a7a..8fed122f 100644 --- a/contracts/gateway/INTEGRATION.md +++ b/contracts/gateway/INTEGRATION.md @@ -237,6 +237,21 @@ The EVM gateway uses a proxy pattern for upgrades, i.e there's a fixed proxy con The upgrade mechanism is expected to vary for non-EVM chains (some chains support contract upgrades natively). +### Multisig + +A multisig might be used for certain privileged roles in the smart contracts, e.g. the `operator` account in the `AxelarAmplifierGateway` and `AxelarServiceGovernance`, the `owner` of the `AxelarAmplifierGateway` (temporarily, until the transfer to Governance), and the `owner` of some less critical contracts like the `AxelarGasService`. + +For EVM chains, a custom [Multisig contract](../governance/Multisig.sol) is being used. However, another approach might make sense for other chain integrations. If the chain supports native multisig accounts, that might be preferrable. If it doesn't or it's capability is limited, we recommend using the preferred Multisig contract that's standard in the ecosystem (e.g. for EVM chains, [Safe](https://github.com/safe-global/safe-smart-account) is the most popular multisig). If this isn't available, then a custom contract needs to be written. + +For CosmWasm contracts that live on Axelar itself, the Axelar governance can be the owner. For other privileged roles, the [native multisig accounts](https://docs.cosmos.network/main/user/run-node/multisig-guide) on Axelar can be used if needed. + +Requirements: +1. Supports a `k`-of-`n` signer set. `n` is not expected to be greater than 10. +2. A method to update the signer set to a new one, signed off by the current signer set. +3. A method to execute another arbitrary contract, signed off by the current signer set. If arbitrary execution isn't supported, the multisig needs to be able to execute `transferOwnership`, `transferOperatorship`, `upgrade` methods on an arbitrary contract, along with specific methods in different contracts that are intended to be callable from the privileged role (e.g. `rotateSigners` on the Gateway can be called by the `operator`). +4. Multisig signing can be performed offline, ideally with hardware wallet support. +5. Easy to use scripts (or UI if it can be run in offline mode) to sign multisig transactions. Script for EVM chains can be found [here](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/evm/multisig.js) (note that some cmds are missing there, since EVM gateway is owned by the governance contract already). + ## Signer rotation delay The auth mechanism of the gateway contract tracks the recent list of signers that were active. This allows a recent signer set to recover the gateway in the event of a compromise of the latest signer set, or a bug in the gateway or Amplifier that allows rotating to a malicious signer set. To prevent the gateway contract from being lost by successive malicious rotations, a minimum delay is enforced between signer rotations (e.g. 1 day). This allows the decentralized governance to step in to react to any issues (for e.g. upgrade the gateway).