Balancer’s access control system is based on permissions, which can be granted and revoked. These are controlled by the
Authorizer contract, which was deployed along with the
Vault in April 2021.
This proposal aims to replace it with the
TimelockAuthorizer, which provides more fine-grained control over permissions, as well as new security features. It additionally addresses a bug in the
AuthorizerAdaptor contract that was disclosed via the Immunefi bug bounty program.
For simplicity, this migration will initially only take place on the main Ethereum network and none of the L2s or sidechains.
TimelockAuthorizer contract (developed by Balancer Labs) is a drop-in replacement of the current
Authorizer contract, enabling new use cases and providing security improvements.
I encourage everyone to read more about each of these improvements, as they will greatly impact the operation of the Balancer DAO if this proposal where to pass (particularly the ‘Delays’ section).
As of today, permissions are global: an account with a permission can use it on any contract in the entire network. For singleton contracts (like the
Vault or the
ProtocolFeeWithdrawer) this is not an issue since there is only one of them. However, for contracts with multiple instances (like liquidity pools) this means that an account with e.g. permission to set swap fees can use that permission on any pool of the same type (i.e. that is created in the same factory).
TimelockAuthorizer allows granting permissions over a single contract, meaning it will e.g. be possible to allow an account to manage a single pool’s swap fees while not being able to do the same on any other pool. This has always been supported on the original
IAuthorizer interface - the current
Authorizer simply did not implement this capability (for simplicity).
It will still be possible to grant global permissions by passing the special sentinel address known as
EVERYWHERE (equal to
Granters and Revokers
Authorizer features a single all-powerful role (
0x00..00), currently held by the Balancer DAO Governance Multisig (
0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f). Accounts with this role can grant and revoke any permission - but they are the only one that can do so.
TimelockAuthorizer instead distinguishes between having a permission and being a granter or a revoker for a permission. This will increase the capacity of the the DAO Governance Multisig to delegate subtasks to other accounts. For example, instead of simply granting permission to trigger the Liquidity Mining BAL bridging process to the Balancer Labs Operations Multisig, it could make said multisig a granter, increasing flexibility (e.g. letting Balancer Labs develop contracts that trigger this process automatically and grant them permission to operate without having to involve the Governance Multisig).
TimelockAuthorizer also has a root account, initially set to the Balancer DAO Governance Multisig, which always has permission to grant and revoke all permissions, and to create and destroy granters and revokers. These permissions cannot be revoked by anyone (except by transferring root to a different account), meaning it always retains full control over the system and can safely evict any rogue granters or revokers.
Arguably the most important feature of the
TimelockAuthorizer is the capacity to assign minimum delays to certain actions. If an action has a delay, then accounts with that permission cannot immediately execute said action: they can only schedule an execution at some time in the future (greater than the action’s delay).
Critically, these scheduled executions can be cancelled, which lets the community detect and stop malicious or erroneous actions after they are committed on-chain but before they are actually executed, greatly decreasing the risk of user error, phishing attacks, etc. This also provides users who are not happy with a future action (e.g. increased fees) with the opportunity to exit the system before those measures take place.
It is also possible to assign delays to the granting and revoking of permissions. By e.g. delaying granting and revoking the permission to mint BAL (currently only held by the automated Liquidity Mining system), we end up with a much stronger committment to said system, and greatly reduce the risk of e.g. a malicious actor somehow acquiring minting capabilities. Similar measures can be applied to other powerful permissions, such as relayer privilege, adding gauge factories to the
In general, if a multisig wields a permission (e.g. adding gauges) then its execution should have a delay (to review the multisig’s action). Instead, if a contract wields a permission (e.g. the
GaugeAdder) then its granting should be delayed (to review the code of the contract that will use it).
For more information on how delays relate to security, see my talk at the DeFi Security Summit.
Authorizer Adaptor Entrypoint
A team of independent security researchers submitted a vulnerability disclosure via the Immunefi bug bounty program that relates to the operation of the
AuthorizerAdaptor. Said issue was promptly mitigated and resolved, but operation of some components of the system (particularly adding reward tokens and killing gauges) has been degraded as a result. The
TimelockAuthorizer includes a fix for this in the form of the
AuthorizerAdaptorEntrypoint, which provides a secure way to restore regular operation.
To ease the transition to this new system, Balancer Labs has also developed the
TimelockAuthorizerMigrator contract, which prepares the
TimelockAuthorizer by granting some of the permissions that exist in the current
Authorizer, as well as setting up some initial delays.
In order to complete the migration, the migrator needs permission to call
setAuthorizer in the
Vault, which can only be granted by the Balancer DAO Governance Multisig. Additionally, the Multisig must also claim the root role in the
TimelockAuthorizer, completing the root transfer from the migrator to the Multisig. This cannot be done before January 5th, 2023, since the root transfer has a minimum delay of 30 days.
From the Balancer DAO Governance Multisig (
role argument corresponds to the permission to call
setAuthorizer on the
account is the
TimelockAuthorizer address can also be found in its deployment.
claimRoot cannot be called until January 5th, 2023.
Once these two steps are done, any account in the network can call
finalizeMigration on the
0xf8ee6f1F9B54F9b2C192D703ea2d22112cBC062b) to complete the process.
No new permissions will be granted. The Migrator contract ensures that all permissions granted during the migration exist in the current
Authorizer. Some of the current permissions have been left out however, since they no longer apply (e.g. permission to pause the
Vault, which can no longer be paused as of July 2021).
Any permissions granted after the deployment of the
TimelockAuthorizer (Nov 30th) are not automatically migrated, and will have to be re-granted after the migration.
The following actions have initial delays associated to them. As a rule of thumb, I propose that we assign delays to actions with high impact and that do not require urgent execution.
Vault.setAuthorizer, 30 days. All delays must be shorter or equal to this one, as they could be otherwise bypassed by simply changing the Authorizer and removing delays entirely.
SmartWalletChecker.allowlistAddress, 7 days. Once veBAL is locked this cannot be undone in any way, so extra care should be taken when adding contracts to the allowlist.
VotingEscrowDelegationProxy.setDelegation, 14 days. veBAL boost upgrades are infrequent and should be handled with care, since they can greatly affect the veBAL operation.
GaugeAdder.addGaugeFactory, 14 days. Adding new gauge factories is a critical action as it grants them permission to mint BAL. See my talk at ETHLatam (in Spanish) for more details.
BalancerTokenAdmin.mint, 30 days. This prevents other accounts from being able to mint BAL.
ProtocolFeesCollector.withdrawCollectedFees, 30 days. This prevents bypassing the
GaugeController.addGauge, 14 days. This prevents bypassing the
BALTokenHolder.withdrawFunds, 7 days. This manages the BAL minted for the veBAL gauge.
- Vault relayer permissions, 7 days. Relayers are quite powerful, so creating them should be carefully reviewed.
The creation of the full list of permissions and their delays can be inspected in this script.
TimelockAuthorizer is a relatively complex contract, which will be used to manage all permissions on the Balancer ecosystem, including the Liquidity Mining program and management of Protocol Fees. As such, care should be taken to review it.
The Balancer Labs team has been working on this contract for around 8 months, and we are confident in its correctness. It has been audited by ABDK, and we’re currently working with Certora to conduct a second review.