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

DAI => PDAI is taking long (e.g. 2 tx) #225

Open
TimDaub opened this issue Jul 15, 2019 · 0 comments
Open

DAI => PDAI is taking long (e.g. 2 tx) #225

TimDaub opened this issue Jul 15, 2019 · 0 comments

Comments

@TimDaub
Copy link
Collaborator

TimDaub commented Jul 15, 2019

Scope

  • Currently when sending funds to the bridge, we're first approving for the exact amount that we then want to deposit subsequently
  • This makes exchanging DAI => PDAI a slow process
  • Many dApps take advantage of approving uint(2^256)-1, such that after the first time they won't have to approve anymore

The Problem

To get PDAI, as a user I have to send DAI to the burner-wallet and then use "Exchange.js" to swap my DAI for PDAI. I'm annoyed that I have to "keep my phone unlocked" for the time of the two transactions waiting to be confirmed.

Personally, I see two solutions

Solution 1

  • In an option that is by default enabled, allow the user to approve the biggest possible integer to the bridge such that two transactions can be avoided

Solution 2

  • Instead of the "Receive" QR code being a regular address, deploy a smart contract for the user that automatically forwards DAI to the LeapDAO bridge. A so called "PDAI => DAI converter contract"

Solution 3

[Feel free to add more in the comments]

Deliverables

  • Implement one of the above mentioned solutions or your own

Roles

bounty gardener: @TimDaub / 10%
bounty worker: name / 75%
bounty reviewer: name / 15%

@TimDaub TimDaub added this to the Burner Current Sprint milestone Jul 15, 2019
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