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
Currently for an Account to consume the standard SWAP note, the Account must have the REQUESTED_ASSET amount in the account's asset vault.
This is suboptimal from a liquidity point of view, since it is possible for SWAP notes to use their liquidity to fill each other.
Say there are two "complimentary" SWAP notes:
SWAP note 1: 10 token A for 5 token B
SWAP note 2: 2.5 token B for 5 token A
These two SWAP notes can be filled against each other using the liquidity of the other SWAP note. These two SWAP notes agree on the same price. If they did not agree on the price, the would not be complementary. Additionally, it is also possible for the sell price of one SWAP note to be lower than the buy price of another SWAP note. This would result in a potential arbitrage opportunity for the solver matching these two SWAP notes.
With the current SWAP note, the Account which consumes these two SWAP notes must have 5 tokens B and 5 tokens A, when their net asset delta will be 0 if they fill these two notes against each other.
Filling SWAP notes 1 & 2 against each other would produce the following notes:
It is not necessary for the Maker Account to have any assets at all in their asset vault to fill these two SWAP notes against each other. The ability to fill SWAP notes against each other, is what I refer to as "in-flight" SWAP note filling.
Proposal:
Make it possible for SWAP notes to be filled "in-flight` against each other. I opened a PR a while back which implemented this.
Since we are moving closer to audits, I propose we add this feature to the standard SWAP note. This adds an if / else branch to the SWAP note which checks if the consuming Account has sufficient liquidity in its asset vault to fill the SWAP note. If not, the SWAP note assumes it is being filled in the context of a batch of SWAP notes.
#1904 will need to be refactored to be updated to the latest state of next
Why is this feature needed?
The current SWAP note implementation is not flexible for solvers.
Feature description
Background:
Currently for an
Accountto consume the standardSWAPnote, theAccountmust have theREQUESTED_ASSETamount in the account's asset vault.This is suboptimal from a liquidity point of view, since it is possible for
SWAPnotes to use their liquidity to fill each other.Say there are two "complimentary"
SWAPnotes:SWAPnote 1: 10 token A for 5 token BSWAPnote 2: 2.5 token B for 5 token AThese two
SWAPnotes can be filled against each other using the liquidity of the otherSWAPnote. These twoSWAPnotes agree on the same price. If they did not agree on the price, the would not be complementary. Additionally, it is also possible for the sell price of oneSWAPnote to be lower than the buy price of anotherSWAPnote. This would result in a potential arbitrage opportunity for the solver matching these twoSWAPnotes.With the current
SWAPnote, theAccountwhich consumes these twoSWAPnotes must have 5 tokens B and 5 tokens A, when their net asset delta will be 0 if they fill these two notes against each other.Filling
SWAPnotes 1 & 2 against each other would produce the following notes:It is not necessary for the
Maker Accountto have any assets at all in their asset vault to fill these twoSWAPnotes against each other. The ability to fillSWAPnotes against each other, is what I refer to as "in-flight"SWAPnote filling.Proposal:
Make it possible for
SWAPnotes to be filled "in-flight` against each other. I opened a PR a while back which implemented this.Since we are moving closer to audits, I propose we add this feature to the standard SWAP note. This adds an
if / elsebranch to theSWAPnote which checks if the consumingAccounthas sufficient liquidity in its asset vault to fill theSWAPnote. If not, theSWAPnote assumes it is being filled in the context of a batch ofSWAPnotes.#1904 will need to be refactored to be updated to the latest state of
nextWhy is this feature needed?
The current
SWAPnote implementation is not flexible for solvers.