Attack surface evaluation

In this section we discuss the posture of SyncSwap with respect to some of the most common threats faced by AMMs.

Reentrancy

The pool contracts are protected against reentrancy exploits by using an appropriate modifier on all state-changing functions.

Vaults are also protected in the same way, applying the nonReentrant modifier on the core vault functionality (e.g., deposit, transfer, withdraw) as well as the flash loan functionality.

Being independent contracts, nothing prevents execution flow from performing a pool operation nested within a vault operation; for example, it is possible to take a flash loan, execute a swap, and repay the flash loan. The possible interactions between the two contracts do not appear to be exploitable for profit.

Arithmetic over/underflows

The contracts perform several arithmetic operations inside unchecked blocks, in which the compiler does not insert checks to guard against over or underflows; these unchecked math operations are usually commented with a rationale justifying why unckecked code can be used.

MEV

The possibility to extract value from swap transactions by reordering them or performing a sandwich attack is a common attack vector for AMM pools. This attack vector exploits the automatic pricing behavior inherent to the working of an AMM, and as such, mitigations cannot exclusively be implemented directly in the AMM. Nevertheless, usage of curves such as Stableswap certainly help in reducing the impact of a MEV attack.

The most common mitigation against MEV is the implementation of slippage checks in the contracts that invoke the pool where the swap is performed. The router contract that does this for SyncSwap was not in scope of this audit, but a limited inspection appears to confirm anti-slippage checks are performed correctly.