Conversation
Angle has a small modification in their Curve fork : they name a variable staking_token() instead of lp_token() as in the original Curve code.
|
Architecture of the lenses and how the balances are reported to the CR oracle :
(I'm never doing a paint chart ever again, lucidchart & drawio ftw) |
|
Removing draft status. I'm happy with the PR as it is. After a review on the Solidity side, we can deploy the |
|
|
||
| /// @title 80-BAL-20-WETH BPT PCV Deposit | ||
| /// @author Fei Protocol | ||
| contract VeBalDelegatorPCVDeposit is |
There was a problem hiding this comment.
should this include governor bravo compatibility? Vote escrow is a hard action to undo
There was a problem hiding this comment.
We can add OZGovernor capability (that have a contract ready & tested), but when I asked Kia he said that Balancer does everything with snapshot + multisigs, no governor
There was a problem hiding this comment.
Can you follow up and make sure they have no intentions of putting anything on-chain?
There was a problem hiding this comment.
including for example a nope-dao?
2 participants
This pull-request contains several changes:
VeBalDelegatorPCVDepositcontractGaugeLenstoAngleGaugeLens. The Angle gauges use astaking_tokenvariable, but the original Curve gauges (and therefore, the Balancer gauges) use alp_tokenvariable. Conversely, aCurveGaugeLenscontract was added (reading thelp_tokenvariable, whereAngleGaugeLensreads thestaking_tokenvariable)BalancerPool2Lenscontract. TheBPTLenscontract reads the whole balance of tokens inside of a Balancer pool. TheBalancerPool2Lensreads a PCVDeposit who reports its balance in BPT, and return the balance of underlying tokens.B-80BAL-20WETH(~4M$) and vote-lock to veBAL