project screenshot 1
project screenshot 2
project screenshot 3

Bonfire Wallet

Bonfire Wallet is a passwordless burner wallet that leverages WebAuthen to onboard the next 1 million crypto users, with biometrics or a token for authentication, making it accesible to anyone entering the crypto ecosystem.

Bonfire Wallet

Created At

ETHGlobal Waterloo

Winner of

trophy

🥇 Risc Zero — Best Use of Bonsai

trophy

💬 Risc Zero — Best Feedback

Project Description

The Bonfire Wallet is a simple web application that allows users to create a burner wallet using WebAuthn. This means a fingerprint (biometrics), or a token such as a yubikey can be used for wallet creation. There is no seed or private key for the user to store, they can just authenticate through the same way after creating the wallet.

The wallet is built on RISC-Zero, which makes it possible to offload the heavy computation, instead of doing this on chain. The computation in this case is the verification of the signature that WebAuthn provides after authenticating. RISC-Zero makes this possible through their general purpose zero-knowledge VM, which is leverageble at the moment through their Bonsai proving service.

There are 2 main parts to the application: the (frontend) web wallet and the Solidity contract that offloads computation to the Bonsai proving service.

Frontend In the frontend WebAuthn is integrated in 2 ways: upon wallet creation the user is asked to register through WebAuthn in the browser (the browser must support this). The user can choose this to be for example fingerprint, a physical token such as a yubikey or a bluetooth connected device. WebAuthn will generate a public key for the user and is used int he Bonfire Wallet to instantiate the burner wallet. The second part where WebAuthn comes into play is when the user wants to send funds to another wallet: this will be authorized using WebAuthn authentication. The user is asked to authenticate in the same way that they registered and this will generate a signature through with WebAuthn. WebAuthn uses p256 which is specifially secp256r1 (not to be confused with secp256k1 of Bitcoin).

Smart Contract The other main part of the application is the smart contract that is deployed for each new burner wallet. The smart contract contains the public key that uniquely identifies the burner wallet and is generated through WebAuthn. Apart from construction there is one other main functionality of the smart contract: verify-and-send. This receives a WebAuthn signature that has to be verified in order to execute the transaction. Verification of the signature is computationally heavy, therefore this is offloaded to the Bonsai proving service. To leverage Bonsai, a zkVM guest program is written in Rust that does verification of the p256 signature. A proof of execution is generated and returned to the smart contract.

Wallet usage A user can easily create a new burner wallet following the instructions from WebAuthn. After a public key has been generated through WebAuth, MetaMask is needed to deploy the smart contract that instantiates the burner wallet. When successful, the user is provided with an address and can receive and send funds. When funds are sent by the user, authentication through WebAuthn is needed and requested in the same way as for registration. Again, MetaMask will be needed to confirm the transaction.

Future With ERC4337 MetaMask could be eliminated from the current flow of the wallet. A user wouldn’t need to already have a wallet to create a burner wallet, which would make it much more accessible. Also, if another standardized WebAuthn-like scheme is presented that uses a different signature scheme, this could be easily adopted, because any heavy computation can be offloaded using RISC-Zero.

How it's Made

The Bonfire wallet uses WebAuthn in the frontend, a smart contract in Solidity and Bonsai (RISC-Zero) for offloading verification computation.

WebAuthn uses p256 (secp256kr1) to generate public keys and signatures, without having private keys to manage on the user-side. Users can authenticate using biometrics (fingerprint), a token or a bluetooth device. This removes the need for them to store a password or any other secret data such as a seed. WebAuthn is built-in for browsers such as Chrome and Brave.

The RISC-Zero VM allows for heavy computation off-chain, which is needed in this type of project, since verification of a signature is heavy and something that should be prevented to be done on-chain. Using the Bonsai proving service, we are able to write a guest program in Rust that performs verification. The Solidity contract offloads the computation to this program and gets a callback after the computation was executed and proven.

Main Functionalities of Bonfire Wallet

Burner wallet creation The user generates a burner wallet using WebAuthn; when clicking on Create Bonfire wallet, WebAuthn is triggered in the browser and asks the user to register. This can be done with a fingerprint (biometrics), a physical token such as yubikey or a Bluetooth connected device. WebAuthn returns a public key. Note: there is NO secret key to manage on the userside. WebAuthn generates the public key and is able to generate valid signatures using the authentication method of the user. With the public key, a new smart contract is deployed that has the public key hardcoded. The address of this smart contract is the Burner Wallet address.

Send funds Upon sending funds, WebAuthn authentication is triggered and the user is asked to authenticate in the same way as during wallet creation. When this is done successfully, WebAuthn returns a secp256k1 signature. This is sent to the smart contract, which in turn offloads the computation to the Rust guest program. This is where the signature gets verified. Through the callback, the smart contract is alerted that verification was successful and the transfer of funds can be completed. Very hacky The main challenge is to connect this all (frontend and smart contract) and run it locally. To achieve this, RISC-Zero created a separate branch (https://github.com/risc0/bonsai-foundry-template/pull/16) that exposed a local relayer that needs to be deployed in addition to our own smart contract. There were no examples of how to get this to work and achieving this has been the main focus during the hackathon.

background image mobile

Join the mailing list

Get the latest news and updates