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
Extend the appdata format to allow users providing hints for how their order can be settled with a flashloan.
Ideally solvers would not need this at all but at least for the initial implementation we'd like users to help solvers out with this non-trivial task.
Without this hint solvers would likely assume if a user doesn't have the necessary sell_tokens that the order is simply unfillable.
flashloan: (optional) field inside the appdata. If it's set the user hints at the solver that it may require a flashloan to settle this order. lender: which contract could be used to borrow the funds from borrower: (optional) who should get the proceeds of the trader, if this is not set assume the order's receive should get the funds token: which token needs to get borrowed (usually the sell token) amount: how many atoms of the token need to get borrowed (e.g. 1 WETH would be 10**18)
It will be made the responsibility of the driver to get access to this information on its own. So it's not necessary to also put this information into the order.
Initially I think it's okay that the usual order placement requirements apply (user needs to have at least 1 atom of the sell token). However, in the future we may need to reconsider this and find workarounds for 1 case in particular:
orders getting filtered out because the owner does not have enough sell_tokens
That can be tackled later, though.
Acceptance Criteria
The PR should include an e2e test where an order with the new flashloan field in the appdata gets posted.
Afterwards the order should show up in the orderbook and fetching the appdata by the appDataHash should yield the originally submitted JSON string.
The text was updated successfully, but these errors were encountered:
Extend the
appdata
format to allow users providing hints for how their order can be settled with a flashloan.Ideally solvers would not need this at all but at least for the initial implementation we'd like users to help solvers out with this non-trivial task.
Without this hint solvers would likely assume if a user doesn't have the necessary
sell_token
s that the order is simply unfillable.New data:
flashloan
: (optional) field inside the appdata. If it's set the user hints at the solver that it may require a flashloan to settle this order.lender
: which contract could be used to borrow the funds fromborrower
: (optional) who should get the proceeds of the trader, if this is not set assume the order's receive should get the fundstoken
: which token needs to get borrowed (usually the sell token)amount
: how many atoms of the token need to get borrowed (e.g. 1 WETH would be 10**18)It will be made the responsibility of the driver to get access to this information on its own. So it's not necessary to also put this information into the order.
Initially I think it's okay that the usual order placement requirements apply (user needs to have at least 1 atom of the sell token). However, in the future we may need to reconsider this and find workarounds for 1 case in particular:
sell_tokens
That can be tackled later, though.
Acceptance Criteria
The PR should include an e2e test where an order with the new
flashloan
field in the appdata gets posted.Afterwards the order should show up in the orderbook and fetching the appdata by the
appDataHash
should yield the originally submitted JSON string.The text was updated successfully, but these errors were encountered: