Zellic - Audit Reports

Classic pool

SyncSwap classic pool is based on this well-known constant product invariant:

Swap

To perform a swap, users must send the amount to be used as input and call swap (since this must be performed in a single transaction, it is normally delegated to the router contract).

The following calculations assume a swap from the first to the second asset of the pair that makes up the pool. The calculations in the reverse direction are specular. The amount of tokens resulting from the swap is computed as

am o u n t_{I nWi t h F ee} am o u n t_{O u t} = a_{0} * (1 - f e e_{Sw a p}) = \frac{am o u n t _{I nWi t h F ee} * r _{1}}{r _{0} + am o u n t _{I nWi t h F ee}}

Mint

The liquidity used to perform swaps is provided by liquidity providers who deposit liquidity in exchange for LP tokens. Liquidity providers must send the liquidity they want to provide to the pool and call mint. This is normally performed by the router contract.

The amount of LP tokens (liquidity) minted to the user is equal to

where

K_{Ol d} K_{N e w} = (r_{0} + f e e_{0}) * (r_{1} + f e e_{1}) = b_{0} * b_{1}

The fee parameters are calculated to account for unbalanced minting: if the user providing liquidity does not provide both assets in a balanced way, the appropriate amount of the asset in excess is converted to the other asset to keep the balance, incurring in swap fees.

The $t o t a lS u ppl y$ parameter represents the total supply of LP tokens, including the newly minted LP tokens minted as protocol fees. If enabled, protocol fees cause the minting of additional LP tokens that are sent to an address responsible of collecting them. The amount to be minted is computed as

K_{L a s t} p oo lF ee L PT o k e n s = K_{N e w} f ro m p re v i o u s e x ec u t i o n = r_{0} * r_{1} = \frac{t o t a lS u ppl y * ( K _{Ol d} - K _{L a s t} ) * f e e _{P ro t oco l}}{( 1 - f e e _{P ro t oco l} ) * K _{Ol d} + f e e _{P ro t oco l} * K _{L a s t}}

Burn

Opposite to minting, burning allows to get back liquidity in exchange for LP tokens. Users must send LP tokens to the pool before calling burn (within the same transaction), normally by using the router contract.

The amount of liquidity returned to the user is calculated by

a_{0} = \frac{l i q u i d i t y * b _{0}}{t o t a lS u ppl y} a_{1} = \frac{l i q u i d i t y * b _{1}}{t o t a lS u ppl y}

where $l i q u i d i t y$ is the amount of LP tokens being burned by the user and $t o t a lS u ppl y$ is the amount of LP tokens in circulation.

We noticed a difference between SyncSwap and Trident: where SyncSwap uses the current balance to compute the amounts returned to the user, Trident uses the cached reserves values. According to the SyncSwap team, this change was made to improve gas efficiency. While the balance can be manipulated upwards before calling burn without affecting the cached reserves values (by transferring tokens to the pool), we do not believe this behavior can be used profitably by an attacker.

Unilateral burn

SyncSwap also allows to burn LP tokens in exchange for one of the two assets of a pool. This is equivalent to burning LP tokens for the pair and swapping the unwanted asset for the desired one.

The amounts of assets gained by burning LP tokens is computed identically to the regular burn functionality, and the conversion rate between the pair matches the amount that would be obtained by a regular swap operation.