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
We want to allow solvers and users to make use of flashloans for settling orders. For context a flashloan is a mechanism where an actor requests some amount of tokens, is allowed to use them within the same transaction and has to pay them back in full (sometimes plus interest) at the end of the transaction. If the flashloan lender does not get back the expected amount in tokens the whole transaction will revert and no balances will have changed.
This feature would enable solvers to handle liquidations for bigger amount than they can bankroll themselves.
The overall plan is to let users provide "hints" in their order appdata that it may need to be settled using a flashloan (and some details around that). The driver will read this information and let the solver know about it (flashloans introduce gas overhead that the solver should be aware for when computing fees) and will encode the transaction appropriately (using a helper contract that still needs to be developed).
Finally the post processing step where we index and analyze Settlement events needs to be made compatible with a smart contract calling the settle() function of the settlement contract.
Details to the individual steps can be found in the linked issues.
In order to ensure that tasks don't depend on each other let's introduce some interface which we code against. Those can then be used with Default implementations until we actually have the real data.
the issues outlines an e2e testing plan that is quite involved. Alternatively this e2e test could be delayed until the end to get 1 e2e test that covers the whole feature.
Problem
We want to allow solvers and users to make use of flashloans for settling orders. For context a flashloan is a mechanism where an actor requests some amount of tokens, is allowed to use them within the same transaction and has to pay them back in full (sometimes plus interest) at the end of the transaction. If the flashloan lender does not get back the expected amount in tokens the whole transaction will revert and no balances will have changed.
This feature would enable solvers to handle liquidations for bigger amount than they can bankroll themselves.
The overall plan is to let users provide "hints" in their order
appdata
that it may need to be settled using a flashloan (and some details around that). The driver will read this information and let the solver know about it (flashloans introduce gas overhead that the solver should be aware for when computing fees) and will encode the transaction appropriately (using a helper contract that still needs to be developed).Finally the post processing step where we index and analyze
Settlement
events needs to be made compatible with a smart contract calling thesettle()
function of the settlement contract.Details to the individual steps can be found in the linked issues.
In order to ensure that tasks don't depend on each other let's introduce some interface which we code against. Those can then be used with
Default
implementations until we actually have the real data.Implementation Plan
The text was updated successfully, but these errors were encountered: