Virtual Synths SIP

The Synthetix fee reclamation mechanism prevents atomic transactions that incorporate a Synth <> Synth exchange, breaking composability. This is due to the waiting period imposed after exchange Synth exchange to mitigate frontrunning of oracle price updates.

Justin has written a SIP that proposes creating virtual Synths for each exchange, this virtual Synth logic could be implemented into an AMM to use Synths as bridges between pools, however this will require changes to each AMM contract. We believe a Synth bridge between USD, BTC & ETH pools would allow for extremely low slippage trades between these pools enabling deep liquidity from ETH -> USD and BTC -> USD.

Currently if we want to bridge USD and BTC pools there is a lack of a common asset. However, Synths can be exchanged with infinite liquidity allowing them to act as a liquid bridge between any pool that contains sUSD, sBTC or sETH.

A trade would work like this:

  1. USDC -> sUSD (rate set by the AMM)
  2. sUSD -> sBTC (rate set by Chainlink Oracle)
  3. sBTC -> WBTC (rate set by the AMM)

This trade cannot currently be done atomically due to fee reclamation. We introduce virtual Synths and exchange sUSD -> sBTC with (vsBTC as the output) then we exchange vsBTC -> vWBTC so the user would have a virtual representation of WBTC until the Oracle rate is confirmed. After this the vWBTC can be settled to WBTC. We leave the specific implementation of the AMM logic to each DEX.

6 Likes

That’s really cool! What kind of changes would need to be made to the AMM in order to support this functionality?

We are trying to not be too prescriptive about how to implement for the exchanges, but if it were me I would be adding a set of virtual tokens for each underlying token and then using the balances of the underlying + virtual to calculate exchanges.

This is a cool idea and a very good start to workaround the oracle issue/fix, my only concerns are:

  1. Withdrawal attack, attacker can do little trades on the exchange to block user from withdrawal/burn

  2. Many flavour of same assets between exchanges, 1:1 swaps between those representation could led to confusion

What do you think @kaiynne?

Anyway, looking forward for the very first implementation!

  1. If I understand it, the concern is that someone would fill up an AMM pool with a bunch of individual exchanges, each of which would require vSynth settlement by the AMM, correct? Definitely figuring out a way for the AMM to reduce that risk - such as some kind of premium per vSynth to vToken exchange - would be necessary.

  2. You mean confusion to a user when they look at the transaction in a block explorer and see a token and its virtual representation being emitted?

1 Like
  1. You definitely hit the point! I like your proposal.

  2. I meant that two AMMs could have two different representations for a Synth e.g. vsBTC for AMM1 jsBTC for AMM2 with the same underlying. I am thinking how could be a good way to swap between different representations so users are able to switch AMM with no friction. Indeed aggregators could face the same challenge.
    Probably at the beginning a good idea would be have a common vSynth between AMMs. Anyway having the same representation could limit the behaviours an AMM could embed in it.

What potential attack vectors could arise from vSynths? How likely do you imagine they could be?

My sense is that there is minima risk to the AMM pool if it uses the naive version Justin proposed. But if it implements the ability to use Virtual Synths into the internal accounting that could open up some attack vectors but these are likely to be idiosyncratic to the AMM itself.

1 Like

@kaiynne the proposal could be a good idea. :ok_hand: :+1: