Design proposal: Send crypto to people without a wallet

hester · February 5, 2020, 2:49pm

People might be easier convinced to download and install Status if they know there’s a warm welcome waiting for them. Here’s a proposal for a DApp that allows gifting crypto to people who don’t have a wallet yet.

The idea is simple: Let experienced users fund an escrow and generate a unique withdrawal url. This is a personal, one-time use url. Funds are released to anyone who visits the url in a web3 browser and connects to the dapp with a wallet address that was not used to fund the escrow.

Criteria

Reuse what we have. Limit development time
Limit actions for a recipient to what’s familiar and reactive

Here’s what that can look like: Figma

System requirements

These are what I see as potential obstacles and I’d love to understand if what I’m proposing is feasible:

Check if Status is installed on device from a webpage (@Ferossgp)
Deeplinking to open dapp in Status browser (@andrey)
Escrow release by any account address that is not the funder (@rramos)
Release escrow to account that is not the funder without requiring gas (@rramos)

Note: There is no step where the sender confirms the recipients address. If the sender wants to control the release of funds they can choose not to send the url and ask the recipient to send them their address. However, this would be more or less the same a sending from any wallet in that case.

Use case

Crypto owner wants to send crypto to someone who doesn’t have a wallet

Benefit

Provide incentive to download and install Status
Removes blocker of needing crypto to buy crypto without gas relay or abstraction

Scenario

Bob wants to invite his friends to start using crypto
Bob wants to invite his friends to start using Status and provide warm welcome

Future improvements

Allow creation and viewing list of multiple withdrawal links
Allow adding multiple currencies to a single withdrawal link. (e.g. Gift both ETH and SNT through one link)
Notifications to update the funder
Figure out how to create an entry point in invite friends flow: Invite with crypto
UI, especially stepcounter for sender

andrey · February 5, 2020, 4:51pm

Would be interesting to have packages options, for example package to register ens name, ETH for gas, and SNT for name in one link

hester · February 5, 2020, 5:01pm

Totally! If it’s possible to capture multiple currencies in the same contract and release at once, I’ll update the UI to include this as an option. Those tiny cards that now show ‘promoted’ currencies (ETH, SNT, DAI) could hold packaged options.

ricardo3 · February 5, 2020, 5:22pm

Possible to implement trough:

account contracts action
shared private key (donater and receiver knows pk)
burner wallet keycard

rramos · February 6, 2020, 3:06am

1/ It’s possible to capture multiple currencies when funding the escrow. We can do this by sending an array of token addresses and their amounts. For example, using this contract Escrow.sol · GitHub, an user that wants to create an escrow would execute:

Escrow.methods.createEscrow(
  ["0x0000000000000000000000000000000000000000", "0x744d70fdbe2ba4cf95131626614a1763df805b9e"]
  ["100", "300"]
).send();

And then, an escrow would be created with 100 wei, and 300 snt/wei. But there’s a catch with regards to using tokens: it must have an allowance assigned to the Escrow contract for the transaction to be executed successfully.

This can be solved in two ways:
a. With an authorization process similar to what Assemble/Teller does for the specific amount being funded (which leads to a not so good user experience IMO),
b. Or, by having an ‘unlock token’ functionality that sets the token allowance to the maximum amount possible (like Uniswap does), to avoid having to approve a token constantly, which makes the UX simpler and is a pattern used by A LOT of DApps but then, it can be risky for users for reasons explained in this 4m video: https://www.youtube.com/watch?v=y9A8wHhNjJA. (We do not use this in Teller for this reason).
We need to evaluate the pros/cons of each solution.

2/ Since most of the time the destination address is not known at the moment of the escrow creation, this might be an scenario ideal for using a commit/reveal mechanism:

a. During the escrow creation a random string is generated and is immediatly hashed.
b. We store the hash in the contract along with the token information and amounts
c. The random string becomes part of the url sent to the receiving user: https://give.crypto/MY_RANDOM_STRING.
d. When that user access this URL, the RANDOM_STRING will be sent to the contract, and then, hashed to be compared against the stored escrow hash, and if they match, the funds will be released.

I’ll code this tomorrow morning to see how it would look like

3/ We might be missing a state or two for this screen: https://www.figma.com/file/LPURdaiSCU3g8kdybzBhtm/Give-crypto?node-id=24%3A1193z : A state to see the escrows that have been generated and be able to cancel them; and also, to see the escrows that are expired (> 72hr) and retrieve the funds from these.

This fund retrieval process could be automated somehow by creating a service that continously polls the contract for escrows that are active and verifies if they’re expired, and if they are, the function expire(escrowId) from the contract above would be executed. However, this has a gas cost, so maybe the escrow owner should be the one calling the cancel/withdraw function themselves, or even better: to have a button to ‘renovate’ an expired withdraw link without having to send the funds again, or if we really want to have this process automated, to have the service substract a small amount from the escrow in order to cover the cost of executing the automated withdrawal.

4/ With regards to gasless transactions, I’ve been reading in the last two days more about advanced GSN usage, and I think it might be possible to avoid having to display the signature screen to the receiving user. I’ll experiment with that tomorrow on Teller and share the results with you. On the other hand, maybe we want the user to see the signature screen, so they get to know this feature of the Status App?

Another point of discussion is that using GSN requires eth, and we should try to make this dapp be able to work without Status subsidizing its usage. A possible solution might be to always require ETH in the funding with some specific amount being allocated to GSN usage.

rramos · February 6, 2020, 2:23pm

Here’s a small demo app that allows creating and redeeming ETH escrows:
https://richard-ramos.github.io/escrow/

It’s only available on Rinkeby, and can be tested using the Status app.

Contract is available and verified here: https://rinkeby.etherscan.io/address/0xd8da0c6eb2868a79526228f559ba7bc27681ba49

hester · February 6, 2020, 4:12pm

Thanks @andrey @ricardo3 @rramos!

@rramos Awesome! Checking out the demo app.

Based on your comments I will:

Add a way to select multiple currency packages
Think a bit more about the authorization flow. Honestly it feels like choosing between 2 evils for all dapps with token transactions. In case of unlocking (authorizing a max) is it possible to do this for multiple tokens at once?
Create an overview to manage urls and actions. I have the following in mind: (cancel/withdraw/extend/renew)

I would prefer offering auto-withdrawal and will think of how to communicate an additional fee to cover gas costs for that. It could be optional, but until there’s a better notification mechanism for dapps (@barry believe you had some ideas to expand on GitHub - status-im/contract-notifier: Send email notifications when a contract event is emitted with Status messaging. That fits this case really well as it’s build around the dapp user already using Status). I think it’s way to easy to forget about the funds or about the link to get them.

@rramos on your 4th point, great point to leave signing tx in for the recipient as a form of education. This is very likely the first ever time to sign a transaction so a great opportunity!

About the idea of funding gas through GSN. To what extend would the funder know where the gas funds go? (e.g. 1) the link recipient, 2) the dapp, 3) any Status contract using GSN, 4) anyone using GSN)

hester · February 7, 2020, 11:02am

Successfully redeemed :

rramos · February 7, 2020, 7:19pm

The funds are stored in the RelayHub contract of GSN and these funds are asocciated to the Escrow contract. A part of these funds will be deducted each time a relayed transaction from the Escrow contract is executed.

ricardo3 · February 8, 2020, 5:52am

There is also eth2.io @hester

hester · February 12, 2020, 2:37pm

Cool, I hadn’t seen them @ricardo3 will see if it can meet the same requirements! Definitely a good example