Implement Curve Pool Booster. #2327
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2327 +/- ##
==========================================
- Coverage 51.54% 50.80% -0.74%
==========================================
Files 91 92 +1
Lines 4414 4513 +99
Branches 1162 1195 +33
==========================================
+ Hits 2275 2293 +18
- Misses 2136 2217 +81
Partials 3 3 ☔ View full report in Codecov by Sentry. |
clement-ux
changed the title
clement-ux
requested review from
sparrowDom,
DanielVF,
naddison36 and
shahthepro
as code owners
| } | ||
|
|
||
| function sendETH(address receiver) external onlyOperator { | ||
| payable(receiver).transfer(address(this).balance); |
There was a problem hiding this comment.
Why is this necessary? to recover any accidentally sent tokens? If yes, can you change it to onlyGovernor? Also, we typically have a transferTokens method for ERC20 tokens as well
There was a problem hiding this comment.
to recover any accidentally sent tokens?
Not really. This contract will hold a bit of ETH, as we need to pay a bit when calling the CampaignRemoteManager (CCIP fees). So it is in the situation where the pool booster will not be used anymore (end of services) and the operator what to claim the remaining ETH.
And using a payable function is not the best (imo) because a surplus of ETH is sent back to this contract, not to the sender.
What do you think of keeping onlyOperator modifier then?
There was a problem hiding this comment.
IMO it is fine, as there will only be small amount of ETH on the contract whose purpose is to fuel the gas for transactions and that is not part of the user funds.
There was a problem hiding this comment.
Yes, exactly, only to fuel gas transactions, nothing more.
clement-ux
changed the title
Pool Boosting isn't designed to work on Arbitrum. I know it is weird, but let me explain.
So at the end, on Arbitrum this contract will only use the We could have develop two different contracts, to manage bribe on mainnet and L2 at the same time. But using create2 requires to have same bytecode for both to have cross-chain replication. For the futur we could use Create3 method. |
ok, that explains it. Thanks |
* fix: adjust deployName. * fix: deploy 119 and 120.
| // If there is a fee, transfer it to the feeCollector | ||
| if (feeAmount > 0) { | ||
| // Transfer the fee to the feeCollector | ||
| IERC20(rewardToken).transfer(feeCollector, feeAmount); |
There was a problem hiding this comment.
Will we ever bribe with USDT? If so, we'll need to use safeTransfer.
If not, the Slither error can be fixed by adding this before the transfer
// slither-disable-next-line unchecked-transfer unused-return
There was a problem hiding this comment.
Fixed in this commit: 6997f35.
Curve Pool Booster
This contract aims to take all funds available in the contract and create/manage bribes on VotemarketV2.
As VotemarketV2 is only available in L2s, this contract connects with VM using the CampaignRemoteManager.
The connection with VM on L2s uses CCIP, so we need to add a bit of ETH in every transaction we do. The remaining gas is sent back to the contract. That's why I suggest ETH remain in the contract instead of sending transactions from the relayer with ethers.
The relayer will be able to perform multiple actions:
Tests are pretty basic and don't test the whole process due to the complexity of testing cross-chain messaging. However, as this contract will hold a small amount of funds, I think it is ok to test it in prod.
This contract should be deployed on BOTH mainnet and targetedChainId to completely manage the bribe.
See this #2327 (comment).
Code Change Checklist
To be completed before internal review begins:
Internal review: