Ready to talk about the Bitcoin ETF? Too bad! We’re here to talk about optimization of Curve TriCrypto parameters on the Base chain.
There’s been a few recent parameter changes being tested, and while results are still premature it looks interesting. Let’s dive in…
Background
Despite securing hundreds of millions of TVL and processing billions worth of volume, Curve’s TriCrypto pools are relatively poorly understood.
Curve v1 pools took a long time to penetrate the public consciousness, but eventually most intelligent people got a hang of the “A” parameter. But then Curve v2 pools went and introduced a half dozen new parameters. We’d estimate maybe a few dozen humans on the planet have yet bothered digging into them?
In most cases, users who launch their own v2 pools through the Curve UI just accept the default settings. It makes sense, how else could they make an informed decision on how to set these parameters?
If you get it wrong, no big deal! Just leave it in the capable hands of the small handful of geniuses who do understand these parameters. They can observe the pool behavior and run advanced models to study the pool behavior, then suggest the DAO adopt better parameters after the fact.
This is essentially how it works in practice. Launch pools, then study and optimize them towards perfection. TriCrypto contracts worked in theory, but like so many innovations from Curve, there was really no way to actually understand how it would function in practice except to deploy it to the wild.
To gain understanding of precisely how these pools operate, the team would end up deploying and observing the behavior of these pools in the wild to see how the pool actually performs. The actual behavior of how users interact with the pools can be very sensitive to very slight tweaks in parameters.
The expected results of changes can be modeled, but of course models are never a substitute for reality. So it ends up as a lot of back and forth — see how changes perform, use real world observational data to inform better models, use these to suggest new adjustments, ad infinitum.
The status quo is that most DAO voters advance the cause of science by basically rubber stamping recommended votes for parameter changes. Voters may have little idea what experiment is being run, but they vote confidently based on very pretty pictures that get generated as a result.
When Curve mostly had a single TriCrypto pool on mainnet, this meant Curve could make, at most, maybe a dozen tweaks per year. Set a few new parameters, run it for a couple of weeks, then repeat the cycle.
It’s enough for science to march forward slowly, but it’s very little observational data compared with the surface of potential parameters you’re exploring. TriCrypto pools are complex organisms, and we only faintly understand how they perform because we’ve only had opportunity to collect a handful of data points.
Fortunately, though, we are getting much more experimental data coming in. The brakes are off TriCrypto-NG! The team is deploying more v2 pools to several other chains. Finally, we can run more tests in parallel.
If certain tweaks work well, the adjustments can be copied to other chains.
Based
So while you’re still recovering from your New Years celebrations, you may have missed some changes playing out on Base chain. In this case, the attempt is to optimize the “fee” structure on the pool.
Many don’t realize that Curve v2 pools are in fact good drivers of revenue for veCRV holders. TriCrypto ranks second to the stETH pool in terms of revenues, despite being a fairly small pool.
Curve v2 pools in particular have a variety of tunable parameters that in theory could be used to further maximize such revenues. Of these parameters, the fee structure is the lowest hanging fruit.
Curve v2 pools charge a different fee depending on whether the pool is “balanced” or “imbalanced.”
Imagine the SEC gets hacked and posts false info that causes rapid shifts in the price of Bitcoin (we know this is of course implausible in an era of 2FA, but bear with our thought experiment anyway).
When prices shift rapidly, everybody wants to trade the pool. It’s imbalanced, and there’s free money on the table for whoever trades it back into balance. Thus, in times of high volatility, you can charge a higher fee (the parameter “fee out
”). You can think of it as a tax on arbitrageurs. Take a piece of their pie, but they may think it immaterial, because they’re still eating a free lunch.
When volatility calms down and everything returns to a state of balance, the pool should rebound to “Fee Mid
” — the lower fee in stable eras. In this state, there’s no arb trades to be made. Instead, you can try to drive higher volume of ordinary transactions through your pool, because you know that you’ve concentrated liquidity as well, or at least better than competitors (a subject for a future article). So you may well process larger trades with less slippage while markets are in this state of relative calm.
The fee structure has lately been the focus of some changes on Base chain.
About a month ago, there were some minor tweaks that didn’t have much effect. Then came a swath of parameter changes, including a lower mid_fee
and a markedly higher fee_gamma
:
Before:
mid_fee: 1499999
out_fee: 140000000
fee_gamma: 7200000000000
A: 2457797
gamma: 40989818020681
After:
mid_fee: 1000000
out_fee: 140000000
fee_gamma: 400000000000000
A: 540000
gamma: 80500000000000
The changes have led to visible effects on the fee structure. In the chart below, the faint blue line represents the change in the Fee Gamma, when the changes went into place.
The red lie representing the actual fee charged by the pool shows off the difference. Before, the pool was mostly clustered around the higher fee, only briefly dipping into low fees. Now, the pool sits very heavily in the low fee range, but pops upwards on occasion, presumably time of greater volatility.
You can see an [imperfect] measure of how this affects pool profitability by looking at the virtual_price changes.
It’s a bit tough to tease out specific takeaways from this graph, but you’d probably agree that at minimum there’s been little change in the overall rate of change in virtual price both before and after the changes. In the new paradigm there’s a bit more “burstiness” that appears to happen in periods of higher fees, but it may be our imagination.
Still, based on this limited window, we would feel content claiming that it appears as if fees have been mostly lowered with little negative effect on virtual price.
Unfortunately, a limitation in the way we scraped the data makes it difficult to try to also tease out actual trading volume data, but we’ll overlay the two charts here — you might use whether “fees” are high or low as a proxy to get a sense of whether the pool is experiencing high or low volatility.
Conclusion
The optimization remains ongoing, but keep an eye on Base TriCrypto activity, as it may inform parameter changes on other chains. These are the sort of slow tweaks that nudge Curve pools towards perfection over a long enough timeline.
We mentioned liquidity density, to be the subject of a future article. Conversations with the big brain Curve Founder suggest there’s an interesting interplay here as well. As liquidity becomes denser, the fee gets lower, converging towards the optimal xyk fee. Yet the fee and density adjust in volatile times to allow for smooth rebalancing. If you want more elaboration on this, you’ll have to subscribe and hope I get around to writing about it someday…
We’ve already had a few calls to see the source code for this. It’s really nothing special, but we’ve posted it to a companion Github repo all the same.
It relies on Brownie, which despite being on life support works pretty seamlessly when you need to work on sidechains. All the script does is scrape a bunch of pool parameters over a window of blocks, and then there’s a separate Jupyter Notebook to import the data and graph it.
So, enjoy, and drop thoughts in the comments!