It came up in recent discussions that we should be using the same Authorizer for v2 and v3. All the veBAL stuff is tied to it; the BAL/WETH pool is on v2, BAL minting is tied irrevocably to the minter on v2, etc.
If it's true that we are committed to using the same Authorizer instance, we shouldn't have a way to set it independently in v3. If we pass in the Authorizer on deployment, and allow governance to change it like in v2, we would have to coordinate v2 and v3 updates to ensure we're using the same instance - and they could diverge.
Here, we pass in the v2 Vault address instead, store it immutably, and fetch the initial Authorizer from it. Since it would impact performance to make external calls to v2 on every authentication, we still cache it in a storage variable like we do now. (It should change very infrequently.)
If it does change, there is a permissionless call to fetch it from v2 again and update the cached value.
I thought of making the v2 Vault address a literal constant instead of immutable storage, but 1) it's possible it won't be that address on future deployments (or forks); and 2) that would be really hard to test.
Type of change
[ ] Bug fix
[X] New feature
[ ] Breaking change
[ ] Dependency changes
[ ] Code refactor / cleanup
[ ] Optimization: [ ] gas / [ ] bytecode
[ ] Documentation or wording changes
[ ] Other
Checklist:
[X] The diff is legible and has no extraneous changes
[X] Complex code has been commented, including external interfaces
[ ] Tests have 100% code coverage
[X] The base branch is either main, or there's a description of how to merge
Description
It came up in recent discussions that we should be using the same Authorizer for v2 and v3. All the veBAL stuff is tied to it; the BAL/WETH pool is on v2, BAL minting is tied irrevocably to the minter on v2, etc.
If it's true that we are committed to using the same Authorizer instance, we shouldn't have a way to set it independently in v3. If we pass in the Authorizer on deployment, and allow governance to change it like in v2, we would have to coordinate v2 and v3 updates to ensure we're using the same instance - and they could diverge.
Here, we pass in the v2 Vault address instead, store it immutably, and fetch the initial Authorizer from it. Since it would impact performance to make external calls to v2 on every authentication, we still cache it in a storage variable like we do now. (It should change very infrequently.)
If it does change, there is a permissionless call to fetch it from v2 again and update the cached value.
I thought of making the v2 Vault address a literal constant instead of immutable storage, but 1) it's possible it won't be that address on future deployments (or forks); and 2) that would be really hard to test.
Type of change
Checklist:
main
, or there's a description of how to mergeIssue Resolution