We applied for a grant: These were the results

Published in

Pink Wall

9 min readSep 27, 2022

A grant is usually a financial award from one entity (typically a company, foundation, or government) to an individual or a company to facilitate a goal or incentivise performance.

That said, we chose the Using NFT Express, Create A Mobile App That Allows Users To Mint NFTs On Celo grant.

This grant proposed the development of a mobile app using NFT Express to mint NFTs in the Celo blockchain. The bounty owners would give extra credit to “clean, organised and high-quality code”, creativity and attention to design. The app and the contracts were not required to be audited or production ready.

NFT Express is a Javascript SDK, provided by Tatum, that easily allows you to mint NFTs in multiple chains, without paying gas fees or having to code smart contracts. Instead, they have free and paid tiers. The free tier mints an NFT in the default Tatum contract, and the paid tiers allow, among other functionalities, to deploy an ERC-721 standard smart contract to use exclusively.

This grant seemed just what we were looking for.

What we envision

Before continuing, we should mention that the grant submission timeline was two weeks. We had to think of the use cases, investigate the mandatory tech stack and develop a final product in this tight time frame.

So, what did we try to build?

For this grant, we created an NFT marketplace for dance moves.

In the app, the users can submit a video of their dance moves and mint an NFT from it. Let’s call this the “dance” NFT.

Other users could then pay royalties to be able to use this dance move anywhere. This payment would mint a different NFT, paying a fee to the original creator of the dance move and proving that the user can use it in their content. We called this the “dance usage” NFT.

Let’s sketch a solution!

In terms of navigation, the app consists of 5 main screens:

Authentication: Where a simple button would allow the user to authenticate using a Celo wallet;
Create Dance: A screen consisting of a form where the user can enter the dance details and mint a new “dance” NFT;
NFT Marketplace: Where the existing dance NFTs would be listed. Upon selection by the user, a pop-up would be shown where the user could mint the “dance usage” NFT;
NFT Details page: Where the user can see the details from the NFT and watch the full dance video;
Profile: User details and owned NFTs listing.

Here are some of the sketches we made just to clarify some ideas:

Approaches

We used the following technologies:

React Native, with Typescript, for the mobile DApp, using rn-nodeify to allow the usage of core node package in React Native apps;
Tatum’s NFT Express for the deployment and communication with the Celo blockchain;
IPFS Mini to make the calls to the IPFS network;
@walletconnect/react-native-dapp for the authentication process;

After investigating the existing NFT standards and how they could help us with our problem, we concluded that deploying and using two different standards would be our best option.

For the “dance” NFT, using the ERC-721 standard would be the most appropriate. This is the default NFT standard, where the user is granted ownership of a specific token, which is unique. It aligns well with our idea since each dance is different and unique, and we should only assign the NFT ownership to a single individual or entity.

For the “dance usage” NFT, we idealised the usage of the ERC-1155 standard. This NFT is expected to grant usage rights of a dance (defined by the ERC-721 NFT previously stated) to a given user or entity, but without necessarily stating any difference between “usage” NFTs from the same dance. The ERC-1155 specification, the Multi-Token NFT standard, makes this the perfect choice for this use case, as we can issue as many tokens associated with the same dance as we want.

The “dance” NFT would be minted with the following metadata, through user input:

Name: The name of the dance to be minted;
Description: A small description of the dance NFT;
Video: A IPFS hash of the video containing the dance to be registered in the NFT.

The video selected by the user is firstly uploaded to IPFS, and a hash of that video is returned. It’s that hash that is used in the NFT metadata field.

All this metadata is then compiled into a JSON Object and hashed to an IPFS address. This hash would then be added to the metadata parameter of the NFT.

The “dance usage” NFT only requires the id of the “dance” NFT to be minted. This id would be attached to the NFT’s metadata, identifying which “dance” NFT relates to which “dance usage” NFT.

Tatum’s SDK provides all the methods to perform the required tasks: deploy contracts, mint a NFT and list NFTs.

To authenticate a user’s wallet, we used WalletConnect’s SDK. We have previously used this SDK, and you can see how it works in this blogpost about the development of our first Web3 DApp.

Given the time and resource constraints, we saw this as an achievable plan. Nevertheless, we hit some unexpected issues and drawbacks that prevented us from implementing some of the features, as we will explain next.

Final Product

The first version of this app was implemented and submitted to Gitcoin’s grant. You can find this version in the main branch of this repo. This first version does not implement the “dance usage” NFT and implements a library that has stopped working a few days after submission. These issues and some updates, done to the app after the submission date, are covered in the next section and are available in the main-post-grant branch.

Significant changes and drawbacks in the solution

During the implementation, we faced unexpected hiccups in using some of the selected technologies.

Firstly, with Tatum.

As we previously said, we needed a paid plan to mint NFTs on our smart contract. We could apply for a 3-month free Basic plan on the grant description page. Cool!

Even though we applied for it, until this day, we never received an answer. We were determined to use this feature, so we bought the Starter plan for 7$ per month. Although we made the purchase, our key was inactive all the time and couldn’t be used, even after talking with customer service.

Without the paid plan, we could not implement the DApp as initially planned.

Using the free tier of Tatum to mint NFTs meant that alongside the NFTs minted in our app, the contract would also have the NFTs minted by everyone else that used the free version of Tatum. We could not afford to verify if the metadata of each NFT from Tatum’s default contract had our metadata inside a mobile app, since this would significantly increase the requests to Tatum APIs and computing power, rendering the app unusable.

To tackle this, we researched tools that would allow us to filter the NFTs that weren’t of interest from Tatum’s API query. One of the tools was The Graph (GRT), an indexing protocol to query blockchain data using GraphQL.

This tool was powerful but not useful for our specific issue, as we would still have to query and verify every NFT metadata’s content from the IPFS network just to check if this was an NFT created by our app.

The lack of a solution to this problem meant that we could not find a way to make a pretty important feature: the NFT Marketplace.

We feel this feature was one of the core experiences of the app. But, since we’ve lost some time with this, and the deadline was quickly approaching, we decided to drop the implementation of the “dance usage” NFT. Without this feature, we still covered what was requested in the grant. Although, we felt that exploring the custom contracts from Tatum was a great thing to add to our experience.

The second drawback we faced happened after we submitted the project to Gitcoin. Some time after the deadline, the ipfs-mini library stopped working. A Github issue was opened but no solution was found. Maintaining the Pink Room spirit, we found this as an opportunity to explore other IPFS solutions. To surpass this, we found some libraries.

Pinata is a pinning service that allows users to host files on the IPFS network. We implemented a working version of the app with Pinata’s, but the free tier was too slow for what we expected. A dance move video took about 10 minutes to download, which made the app unusable.

We strived to find yet another solution to this problem, preferably free-to-use. We were then able to find a Javascript implementation of the ipfs-https-client library.
Getting this one to work was tricky, though. Besides the rn-nodeify library already being used in the project, to patch core node libraries to React Native, an extra library had to be used: patch-package. We used it to patch specific bits of code inside some of the used libraries.

The patching was required for the ipfs-https-client and react-native-polyfill-globals, a peer dependency of the project.

Another problem we faced during the implementation was dealing with Tatum JS SDK and REST API. Tatum JS offers an SDK for React, but to use it, the API KEY must be available in a `process.env.TATUM_API_KEY` variable. Though we tested a lot of .env libraries for React Native, we couldn’t make this work. It is straightforward in React but not in React Native. To overcome this, we communicated with Tatum JS using their REST API.
This API provided the endpoints to perform the required features, without much complexity. We used endpoints such as

https://api-eu1.tatum.io/v3/nft/collection/celo/<address>

To list all NFTs within a given contract,

https://api-eu1.tatum.io/v3/nft/address/balance/celo/<accountAddress>

to list all NFTs from a given wallet or

https://api-eu1.tatum.io/v3/nft/mint/

to mint a new NFT.

This proved enough for all the features we defined for this project.

So far, so good, but some API methods were not stable, and sometimes they worked, and others didn’t. Stable and tested code just stopped working one day after, which made us lose a lot of precious time.

Conclusions

After the dust settled, we were able to pinpoint some key conclusions:

This project, and grants in general, are really helpful in getting to know the state of the web3 development tools for mobile, more specifically for React Native.
The primary tool to be used, Tatum, proved to help develop NFT solutions, but also revealed some issues and disadvantages, especially when using the free plan. After this experience, we probably wouldn’t use it for a client project.
Some other new tools were discovered and/or tested in a real use case, such as WalletConnect, The Graph and several solutions for communicating with the IPFS network. The Graph seemed really powerful and we’re looking forward to having more opportunities to use it.
The world of web3 development tools in React Native is still in development and needs a continuing effort from the developer landscape to make it more powerful and usable.

Like previously said, this project was great for researching the current tools for mobile web3 development and a positive experience for us, as developers, and for Pink Room in general.

But sadly, we must conclude with a negative comment: At the time of writing this, roughly 2 months after the grant delivery date conclusion, the bounty announced by the grant owners hasn’t been rewarded to anyone who submitted work. There hasn’t been any message from the owners which doesn’t fit with gitcoin’s philosophy. So even though it doesn’t affect us monetarily, we feel slightly disappointed.