This is going to be an in-depth guide on how to build an Ethereum dApp that fully utilizes the functionality of Snowflake. I will cover both the backend (Solidity) and the frontend (React).

Getting Started

To follow along with this guide you are going to need a few things:

I would recommend that you have at least some experience building dApps with Solidity. A general knowledge of React (I just learned it last month. Knowing Javascript should be fine if you are good at learning on the fly). A Github account.

To get a working proof of concept for a dApp is really going to depend on how complicated your application is and the scope of what you are doing in the app. For a basic dApp, all of this can certainly be done in a days work.

You will also need to acquire Rinkeby Testnet Ether and Hydro.

To acquire Testnet Ether, follow the steps in this StackExchange answer:

To acquire Testnet Hydro, connect your Rinkeby account from MetaMask on this page:

and “write” the getMoreTokens function, which is a function on the Rinkeby version of the HYDRO token contract that creates 10,000 HYDRO and pulls it into your wallet.

Smart Contract

Snowflake, is currently live on Rinkeby and allows for developers to leverage a few key features that we feel really help the development process. Some of these key features are:

Multiple addresses linked to an account

Easy access to integrating token economics into any dApp

User sign up and account deletion

Access to a dApp store for all Snowflake users for visibility

In order to leverage these capabilities it is important that all smart contracts inherit the Snowflake Resolver contract. This contract implements all of the required functionality that is needed to be a resolver. Here is a basic contract which is implementing the Snowflake Resolver contract and utilizing some of its logic.

Lets take a look at whats going on here:

Line 12: Setting this variable to true tells the Snowflake contract that we have custom sign up logic.

tells the Snowflake contract that we have custom sign up logic. Lines 22 & 44: Here we have the onSignUp function. This function is called automatically when a Snowflake user sets your dApp. For each dApp this logic will need to be custom based on the needs of the dApp. In our example, we are just taking the HydroID that is passed to us and checking if they are already a member. If they are, then they can’t sign up again. If they aren’t we add them as a member.

Here is an example of an onSignUp function which is also utilizing the Hydro allowance to charge users a fee:

The sign up is attempting to withdraw the signUpFee variable from the users Snowflake balance. If this is not successful, the user cannot use the dApp. This withdraw functionality can be used all throughout your dApp. As long as the user has set an allowance for your dApp in their Snowflake they will be able to easily transfer you Hydro and you won’t have to ever worry about calling approveAndCall again!!