Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate callees for other DEX protocols #576

Open
3 tasks done
LukSteib opened this issue Jan 6, 2023 · 1 comment
Open
3 tasks done

Investigate callees for other DEX protocols #576

LukSteib opened this issue Jan 6, 2023 · 1 comment

Comments

@LukSteib
Copy link
Contributor

LukSteib commented Jan 6, 2023

Goal

Research notes on how to implement callee for other DEX protocols

Context

Currently, the main liquidity provider for unified-auctions swap transactions is UniswapV3. But we want to add at least one other callee, the one which is the easiest to integrate in the limited amount of time we have. For this, we need to investigate further the technical details of the implementation and testing framework and prepare proof-of-concept.

Tasks

  • Collect notes along the way
  • Outline next steps
  • Discuss if required
@LukSteib
Copy link
Contributor Author

LukSteib commented Jan 6, 2023

Research done by @valiafetisov.

What a typical existing callee code does:

  • while being deployed, constructor takes and sets some values
    • *router – address of the router contract – from which the flash loan will be provided
    • daiJoin – address of the MCD_JOIN_DAI contract – to which the DAI needs to be retured
    • it gets DAI address using the MCD_JOIN_DAI contract view method .dai()
    • it approves MCD_JOIN_DAI contract to take any amount of DAI from the callee address
  • exposes a single external function clipperCall
    • which have to accept
      • sender address – the address of the contract calling the function, which suppose to pay back the loan
      • owe (uint256 amount denominated in RAD) – DAI amount to pay back (otherwise the callee will fail)
      • slice (uint256 amount denominated in WAD) – amount of the token "received" (or rather "approved", the amount that can be taken by the callee from the "gemJoin" address)
      • data (calldata bytes) – arbitary data that can be passed from the frontend to the callee. It is usually contains at least
        • to address - the address to send remaining DAI to
        • gemJoin address – address that holds slice amount of tokens that callee is allowed to take
        • minProfit (uint256 amount denominated in WAD) – minimum profit in DAI to make
        • other params required by the callee
    • the function then:
      1. converts slice from WAD to the actual ERC20 amount of tokens (eg sliceERC20)
      2. moves sliceERC20 amount of token from gemJoin to the callee address
      3. gives *router the approval to move sliceERC20 amount of tokens away from the callee address
      4. converts owe from RAY to the actual ERC20 amount of DAI (eg oweERC20)
      5. execute external *router function to exchange sliceERC20 into DAI
        • passing oweERC20 as a parameter to validate that the transaction can succeed
      6. checks that exchange took complete sliceERC20 amount, otherwise transfer back the leftovers
      7. send back oweERC20 of DAI
      8. transfer remaining DAI to the to address

The only variations between callees that I've found so far:

So the overall next questions:

  1. What external function we need to call to swap using 1inch?
  2. What data do we need to pass to 1inch swap function (eg a route, something else)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant