October 2, 2024: Splitter ⬅️➡️
October 2, 2024: Splitter ⬅️➡️
Deciphering the $st-crvUSD Fee Splitter contract
Another big news day! Specifically, the Curve news site showing off another great month of progress… make sure to subscribe!
Oh wow, things look great! Let’s check in on other news sites…
Yikes…
Y’all wonder why we follow the DeFi news beat instead? The world looks a lot cozier from the Curve perspective, in which the tech continually improves and the price continually declines.
Outside, we saw about half a billion in liquidations as markets cratered…
Most interesting was studying this particular liquidation…
Quite an elegant series of transactions here. Follow along as the user takes out a .1874 WBTC flashloan from Balancer to perform a liquidation about 10x the size.
If you need help decoding this series of squiggly lines, check out our prior article unpacking a similar loan using the crvUSD flashlender:
For now though, let’s review the Splitter…
Splitter
Once again, democracy is at stake! Vote early, vote often!
If approved, the Fee Splitter is going to be inserted into pipeline to reapportion some amount of $crvUSD fees towards $st-crvUSD, which will give stakers a pipeline of yield.
This diagram shows off where it sits in the flow:
We already covered the st-crvUSD repository here:
Today we dissect the Fee Splitter repository, for which the README explains the background of the project
One interesting paragraph tucked towards the end of this README explains that this repository had a storied history, via a prior iteration called “Autobribe.”
If you’re active in the Curve social channels, you perhaps stumbled across some loose, irresponsible talk about “autobribe,” which would have tried to deliver yield to $st-crvUSD via vote markets. It was built but scrapped because it was not practical to build in a neutral manner. The codebase still exists within this codebase for any builders who want to review.
In lieu of Autobribe, we have Fee Splitter.
The key components of this repository is two contracts, FeeSplitter.vy and ControllerMulticlaim.vy, along with a robust testing suite to show off how it works:
We’ll start with ControllerMulticlaim.vy, which serves as a helper module to claim fees from multiple controllers at once, because it’s the simpler of the two. The entire contract clocks in at a meme-worthy 69 lines
The contract supports up to 50K controllers, a benchmark that gives some wiggle room for likely several years before it requires an upgrade. This cap is required because, unlike Solidity, Vyper requires Dynamic Arrays to be bounded to avoid potential overflow issues.
The contract has a pair of state modifying functions. The meat of the contract is the claim_controller_fees function, which simply loops through the list of controllers and calls the collect_fees function on each.
Otherwise there’s an update_controllers function to refresh the list of controllers from the factory contract.
With this context, we can read through the actual FeeSplitter.vy contract
In the contract setup, the contract imports the aforementioned ControllerMulticlaim module along with Snekmate’s authorization libraries (observe the contract utilizes Vyper 0.4 which modularizes Vyper).
The meat of this contract is the dispatch_fees function
The function starts by claiming fees from the aforementioned multiclaim contract. Then the contract loops directly over the list of receivers. At each step it calculates the weights and transfers the crvUSD according to the results.
More specifically, the logic first calls the internal _is_dynamic function to safely checks if the fee receiver supports the dynamic_weight interface. If so, then the function should be able to safely call the weight function on the contract.
The full logic of these checks:
You can see these functions include a lot of redundancy checks in case something strange happens, as we see so often happens in the “code is law” paradigm.
The good news about the Fee Splitter contract is that the stakes are relatively low, in that the contract does not handle user funds or deposits. If something unforeseen and screwy happened, perhaps st-crvUSD might lose yield for a week, but **knock on wood** it would not be possible to drain user funds.
This is necessarily a high level overview, but you can get a lot more background into these contracts via last week’s Llama Party with Alberto Centonze, developer for both the Fee Splitter and st-crvUSD.
