ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAUAVAWAXAYAZBABB
1
ATTACKASSESSMENT
2
NameDescriptionWhenTypeImpactLikelihoodAssessmentMitigations implemented
3
MEV delta hedge swapAn IG trader could, before trading, calculate the protocol delta and frontrun / sandwitch the delta hedgeDelta HedgeMEVLOWMIDThe impact is limited by:
1) implemented mitigations.
2) the impossibility to execute it recursively becase the delta is based on the Oracle Price (thus the attacker would need to manipulate / move the Oracle Price to have the delta of the protocol to change after having sandwitched a transaction - more info in "Delta hedge manipulation leading to fee drain")		Max slippage on swap

Price IG using worst(Oracle ; Swap price)

Only launch vaults on liquid tokens
4
MEV IG buyers / sellersUser may MEV another user buying or selling IGDelta HedgeMEVMIDLOWOnly possible on MEV-exposed chainsMax slippage on IG premium
5
MEV roll-epochBefore roll epoch happens, a bad actor can compute the swap amount and frontrun / sandwitch the swapRoll EpochMEVHIGHMIDOnly possible on MEV-exposed chains and in any case mitigated by mitigationsRoll-epoch is randomized over a few min time period by the epoch-roller

Max slippage on swap
6
Delta hedge manipulation leading to fee drain In certain scenarios, the delta of the protocol may change much from a trade to another due to price movements.
This happens in particular for:
1) highly volatile tokens
2) tokens with limited liquidity, whose price is much impacted by Smilee swaps themselves
In such scenario, a bad actor can buy and sell tiny position of IG OTM to cause swaps to rebalance delta.
This:
1) impacts the vault due to DEX slippage and fees
2) can be used by the bad actor to profit from MEV or JITL on the underlying DEX pool		Delta HedgeManipulationHIGHLOWOnly possible if the delta hedge swap moves both the DEX and the Oracle Price which is unlikely for liquid enough tokensMin fee on each swap

Only launch vaults on liquid tokens
7
DEX & Price Oracle manipulationIG buyers / sellers or Smilee LPs may have an incentive to manipulate DEX and Oracle prices to:
1) change IG premium computation
2) change expiry price and share price at roll-epoch
3) make certain transactions or roll-epoch revert		BothManipulationHIGHLOWOnly possible for illiquid tokensOnly launch vaults on liquid tokens
8
Divergence between Oracle Price and DEX prices at roll-epochDivergence between Oracle Price and DEX prices at roll-epoch may lead to use an Expiry Price better (or, potentially worst) than the swap price at which the vault rebalance. This may generate some small impact on the payoff of the vaultRoll EpochIntegrationLOWLOWDifficult to forsee how this could happen always in a direction that adds up more and more over timeMax slippage on swap
9
Divergence between token prices used to compute IG premium during epoch and prices used to determine roll-epoch expiry priceDivergence between token prices used to compute IG premium during epoch and prices used to determine roll-epoch expiry price may allow a bad actor to buy IG just before roll-epoch to try to immediately profit from it at expiryBothIntegrationMIDNOT POSSIBLEThe IG pricing during epoch is based on "worst(Oracle ; Swap price)", while Expiry Price is based on Oracle. Therefore the exploiter will get at best for him the same price and at worst for him a worse onePrice IG using worst(Oracle ; Swap price)
10
Price Oracle frontrun / stale feedA bad actor may try to frontrun an oracle price updateBothIntegrationLOWNOT POSSIBLEDuring epoch the IG pricing is based on "worst(Oracle ; Swap price)", therefore the exploiter will get at best the same price and at worst a worse one.
At roll-epoch users cannot easily frontrun roll-epoch because this is executed randomly over a few min timeframe		Price IG using worst(Oracle ; Swap price)

Roll-epoch is randomized over a few min time period by the epoch-roller
11
Volatility Oracle issuesSmilee uses on-chain volatility data generated by Smilee AMM itself for all tokens but ETH and BTC.
For ETH and BTC Smilee uses Deribit data.
This may lead to integration issues, such as: wrong data feed, stale data feed, no data feed, which may lead to IG mispricing or roll-epoch to revert		Roll EpochIntegrationMIDMIDIn case of revert the issue can be overcome fixing the data, in case of mispracing (more rare) the issue can be managed pausing the vault.
In addition, Smilee can be moved to use only on-chain volatility data fully solving the issue		RBAC to pheriphery contracts to overcome integration issues

On-chain volatility data
12
Volatility model does not reflect underlying asset dynamics correctlyBothFinancial / mathLOWMIDBlack&Scholes model relies on assumption that may not be verified in crypto markets. However, this has very little impact on Smilee's pricing model, thanks to the volatility bonding curve: for example if people think crypto returns have heavy tails, they will buy more IG leading to a higher utilization rate and therefore a higher IV that needs to be plugged in the B&S model to get the IG market price.Convex Bonding curve
13
Volatility does not depend on skewUsually in tradfi the OTM put has a higher IV than the OTM call, resulting in a higher cost. In smilee, Bull IG and Bear IG have the same IV even if they could be replicated with a portfolio of different OTM calls/putsBothFinancial / mathLOWMIDIn an ideal world, volatility should move along the skew. In practice, the difference is usually tiny and skews are not very steep in crypto. As Impermanent Gain is only minted on 1 strike per week (epoch), it was not worth adding an extra skew parameter to marginally improve pricing
14
Smilee implied volatility may not reflect correct Market VolatilityBothFinancial / mathMIDLOWBonding curve is defined in order to adjust dynamically volatility based on utilisation rate and time and so shall limit any discrepancies thanks to arbitrageurs' activity. If volatility is set too low, buyers will come in and raise U, if volatility is set too high, the time decay will make it fall relatively quicklyConvex Bonding curve with time decay parameter
15
Smilee vault may underperform DEX LPs due to DEX slippage and fees when swappingSmilee delta hedging math ensures the protocol delta is always realigned to that of the DEX LP. This ensures Smilee vaults never underperform DEX LPs with same range but this math does not take into account DEX fees and slippage, which may translate in underperformanceBothFinancial / mathMIDLOWWe tested the issues with specific financial simulations and backtest and identified that the mitigations more than cover the DEX fees and slippage for liquid tokens in a large majority of the scenariosPrice IG using worst(Oracle ; Swap price)

Min fee on each swap

Max slippage on swap

Bid ask spread on the bonding curve
16
Delta is computed using the delta of the payoff of the IG, which is an approximation compared to using the delta in that specific point in timeThere is a range of prices in which real delta and payoff delta have different signDelta HedgeFinancial / mathLOWMIDThis happens when volatility and time to maturity are very high. It is not an issue since it doesn't cause scenarios where the vault underperforms the LP at expiry in absence of fees and slippage
17
Liquidity on the DEX pool decrease significantly Big price movements or change in liquidity distribution may cause a DEX pool to end up with not enough liquidity in range to allow Smilee to swap at a reasonable price causing delta hedge or roll-epoch to revert due to max slippageBothFinancial / mathLOWLOWLimited impact because the max slippage on swap protects the vault from excessive slippage on the swap.
If liquidity does not come back to the DEX, the issue is probably more related to the DEX / token itself.
A new DEX venue can be found in case or the vault can be paused and killed		Max slippage on swap

RBAC to pheriphery contracts to overcome integration issues
18
Smilee vault ranges (Ka and Kb) computation may lead to numerical issues when implied volatility is very highEach Smilee vault replicates a DEX LP with ranges (Ka and Kb) computed from implied volatility data.For high value this can translate in issue with computing Ka, which may translate in roll-epoch to revertRoll EpochFinancial / mathMIDLOWIssue can be managed by adjusting the volatility value in the oracleRBAC to pheriphery contracts to overcome integration issues
19
Utilisation rate may stay low for a while after a volatility spikeBonding curve adjusts volatility based on utilisation rate and time. If the initial volatility value is set too high (for example due to a volatility spike in the revious epoch), smilee's time decay parameter may take some time to lower volatility back to market levels BothFinancial / mathLOWMIDWe expect this to happen after a volatility spike, but the only effect will be a temporary lower utilization rate
20
Time-vega weighted average utilisation rate could not be a good proxy for the real average utilisation The formula chosen gives more weight to the utilization rate in the first part of the epoch. This limits certain potential attacks close to roll-epoch to try to modify volatility for the following epoch.
However, it may not fully reflect real market dynamics.		BothFinancial / mathLOWLOWThe rationale is that trades done in the first part of the epoch (when vega is high) give more indications on what the right level of volatility is, so they should be weighted more. The issue is that volatility may be underestimated if it rose during the previous epoch or overestimated if it fell. In any case the only effect would be a temporary higher/lower utilization rate
21
Smilee vault token balances do not match an exact equal weight after roll-epochThe roll-epoch rebalance targets an EW portfolio but due to DEX slippage and fee actualy results in a slightly different portfolioRoll EpochFinancial / mathLOWHIGHThe issue is limited by the max slippage and in any case the delta is then adjusted at the first IG tradeMax slippage on swap
22
Execution premium may be different from the one shown to the userPremium previewed to users are computed using Oracle Prices, but then the final Premium is computed using the worst between the oracle price and the dex swap price. This minimizes manipulation attacks but lead to a premium previewed slightly different from the final oneDelta HedgeFinancial / mathLOWMIDMax slippage on IG premium
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100