BitcoinDesign
Add a "graduated wallet" reference design
Not sure who came up with it, but I think I've heard about this concept from Matt Corallo. This is essentially a wallet that uses custodial or trusted layers (like ecash) for tiny amounts and then transitions you to self-custody as funds increase (similar to our progressive security principle). Reasons for this to exist are:
- Make small amounts economically viable by using other layers/services that compromise on self-custody
- Balance this by providing a built-in path towards self-custody
I think a lot of patterns we have in other reference wallets generally apply:
- The Daily spending wallet uses both bitcoin and lightning network, and automatically moves user funds to lightning.
- In Multiple wallets, the user explicitly manages different wallet in the same application, for different purposes as well as different ownership configurations.
So we can probably borrow or link to other sections, but there is also a lot of nuance in this idea here. Some guiding questions might be:
- What is the point where self-custody becomes economically viable?
- Can this be generalized or is this unique per user (their transaction and savings behavior)?
- How often might these transitions between layers happen?
- How aggressively should the wallet ask users to move funds?
- Can (should) they be automated? Do we always ask the user for confirmation?
- How much do users need to understand about each layer? What can be abstracted away?
- Does implementing custodial solutions have legal/regulatory impact?
If this is really meant to make small amounts economically viable, then fee optimization is probably at the heart of many of these decisions. And fees are really messy. It's a good challenge.
Naturally, I did an AI-brainstorm. So here's where I ended up with Claude after some back and forth. I find it overall helpful, but also a mixed bag in various places. graduated-wallet-reference-design.md
Before spending more time on this, I'd like to see if there's general interest. What do you think? Is this a good addition to the guide?
Generally I like it. Framing custodial as ecash also makes sense for such a setup. Plus it's already a documented behaviour, but it doesn't just happen in one interface/app or network.
Personally I've seen it more the case for the savings use case that it's custodial (like blink) -> on-chain. Additionally, one challenge that will have to be addressed is the explanation of the payment request format change.
In the ai brainstorm I like the migration process.
I think it's an addition that would be good to put together, but I'm not sure if it's a design pattern or a product which could fit into a case study.
I'd be interested in working on this, especially on the cash side of it. Evan from Zeus gave a great presentation on graduated wallets at Bitcoin ++ Lightning Edition.
Here are some of my quick thoughts on the questions:
What is the point where self-custody becomes economically viable?
Depends on the wallet's target audience. There's no one single correct answer for this. I think before any of these questions are answered, the wallet needs to define who their target audience is. A graduated wallet for users in Nicaragua is going to have very different points, amounts, and tolerance for fees than a wallet that's targeted for Americans and Europeans. I think the wallet needs to define its audience and then just make an opinionated call. If I were designing one, I would put my limits for custodial/ecash solutions at 100K sats. I think that's the max amount that someone can "lose" to a rug pull or a mint going offline and it's not a big deal. This is a totally personal opinion based on my own personal preferences and experiences. I understand that in some places in the world, losing 100K sats due to a mint going offline might be a major deal. Again, it's who you think your target audience is.
Can this be generalized or is this unique per user (their transaction and savings behavior)?
I'm not sure I fully understand this. Is this a suggestion to have the graduated wallet adjust its thresholds/amounts based on user behavior or some savings targets they set up during onboarding? Either sounds like over engineering to me and added complexity. Would prefer that the wallet makes these choices beforehand and they are set in stone. Keep it simple.
How often might these transitions between layers happen?
Depends on the user's activity.
How aggressively should the wallet ask users to move funds?
I would personally be very aggressive. I would introduce blockers/modals to the user where they have to acknowledge that they're holding certain amounts in certain layers beyond our recommendation. Some wallets may want to be more gentle.
Can (should) they be automated? Do we always ask the user for confirmation?
Again, it depends on the wallet. IMO no. Wallets should never do anything that could incur fees without the user's explicit authorization.
How much do users need to understand about each layer? What can be abstracted away?
Depends on the wallet and their target audience. Could be very detailed and technical like Zeus, or could aim for a very user-friendly wallet that abstracts it all away.
Does implementing custodial solutions have legal/regulatory impact?
To avoid this question. I don't think the wallet should ever be a custodian. It should allow you to pick a federation/mint to be the custodian for on-chain. And once a certain balance is hit, the wallet suggests to the user that now it's time to open up their own lightning channels and be self-sovereign.
@johnsBeharry in terms of the guide, case studies are based on real projects. So a reference design (imaginary product) fits better here. Picking up our convo around branding and communication, treating this as a reference design would also allow us to frame this product overall (think home page and app store mockups) and not just UI designs. Going to add in a bit of an extreme experiment from design week where I mocked up a home page a for a wallet that goes hard on promoting low fees.
@swedishfrenchpress I think we're on the same page on most things. I would go the route of an end-user focused product - abstract away as much as possible without being paternalistic. Thanks for the link to Evan's talk, I'll check that out.
Yesss @GBKS I'm very much for reference designs. the #leadByExample or at least #leadByHighFedilityMockup angle versus giving people the tools to adapt (as we do with much of the guide) could be a good experiment that's worth trying. It also could help establish a north star product that designers in an educational program could work towards. Let me know if I'm pushing too much towards this direction (below) btw.
What is the point where self-custody becomes economically viable?
As @swedishfrenchpress says, and I agree this is something we often preach.
Can this be generalized or is this unique per user (their transaction and savings behavior)?
If we are going reference design then we should consider all the tools we have at our disposal -- to use what's appropriate for the problem and not too far fetched to implement technically (Apple Intelligence / Local AI Models). Let's leave it to the devs/finance/econ folks to figure out generalised approaches without the AI models. Still to be documented.
How often might these transitions between layers happen?
¯_(ツ)_/¯
How aggressively should the wallet ask users to move funds?
Seems like a perfect space to let students adapt the "aggression level" as such things would depend on the brands' priorities/values.
Can (should) they be automated? Do we always ask the user for confirmation?
I think providing the wallet owner with the notifications, and notices to do it themselves is ideal. Not just for exposing the feature, but for autonomy / transparency. With some nice copywriting it doesn't have to seem like "Do Action" button but a "Get Value" offer.
How much do users need to understand about each layer? What can be abstracted away?
At minimum:
- Payment Request formats
- Custody Level
Does implementing custodial solutions have legal/regulatory impact?
Agreed with @swedishfrenchpress
(i'm pretty excited to see how Zeus will integrate ecash to get users started on the lightning/bitcoin journey)
(The AI-collab-ed text seems like it nailed the rationale for graduated wallet and difference from Multiple wallet guidance)
I'll play the devil's advocate on this:
- in my book, the bar for a "reference design" should be the fact that something is an established industry practice/pattern (iirc Steve also expressed something similar in another context), and the reference design merely documents it for use of newcomers to the space
- There are a number of open questions generally (some mentioned in comments above) that seem to confirm the above point.
- Since the exact mechanics, usage/UX patterns of such a wallet are not established yet (at least not to me, but I might be behind on things), I wouldn't presume to know them or prescribe UX practices based on it, but agree this should be exciting area of research (this is similar to my research on silent payments or async payjoin ux: though I think i have quality insights that IMO could go into best practice, I'm holding off from putting them as guidance yet...we simply don't have enough reference points or implementations yet)
- contra @GBKS I would say a case study might be a better fit than a reference design, since case studies are not always or necessarily real-world (though that is generally the case) but also the graduated wallet is an opportunity to explore various approaches and the design space generally... maybe even designing an entire fictional wallet app based on this towards the end (like Christoph seems to be want to do)
overall, i'm curious to see graduated wallet design being explored as a "one wallet to rule them all" sorta thing.
