Summary:
Vote to change parameters of the TricryptoUSDT Pool at 0xf5f5B97624542D72A9E06f04804Bf81baA15e2B4. Newly run simulations show big potential to improve the pool for both the Curve DAO + LP.
Abstract:
TricryptoUSDT has 7 parameters that can be tweaked:
A: 540,000 ► 1,512,000 (2.8x)
gamma: 80,500,000,000,000 ► 507,150,000,000,000 (6.3x)
mid_fee: 1,000,000 ► 22,000,000 (22x)
out_fee: 140,000,000 ► 296,800,000 (2.12x)
fee_gamma: 400,000,000,000,000 ► 72,000,000,000,000 (0.18x)
allowed_extra_profit:100,000,000 ► 100,000,000 (1x)
adjustment_step: 100,000,000,000 ► 100,000,000,000 (1x)
TricryptoUSDT is a Cryptoswap pool. The key metric that influences its performance are price movements of such crypto. A simulator was build to cover the chaotic 2 last years of Bitcoin+Ethereum price movements. The pool was then practically forked at its state 2 years ago, with a combined TVL of $39.77M. Next, a speed-optimised arbitrage agent was set out to re-run the last 2 years with the pools’ actual parameter, establishing the baseline to compete against.
Entering the 7D search-space, some boundaries were set for parameter-sets that should or should not get considered. NOT considered should be sets that:
A: Decrease admin_fee$
B: Decrease LP_revenue$
C: Halt pool activity at one point in time (keep pool active and alive)
D: Are a sudden performance-spike compared to neighbour parameter-sets
I was used to 2D search-space (A, fee), where a 300^2 grid search means computing 90,000 parameter-sets. In 7D, this results in 218 quadrillion sets. To overcome this constraint, I increased the code-speed from handling 4 days worth of data per ms to 6 weeks worth of data per ms. Furthermore, all parameters are not equally sensitive. The grid can be adjusted to match each parameters sensitivity level.
Fineness of steps depended on parameter-sensitivity, 3D visualisation of the concept, but in sim in 7D. The 3D example reduces cell-count by 96% compared to evenly spaced grid.
Many fine-tuning iterations followed, with high precision scans in the neighbourhood of candidates for good parameter-sets. Finally, I settled on the parameter-set mentioned above, as it dealt well in all regards, decently increased LP revenue, decently increased Admin fees, ongoing active and alive pool throughout the 2 years none-stop, while having a similarly high performing neighbourhood of param-sets (high consistency).
admin_fees$ are doing roughly 50% better.
admin_fees$ are continuously outperforming.
The virtual_price is continuously outperforming the baseline.
Motivation:
The parameter update aims to increase the general performance of the TricryptoUSDT pool. An organic growth of TVL, increased DAO revenue, and an increased APR on the Pool can lead to a very healthy development of the landscape. Stay tuned for TricryptoUSDC.
Specification:
Calldata
Call via agent (0x40907540d8a6C65c637785e8f8B742ae6b0b9968):
├─ To: 0xf5f5B97624542D72A9E06f04804Bf81baA15e2B4
├─ Function: ramp_A_gamma
└─ Inputs: [('uint256', 'future_A', '1512000'), ('uint256', 'future_gamma', '507150000000000'), ('uint256', 'future_time', '1780300631')]
Call via agent (0x40907540d8a6C65c637785e8f8B742ae6b0b9968):
├─ To: 0xf5f5B97624542D72A9E06f04804Bf81baA15e2B4
├─ Function: commit_new_parameters
└─ Inputs: [('uint256', '_new_mid_fee', '22000000'), ('uint256', '_new_out_fee', '296800000'), ('uint256', '_new_fee_gamma', '72000000000000'), ('uint256', '_new_allowed_extra_profit', '100000000'), ('uint256', '_new_adjustment_step', '100000000000'), ('uint256', '_new_ma_time', '601')]