But First, a TL;DR

I made my own stylish, lightweight, opinionated, and extensible burner wallet (in 10 days)

It powered over 650 transactions over the course of a single evening

Our centralised micro-economy had a market cap of over AUD $1200

A single game within the app accounted for 23% of token traffic

Transaction notifications were a tiny addition which made a HUGE difference

Our accountant gave a fiat bribe to our Airtasker-hired, VIP-area bouncer

At least ten people have told me it was a house party to remember (very important metric)

Wait, What’s a Burner Wallet?

Feel free to skip to the next heading if you’re already familiar with burners, but certainly read this section if you want your burners-are-great beliefs reinforced.

Burners are a form of cryptocurrency wallet, but first let’s set the stage, why do we need another crypto wallet, aren’t there tons already?

Cryptocurrency wallets generally suck. I don’t mean this in a derogatory way, and I don’t mean to besmirch those who spend their time making wallets: you’re in an exceptionally difficult job, I don’t envy you, and I think that you’re making software that will be used by my children and their children too. Seriously.

However, most of the time when you use a crypto wallet, the first thing you’re shown isn’t what you can do with the wallet: the myriad of possibilities now at your fingertips; instead you’re shown twelve random words and some giant warnings about how your children will be auctioned off if you don’t write them down somewhere uncle sammy can’t see. Less than fun.

There’s some necessity here. Wallet developers don’t do this because they hate you, in fact it’s the opposite: they love you and don’t ever want you to be parted from your special cryptographically-secure money. Thanks wallet developers!

Nevertheless, sometimes you might just want to test out what using a wallet feels like, or you might want to quickly fire one up to receive reimbursement for the dinner you bought a friend who insists that you should try out this crypto thing, who then probably has to hover over you commentating:

“Yeah make sure you screenshot this part, you’ll need it later but don’t worry about it right now, hit next. Yeah now go look at that screenshot you just saved and type in words 6, 8 and 10 here, you can’t copy and paste them you’ll have to type them in, it’s annoying I know but stick with it. Yeah okay cool almost there just hit next a couple more times and ignore these warnings.”

Not the most fun experience for the uninitiated.

Bring on the Burner

Austin Thomas Griffith, otherwise known as Gandalf the White Wizard, released the burner wallet in the form of xdai.io a few months ago. It’s a wallet on a website, but the private key lives in your browser’s cookies (or localstorage, whatever). This means it’s never seen by a server, and it’ll persist for as long as your browser persists its storage, which is a bloody long time.

Austin’s wallet doesn’t show you any warnings or messages about making sure your pen doesn’t run out halfway through writing down your new-most-private-information-that-you-shouldn’t-show-anyone-ever, instead you’re given a wallet address and the ability to make transactions right from the browser, without a password.

At first, I must be honest I (probably like many) thought: What’s the point? This feels insecure. This isn’t a wallet, this is a disaster waiting to happen. I had a similar level of disbelief that Aragon, Legolas and Gimli probably had when they saw Gandalf alive again after he fell off that ledge with the Balrog.

After a ton of work testing the concept and the flow at many crypto speakeasy events in Colorado, ETHDenver (which I attended) was the home of the first major test of the burner wallet. I won’t go over the details again because they’ve been described here but essentially, Austin’s burner wallet powered nearly USD $40k worth of transactions over three days without a single major hitch. If that’s not proof in (almost literal) pudding then I don’t know what is. Using the wallet at ETHDenver was slick, and the only issue I personally encountered was snow hitting my phone screen and making it difficult for me to press buttons.

Austin didn’t stop there either, a few weeks ago he started work on ‘burner modules’, which are little pieces of functionality inside the app. Think of these as ‘mini dapps’, which can be used as easily as a web2 app. The first of these little modules was emojicoin.exchange. I recommend you read the blog post, it’s a riot.

So the Burner Works, Now What?

Inspired by Austin’s technical and opinionated approach to solving some of the more commonly-cited “onboarding” problems with Web3 tech, and spurred on by the thought of being able to test things at a house party we were throwing, I decided to take Austin’s concept and run with it.

The brief was pretty simple: Create a crypto wallet which can be used by drunk people who might not have used cryptocurrencies before. What I learned is that building a wallet for drunks is pretty fun and a good proxy for building a wallet for newbies. If I had to guess (I didn’t survey them) I’d say that about 50% (~35) of the onboarded folks at our party had not used a mobile crypto wallet before.

The brief was pretty simple: Create a crypto wallet which can be used by drunk people who might not have used cryptocurrencies before. What I learned is that building a wallet for drunks is pretty fun and a good proxy for building a wallet for newbies.

It also meant a few things were pretty much decided for me:

Big buttons

Self-explanatory workflows

Clear feedback about which actions have been performed

No copying and pasting

No hexadecimal 0xstrings

I’ll make another post probably later this week or early next about how exactly we built the wallet, but for now you can check out the initial designs I made on Figma (golly I love Figma) and I’ll post the link to the source code once it’s a little cleaner and has a half-respectable readme.

There was a couple of other things I wanted to add which were specific to the house party itself. We planned to have a VIP area, for which we had pre-sold 5 tickets on a pay-what-you-want basis (average price $20, woah). Within the app we wanted to allow for those tickets to be purchased from the holders for 5% more than the previous purchase price.

There was also a funky smart contract powered boat racing game made by our friend Andrew Parker (due to be released on mainnet this week, watch his Medium) which we wanted to allow people to interact with via the app. In short, it sounded like we needed a Minimum Viable Extensible Burner Wallet.

Ideally I would have liked in-app as well as native notifications, but due to timelines I had to chop the latter option. Our notifications are powered by Blocknative’s Assist.js, which was a breeze to add (much simpler than my efforts to integrate Assist with pre-existing dapps), and due to the fact I literally sit next to the front-end lead of Assist every single day (hi Aaron) I was able to help influence the immediate feature roadmap and get access to some pretty nifty things (custom alerts, mobile notification UI). It wasn’t all sugar and rainbows though, there’s still some bespoke #party code in my version of Assist.js, but we’ve documented those things and are working to ensure that’s not necessary in the future.

Assist.js gave us the power to make completely custom notifications directly in the app. We used them a ton. Sending and receiving FLEXBUXX was rich and gave plenty of intuitive feedback about what was occurring, and all it took was a single contract listener and a couple of calls to assist.notify .

The send/receive flow, imagine how much more confusing this would be without the notifications 🙌.

Not only that, but since we used an ERC223-standard token for the base of FLEXBUXX and ensured that our contracts were 223-compatible, we only required a single transaction to participate in all of the bespoke apps that we created for the party, so the action of engaging with them was completely atomic and there was no chance of what would be perceived as a “single” action being completed over two or more actual transactions.

Select your boat from the app, then watch it race on the TV. A barrel of laughs.

This simplicity not only made it much easier to make rational choices about experiences which favoured the user, it also gave us time to really polish the UX of the boat racing dapp in particular. I’ll let Andy do the full concept real justice over in his own writings about the game, but I’m very pleased with the boat-selection flow which was scaffolded in barely any time at all (❤ choojs).

A blurry image of the final regatta race of the evening. Steamboat Scurvy took home the bacon.

Did it Make the Party More Fun?

Heck. Yes.

Not all the little dapps we built were trivial distractions, they were trivial distractions with real money involved and they made up integral parts of the event experience. We literally hired a guy from Airtasker to guard the VIP area so only people with in-wallet VIP tickets could enter. His name was Juan-Sebastian and he did a fantastic job until he took a $5 fiat bribe to let our accountant in. If that’s not a good story I don’t know what is. The five VIP tickets had a 15min cooldown when purchased, and they changed hands through the app a total of ten times.

The VIP ticket purchasing screen.

Crypto Regatta went off — 23% of the token transactions made on the night were because of this one game. It processed ~77,000 FLEXBUXX (AUD $60) and it had people yelling things like: “Come on HMS Dennis Waterman you lousy sponge!” at the television for most of the evening.

The other games might have seemed a little more trivial, but again, the inclusion of real money drove usage. Chain of Thrones (a simplified FOMO3D, thanks Andrew B Coathup, whose vlog of the event you can see here) was a hit, ~110,000 FLEXBUXX (AUD $82) moved through that one in 0.50c chunks, not a shabby amount of transactions at all.

Other dapps collected some change too — the super-simple Tarot dapp (collect money and return 3 pseudo-random numbers which become your tarot cards) netted AUD $20, and the immaculately-immature poop noise dapp (pay a fraction of a cent to make everyone else’s phone make a fart sound) was used over 90 times. These dapps are a cinch to make, and it doesn’t matter that their code is replicable because they’re only used for a small period of time (almost like a new class of dapp: burner dapps) and they’re the only ones which are baked into the wallet.

Not only did the wallet enable us to build little moneytraps for people in the form of burner dapps, we also held an auction, selling off various pieces of crypto merchandise that we’ve collected/stolen over the year, and invited others to auction off their goods too. Everything was paid for in FLEXBUXX, no need for complicated maths and finding the correct change, just pay the exact amount from your wallet. Simple.

When Burner Wallets Burn

Most of my evening was spent onboarding people into our little economy, so I didn’t get a ton of time to enjoy most of the fun. I did however get to experience the issues people had with the technology, and learn a ton about how to avoid any of these things in the future.

In no particular order, these are the problems (that I remember) we ran into:

PWA didn’t work on iPhone, could not access the camera — we had to tell people to use the app directly from Safari

Safari QR-code scanning wasn’t properly tested and I had to push a fix mid-party whilst still trying to onboard people (not fun at all)

A couple of people used incognito tabs (something I didn’t think anyone would do) and then burned their wallets by accident due to not knowing how they function — we regenerated about AUD $140 in total

Unstable internet connections left a couple of people thinking they had lost their funds but in actual fact the balance just hadn’t been fetched yet

The addition of a confirm screen (a staple in crypto wallets!) in the send flow led to a few people not finishing up the flow and forgetting to actually send their funds

A couple of these are easily fixed with some craftier user experience work and some more user testing, but losing your funds still seems like a very real concern with a burner wallet. If it can happen to 2/3 people at a gathering of ~70 or so, it can happen to many many more at a larger event. This could certainly have been due to some janky code in our wallet, but we can’t rule out that the problem is inherent to this class of wallet just yet. One way to mitigate reasonably well is to have a recovery mechanism though the scan of a QR-encoded key on some paper or a physical token, we certainly could have done this but it adds significant overhead, which is worth calling out.

Where To From Here?

A ton of folks have said that this is exactly the kind of thing they expect to see at a music festival and it’s not hard to see why: give your attendees some $$$ in a wallet, included in the ticket price (maybe even allow them to top up, ala Fyre festival wristbands), allow them to spend it on trinkets and baubles at the festival, and give your event sponsors the ability to quickly build “burner apps” to capitalise on the liquidity and availability of this cash money. This model extends to pretty much any event too, not just festivals.

We’re going to strip out the house-party-specific code (sans a couple of simple apps so you can see how to add them) in our wallet over the next few days and stick it on GitHub for anyone to deploy at their own events (highly recommended for house parties). If you’d like my help setting it up/skinning/advising on how best to build an extension, let me know either on Twitter, Telegram, or via email and let’s have a chat. I also welcome PRs to the repository to add new features and/or optimisations. I think there’s a ton of merit in being able to scan a private key to recover, as well as plenty of other things which I’ve cut from the original burner wallet to save time.

I’ll also write another post which goes more into detail about how we created the wallet with the tech at hand, so you can see just how little code there is in a minimum viable burner.