You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MEV suck, Sandwhiches sucks, use OpenMEVs.~\cite{openmev}.
66
+
MEV suck, Sandwiches sucks, use OpenMEVs.~\cite{openmev}.
59
67
\end{abstract}
60
68
69
+
\subsection{Design}
70
+
The Original design for the router was to use flashloans only to arbitrage then immediately distribute profits to hard coded addresses. Apart from the issue of hard coded addresses, this setup was inefficient because of small amounts frequently being split and transferring to multiple addresses being expensive. This opened the possibility of leaving profits to accumulate on the router. Furthermore it provides a way to arbitrage without a flashloan, saving gas and the loan fee (i.e. more profit, less gas). Additionally, the harvesting profits means ownership control of the router. A more robust 2 step process was chosen to control and transfer router ownership and harvest control. Ideal setup would be multisig consensus ownership.
71
+
72
+
\footnote{Ownership control of the router is not an issue, as a new router can be used or fallback to the legacy router contract.}
In following the standards set forth by the UniswapV02/SushiswapV01 router contracts, the SushiswapV02 router contracts are intended to be safe to use with:
68
82
69
-
Potentially reentrant tokens
83
+
Potentially re-entrant tokens
70
84
Tokens that do not return from transfer
71
85
Pathological Tokens The SushiswapV02 router contracts are not intended to be used tokens that exhibit the following behavior
72
86
Tokens that exhibit a discretizing inflation curve
73
87
Tokens that exhibit an 'unowned' supply
74
88
Tokens that implement user defined types for standard mathematical operations
75
-
Numerical error analysis The engineering team would like to request a review of the numerical error incurred during contract execution, with a focus on the desirable invariants proposed by both the development team and auditors. Examples include any significant rounding error, if any, in a swap, favors the pool. etc.
89
+
Numerical error analysis The engineering team would like to request a review of the numerical error incurred during contract execution, with a focus on the desirable invariant proposed by both the development team and auditors. Examples include any significant rounding error, if any, in a swap, favors the pool. etc.
Profits are distributed to liquidity providers, in turn giving users better rates. Extracting MEV at source protects user trades from front-run attacks inherently and helps prevent fee spikes from attackers.
96
110
97
111
112
+
Slippage: The amount of price impact that a liquidator engenders when trying to sell collateral.
113
+
Slippage is denoted \text{$\Delta p(q)$} and is formally defined as the difference between the midpoint price at time $t, p_{\text {mid }}(t)$ and the execution price, \text{$p_{\text {exec }}(q, t)$} for a traded quantity $q$ at time $$t, \Delta p(q, t)=p_{\text {mid }}(t)-p_{\text {exec }}(q, t)$$. This quantity is usually a function of other variables, such as implied and realized volatility.
114
+
\footnote{Slippage is also known as market impact within academic literature.}
115
+
98
116
99
-
\newpage
117
+
\subsection{Router Implementation}
118
+
As a general approach to security, deviation from current UniswapV2Router was kept to a minimum. Pair contract calls should be consistent with the existing router. Reliance on the new router storing and transferring tokens brings in a new attack vector. A robust Ownership setup, as above, was chosen to mitigate this threat along with reduction of functions accessing the funds. 2 helper libraries were also chosen from \text{solmate} to supersede \text{UniswapV2Helper} libraries for security.
119
+
120
+
safeTransferLib
121
+
ERC20
122
+
Since UniswapV2Router was not designed to store tokens, some functions are not compatible and had to be changed. E.g.
123
+
124
+
\begin{minted}{lexer.py:SolidityLexer -x}
125
+
126
+
removeLiquidityETHSupportingFeeOnTransferTokens
127
+
128
+
(, amountETH) = removeLiquidity(
129
+
token,
130
+
WETH,
131
+
liquidity,
132
+
amountTokenMin,
133
+
amountETHMin,
134
+
address(this),
135
+
deadline
136
+
);
137
+
TransferHelper.safeTransfer(token, to, IERC20(token).balanceOf(address(this)));
We also tried PRBMath\footnote{https://github.com/paulrberg/prb-math/} library. These faired better in echidna tests but still suffered overflow issues.
Ultimately we settled on Uint512 \footnote{see $github.com/SimonSuckut/Solidity_Uint512/blob/main/contracts/Uint512.sol$} which both passed echidna and overflow issue.
0 commit comments