# \[BIP-277\] Enable Authorizer Wrapper **URL:** \ **Category:** General Proposal\ **Created:** [April 28, 2023, 5:42pm UTC](https://forum.balancer.fi/t/bip-277-enable-authorizer-wrapper/4718 "2023-04-28T17:42:41Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![solarcurve](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/solarcurve/32/1487_2.png) [@solarcurve](https://forum.balancer.fi/u/solarcurve)\ **Post date:** [April 28, 2023, 5:42pm UTC](https://forum.balancer.fi/t/bip-277-enable-authorizer-wrapper/4718/1 "2023-04-28T17:42:41Z")
> ### Motivation As part of the [timelock authorizer rollout](https://forum.balancer.fi/t/bip-140-introduce-timelockauthorizer/4159) which has been temporarily put on hold we executed [BIP-169](https://forum.balancer.fi/t/bip-169-execute-the-transition-migrator/4323) 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/mainnet/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/tasks/20230414-authorizer-wrapper/output/mainnet.json). > > #3 > The DAO Multisig `eth:0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will interact with the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` calling `renounceRole` with the following arguments: > > role: `0x1cbb503dcc0f4acaedf71a098211ff8b15a220fc26a6974a8d9deaab040fa6e0` > > can be confirmed [here](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/mainnet/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/arbitrum/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/tasks/20230414-authorizer-wrapper/output/arbitrum.json). > > #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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/arbitrum/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/polygon/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/tasks/20230414-authorizer-wrapper/output/polygon.json). > > #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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/polygon/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/gnosis/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/tasks/20230414-authorizer-wrapper/output/gnosis.json). > > #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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/gnosis/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/optimism/action-ids.json#L30). > > 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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/tasks/20230414-authorizer-wrapper/output/optimism.json). > > #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](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/optimism/action-ids.json#L30). > > 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. ---
**Author:** ![Xeonus](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/xeonus/32/3621_2.png) [@Xeonus](https://forum.balancer.fi/u/Xeonus)\ **Post date:** [May 3, 2023, 2:20pm UTC](https://forum.balancer.fi/t/bip-277-enable-authorizer-wrapper/4718/2 "2023-05-03T14:20:22Z")
[https://snapshot.org/#/balancer.eth/proposal/0x056448eeac1345d8b7aaca10f01c4325c5254bb1652bc256fceac9a0859dd178](https://snapshot.org/#/balancer.eth/proposal/0x056448eeac1345d8b7aaca10f01c4325c5254bb1652bc256fceac9a0859dd178) ---
**Author:** ![nventuro](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/nventuro/32/49_2.png) [@nventuro](https://forum.balancer.fi/u/nventuro)\ **Post date:** [May 8, 2023, 8:29pm UTC](https://forum.balancer.fi/t/bip-277-enable-authorizer-wrapper/4718/3 "2023-05-08T20:29:55Z")
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](https://etherscan.io/address/0x6048A8c631Fb7e77EcA533Cf9C29784e482391e7#code#F13#L67), 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.