# Potential hyperdrive bug classes

I've been trying to take apart the hyperdrive proposal and have identified a few spots which may be bugs. If all are valid all of: LP join, exit, bond redemption, short selling and normal selling appear to cause problematic invariant interactions.

## Time bomb attacks

The hyperdrive curve system uses different curve invariants at different bond maturities but allows them all to be traded at the same time. The curve does not allow buys at any time or short sells at any time but does allow sells of pre-existing bond buys and short closes at any time under the assumption that if the market was moved by either of these their impact would be arbed out. However this is not strictly true. A user who holds multiple durrations with enough distance between maturities can preform a curve style manipulation on the prices as if the upgrade were happening at any time. https://medium.com/@peter_4205/curve-vulnerability-report-a1d7630140ec

### Time bomb via shorting

The core of this attack is to long an short short with very high notional at the same time [arbing yourself], but then to wait to nearly the endpoint of the bond/bond short then close at the same time as you buy at 6 months.

This example is a worst case, assuming better cases does impact the profitability of this.

Example:

* Assume a 1 million dollar LP pool with a 5% fixed apr, timestrech = 0.995 and that the bond period is one year. Assume there are no fees on the transactions. x = 1000000 and y = 950000 [5.02...% apr]

* A user opens a 10 million dollar notional short and also buys at the same time for 10 million dollars. Because of the curve symmetry the only cost is fees so here zero.
* Short is selling 10,000,000 bonds we calculate a short to sell 915773 x output via 
* Since there are no fees and amm trades are perfectly symmetrical we also pay 915773 and receive 10,000,000 bonds. Net reserves are still (1000000, 950000)
* The attacker waits 1 year their short and long are balanced so they will get the market apr on their 10 million, we assume no other trades happen. We wait till the time to redemptions is 0.05.
* We now sell 999000 thousand of bonds from out 10,000,000 supply.
* We get 992450 tokens and the reserves are (7550, 1949000)
* Now use 8,000 to purchase bonds at the 1 year mark and get 986212 bonds out [note trading more would make the bonds unbacked and possibly lock the system]
* 
* You can close your positions of short and long despite the low size of the AMM by trading back and forth, this will reset the AMM to a position where you can also remove the aproximently 1 million bonds you got for free.

This example is extreme because it lacks trading fees and the duration and lack of timestrech are very problematic, however this curvature attack will exist at higher timestreach even if the fees eat into profits. Note that at higher timestreach the multiplier factor of the last trade goes down but (1) this means it requires less capital to get the position necessary for the trade (2) we can push the manipulated reserve ratio even further to still get a very high payoff as the final t -> 0

### Time bomb via sales + LP

A first pass on the previous variant of this attack may conclude that the problem is shorting, but the core of the problem is the ability to trade on multiple curvatures at once. We can produce the same type of result by providing a very large amount of LP then buying bonds which equal the reserve size. We then exit the LP and will have executed primarily against the smaller LP. Our trade is a very large percent of notional at the end.

Note: because the definition of LP withdraw is in flux we assume an LP withdraw which can allow the withdrawer to withdraw up to the amount which preserves solvency. IE: If 1 million of loans have been written at 5% the unwithdrawable component is only the 5% interest which must be paid to those users [as the users add the other capital themselves].

Now the setup is:

* Assume that Alice has deposited 1 million of liquidity into the protocol. Then have Bob deposit 100 million [note while we use a very high multiple here for effect you don't need this much in practice]
* Bob purchases 1 million of bonds from the protocol at 6 months from now. He then withdraws liquidity, assuming all but the risk he took on from the bonds is withdrawn he withdraws all but (100/101)*(interest on 1 million for 6 months).
* The trade of 1 million at 101 million of liquidity has not moved the interest rate much, and when withdraws process they select for the y which will keep the interest rate the same. It should be roughly (2 million PT, (101/102) * 2 million bonds) as this is roughly the ratio before withdraw.
* Notice here how had Bob bought bonds directly the pool would be around (2 million, ≈10,000) that's the invariant problem.
* Bob waits 6 months and the interest paid to him largely makes up for his loss in the pool withdraw. At the instant before redeption Bob sells his 1 million bonds into the pool putting it at (1 mil, 3 mil) [ratio can be made much more dramatic here for more effect], and then buys 1 million bonds again at a much higher interest rate.

While this scenario has not been as exaggerated as the first (1) it could be by having larger trades (2) it still causes a loss to the LP by manipulating fixed interest rate purchases way above market rates.

## Forced redemption selling attack

The time bomb attack uses the curvature right before redemption plus an earlier transaction in order to trade on both curves simultaneously. They could be prevented by forbidding all but 6 month trades, however this is not enough to prevent curve unbalancing attacks. All redemptions are forced sales and are public in the mempool, moreover after redemption the curve reverts to x+y=k and has no slippage penalties. Sandwiching a redemption can allow the curve to be put in a state which allows LP fund theft for the same reason as the short timebomb.

* Assume Alice has 1 million of lp provided and Bob has purchased 200k of bonds. Bob waits for the bonds to mature and then a week after maturity redeems them, he makes this transaction in the public mempool of ethereum.
* Eve sees Bobs transaction and then short sells into the curve enough bonds in order to receive 1 million, at a reasonable interest rate assume that amount is 1.05mil. The pool is (200k, 1.805 mil)
* Now Bob's transaction processes and sells 200k of bonds because his bonds have already matured he gets a 1 to 1 rate. The pool is now either (0, 2 million) or very close to it.
* Eve now executes a buy bonds trade to the curve providing a very small amount of capital such as 8k and will get out nearly 1 million on bonds. She now has 1 million of short exposure and 1 million of bond exposure for the cost of 1.08 million, when withdraw time comes she will be able to withdraw 2 million and Alice only can withdraw 0.

This transaction sandwich is very safe and can be easily done via flashbots bundle. The larger the withdraw the smaller the capital commitment needed to empty the pool.

## LP Join and Exit invariant attack

The previous two attack classes make use of the changes in curvature between trades at various parts of the protocol however these time based curvature changes are not needed in order to execute attacks on the trading curve. Even if only buys and a short sale mechanism exist at the 6 month without changing curvature there's still an exploit class which works on the LP joins. The reason for this is the selection of y as a constant which preserves interest rates on join, this also preserves the curve ratio.

When a AMM like Curve has constant curvature between actions it also has that a buy sell pair are perfectly symmetric (minus fees) the cost of slippage to push up interest rates to 200% is equal to the gain of pushing interest rates back down to 5%. The core problem of the LP join function is that it's a single sided LP join without trades into the pool. If the pool is perturbed to 200% apr the join doesn't change that [unlike Curve where it both trades and joins]. We can exploit this via a sandwich around LP joins which forces them to provide liquidity to only the side of symmetrical trade which the attacker gains from.

NOTE - In this example we remove gas reserves and by removing them we note that to preserve APR we only have to preserve the x/y ratio.

* For the worst case consider a pool which is just being funded and has only 1000 deposited at a 5% fixed apr. Assume the pool is roughly (1000, 950). Now Bob commits a transaction to the mempool which will deposit 1 million usd into the pool. Alice sees this transaction and does the following in a flashbots bundle:
* Trade the pool to a highly extremal state via a short/sell, say she sell 2k bonds into the pool and the result is (10, 2950) with an APR near the max expressible by this timestrech. She pays about 50% of her deposit to get to very far on the curve. For a cost of around 1k.
* Bob's deposit now processes and will roughly preserve the ratio of the x and y reserves to preserve the pool apr. Meaning the pool will go to roughly (1 million, 295 million).
* Buy several million of bonds which will receive nearly the max APR. This APR is likely well in excess of the variable rate and so this trade generates a massive and possibly total loss for Bob.

This attack scenario is worsened by it being at the start of the pool but is possible that even with fees large LP joins into existing pools may have some extractable value from this type of manipulation. This would of course require large capital for existing pools unless intra bundle flash loans are created.

I think that you might be able to format an attack like this in some special circumstances on the exits as well, but my initial ideas are much more contrived [big LP withdrawing just in time to force larger trader fees via slippage]

## Conclusion

Unless I'm missing major details, which is possible given how fast the design moves, these appear to be serious problems causing loss to LPs which are hard to mitigate via transaction checks [such as min withdraw/trade amounts]. The common thread between each attack is that something is happening which causes insecure use of or change to the invariant of yieldspace. If the bugs are correct my thinking is that it may be easiest to reformulate to remove the centrality of the yieldspace invariant to remove the problems created by AMM curvature bugs when extended in this way.