They are users who have contributed to Curve and its community in various ways since its launch. We have opted to have a mix of Curve team members as well as community members to make sure the community is well represented and that its interests are put at the forefront of the grant decision making.
All six Curve team members are part of the council
The Multisig itself is controlled by all Curve team members and four community members (Julien T, Quentin Milne, Amadeo Brands and Adam S)
The council is planning so far to award two grants (all pending on approval of this proposal):
1. A Parameter Research
Our goal is to develop methods to optimize the A (“amplification coefficient”) parameter based
on time-evolving market dynamics (e.g., mean reversion, kurtosis) and pool statistics (e.g.,
liquidity utilization, asset balance). We will develop a suite of simulation, testing, and statistical
tools to identify the best predictors of optimal A values, and create an intuitive stats dashboard
to facilitate informed DAO voting on A parameters. We will then use these tools to identify,
model, and/or optimize future pools involving assets with various levels of volatility and
correlation (e.g., FOREX, unpegged cryptocurrencies, tokenized assets).
backd is a decentralized and non-custodial protocol, which protects owners of overcollateralized
loans on borrowing and lending protocols against becoming liquidable. The protocol
incentivizes deposits, which are intended to be used to top up positions endangered of
becoming liquidable on different protocols. However, when these deposits are not required they
are employed to generate additional income.
backd unused liquidity will be provided to Curve and they have committed to lock no less than 50% of CRV received upon whitelisting of the protocol
After receiving feedback, we have decided to request a higher amount to match grant sizes given by other protocols (Uniswap for example has a budget of $250k per month). We are therefore proposing to make the budget $150k per month for a year. Any unused funds will go towards next year budget.
This represents less than 2% of the budget and is line with commitments of other large protocols like Uniswap, Balancer, Yearn or AAVE.
The folks behind the first grant (A Parameter Research) were nice enough to share their proposal. It would be good for the community to have access to the second proposal to make an informed decision on the grants (assuming they can be discussed publicly).
Someone please correct me if I am wrong here, but the premise of the A research seems incorrect.
One of Curve’s primary advantages over other AMMs is it’s StableSwap invariant, which allows for flexible tuning of bonding curves in accordance with expected volatility.
This is not Curve’s advantage and volatility is not what A is tuning for. Given a non-zero A, Curve will actually perform worse vs. other AMMs for volatile assets.
As stated in the whitepaper,
The StableSwap invariant has an “amplification coefficient” parameter: the
lower it is, the closer the invariant is to the constant product. When calculating
slippage, we use a practical value of A = 100. This is somewhat comparable to
using Uniswap with 100x leverage.
The amplification coefficient is currently used to determine the wideness of the flat portion of the curve.
I don’t see how simply manipulating A can help you
“optimize future pools involving assets with various levels of volatility and correlation”.
To do the above, you will very likely need to create an entirely new bonding curve.
And this team seems to have no working experience with the EVM. You can do all sorts of statistical analysis to create new curves/manipulate the amplification coefficient. But how feasible will these new equations be for Ethereum implementation? The current gas cost to compute the StableSwap invariant D is already very high. If more variables need to be approximated (i.e. computing square root), the cost of invoking functions will increase, and usage will decrease.
The consensus within the grants council is that the Curve community will benefit from this research and the data analytics that will allow us to better understand the impact of the Curve invariant, and how to optimize it. We think this is a good team that is qualified to do this research.
I would guess that right now, probably Michael is the only person in the world who really has a good understanding of how to optimize A. Every time we make adjustments to A, it’s really just a shot in the dark, let’s be honest. It would be in all of our interests if these adjustments were backed by data and a clear understanding of where A should be set and the impacts an adjustment will have.
IMO, this research can potentially lay the groundwork for further improving AMMs, including exploring new and improved algorithms, automating A calibration, and perhaps eventually supporting non-stable assets.
Author of the A parameter research proposal here. Thanks for your feedback. You raise important points, but I hope I can assuage your concerns.
First, to clarify, we’re talking about initially optimizing A for “like-for-like” pools (e.g., sETH-ETH), where we can generally expect mean reversion. You’re right that, as it stands, tuning A won’t help with pools that aren’t expected to mean revert (e.g., BTC-USD). However, even across the various “like-for-like” pools, we can expect different degrees of deviation from 1:1 trading regimes, and ideally we’d like to optimize A for the observed noise distribution and mean-reversion properties of various pairs/pools.
Regarding your second point, we were imagining auto-calibrating A pools as being a pretty distant future, possibly on L2. However, fortunately, we’ve already come up with a much simpler approach that has the same data storage (previous state) and computational requirements (Newton solver) as the current contracts.
Like the current Curve contracts, there is only 1 tunable parameter, but it can produce bonding curves that are either wider or narrower than constant-product. Essentially, when the parameter is positive, it is tuned for mean-reverting prices, and it replicates the current StableSwap invariant behavior. When the parameter is negative, it is tuned for non-mean reverting (trend-following) prices, and starts to penalize trades for their rate of debalancing when the pool is out of balance. Obviously experimental at this point, but we think it can form a sound basis for further development.
I hope this clears some things up. Please let me know if you have any additional questions/comments.
Okay. I am all for more data-driven approaches to help the DAO tune the amplification coefficient for stable swap pools. This is a good idea.
But the material in your proposal on how research here will help identify or model AMM curves for unpegged assets was misleading and made the research goals unclear. Any solution for this is most likely an entirely different protocol.
I’m skeptical of this 1 parameter AMM curve you described. Would probably be better if you can provide a few references that support your hypothesis.
Yes, my apologies – I was less clear than I’d hoped, so I appreciate your feedback.
Without giving too much away, the bonding curve approach I alluded to is based on limiting trades that are inconsistent with mean-reversion to balanced holdings. The 1 free parameter dictates how much users want to enforce mean-reversion of the balance vs. letting the market dictate the balance. As the parameter gets more negative, it more strongly enforces that trades must result in mean-reverting the balances (i.e., it only tolerates trades that promote more balance than Brownian motion). As the parameter gets more positive, the pool tolerates a greater degree of deviation in balance.
The approach is inspired by the theory of fractional Brownian motion, first introduced in Mandelbrot & van Ness (1968), “Fractional Brownian motions, fractional noises and applications”. Mandelbrot explicates the theory more coloquially in his book “The Misbehavior of Markets: A Fractal View of Financial Turbulence”. Good discussions of fractional Brownian noise, multi-fractal noise, and related topics in relation to cryptocurrencies can be found here: https://arxiv.org/pdf/1804.05916.pdf and https://arxiv.org/pdf/2010.15403.pdf