April 24, 2023: I Got You, 0xbabe 🔜™️
The protracted $crvUSD deployment process, explained
The long wait for the start of $crvUSD deployment is over!
Welcome to the long wait for the conclusion of $crvUSD deployment!!
Over the weekend an unfairly handsome chain checker cited activity on the Curve deployer address, 0xbabe.
What some users may not have suspected is that the process of deployment would turn out to be a lengthy process in and of itself. Perhaps not realizing this, some itchy traders just smashed the buy button.
So, not financial advice, but contract deployment is not really the sort of event one should try to frontrun.
Even if the deployment played out in a single block, we might still expect a few governance delays. In this manner bureaucratic red tape can have the effect of making the launch process more equitable.
In a public Curve Telegram channel, Curve founder Michael had fun teasing the events in realtime.
After this comment, the deployment process would pause for a 24 hour power lunch. Meanwhile the rest of us would sample the tasty breadcrumbs he’d continue to drop.
What exactly are we looking at? On the first day of deployment four contracts were deployed, two of which verified the other two of which could not have the source code verified.
Etherscan compatibility is a known issue for cutting edge Vyper devs, who might see everything working fine on a local mainnet fork, and then panic they just spent their hard-earned ETH deploying a borked contract to mainnet. In this case, the $crvUSD related deployments were pricey, costing upwards of 1 ETH already spent, necessitating a refill!
The deployment issue also hit The Llamas NFT project, the most successful Vyper NFT project to date by a wide margin.
The issue is due to the fact Etherscan defaults to an different EVM version to compile Vyper, which can cause slight issues with verification. If you find yourself facing these issues, you may need to adjust the EVM version being used deployment (ie Berlin, Istanbul, Paris…). An IDENTITY_PRECOMPILE issue may also be tangled into the mess.
If you find yourself facing such issues just pop into the friendly Vyper Discord and the community will get you over the finish line.
The contracts that did successfully verify appear to be implementation contracts, with the source code based on the StableSwap.vy file in the codebase.
Curve makes frequent use of implementation, particularly with its factories. Essentially this involves deploying skeletal contract gets deployed to the blockchain without setting initialization parameters. Separate contracts can use these as a template to launch new contracts with initialization parameters via the create_from_blueprint function.
The nice thing about this process is that if source code for the implementation contract has already been verified by Etherscan, nothing else changes but the initialization parameters, so source code verification is easy. The process can occasionally be a headache for fearless Vyper devs, as we noted above.
For this case, there are two different StableSwap implementations now parked live on mainnet. One supports rebasing, the other more vanilla.
So, maybe you don’t care about all that. Wen $crvUSD?
A few weeks ago when we spotted commits in the Github repository related to deployment scripts, it was a pretty good hint that deployment is in fact a delicate process. Here’s the current mental illness masquerading as an ape-deploy script currently checked into the repo.
Note the actual deployment may follow a different path — it can be common for developers to make local tweaks to such scripts last minute. ie, if the deployment got disrupted and the script needs to be restarted.
Indeed, just this morning we saw the Github repository updated with a new test contract.
This simple script appears to match the pair of bare-boned contracts launched early this morning. This particular contract hasn’t been changed much from its use throughout testing, except to add some more documentation for anybody who stumbles across the contract on mainnet. So presumably some source verification to calm any future historians who find it in the wild.
In case you’re confused about how it can be so tricky to match raw bytecode, it’s often not as easy as testing a strict 1:1 match, since the initialization parameters can be different. Especially if these parameters are on-chain addresses, which may be quite different between testing and prod.
The tell is the very end of the bytecode, where initialization parameters are appended. These usually end up slightly different. Note here the deployment in dev deployment mostly matches, except the tail of the contract on live is the 0xbabe deployer address.
This contract was used constantly throughout the test suite. When you’re testing you can’t wait for the price of $ETH to dump before you test how your stablecoin performs — you might need to sit around for an hour. You need a quicker shortcut to death spiral the collateral price toward ZERO and see how the stablecoin fares under rough circumstances.
This contract is a useful one to bookmark if you’re, say, going through the Curve Vyper tutorial. It’s a simple contract where the admin can change the price of the collateral at will — sort of like Mochi.
At any rate, looks like we’re due for a little on-chain testing in prod before it all goes live. SOON™️, but maybe not SOON™️ enough for the impatient people who have over-invested by a lot.
Of course, we always like to drop the juicy bit at the end of the article, to keep it from the illiterates who stop reading.
The most interesting leak over the past few days is nothing to do with the deployment process, but this innocuous-looking commit.
But wat does “use $sfrxETH collateral” mean though?!? We’ll just leave you in suspense on that one…
