[BIP-277] Enable Authorizer Wrapper

Governance General Proposal
1

Motivation

As part of the timelock authorizer rollout which has been temporarily put on hold we executed BIP-169 which was a pre-requisite requirement. BIP-169 disabled the use of GaugeAdderV2 in favor of preparing GaugeAdderV3 to be used with the timelock authorizer. Since the timelock authorizer is on an uncertain timeline a new “Authorizer Wrapper” has been deployed which brings the GaugeAdderV3 online without requiring the timelock authorizer to be in use.

This will allow the Balancer Maxis to go back to adding gauges from the LM Multisig and no longer need the DAO Multisig to add gauges directly to the controller which is an inherently risky and dangerous practice.

Specification

Ethereum

#1
The DAO Multisig eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

which corresponds to the address for the DAO Multisig. This allows the DAO Multisig to call setAuthorizer on the Vault.

#2
The DAO Multisig eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8 calling setAuthorizer with the following argument:

newAuthorizer: 0x6048A8c631Fb7e77EcA533Cf9C29784e482391e7

which can be confirmed here.

#3
The DAO Multisig eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling renounceRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

which corresponds to the address for the DAO Multisig. This removes the ability for the DAO Multisig to call setAuthorizer on the Vault.

Arbitrum

#1
The DAO Multisig on Arbitrum arb1:0xaF23DC5983230E9eEAf93280e312e57539D098D0 will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0xaF23DC5983230E9eEAf93280e312e57539D098D0

which corresponds to the address for the DAO Multisig. This allows the DAO Multisig to call setAuthorizer on the Vault.

#2
The DAO Multisig eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8 calling setAuthorizer with the following argument:

newAuthorizer: 0x6B1Da720Be2D11d95177ccFc40A917c2688f396c

which can be confirmed here.

#3
The DAO Multisig on Arbitrum arb1:0xaF23DC5983230E9eEAf93280e312e57539D098D0 will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling renounceRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: arb1:0xaF23DC5983230E9eEAf93280e312e57539D098D0

which corresponds to the address for the DAO Multisig. This removes the ability for the DAO Multisig to call setAuthorizer on the Vault.

Polygon

#1
The DAO Multisig on Polygon matic:0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85 will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85

which corresponds to the address for the DAO Multisig. This allows the DAO Multisig to call setAuthorizer on the Vault.

#2
The DAO Multisig on Polygon matic:0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85 will interact with the Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8 calling setAuthorizer with the following argument:

newAuthorizer: 0x020301b0a99EFB6816B41007765Fb577259eC418

which can be confirmed here.

#3
The DAO Multisig on Polygon matic:0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85 will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling renounceRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0xeE071f4B516F69a1603dA393CdE8e76C40E5Be85

which corresponds to the address for the DAO Multisig. This removes the ability for the DAO Multisig to call setAuthorizer on the Vault.

Gnosis

#1
The DAO Multisig on Gnosis gno:0x2a5AEcE0bb9EfFD7608213AE1745873385515c18 will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0x2a5AEcE0bb9EfFD7608213AE1745873385515c18

which corresponds to the address for the DAO Multisig. This allows the DAO Multisig to call setAuthorizer on the Vault.

#2
The DAO Multisig on Gnosis gno:0x2a5AEcE0bb9EfFD7608213AE1745873385515c18 will interact with the Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8 calling setAuthorizer with the following argument:

newAuthorizer: 0x03F3Fb107e74F2EAC9358862E91ad3c692712054

which can be confirmed here.

#3
The DAO Multisig on Gnosis gno:0x2a5AEcE0bb9EfFD7608213AE1745873385515c18 will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling renounceRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0x2a5AEcE0bb9EfFD7608213AE1745873385515c18

which corresponds to the address for the DAO Multisig. This removes the ability for the DAO Multisig to call setAuthorizer on the Vault.

Optimism

#1
The DAO Multisig on Optimism oeth:0x043f9687842771b3dF8852c1E9801DCAeED3f6bc will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0x043f9687842771b3dF8852c1E9801DCAeED3f6bc

which corresponds to the address for the DAO Multisig. This allows the DAO Multisig to call setAuthorizer on the Vault.

#2
The DAO Multisig on Optimism oeth:0x043f9687842771b3dF8852c1E9801DCAeED3f6bc will interact with the Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8 calling setAuthorizer with the following argument:

newAuthorizer: 0xAcf05BE5134d64d150d153818F8C67EE36996650

which can be confirmed here.

#3
The DAO Multisig on Optimism oeth:0x043f9687842771b3dF8852c1E9801DCAeED3f6bc will interact with the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 calling grantRole with the following arguments:

role: 0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0

can be confirmed here .

account: 0x043f9687842771b3dF8852c1E9801DCAeED3f6bc

which corresponds to the address for the DAO Multisig. This removes the ability for the DAO Multisig to call setAuthorizer on the Vault.

2 Likes
2

https://snapshot.org/#/balancer.eth/proposal/0x056448eeac1345d8b7aaca10f01c4325c5254bb1652bc256fceac9a0859dd178

3

It seems there’s been some concern about this proposal, which is very understandable given that it alters a key piece of infrastructure (the Authorizer, which manages all permissions), and there’s barely any explanation as to why or how. I aim to provide some information in this regard.

The Problem

The current Authorizer acts as a database of permissions (called ‘roles’ in that contract), which other contracts query via the canPerform function (i.e. they ask ‘can account X perform action Y?’). We grant and revoke permissions via grantRole and revokeRole.

Some contracts were inherited from the Curve codebase, and as such are written using Vyper. These contracts use a different permission system, so we introduced the AuthorizerAdaptor, which adapts the Vyper contracts to work with our Authorizer system.

Unfortunately, the AuthorizerAdaptor has a bug that can result in escalation of privileges, as it can be tricked into checking permissions incorrectly. And because many contracts (most of the veBAL system, including gauges and the GaugeController) have the Adaptor address baked into them, we cannot replace it without redeploying these entire systems as well.

Because of this, we’ve developed the AuthorizerAdaptorEntrypoint, a contract that is meant to be called when interacting with the Adaptor (i.e. it acts as its entrypoint), and which correctly performs the permission check the Adaptor does faultily. This means that calls through the Entrypoint are not subject to the bug that causes escalation of privileges, and can be made safely.

However, this is not sufficient, as we also need to prevent people from calling the Adaptor directly (and potentially exploiting the bug). The simplest way to do this is by including special behavior in the Authorizer itself: it can be modified to never let anyone perform any call via the Adaptor, except the Entrypoint, which we know works correctly.

The Solution

This proposal introduces the AuthorizerWithAdaptorValidation contract, with performs exactly the task described above. Even people with limited technical knowledge should be able to follow the canPerform function, which simply rejects any permission check performed by the Adaptor unless the call originated in the Entrypoint. For any other scenario, it falls back to the current Authorizer.

This fallback mechanic means that we do not need to perform any permission migration or anything of the sort, as the current Authorizer will still be the one that stores permissions. We will continue granting and revoking them at the current address (0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 in all networks), using the same functions we currently use.

All in all, this proposal fixes the Adaptor bug in a very surgical and nondisruptive way, without causing any further changes in the permission system, and without requiring any complex migrations. We will eventually replace this temporary Authorizer with the TimelockAuthorizer, but this lets us fix the issue without having to wait until that component is ready.

11 Likes