How to Fuel Hacker Creativity with Burner Wallets

A deeper look at system design and engaging use cases utilizing blockchain aware devices, xDAI, and the Burner Wallet toolset

Published in

Next Big Thing Tank

7 min readSep 23, 2019

In a recent post, Next Big Thing, AG (NBT) shared how the ETH Berlin zwei hackathon attracted hundreds of attendees and multiple hack submissions. Decentralized Finance (DeFi) played prominently in developers’ minds as they built successful interfaces and created novel business models on DeFi platforms.

In this post, you’ll find a more technical perspective on event learnings.

ETHBerlin zwei hackathon participant using the QR code on the side of the vending machine.

An initial experiment in blockchain-aware IoT devices

Earlier in 2019, for an event organized by the Nike store Berlin, NBT developed a demonstration of a private Ethereum token-based game system. Using a rowing machine interfaced via a Raspberry Pi and Python controller modules, we presented three very challenging time trials (carefully calibrated by our Crossfit colleagues).

Game 1 — row 100 metres in 18 seconds,
Game 2 — row 500 metres in 1:45, and
Game 3 — row 1000 metres in 3:45.

NBT’s rowing machine challenge station set up at Factory Berlin Görlitzer Park during ETHBerlin zwei.

Participants were first guided to download a custom web-app onto their mobile phone. They could then scan their unique address QR-code (an in-browser Web3 new address) before starting a game, with a webcam connected to the Raspberry Pi. By completing one of the games, they got rewarded with an ERC-20 token based on their performance.

Within the web-app, participants could send tokens to our vending machine (polling the ERC-20 Transfer event) to receive their prizes. The vending machine is again controlled by a Raspberry Pi, which interfaces with the vending machine via the MDB protocol to credit the machine and dispense the prizes.

Hackathon participant redeeming rewards from the vending machine.

Design considerations

While still a great proof-of-concept showing the possibility of blockchain-aware devices, the user flow and blockchain elements had some shortcomings in the original Nike version. Since the token is minted by NBT and hosted on a private network, it is essentially a fully centralized, single-use token for the duration of the setup. While this is a great way to encourage people to immediately spend their tokens on the merchandise in the vending machine, it isn’t a great example of a decentralized economy, trustless interaction, nor blockchain use-cases in general.

One of the major issues in the blockchain space is demonstrating truly fit-for-purpose interactions. Could this game operate equally well with a plain old database recording the unique ID of participants on the rowing machine and their scores, which they can send to the vending machine using normal web methods? Secondly, the presence of a custom web-app keyed to a known ABI and contract address to transfer tokens felt like too-specific an implementation.

In other words, why would we need to code our own custom “wallet”? Is there something missing from the current open-source toolsets?

But asking these questions is also just the point. We wanted to push the technology among this group of dedicated participants to test ideas and explore any limitations, in order to generate dialogue in the blockchain space.

A solution for everyone

One of the UI considerations that made sense for the Nike demonstration was that users could conceivably not know, nor need to know, that blockchain technology was behind their interaction. A couple of security flaws (weak client-side private key management, for example) and very tight coupling between the rowing and vending machines were accepted in the original version to focus on this usability.

For ETHBerlin however, to a room full of the most knowledgeable hackers in the space, keen to peek under the hood and see the full architecture, we had to make the solution more blockchain-native.

The challenge became: how can we keep the demonstration and game rewards accessible to the non-crypto-native public, while still having a secure, functioning public blockchain economy to show the engineers?

ETHBerlin Zwei — experiment with xDAI and the burner wallet

After seeing very successful pop-up economies using xDAI at ETHDenver and Ethereal NYC, we re-engineered the rowing and vending machine setup using xDAI and Austin Griffith’s burner wallet.

The revamp was driven by a burner wallet “Links” plugin that allows an owner to send assets (in this case, the native xDAI token on the xDAI POA chain) to a “Links” smart contract, while only allowing a single claimant (who can prove ownership / signatory of a predetermined random hash). Check out this article by John Grant for a more detailed look at how this works.

This solves a big issue with Dapp and blockchain experience — having a user who already has a wallet with funds in it so they can claim their tokens or interact with a pop-up demonstration. In web terms — the “call to action” is no longer behind layers of setup, and the user can simply jump on the rowing machine and row! If they win (and the games were fairly challenging), they can follow a Links URL briefly shown on a display as a QR code.

Secondly, it decouples the (IoT) machines from each other and enables them to be independent actors. This way, we can extend the setup to X rowing and Y vending machines which all act autonomously. Here’s a look at our architecture for ETH Berlin:

NBT’s architecture for the ETHBerlin zwei Hackathon

Code for our serverless API exposing xDAI Links creation can be viewed here.

The upgraded flow now looks like this:

User starts a game using the Raspberry Pi hardware module on the rowing machine. User completes game successfully. The rowing machine module POSTs to a private API endpoint the results of the game.
If the game result is a win, this sends the xDAI reward to the Links smart contract, the URL result of which is displayed on the rowing machine tablet display.
User scans the link and follows the URL to their new burner wallet, which claims the reward from the Links contract. Because the user (unless it is a second successful attempt of the game) will have no gas with which to claim from the contract, the burner wallet utilizes the Gas Station Network of relays to pay for this transaction. Gasless transactions are an essential part of this onboarding, and can be read about in more detail on EIP-1613.
User scans QR code fixed to the vending machine and sends the xDAI from their in-browser burner wallet to this address.
Vending machine is listening for balance updates to its funding address, using regular Web3 methods, and credits its internal balance, and a normal vending machine flow takes over.

Criticisms and further considerations

The burner wallet, and xDAI in general, does a great job of bootstrapping participation, but our implementation was far from perfect. We decided to abstract the Links contract interaction to a Lambda function, safely quarantined on a cloud server that responds to instructions to “create a Link with 50 xDAI in it” from the rowing machines, instead of transacting on-chain directly via the rowing machines themselves.

This was a security implementation at the expense of a blockchain-only solution. Since there was a centralized part of the game — NBT was the “bank” funding the xDAI that was given to players who beat the game — we needed to have xDAI somewhere, from which we could create Links transactions. We didn’t really want any private keys (or physically attached hardware wallets) bundled in a small Raspberry Pi, attached to the side of the machine with thousands of xDAI in it. We trust ETHBerlin hackers, but it was a big week and we needed sleep at some time!

So, a simple serverless API was configured, which performs the Web3 operations to interact with the Links contract, and hides the private key funding the xDAI (injected as an AWS managed secret). Depending on the application, it may be an architectural feature — not a bug — to have this model, especially if we have N blockchain-aware machines in the field where physical access is always possible by unknown parties. While full decentralization is not always the goal of any commercial enterprise (a fleet of vending machines at a gym chain, for example) a future blockchain-only solution could perhaps utilize the relay contract concept for the funding “vault”. This would remove the need for centralized services which store the created links for transmission to the recipient.

Ideally, we wanted to display the reward link on the rowing machine LCD output as an ephemeral QR code — you either scan it or it’s gone — but this wasn’t really feasible in the time allotted without rewriting the LCD firmware, (and there may be contrast issues with an old-school LCD). The secondary tablet to display the QR code (for 30 seconds only) was a stand-in for this. No one is ever truly comfortable with private keys being transferred electronically (it is part of the link URL), even with TLS, but this idea is baked into the “burner” concept itself. Give a user their link, they claim it, spend it, and burn the private key or transfer any change to a more secure wallet.

In sum, we look forward to future hackathons as high-level playgrounds for new ideas, in the company of fellow builders who want to solve problems! If interested in joining in future events, just sign up for the NBT newsletter.