February 3, 2023: Wen $crvUSD? ⏲️⏳
CAN CURVE DEVS DO SOMETHING?
The most up-only market?
The number of times the Curve support crew receive requests for info on when $crvUSD will be released.
Some quick alfa… if you want to get a sense of the status of crvUSD, you can simply keep an eye on the public Github repo.
Even if you don’t know the first thing about coding, it still has some nice pretty pictures you can use to confirm that yes, in fact, devs have been doing something.
And by devs, we mostly mean Curve’s chad founder Mich, who has been keeping his github streak alive lately.
To dive into what exactly has been happening lately, we can run a quick check on which files have been modified in the past month.
Basically, $crvUSD could have launched last month, but it would have looked very different than it looks today.
For starters, a lot of extra tests have been added. This is pretty important because $crvUSD is sort of uncharted territory in a lot of respects. We know auditors miss stuff. More robust tests means we’d be safer when we launched.
Most importantly, these tests are still uncovering bugs. When you browse through the commit history, if you notice something titled “bugfix” — it’s potentially a big deal.
Had $crvUSD been deployed with bugs, if you didn’t lose all your money, you might need to, at minimum, spend gas to migrate all your funds to a new contract. Probably better to wait until launch in this instance!
We also probably want the AMM exchange functions to be free of bugs as well…
More important than changes to unit testing is to note the changes to the actual smart contract.
Smart contracts are immutable, but Curve smart contracts are more immutable than most. That is — some protocols cheat a bit by using upgradable proxy contracts. A proxy contract allows one address to inherit its logic from any other address, which can be changed at any time.
This means you can ape your money into a proxy contact under one set of terms, then devs can rug you by changing the underlying logic after they have access to your money.
Curve does not do this. This is great because it means nobody can rug you. This is also bad because it means devs cannot fix bugs or add new functionality after the fact. Devs need to spend a little extra time thinking through edge cases and making sure to anticipate every possible feature before launching.
It’s almost impossible to get everything right, but more time spent playing with the contract before it launches (by writing new tests) can expose where new functionality would be useful.
As it stands, the smart contract suite today is more featureful and user-friendly than it would have been if it launched a month ago. A few examples:
One common issue with earlier Curve contracts is the lack of a get_dx() function — get_dy() tells you how many tokens you would get out for a certain input, but sometimes people need to know how many tokens to supply to ensure a specific output.
The new logic provides a single get_dxdy() function with a helpful toggle to determine whether it’s used as get_dx() or get_dy()
This change is substantiated by tweaks to the curve-stablecoin-js repository.
This middleware repo has far less activity, suggesting it is at a more mature stage and that the bulk of the functionality is the same as far as the frontend is concerned. The only changes in the past five months are modifications to support the newly enriched get_dxdy() function.
Another helpful new feature added this past month is the capability to withdraw a fractional amount of liquidity for a user.
So too with liquidations…
Another nice benefit we see from the extra time spent on the contract is continuous gas golfing to make it more efficient.
Gas optimization is important because Curve contracts are complex. These complexities become more manageable because Curve is written in Vyper, which has a more efficient compiler than other smart contract languages. Even then, it’s possible to save gas further with careful design choice.
We see this directly with Curve’s v2 pools. Where Uniswap v3 pushes the onus of rebalancing liquidity to LPs, who must alter their positions as prices change, Curve v2 pools do it automatically. Somebody pays the gas in both cases — Uni v3 by LPs manually when they readjust their positions, whle Curve v2 incorporates the logic internally, which results in higher contract execution costs.
In fact, the great Fiddy is presently rewriting TriCrypto from scratch to provide a gas optimized version, which will likely be the subject of a future article.
For every month $crvUSD is pushed back, the contract tends towards more gas savings getting discovered and included in the final design. So feel good that every delay will save you a little ETH in the long run (though burning more ETH might be good for supply reducdtion…)
Finally… it seems like every week or so the Curve money waterfall checks the couch cushions and finds a few million dollars worth of tokens that got missed.
A new function got added to improve the capability of the admins to collect these fees if they grow to excess. Good to have a few extra provisions to make some surplus money!
