Building on ICP: gifting Bitcoin to people who have never had a wallet. Feedback requested

Developers Showcase
,
1

Hey everyone,

I want to share what we are building and get some honest feedback from this community.

I have been in crypto since 2017, and I have spent a lot of those years trying to onboard the people I care about. I bought many hardware wallets for friends and family. Nearly all of them sat in drawers, and the ones that got used turned me into tech support. These are smart people who were interested. The problem is that the first step is confusing and a little scary when you are new, and nearly everything in this industry is designed for the person buying crypto, not the person receiving it.

That is the problem we are working to solve. Gifty is a non-custodial platform for gifting Bitcoin and crypto to someone who has never had a wallet. The gift is held under rules enforced by the escrow canister itself, not by us. Once the implementation has been thoroughly tested and publicly verified, the plan is to remove the canister’s controllers, making the escrow immutable so that neither Gifty nor any administrator can change the rules.

To claim the gift, the recipient completes short lessons the sender picks from a library, things like what Bitcoin is, how to receive and hold a gift, and how to stay safe. We call it Learn and Unlock. The sender knows the person they are gifting, so the sender decides what they should learn before the gift unlocks. If you are gifting someone their first Bitcoin, whether it is for your kid at graduation or for a friend you have been trying to orange pill for years, the gift should come with the knowledge to actually hold and use it.

Why ICP

ckBTC gives us a 1:1 BTC-backed token native to ICP, with no third-party bridge, while supporting conversion to and from the Bitcoin network. Canister-enforced escrow means nobody has to rely on our discretion, with a path toward publicly verifiable and immutable rules. Reverse gas means the recipient does not need to acquire tokens just to claim a gift. And Internet Identity gives a first-time user account entry with no seed phrase on day one. We looked at other stacks and could not build this experience the same way anywhere else. We filed for provisional patent protection on the education-gated approach earlier this year.

Optional email-bound claiming

We are also exploring an optional email-bound claim flow using Internet Identity’s verified email attributes. A sender could address a gift to an email address, and the recipient could prove control of that email during claiming, without Gifty running its own separate email verification flow. This is still at the product design level, and we would love feedback on how it could work in practice.

Team

I have run a production company in San Francisco for 19 years working with consumer brands. My co-founder Michael Mitchell has been a design leader at Intuit. We have also received technical input from an experienced ICP and Rust developer while planning the architecture.

The site and a short video are here: https://www.giftylabs.io

(the video is under the See Gifty in Action button)

One thing to know before you visit: the MVP is currently in design and technical planning. What you will see is the intended design direction and envisioned flow, not a live product you can try yet. That is part of why I am posting now, while we can still change things easily.

Four things I would love feedback on

  1. The claim flow. Watch the video and tell me where it would break for someone who has never touched crypto.
  2. Internet Identity as a first-time user’s entry point. What trips new users up in practice, and what should we design around?
  3. Trust. A claim link from an app the recipient has never heard of may look like phishing. What would it take for you to feel good sending one to someone you care about?
  4. Email-bound claiming. Does the verified email approach above hold up, and what fallback would you recommend for users who authenticate with passkeys and do not have a verified email attribute?

I will share build progress here as we go. All feedback is welcome, especially the critical kind.

Tommy Gifty Labs, San Francisco

2

Is it just me, I can’t find the video..

My eyes are tricking me, I thought I read AI feedback is welcome

I actually think this is a great idea, it makes me want to gift BTC to my dad. As per how to gift, email gifting is really just sending a link right. Thankfully most people I know are no longer solely on email, and even older people prefer to be messaged on messaging apps these days.

Say you are gifting a large amount, then the trust factor becomes even more crucial. I feel like in this case you almost don’t want it just to be a link but link plus something else whether that be a password, seed phrase which you can give in person even, or some Big Tech company auth flow like Google account verification.. something to make the sender feel more secure in their investment.

But overall great idea and ICP is a great platform the idea.

3

This sounds like a fantastic project. Blackholing also sounds like a great move for this sort of thing. I would suggest making the controller the canonical blackhole controller, such that the cycles balance becomes public.

I’d happily make an endowment via https://jupiter-faucet.com/ for such a canister, such that it becomes irreversibly perpetually funded with cycles.

I’ll plan to take a look at the video later tonight.

4

I’d also recommend you deploy this canister to the Fiduciary subnet for the added decentralisation and security. There’s a blackhole controller on that subnet too (you can confirm that the WASM is identical to the original 13 node blackhole referred to above). Both have perpetual cycles funding via Jupiter Faucet.

5

https://www.giftylabs.io/#how click on see gifty in action button on the right, sry :slight_smile:

6

Thanks. Personally I’m not a huge fan of AI videos.. but I do like the messaging. One interesting thing you could also do on the IC is gift neurons with.. I guess.. automatic following or automatic proposal rejection and then on the dashboard show the rewards gained then they can ignore the fact that nexy year ICP will be down to 50 cents

7

Thanks Brady - The video is under the See Gifty In Action button on the page. Here is a direct link to it. https://youtu.be/3syxnkmXQzg

Right now we plan to have basically what I would call 3FA for the recipient, but it might be clumsy. Since the sender would know the recipients email and phone number, the sender would provide that and the recipient would need to verify both before seeing their gift. Hopefully we can do better than that with verified email claiming, but we are exploring that.

8

Cool idea. Following Neuron: αlpha-vote - ICP Dashboard would be more productive though.

9

Thanks for jumping in to point out where the video is. I added instructions to the post to be more specific.

10

No problem it took me also a while to find it as well.

11

Wow, that is fantastic and something I hadn’t thought through. The endowment offer is very cool. Basically an escrow that can outlive even us is exactly the kind of trust we want to build into this. I will be reviewing all of this with my team and would love to continue to get your thoughts as we move forward.

12

That is good to know. We will be changing that up on the site so it is more obvious.

13

Exactly, Jupiter Faucet is there to make it easy to set this sort of thing up.

The other thing you’ll need before blackholing is a reproducible build that several people have verified. Motoko tends to be a better language for reproducible builds, and the simpler you can make the canister the better.

I noticed in the video there was mention of earning yield while assets are held in escrow. Did I understand that correctly? Can I ask how that works / where does the yield come from?

14

Thanks, i think its something that can work in Africa… most bse its were these people are, open to collaborating on adoption

15

That all sounds like a good roadmap for increased security and backup. The one question we have run into while explaining this to non-ICP native people is “What happens if ICP ceases to exist?” We have answered what happens if Gifty disappears, but with so many blockchains failing in the past, when we mention this to laymen that don’t understand ICP it is a question that comes up.

You understood the yield section of the video correctly. Yield on escrowed assets is part of the longer-term vision, though not the MVP, and the hard design constraint is that it stays fully non-custodial. The how involves technical and regulatory questions I want to get right rather than post on a thread, but it’s exactly the kind of thing I’d value your eyes on. If you’re open to it, I’d love to take that conversation direct as we get closer to those decisions.

16

Yes, I agree. We definitely are planning to launch globally after we release the MVP here in the US. Increasing global adoption of crypto is part of the bigger play here. Once we are ready to go global I would love to talk more and am happy to hear any insights you have in the meantime.

17

I think one way to answer this is that ICP technology is continuing to advance at an impressive rate, which includes increasing the number of ways in which the protocol can be used and the assumptions/dependencies that come along with that. In principle though, if the protocol is running on at least 4 machines, either across cloud platforms and/or across data centres (with each node ideally maintained by a separate party), then the protocol can remain alive.

I’m not aware of any other crypto project like that, and in that sense ICP is the most resilient crypto-native platform for building on that I’m aware of. I recommend following the developments with Cloud Engines for the cutting edge stuff that’s happening with the protocol.

18

This is very helpful and a strong arguement. Thank you!

19

thanks for sharing your idea. in general I like the idea of gifting crypto easily to average users while ensuring the funds are safe.

blackholing is certainly sth. that some adopters would like to see, but it also means you cannot further update the canister code. for that reason we usually don’t recommend blackholing for stateful canisters. it also means you cannot fix potentially serious bugs. the bugs could be unrelated to the canister code but included in the libs and toolchain used (e.g. memory leaks, …).

I 100% agree that canister control is an important topic, especially if your platform claims that the funds are held “non-custodial”.

however, I think you can postpone this topic for now and instead try to assemble a group of willing testers and set up a staging environment on ICP mainnet where you can rely on testnet BTC instead of real BTC so nobody can lose any funds while testing and providing feedback.

I think you can indeed rely on the II shared e-mail address as ownership was already verified by II in such a case. but I am also tagging @sea-snake / @aterga to quickly confirm that. IIRC, you would also need to restrict the feature to the II supported email providers.

regarding the passkey only route → personally I wouldn’t see that as the highest priority for this kind of application. I would assume that in 99%, a crypto native user would want to gift some BTC to a person who doesn’t own any crypto yet. and the easiest way would be to provide the email of the desired recipient and use the email-bound claiming only.

if you want to support an alternative route I think you would just generate some claiming code which can be shared with the claimer. so knowing the claiming code would make one eligible to claim the funds.

in the video you also show the email that the potential recipient receives. so you must know the email somehow in order to inform the recipient. otherwise the creator of the gift needs to send the information and claiming code manually to the desired recipient.

as a sidenote: there was already @f0i who worked on a similar project. I think at some point he stopped working on it. but I am sharing some details in case you want to also have a look how he did it:

20

Thanks for the detailed feedback and for connecting us with other people in the community.

We are open to not blackholing the canisters be need to have a secure way to hold funds and keep bad actors from stealing somebodies gift. I am open to suggestions. Also we definitely planned to work with testnet BTC in the beginning. We would also want to gift ICP in the MVP or very shortly afterwards. Ultimately this whole product is an adoption play. After years of sending Ledgers to family and friends and then becoming their educator and then tech support I felt that there had to be a better solution.

It would be great if the II shared email worked to securely deliver that gift. And yes, the current plan would be that the sender would provide both the email and phone number of the recipient and we would use 2FA, this way nobody could intercept the email and therefore the gift, but hopefully II email is a better solution. I just haven’t educated myself on it enough yet and need some direction and to do more homework.

I will take a look at the links provided for the similar project. Thanks for sharing.