Add BAL Token Holder contract #1149
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TomAFrench
reviewed
Feb 17, 2022
There was a problem hiding this comment.
I imagine the main usecase for this would be for the funds which the LM committee is supposed to distribute, correct? If so it might be worth adding another function to allow other tokens which are sent to this address to be recovered.
Justification being that there's a decent chance that if the pools have co-incentives with another token then there's a decent chance that someone sometime is going to send that token to this contract.
I'd keep this as a separate function to BAL so that we can have separate authorisation for withdrawing BAL vs other tokens.
TomAFrench
reviewed
Feb 17, 2022
Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
TomAFrench
approved these changes
Mar 23, 2022
TomAFrench
added a commit
that referenced
this pull request
Mar 24, 2022
* master: Deploy Batch Relayer V2 to Polygon (#1182) Fix reading historical balances/total supply by timestamp (#1201) Prevent duplicate gauges for a pool being added to GaugeController (#1185) Authorizer: Fix missing renames (#1193) Misc fixes on LM system (#1196) Lock gauge implementation on LiquidityGaugeFactory (#1195) Create bal_supply.md (#1192) Use BALTokenHolder factory in coordinator (#1194) fix: Decimal math errors in stable-pool math.ts (#1188) Fix tests for real now Fix tests Add BAL Token Holder contract (#1149) Authorizer: Rename and improve wording (#1167) ManagedPool weight storage (#1102) Add snapshot link to veBAL script readme (#1189) veBALDeploymentCoordinator gauge deployment (#1187)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This contract is meant to act as the recipient of a single recipient gauge (#1144). I've thought of alternative ways to tackle the problem, such as embeddeding this in the gauge itself, but I wanted to keep the
checkpoint()interface in the gauge, and so this pattern seemed to make sense.I don't think the need for multiple calls (
checkpoint+withdrawFunds) is a problem, since these can always be scripted in a contract if desired, or even batched by e.g. a Gnosis Safe, which we expect the authorized parties to use.