You know how a regular road movie begins, don’t you? Someone comes up with a hot adventure idea, his friends buy into it … And it all takes off. It was the same story for us. In November, Michael and Yao from Japan shared a crypto wallet concept with Purrweb. By that time, we had created an app for Broex and redesigned the PayPay wallet. So we gained insight into both the crypto and the wallets. That is why Purrweb was an obvious choice for such a project.
A good crypto wallet: key features and a bit more.
We headed for a functioning app that would enable users to:
- store cryptocurrencies and NFT tokens,
- receive and transfer cryptocurrencies,
- check the balance,
- view the transaction history.
The clients asked to make an MVP that allows users to delete NFTs and import tokens from auctions manually. We suggested leaving this for later, as the basic functions are far more important. Extra features would entail longer development and higher cost. The clients agreed.
As a result, we met the deadline and added the extra features during the testing.
Michael and Yao weren’t going to monetize the app: no ads, no paid goodies, and no transfer fees. Users pay only the net commission for miners. We still puzzle over the mystery of this generosity.
This crypto wallet is just a part of a major project. The clients wish to create an e-learning platform that would teach how to manage cryptocurrency. Perhaps, the platform will generate the profit. Besides, the MVP’s aim is to attract an audience and we can add monetization later.
Flow: the beaten path
Users go through the same stages with all the crypto wallets.
- A user creates a wallet, gets its address, and creates a password. Now two transaction encryption keys are stored on the device.
- Gets a seed phrase — a series of words that helps restore access to the wallet if the user forgets the login details.
- Goes to the main screen and views the balance.
- Sends tokens and views the balance again.
We built a special team of 5 people for this project. It included a project manager, a designer, 2 developers, and a tester. The clients helped us with the technical details and checked the design we made.
No need to reinvent Metamask
We were free to make the design our way. The first stage was to figure out the no-goes: the color schemes and other design elements the clients rejected.
Negative references from the clients. They disliked the colors
We took into account the positive references as well. For example, Michael and Yao wanted an app that looked like Metamask. Its design is very simple and austere. Besides, we drew inspiration from a few Dribbble shots.
We met the expectations, so the clients approved the mind map and wireframes in no time: it took 2 and 7 hours, respectively. As a rule, we allocate 8-10 hours for a mind map and 20 hours for a wireframe. We cut a lot of time and progressed to the goal.
Final app wireframes
Colors and personality
We checked out similar apps for the best typeface and picked Outfit, as it met all the project requirements.
Optimal font width. Figures are the primary objects in an e-wallet. Outfit’s width enables long strings of numbers to fit into the screen.
That’s how the app displays the Ethereum balance
Readability. It’s a part of UX. Even if a crypto wallet doesn’t need multiple lines of text. On top of that, the variety of Outfit fonts helps organize information.
We used different fonts for the balance, cryptocurrency name, and transaction date.
Originality. Outfit is not yet popular among e-wallets, so it looks fresh.
The clients wanted a clear and stylish design, so they asked for a light color scheme. Bright colors and an abundance of details would make the app gaudy. So, we used white, grey, and blue, as they give a sense of purity and lightness. Then we added sand, red, and green accents.
The app’s color scheme
A new participant at the last design stage: came just a bit later
At this point, the clients’ designer joined the process. He watched mostly — the Purrweb team created the whole design. The newcomer reviewed the Figma mockups and gave feedback. He commented on such details as the rounding of corners or the colors of some elements. The clients liked what we did, so he didn’t ask for any fundamental changes.
Sometimes the changes would hurt the app. In such cases, we showed the clients’ designer what’s best for the clients and a user.
We accepted some changes and provided reasons when rejecting the others. For example, we agreed that a bolder font is better for a token fiat balance, as it is a more vital figure. But we convinced him that here a tab bar is better than hamburger navigation, as a user would need to switch between the sections that the clients wanted to add later.
Tab bar navigation (the left screen) vs. hamburger navigation (the right screen)
This app is a part of an e-learning project, and it will include game elements later. It was not our task to develop and implement the game mechanics here. Still, we made a modern design with bright accents to meet the future needs. We decorated the balance widget with a soft blue gradient combined with an unusual geometric element and used bright colored crypto icons.
A user’s balance
Cryptocurrency icons
User safety is above all
The clients were clear about safety — the user data must be protected to the fullest possible extent. Only decentralized apps can provide such a safety level. So, anonymous servers are out of the question here — all the data must be stored on the user’s device. No backend for this app. So, all the functions must be device-based, and the data must be collected from the nodes (with the help of API). It’s the only way to guarantee users’ anonymity.
We knew that there were a whole bunch of crypto wallets without a backend, so we set to work. Spoiler: integrating API turned out to be a tricky task.
he crypto wallet audience cares about their anonymity. We preserve it if we make no backend, as the third-party APIs deal only with the wallet address. The owner and the device are anonymous.
How we racked our brains and made a free backend
When we looked into the third-party API issue, we realized that a free and functioning backend could save the client’s money. We needed only to puzzle out how to unite a few free APIs, so that an extra request per second or an extra user per month wouldn’t affect the app.
The thing is that free APIs have request limits, like 1,000 transaction requests per minute. The 1001 user is going to see an error. We needed to find an efficient API combination for each function. It’s just like drawing a line to the correct answer.
What we did:
First, we selected an individual API service for each task. So, we got a multifunctional API set:
- Etherscan.io — to view the details on tokens and coin balance (the app switches to infura.io once the limit is reached).
- Cryptocompare.com — to view the token and ethereum costs in various currencies.
- Opensea.io — to view the NFT tokens data.
- Moralis.io — to view the transaction history.
Initially, we chose Etherscan for the transaction history and the token details. If a user requests the transaction history for one wallet, the service returns hashes — long and unique sets of numbers. The system sends one more request to the API to get more details on one hash (the status, the sum, and the transaction time). This is a very complicated process. Besides, etherscan accepts 5 requests per second, tops, so the app would display errors often. That is why we integrated the Moralis API. It requires one request only, and the limit is higher: 25 requests per second.
Then we puzzled over the best way to integrate the API services. Let’s take the cryptocompare.
As a rule, the cryptocompare service is used along with a special user ID — an API-key. It’s available in the personal account after registration. A user can select a price rate there too. Cryptocompare accepts 100,000 per month for free.
1 user = 1 request. The 100,001st user will see an error instead of token cost.
That is why we rejected API-keys. Now the system counts the number of requests from one device, not the number of users. The request limit decreased to 50,000 per month, but it’s more than enough for one user.
As a result, the system doesn’t return errors caused by request limits. An endless amount of users can learn the token cost.
Ditching the backend led to a few captivating challenges. We had to keep in mind that all the data must be stored in the smartphone: no data bases, no big data sorting and concatenation. The requests to the third-party APIs were the most awful headache, but we cracked this riddle.
What’s next for the project?
The final app looks like this
At the end of April, we sent the Android app file to the clients. Michael and Yao haven’t uploaded the app to the App Store and Google Play yet, as they want to show it to their investors first. For presentations, we created a special Test Fight version.
All in all it took us 1268 hours to deal with the project: 59 hours for design, 327 hours for testing, and all the rest — for development.
