What does Clay.one do? — We’re a team which strives to solve the user-side conundrums of Blockchain through cryptocurrency wallets. But then, what are the conundrums?
My name is Kain, and I work at a team called Clay.one. For a long time, I’ve worked as an IT service Product Manager and entrepreneur. Now, I formulate strategies on not only company products but also overall, long-term targets such as business and vision.
Our service Clay aims to be a cryptocurrency multi-function wallet and dApp platform. Put simply, wherever your coins are, whatever you plan to do with them, we want you to be able to manage it on one platform.
We’ve already launched our iOS/Android mobile app. It provides an all-in-one experience for blockchains such as Ethereum and Ontology, and also incorporates exchange wallets from vendors such as Binance, Bittrex, and HitBTC.
*Note: In this article, we’ll refrain from using stricter classifications and call all applications utilizing blockchain and/or cryptocurrencies ‘blockchain services’ or ‘dAPPs’.
Who uses Blockchain?
A lot of people talk about Blockchain, but their motives and inspirations seldom align. We all talk of the ‘technology’ and ‘price’ of tomorrow, but our team lives in the present, laughing and crying at the events of today.
We picture the ‘users’ of the present, and then contemplate how they would use blockchain services. However, it seems as though such discourse lacks in this market. People simply disregard these real problems, and pass it off as something that will somehow be fixed within the year.
What needs to happen before blockchain and/or cryptocurrencies can be popularized? To put things into perspective, we can observe parallels between early age Internet and blockchain technology. Blockchains are protocols like TCP/IP or WWW, crypto wallets are web browsers which display data within the protocols in a user-friendly manner, and dApps are various web services/apps based on the Internet.
Basically, we need to prepare: 1) A protocol/network system which can facilitate fast and stable communication of data (i.e., blockchain), 2) An interface which can display data within decentralized nodes in a user-friendly manner (i.e., crypto wallets), and 3) Applications which utilize this technology to meet user needs and create value (i.e., dApps).
All at once.
If our vision of blockchain technology were limited to B2B usage through private blockchains, the market would have garnered much less hype than it has today. That being said blockchain and cryptocurrencies must achieve mass adoption, and for this we need to overcome the severe “non-intuitiveness” intrinsic to blockchain.
But then, is it at all possible for my grandmother, a 19-year old technophobic college student, or your 10-year old nephew to use any of the numerous blockchain services currently on the market? How many ideologies and/or concepts do they have to be familiar with before they can even start? How long does this take? (I’ve personally tried multiple times to explain ‘Bitcoin’ to the layman. I’ve never been able to finish within 20 minutes.)
There is no doubt that Bitcoin and its decentralized ledger blockchain are both inventions never-beforeseen in human history. After all, it is our first implementation of a value storage/transferral system which does not require a central entity. But blockchain, due to various reasons (engineering efficiency and/or nonchalance?), is very unfriendly for the user.
I’ve labelled and categorized this lack in intuitiveness into “the 7 deadly sins of blockchain UX”.
Not to say that someone explicitly made a mistake, but as humans have shown over the years, our inventions are mostly works in progress. Blockchain just happened to have these characteristics, and we have to constantly put in effort to overcome these hurdles; hence the naming.
UX is everything, idiots
People in the blockchain industry often take UX lightly. A lot of them seem to think that with technology, user experience is bound to be solved at some point. I’m not saying this is false. Of course at some point, a solution will arise one way or another. The problem is that most teams envision and guarantee mass adoption without putting in the time and effort necessary for the development of a proper user experience.
UX issues will actually take a lot more time and will require much more effort until they are solved. At least, for projects that aim to do something on preexisting blockchains.
UX(User Experience) is a much larger technological obstacle than we give it credit for, and brings about larger innovations than we think. Think of examples like the invention of the mouse; the difference between DOS and Windows; and pre-iPhone “smartphones” vs. the iPhone. I’ll just leave it at that.
In this article, I’ll mainly point out exactly why blockchain is so non-intuitive, and provide some alternatives that may alleviate this problem. Blockchain right now is like the Internet before it had browsers. It’s… basically unusable for most of us.
Decentralization be damned, the sins below are all UX-related technological hurdles, and they all need to be surpassed before we can even dream of mass adoption. Some of these hurdles we can simply remove, while others, well, for them, all we can do is hope someone jumps over them somehow.
- Key management — Backup, storage, and maintenance
- Asset purchase — Purchase methods, exchanging between assets
- Transfer experience — Address, the concept of Gas, transaction time, payment-asset volatility
- Token management — Token balance, adding custom tokens, token/fee mismatch, spam tokens
- Platform/Protocol fragmentation — asset storage, blockchain concepts, using services/dApps
- Decentralization — vs. centralization, the dilemma between non-intuitiveness and security
- Regulation issues — KYC, cashable dApps, …
Anyone who uses blockchain services for the first time experiences these ‘7 deadly sins’ ‘all at once’, and have to find their own methods of overcoming them.
I’m going to try to explain each of these sins in detail, which is going to take a long… time. Please help me by searching for and downloading the “Clay” app from the Appstore. Think of it as an acknowledgement of my devotion to this article. Please.
1. Key management
Blockchain accounts use Public/Private Keys similar to how we use the ID/PW combination in traditional networks. While they aren’t equivalent concepts, and are actually quite different, the reason I use this comparison is because 1) the use cases are roughly similar, and 2) if I just stick to academic, strict definitions, I’d be throwing out any possibility of helping the general public comprehend this obscure cryptographic concept.
Users acquire personal accounts on the blockchain using private keys. We can store cryptocurrency assets within these accounts. Because private keys take the role of passwords, the public key functions as a sort of address, or ID.
The reason we use public and private keys to distinguish between users is probably because it’s an authentication system that has been proven to be safe over and over again in the case of digital currencies. However, while traditional networks make it easier for the user by augmenting this system with the more intuitive ID/PW combination, blockchain uses the never-before-seen and unfamiliar method of directly asking the users to handle their public/private keys.
A simple centralized ID/PW issuance system which stores the private keys within those accounts can serve to alleviate the shortcomings listed below. However, since centralization isn’t much of an option right now (I’ll go into more detail on this at 6. Decentralization — vs. centralization) we do have to use decentralized wallets, that is, a system in which we issue private keys to each user individually. Now that we’ve established this, let’s talk about the hurdles users face when using such a system.
1.1. Backup
Although it’s cumbersome, we all backup our wallets because most cryptocurrency wallets require us to do so.
Recently, wallets often use 12-word mnemonics which correspond to the private keys instead of using the private keys directly. Why? Because it’s easier than writing down the private keys. (duh)
In the case of decentralized wallet services, one of the main goals is to refrain from storing users’ private key data in centralized servers (since this increases security risk, e.g., external hacks, internal breaches — again, for more details, refer to 6. Decentralization — vs. centralization). Therefore, the burden of data storage is shifted from centralized entities to the individual.
When you use these wallet services, most of the time, your private key data is encrypted and stored in the location of the wallet program. That is, for web wallets like MEW, private key data is stored in your hard drive. For hardware wallets like Ledger, it’s stored in the hardware itself, and for mobile wallets like Clay, it’s stored in your mobile device storage.
Problem is, data stored in this manner is extremely susceptible to physical impairment. What if the keystore file stored in your hard disk is infected by malware? What if you lose your Ledger device? What if you lose your phone, or accidentally erase the wallet app? Instantly, all of your crypto assets would become inaccessible. Then, what alternative methods of key storage can we provide?
- Usually : Advise users to backup the 12-word mnemonic. Make sure users store it somewhere else like on a piece of paper. Some services make a stronger case for this by restricting screenshots on the backup screen (Think: screenshots are often lost with the device). Personally, I copy my private keys to a TXT file, encrypt it, and then store it in multiple locations. (Sometimes, I also use services like 1Password)
- Centralization : Just create a DB in the company server, store private keys there, and make users access their wallets using an ID/PW combination. It’s simple, and it works. The largest wallet services there are — like Coinbase or Blockchain.com — use this method, and cryptocurrency exchanges also have similar deposit/withdrawal wallet systems. However, using this method leads to the whole new problem of guaranteeing security. Once a crypto wallet private key is stolen, there is nothing anyone can do.
1.2. Storage
Now arises the question of where, and how to store your mnemonics and/or private keys. For a service to fetch the user’s balance, and to receive and send cryptocurrencies, the private key has to be within reach at all times. At the same time, it must stay safe even in the most dire of circumstances.
- Device storage : Most decentralized services encrypt the private key using the user’s password (we call this a keystore), and then store it within the user’s device. This way, a service provider can provide their services in comfort, without worrying about security threats. If a centralized server is hacked, every user’s assets are at risk, but if keys are stored only within the user’s devices, even in the worst case scenario, where someone is hacked, only the individual’s assets are at risk.
- Keystore issue : Another issue that arises here is how strictly we’re going to encrypt the keystore file. Since there is no such thing as a perfect security measure, assuming the worst, individual users’ keystore files are not that hard to hijack. (Especially in the case of PCs, Android phones, and jailbroken iOS phones) In this case, a hacker can easily brute-force (this means to try every combination of every letter that can appear in the password using a computer) their way into the keystore file, thereby acquiring the user’s private keys.
Most centralized services impose time restrictions or even better freeze the account when the wrong password is input multiple times, but keystore files are not made that way. Anyone can try any number of times until they get it right.
Taking this into account, a password that can really be considered “safe” is one that a) mixes upper/lowercase letters, digits, and special characters, and b) is at least 11 characters long. But then, this degrades usability. (Think of a situation where you have to input an irregular, complicated 12-character password every time you send a transaction. Now think again, because this isn’t your once a day bank transaction. In dApps, you have a lot more transactions to send. 🤮 )
In the case of mobile wallets, we can put the keystore file somewhere externally unreachable (e.g., Apple’s Secure Enclave), use a 4~6 digit PIN number for the password, and then let the user replace the PIN with biometric security (e.g., facial/fingerprint recognition). On a side note, mobile operating systems do not provide fixed values for facial/fingerprint recognition, so it’s impossible to directly encrypt keys using biometric data.
- Using dedicated hardware : This is what we mostly mean by ‘cold wallets’. In this case, we put the private key inside of a piece of hardware that is engineered to manage keys (called a HSM — Hardware Security Machine), and only allow this device to know the exact contents of the private key. Some B2C examples of this are hardware wallets such as Ledger or Trezor. In this case, the user can never actually see the private key, and assets are transferred only through the hardware device.
A lot of B2B companies which provide wallets also support this method. These firms purchase millions of dollars worth of huge HSM equipments, and provide multi-sig wallet services or custody services for large institutions. (The largest customers here are exchanges)
- Server storage (centralization) : Again, centralization makes everything easy. To go into a little bit more detail, there are largely two methods of doing this — one, issuing separate keystores and/or private keys for each individual user, and then storing it on a server (a lot of dApps use this method when providing their own wallets), and two, storing all user assets in a number of company-owned private key accounts, and then managing individual assets through the more traditional written ledger method. (Most exchange wallets use this method)
- Even regarding server storage, there is an issue of deciding whether to keep data within the service provider’s own server, or utilize external wallet providers. This is basically a decision between: using proprietary physical servers and HSM equipment; storing on cloud servers like AWS; and using solutions from external wallet providers like BitGo.
- For instance, BitGo provides a multi-sig B2B wallet solution in which at least two out of the three stakeholders — BitGo, the operating entity, and the user — need to concur for a transaction to be approved. This prevents asset loss in cases such as: a) when a specific individual needs to be banned from sending transactions, b) when the operating entity has been hacked, and c) when BitGo itself has been hacked. While these security benefits do exist, BitGo’s solution has a high remittance fee (larger than 0.01ETH), and the entire wallet has to depend upon BitGo, which leads to low expansibility. Basically, this method is inadvisable for dApp platforms which have to send numerous blockchain transactions, and it’s the perfect fit for exchanges.
- If you’re storing data/funds directly in a management firm’s server, you have to meticulously check its safety. Numerous security solutions which prevent hacks, and managerial protocols which deter insiders from hijacking user funds (regardless of intent or purpse) must be implemented. However, the truth is, many exchanges are structured in a way so that if management so desires, they can extract any amount of user funds whenever they want to. (The larger problem being that if this actually happens, and the exchange just claims they’ve been hacked, you can neither confirm nor invalidate this claim.)
- These risks are quite well mitigated by traditional financial institutions. They impose methodologies like network isolation on company devices (when imposed, staff computers cannot be accessed outside of the company, and computers owned by staff — especially developers — are only allowed to connect to the firm’s intranet system. Additional measures may also supplement this system.), manage sensitive information through HSMs, and so on and so forth.
- At the same time, traditional financial institutions in Korea — for instance banks — use a system called government-approved certificates to avoid the aforementioned risks. Even if central authority is compromised, if the certificates stored on customers’ personal devices are intact, the intruder cannot do anything. One could say that this is a sort of centralized-decentralized hybrid method. (On the other hand, one could also argue that even if you are fastidious with security, there are always risks.)
Anyway, coming back to the matter at hand, our users’ private key data and/or crypto assets must be kept 1) safe from hackers, 2) safe from user negligence, and 3) they must be managed in a way so that it can be easily utilized in our services.
To provide some examples of user negligence, there may be cases where the user’s device is infected with malware, where they lose their phone, where there’s a fire (in this case, even written down pieces of data would be incinerated😅), or where they lose their password (and/or OTP).
Service usability is an issue regarding what users have to input in their use of blockchain services and crypto assets. Some services might only require your ID and password. Others might use PIN numbers or biometric recognition. OTP, deposit/withdrawal restrictions, e-mail verification, SMS verification, … the list goes on. These are responsibilities put upon the user by the service operator according to their security policies. If they are excessive, service UX will be negatively impacted.
- For instance, let’s say you’re operating a game dApp, and the system requires every action to be broadcast to the blockchain. Now, ask yourself this: are you going to require users to input their password every time the character takes a step, or every time an item is moved? (I recommend having a go at EOSKnight.)
What is the most ideal storage method? It seems this question is yet to be answered. A simple exchange business requires you to take responsibility for only a certain amount of user funds, but if you’re operating a steadily growing dApp and/or wallet service, an exponentially increasing amount of user assets and accounts will be in your custody. In this case, the slightest hint of a system vulnerability may lead to irreparable damages. It’s a demanding issue.
1.3. Operation
If users’ keys are lost/stolen, while it is true that decentralized services can’t do anything to help, people will still utilize customer services to ask for help. Think of it from the user’s perspective. They’ve lost actual money using your services, and they want, or rather wish, someone to take responsibility. They’re just desperate, trying everything to get their money back.
Once, an acquaintance of mine was trying to invest in an ICO, and in the process realized that someone had stolen his private key by gaining access to his laptop. He asked me if he was supposed to contact MyEtherWallet (which he was using at the time), and tell them to freeze his account.
(MyEtherWallet simply organizes and displays the ledger within the blockchain, and can’t do anything more than that 😥)
- In decentralized services, there’s really nothing much you can do when customer service inquiries come in. All you can do is provide some guidance as to what the customer can do from his/her end, and get insulted in return😭
- In centralized services, issues like ID/PW loss can of course be easily dealt with. One could argue that centralized services carry less risk related to customer negligence, and is therefore safer from this perspective. (Of course, when looking at security as a whole, they definitely aren’t safer — refer to 6. Decentralization for more details.)
2. Asset Purchase
To use most blockchain applications, first you must purchase cryptocurrency assets. For instance, if you want to use Binance, you must first buy Bitcoin or Ethereum at a local exchange, send it to Binance, and only then can you start using their services. To use the recently publicized Dogeworker (beware of Ponzi schemes), you must first find an exchange that lists Dogecoin, purchase it, and then send it to their website.
In a lot of countries, exchanging between cryptocurrencies and fiat currency is challenging. In the United States, you must be licensed by each state to trade crypto using USD (as is the case with Coinbase, Kraken, etc.), and in China it’s illegal, which is why most exchanges prompt users to obtain cryptocurrencies through OTC trading (over-the-counter — think of it as a direct exchange between individuals; off the regulated market, just as you would buy and sell things off of Craigslist). In Korea, only Bithumb, Upbit, Coinone, and Korbit have official partnerships with banks which allow them to provide digital verified accounts where fiat deposit is legally allowed. The rest use corporate bank accounts commonly known as ‘beehive accounts’ to provide fiat deposit and fiat-crypto trading services.
2.1. Using order books/charts
When instructing users on how to use your blockchain services, you must tell them to
First, register at exchanges such as Coinbase, Kraken, etc. by doing this and that, complete their KYC process, trade at the order book, and send crypto to this address.
This is because most exchanges are not ‘(currency) exchanges’ but more ‘(stock) exchanges’, where trades are carried out on order books. Considering that a lack of prior experience in stock trading might mean a lack of familiarity with order books and charts (as was my case before I entered the blockchain industry)… even this is a hurdle that is hard to overcome.
To sum up, just to make it possible for users to use your services, you must instruct them to 1) register at an exchange, 2) register and/or create a bank account, 3) follow KYC procedure, 4) put in an order at the order book (whilst educating them on charts and spreads if possible), and 5) send the acquired crypto to a specific address (this automatically includes the complex transfer experience which I’ll cover at 3.).
2.2. Exchange between assets
This may be a minor issue, but if your service uses a certain token, and it isn’t listed on any fiat-to-crypto exchange (this is the case most of the time), user assets must make yet another stop, this time at a crypto-to-crypto exchange.
In this case, your instruction would read somewhere along the lines of “buy ETH at exchange XX by registering, blah blah KYC, blah blah order book, send it to exchange YY, exchange the ETH you bought for coin A, and then send coin A to address P”.
Crypto-to-crypto exchange services are provided by projects like Shapeshift or Kyber Network. Even if you only have Ether, using Kyber Network’s APIs, you could easily swap it for any token (provided the token is listed at Kyber Network).
Solutions
Is there anyone left at this point? Are your blockchain services so enticing that customers will actually be willing to jump through all these hoops just to take a glimpse at what you can do? (To be frank, in the real world, hurdles like this, doesn’t matter what service you provide. No one’s going to use them.)
Possible solutions to this problem are actually quite simple.
- Regulation issues: Whichever solution actually solves the problem, lifting regulations so that anyone can easily trade between fiat and crypto currencies must take precedence. I’ll go into more detail on this at 7. Regulation issues.
- Giving up on listing: Does your coin have to be listed/traded on an exchange? If you give up on this, you gain a lot of choices. You could just use Ethereum within your services. You as the operating entity could also directly sell/repurchase whatever coin you decide to use for your services. (just like how game companies sell in-game currency)
Selling tokens for fiat is quite straightforward, but the opposite does require some thought. Think: why don’t game companies exchange users’ game money for cash? - Emerging wallet/payment services: If regulations are lifted, and fiat deposit becomes easy, numerous businesses (other than exchanges) which support cryptocurrency trading/payment can appear. To properly utilize blockchain applications, such businesses must emerge to bridge the gap between customers and dApps.
For some between-the-lines advertisement: Clay utilizes Kyber Network to make exchanging between Ethereum and ERC-20 tokens as simple as possible. To go a step further, one could also provide an interface where exchange happens simultaneously with transfers.
3. Transfer experience
The transfer experience for crypto is, to be frank, shitty. The things we take for granted when we use wire transfers… none of them are applicable here. Everything is different, excluding just the basic concept where money is sent.
- Of course, international wire transfers are a million times more shittier than this, which is why crypto transfer services are quite a big deal in this portion of the market. (If you send $1,000 from a bank in Korea to a bank in Brazil, the remittance fee is a mind-boggling $440 / for a more in-depth look, learn about SWIFT and IBAN codes)
I don’t know if we’re supposed to look the other way because blockchain and decentralization are pioneering innovations which are bound to come with a few snafus along the way. One thing I know for certain though: from the average user’s point of view, the current system is confusing as hell.
3.1. Address
Blockchains use the public key we talked about earlier as its account number. They look like this:
- Bitcoin: 17A16QmavnUfCW11DAApiJxp7ARnxN5pGX
- Ethereum: 0x5e8b33ebd72c7d9f32020174f5e827d796a16b43 (There’s a domain system called ENS, but no one uses it, so let’s ignore it. It sucks.)
- EOS: eosyskoreabp (EOS is one of the only blockchains in which users can set their own ‘account string’. It’s not perfect, but at least it’s better.)
The problems are apparent. 1) It’s impossible to memorize, and 2) it’s hard to input. If you’ve ever sent tokens to these types of addresses, you know what I’m talking about. Every time, we have to double-check and triple-check the address, and even after that, we’re sitting on the edge of our seats until the money arrives at the opposite end. Doesn’t help that there was a real world case where a computer virus swapped out the contents of the clipboard for a similar, yet different address when a user was copy-pasting the destination address. (The prospect of easy/safe money leads to the creation of all sorts of viruses)
It doesn’t stop here. EOS, and some other blockchains like Ripple or Stellar use an additional variable called ‘memos’ when sending tokens. A lot of exchanges use this data as a sort of identifier to figure out who sent the money. But then we’re not used to this, which is why a lot of users forget to input the memo before transferring tokens. As you can guess, this leads to a lot of calls to the customer services department.
Another large problem is that it’s impossible to figure out ‘whose address this is’. When we send money to a bank account (at least in Korea), a pop-up informs us of the account owner’s name, which we double-check before finalizing the transaction. Problem is, blockchain accounts are simply a set of public/private keys, and are not linked to any personal information regarding the owner. Anonymity may be important to a certain extent, but it’s only creating inconveniences here.
- One could create a DB of addresses and ownership information. Largely, one could either open-source and manage it like a sort of DNS, or use it privately just for transactions between users. Most of the time, this DB would be kept within the operating entity’s servers, so system-to-system compatibility is a no-go.
- Anyway, using DBs, it’s possible to send cryptocurrencies using SSO IDs from Facebook or Whatsapp, or contact info from the contacts app. Of course, it would be limited to members of the same service… so this is subject to a bit of networking effect, just like messengers. The more members you have, the more powerful the functionality becomes.
- In Clay’s case, we’re working with Sentinel Protocol to manage our Whitelist (verified businessmen) and Blacklist (hackers, frauds) so that we can develop a solution where we display this info before the transaction is finalized. (Related article)
3.2. The concept of Gas
In most blockchains, there’s this thing called Gas. It’s a fee we pay to the network when sending transactions, and it’s used as rewards for the nodes that sustain the network.
Gas is slightly different from the fees we pay at banks or other similar services. For one, it isn’t fixed in value. For example, even for a single transaction, fees vary greatly depending on whether you’re simply sending ETH, sending tokens, or deploying a smart contract.
So from the user’s perspective, there can come a point where the fees become just too high. This also means that dApps need to decide upon optimum level Gas and Gas limits when sending transactions.
If Gas is set too low, the transaction may not go through, and if set too high, the user ends up paying more than they are willing. Also, since dApps fundamentally have no choice but to burden the user with all Gas related to blockchain transactions, if every single transaction is broadcast to the blockchain, users have to pay an inconceivable sum of fees. (Imagine what would happen if you have to pay 10 cents every time your character takes a step in a dApp game😫)
- There are solutions which provide answers to the Gas dilemma (there’s usually a recommended amount which blockchain explorers provide — like ethgasstation) so oftentimes we reference these services to set Gas. But then sometimes these services go down… which leads to absurd cases where we can’t send transactions because we can’t set Gas.
3.3. Transaction time
Blockchains take a long time to complete a transaction. Bitcoin takes 10 minutes to create a new block; Ethereum takes 15 seconds; EOS, Ontology, and others take 1~2 seconds. Whether or not your transaction is included in the next block is a whole other issue, but whatever the case, Bitcoin and Ethereum take at least a couple of minutes until your transaction is completed.
- In dApps, the bare fact that each transaction takes such a long time is in itself a large hurdle. That’s why we use sidechains, or use high-TPS blockchains like EOS from the get-go.
If exchange usage is a necessity when using your services, like we mentioned before (the whole fiat-to-ETH-to-random-token-to-your-service shebang), considering the time it takes for exchanges to manually check deposit/withdrawal, and block confirmations, which a lot of exchanges require when depositing tokens (this usually means that 15~30 additional blocks have to pass before your deposit is deemed ‘trustworthy’), each transaction can often take over an hour before it’s confirmed.
3.4. Payment-asset volatility
This is actually an extra-blockchain problem. A lot of blockchain services use cryptocurrencies as a form of user rewards. And a lot of (virtually all) cryptocurrencies are listed on exchanges.
This leads to situations where the value of a promised reward changes, or where yet-to-be-made payments are realized with unexpected gains/losses due to asset volatility.
For instance, think of a service where you pay for food using cryptocurrencies. If 10 coins were worth $20 one day, but $10 the next, either you would not be able to provide the store with the proper, promised amount, or the payment intermediary would take a hit. All international transfer services based on cryptocurrencies carry the same risk.
- One way of minimizing risk would be to buy crypto futures at vendors like BitMEX to create a portfolio that hedges risk. (See here for more details)
Blockchain projects that work in tandem with real-world economies often have to consider and/or manage the volatility of tokens/fiat they utilize within their services. It’s an unfamiliar experience from the user’s perspective as well.
3.5. Public transactions
In most blockchains, all transactions are readily available to the public. Of course, this openness is one of the core principles of decentralization, but still, considering the traditional transfer experience, it’s definitely not what we’re used to.
For instance, let’s say that I was using a certain Ethereum address to simply manage my cryptocurrencies. Then let’s say that I put that address within a centralized service in order to use dApps. What would happen if I, without thought, accessed an Ethereum gambling service using my address?
If the regulatory entity in my area has access to the DB of the centralized service, it would be able to link my address (which accessed a gambling service) to me. Like this, because all transactions are made public on the blockchain, its anonymity can be compromised in certain circumstances.
As illustrated in this example, there are inconveniences that arise because all transactions are made public. This openness is not just a good thing, and not all participants wish to follow decentralization principles, which means that the more dApps become popular, the more issues will appear from these inconveniences. (What happens if a wife knows her husband’s Ethereum address…?)
Solutions
- Sidechains: A lot of dApps construct sidechains to solve this problem. In this case, the service first records transactions on their own chain, in which ETH fees aren’t required for every single transaction, and when a sufficient number of transactions have accumulated, links it back to the Ethereum blockchain. In Korea, the decentralized exchange Allbit is best known for using this technology. (Thing is, it’s quite difficult to implement technically, and oftentimes people wonder if this is ‘real decentralization’.)
- Centralized vs. less centralized vs. decentralized?: Anyhow, the decision of how much of a service to put on-chain as opposed to off-chain is quite difficult to make. A lot of services, like exchanges, support on-chain deposit/withdrawals only when funds actually cross service boundaries, and take care of the remaining ‘intra-service’ transactions on centralized servers. However, these apps are technically not ‘decentralized services’, and can’t solve the aforementioned storage issues properly.
- EOS: There’s a lot of controversy surrounding it, but EOS is, without a doubt, the most user-friendly, intuitive blockchain that has been designed so far. Users don’t pay fees, and they can choose their own addresses as they would with IDs. It isn’t widely used yet, but if I’m not wrong, EOS’s blockchain also has a built in Identity functionality. Still, because EOS is required in order to make EOS wallets, and because users have to stake and/or purchase CPU/NET/RAM resources, I can’t stop feeling that all that’s changed is what the hurdles look like.
4. Token management
Excluding cryptocurrencies that were developed in order to replace ‘fiat’ (e.g., Bitcoin, Dash, Monero, etc.) most crypto platforms have something called ‘tokens’. For instance, ERC-20 tokens are ‘Ethereum-like’ cryptocurrencies that anyone can create.
Ethereum made it easy for anyone to issue and distribute their own tokens. This made it possible for numerous projects to issue tokens, do an ICO with those tokens, list them on an exchange, and then create functionalities, molding them into utility tokens.
From the user’s perspective, whether you’re using ETH or proprietary tokens, either way, it would just feel like a sort of point system utilized in the service — but obstacles exist here as well. We mentioned the complicated asset exchange process at 2.2., and now, we’re going to delve deeper, to talk about the more technical aspects we encounter as service providers.
4.1. Token balance
‘How many of which tokens do I have in my account?’ seems to be a simple enough question to answer. Setting expectations aside, however, if we look at this from the developer’s perspective, to answer this question we need to figure out 1) what tokens you have, and 2) how many of each of those tokens you are in possession of.
Problem is, the decentralized ledger we call blockchain is basically a DB that hasn’t been indexed in any way.
There are a total of 3.3 billion transactions currently on the Ethereum blockchain. To figure out how many ETH and other various tokens I have in my account, I would, in theory, have to search all 3.3 billion transactions for each of the thousands of tokens that exist in order to figure out all the transaction records pertaining to my address. (This article is written mostly with non-developers in mind, so please bear with me even if there are some technically imprecise explanations)
Because of this limitation, services like MyEtherWallet make you check each token’s balance separately by clicking on them individually. (There are so many tokens that loading balance data for all those tokens in advance would take too much time) Basically, if you want to know how much of a specific token you own, you’ll need to find that token from a list consisting of thousands of tokens, and then click on it.
Of course, not all blockchain services need to display every single cryptocurrency that exists within user accounts. However, services like crypto wallets do struggle with this issue, and the solutions aren’t that simple.
- The easiest method would be to build a proprietary system in which the blockchain ledger is continuously indexed and saved in a central DB, or to fetch data from a company that does that.
- Building a system like this on your own requires a lot of effort and time, so most firms choose the latter route. To my knowledge, Imtoken, a Chinese crypto wallet firm, is one of the very few companies that actually have their own system.
- Most wallets provide balance data on just a few preferred tokens of their choice. Only a small number of wallets support true custom token addition capabilities. (Refer to 4.2. Adding custom tokens for more information)
- Etherscan, Ethplorer, Infura, and some others provide indexed ledger data to third-party developers. However these services are limited to the Ethereum blockchain, and if god forbid their servers go down, it becomes hard for third parties to provide reliable services. Also, there’s a high likelihood that these services will soon be monetized.
- Similarly, providing push notifications for users when transactions occur or when certain coins/tokens are deposited/withdrawn is neither an easy nor a reliable task.
In Clay’s case, we fetch information from multiple sources to provide a real-time feed of token balances. Push notifications also work splendidly.
4.2. Adding custom tokens
Another problem that arises here is a UX element called ‘add custom tokens’. Many dApps that use proprietary tokens aren’t known well enough to have their tokens listed on mainstream wallets. In this case, if their users’ wallets don’t support the token, users would be unable to manage it in their wallets, which is a huge UX crisis.
- If your project utilizes its own unique token, it’s very important to register the token on well-known blockchain explorers like Etherscan. Many wallet services get their list from sources like this.
- Also… a good thing to do is to check if your tokens work well with prominent wallet services. (Bear in mind, a lot of wallets just don’t support adding custom tokens.)
4.3. Token/fee mismatch
This is actually the largest and most severe problem. In most cases, tokens used within services are not the tokens used when paying fees to the blockchain.
Let’s illustrate this with an example. Let’s say that I developed a game dApp called KAINGAME, and it uses a proprietary token called KAIN. I put out an ad on Facebook, and users start using my dApp. Users can earn KAIN by playing my game. (You don’t need KAIN to start playing the game) But then, when users try to withdraw the KAIN they earned, they find out that they need to have ETH in their wallets so that they can pay for the Ethereum network fees that arise when sending the withdrawal transaction.
Paying transfer fees in a game is in and of itself quite peculiar, and it’s not even the token used in the service — it’s a whole other one which I need to obtain just for ‘fee-paying purposes’.
So what can we do about this?
- Centralization: In this sense, exchange wallets are actually more logical. At exchanges, when withdrawing KAIN, the fee is paid in KAIN. Of course, this is only possible because the management system is completely centralized. A lot of services like Cosmee or certain airdrop systems are structured in this manner. Basically, crypto assets are managed in a DB ledger stored in centralized servers, and they’re dealt with by the operating entity only when deposits/withdrawals occur. (I sometimes call these ‘semi-centralized’ services.)
- Sidechains or proprietary blockchains: Which is why some teams structure sidechains or even better, design their own blockchains. But this is way out of reach for most developers.
- EOS: EOS doesn’t have fees, so it’s free from this dilemma (for now).
4.4. Token identity
This isn’t that problematic of an issue at the moment. It does have the potential to become quite a nuisance though.
Each token has its own symbol. Ones like ETH, KNC, EOS, and so on. Thing is, anyone can issue their own tokens, and there’s no rule that dictates token symbols can’t overlap.
For example, what if I decided to do a P2P token trade, and the seller sends me KNC, just not the KNC I’m looking for? What if it’s an empty, non-functional shell of a token, just with the symbol KNC? People actually do a lot of P2P trades for in-game currencies, so what if, moving back to the KAINGAME example for a moment, someone issues fake KAIN? There’s actually quite a large opening for fraud here.
You should check for similar vulnerabilities when designing your own project. Newdex, an EOS-based DEX (Decentralized Exchange) actually had an incident where a fake token with the symbol ‘EOS’ was used in malicious trades, leading to customer losses.
5. Blockchain platform fragmentation
The representative ones: Ethereum, EOS; the already famous ones: Tron, Ontology, ICON, Aelf, Zilliqa, Waves; some in Korea: Klaytn from KakaoCorp., LINK from Naver Line, TTC, … — numerous platforms have either already been released or are on the verge of launching.
Is it any better for the user if there are multiple platforms? Maybe in certain cases, but most of the time, probably not. Think about it: you’re still familiarizing yourself with cryptocurrencies as a whole, and now you learn that depending on the service you use, your crypto assets have fundamentally different properties.
The dApps here have one set of attributes, while the ones over there have their own, completely different properties. You have to fully understand each of these, separately. It’s a disaster. To make an analogy, think of a situation where the two credit cards you use have completely different point systems, and you have to comprehend each of them fully to use them. (I’ve been using Steemit for a long time, and I still can’t understand nor explain the Steem-Steem Dollar-Steem Power structure. TBH I don’t want to understand.)
5.1. Fragmentation of asset storage
Let’s look at this from the user’s perspective. Let’s say you’re using dApps A, B, and C. You earned tokens A, B, and C from dApps A, B, and C, respectively. Since tokens are mostly cashable, users would want to manage/hold/exchange these tokens within a single, integrated service (for convenience sake).
Usually, crypto wallets provide this functionality. (Of course, as of now, exchanges also do this for you, but I personally think that as dApps become more widespread, the ‘exchanges’ as of now will become more limited in its role within the industry, to the point where they’re just determinants of market prices.) At least, users would require an external wallet/exchange in which to cash their tokens, and they’d most likely prefer a single, integrated service to two separate services with separate protocols.
Problem is, as it is in the case of exchanges, there’s no way for crypto wallets to support all blockchains and tokens. Therefore, the user is left with no choice but to figure out something like “A is Ethereum based, so let’s use Clay. B is Neo based, so I have to send this to Poloniex first. Huh, C is Waves based. Where the hell can I send this?”.
- From a service provider’s point of view, if you’re going to issue your own tokens, you’re basically left with no choice but to base them on the most high-profile blockchain, i.e., the one which is supported by the largest number of exchanges/wallets. This is why most dApp tokens are ERC-20(Ethereum) based — even if the service itself runs on a completely different chain. It’s virtually impossible for projects with tokens based on smaller chains to be listed on prominent exchanges.
- Clay currently supports Ethereum and Ontology chains, and we’re trying to add support for EOS and Bitcoin chains as well. But we know it’s damn near impossible to cover all blockchains, so instead, we’re using API keys to link major exchange wallets. As of now, you can add Bittrex, Binance, and HitBTC wallets to conveniently manage deposit/withdrawal and even trading within a single app, and we plan on adding Upbit, Huobi, and a couple more exchanges as soon as possible.
- We expected interchain solutions like Cosmos or Polkadot to at least try and solve this problem for us, but as of now, we have no idea when they’re going to become available.
5.2. Fragmentation of blockchain concepts
Best case scenario: the above-mentioned crappy UX elements of blockchain are completely hidden from sight, resulting in an extremely user-friendly experience. Sadly, this isn’t realistically possible. Public keys (addresses), Gas, transactions, smart contracts, … these concepts are ultimately exposed one way or another.
The problem here is that these concepts aren’t universal across different blockchains. This means that users spend time understanding the concepts of blockchain α in order to use dApp A, only to find out that those same concepts are used differently at dApp B, which is based on blockchain β. This leads to increased confusion.
For instance:
- In Ethereum, users pay for their own Gas using ETH. Ethereum-based services require the user to obtain their own ETH in order to pay fees. If you run out of ETH whilst broadcasting transactions, you need to go get more.
- EOS doesn’t have fees. Instead, EOS is required when creating EOS wallets, and they have to be allocated to certain resources like CPU, NET, and RAM. Careless use of dApps results in a shortage of these resources and this renders the dApp unusable.
- Ontology fees are paid in units of ONG. If you hold ONT, their main token, ONG is automatically generated, but you need ONG to claim this generated ONG — which means that users have to start by obtaining ONG from some other third party.
- At the end of the day, most businesses that develop blockchain services end up using sidechains; developing proprietary blockchains; not issuing in-service currencies as blockchain-based cryptocurrencies, or moving core transactions off-chain.
5.3. Problems when using wallets
Ultimately, whether it be from the blockchain service provider’s perspective or the user’s perspective, crypto wallets are a must. Blockchain (B2C) services all use cryptocurrencies one way or another, and for that, there needs to be an account to and from which to deposit/withdraw users’ cryptocurrencies.
Note: the ‘wallets’ I’ve talked about so far aren’t limited to crypto wallet services like Clay. I’m also talking about things like exchange wallets and wallet modules equipped within dApp games.
Blockchain service providers mainly have to choose between internal, proprietary wallets and external wallets which provide SDKs (e.g., Metamask, Scatter, etc.). When choosing the former, an additional decision has to be made between decentralized data storage and centralized server storage. Basically, you’re opening a mall, and you have to decide upon the specifics for the payment system you’re going to use. As if that weren’t enough, external wallets are very limited in choice, so most of the time, you’ll have to force users to install either Metamask or Scatter (which were both developed as Chrome extensions), and there aren’t any mobile dApp platform wallets. (There are things called dApp Browsers, but these are temporary fixes, made only with web support, so we’ll disregard them for now.)
Most dApps feel that proprietary wallets are too much of a burden, so they use dApp platform SDKs provided by Metamask, Scatter, etc. to link the user’s blockchain account to their services. In this case, users come face to face with a situation where they have to download a wallet app, create an account, and put money in it just to play a game.
Also, whenever dApps broadcast transactions (e.g., when the game character moves a step, or when an item is removed/equipped) it has to show the wallet UI so that users can approve the transaction. If not, malicious dApps could siphon away user assets without the user knowing about it, so this is in part a necessary procedure. Still, it would be better if transactions that don’t send actual coins could skip this process altogether. All in all, UX research for dApp platform wallets is grossly incomplete.
- The EOS game dApp EOSKnight, and DEXs like Allbit and Bancor Network are, in my opinion, the best we can do… as of now. They have built-in wallets, and also accommodate the user by letting them import their own wallets if they choose to do so.
- dApps can’t make their own wallets. Therefore, there’s a necessity for a dApp platform wallet which is easier to use, better in terms of expandability, and properly supports mobile. This is Clay’s ultimate end-goal.
6. Decentralization
Everyone in the blockchain industry knows about decentralization, but have different views on it. I do agree that Bitcoin and blockchain were conceived and invented by cyberpunk-anarchist geeks who revered the principle of decentralization. At the end of the day, however, like the Internet, this principle will be diluted. The industry will eventually focus on what values and utilities we can create.
Decentralization is a ‘wonderful and great’ principle, but it isn’t ‘the wheel’. Not yet. Because it’s inefficient as of now. Maybe, similar to how we compare modern-day democracy with age-old autocracies, just maybe, in the long run, this discourse may provide us with revelations which propel us to greater heights.
Whether or not that happens, for us to advance, we need to come face to face with its inefficiency. And as service providers and users, we also have to think of the choices we have to make between the numerous ideologies and inefficiencies.
6.1. vs. Centralization
All decentralized services are subject to the temptation and/or provocation of centralization. Cryptocurrencies, which were conceived through the principles of decentralization, are as of now mostly managed and stored within centralized services.
We already covered most of this, so here, I’ll simply provide a rough summary of the more essential aspects of this comparison.
- Decentralization : Cheap to implement, free from the risks of hacking/security vulnerabilities. Users have rights over their own data/assets, but are also burdened with corresponding responsibilities. Storage negligence (data loss, personal hacking) issues may arise, and there aren’t any applicable ex post facto countermeasures when this happens. Non-intuitive, and hard to use.
- Centralization : Vulnerable to hacking/security risks. If the central operating entity is hacked, all users’ assets are at risk. Users’ data and assets are entrusted to the central entity, who manages and controls them. Easy to use, and intuitive for the user. Management protocols can help negate user negligence.
That’s it. I’ll skip over major UX issues since that’s basically what we’ve been talking about all this time. Decentralized services are just… so irritating to use. Really.
Thing is, because it’s so damned irritating, we’re often tempted to add some centralization into the mix. What about security, then? To once again stress the gravity of the statement “vulnerable to hacking/security risks” — this isn’t something that can just be brushed off as some sort of trade-off that we choose to embrace. We need to contemplate how we’re going to provide an answer that can satisfy our customers 100%. A lot of IT firms and even corporations with massive amounts of capital are often hacked. Financial institutions are no different.
To counter this, centralized financial systems are structured in a way so that no matter what happens, we have countermeasures in place. The flow of assets can be traced, and data can be recovered. Cryptocurrencies, however, were structured with decentralization in mind, so assets are untraceable, and data is irrecoverable. It’s ideal prey from the hacker’s perspective.
So the best case scenario isn’t “we’re not going to be hacked”. It’s “even if we’re hacked, your assets are safe”. There’s no scenario in which hacking is ‘impossible’. Some methods of making this possible would be centralizing and storing user data, but protecting each key with separate, robust encryptions; keeping only a limited amount (ideally an amount that you can reimburse just in case anything goes wrong) of funds in hot wallets and keeping the rest in cold wallets — this is what exchanges do; or getting insurance so that you can take responsibility for asset loss.
6.2. Non-intuitiveness
We must again remind ourselves that decentralization is in and of itself an unfamiliar concept.
For instance, a lot of users that start using decentralized wallets believe that their assets are stored within the wallet service. They’re not. User assets are stored on the blockchain. Wallet services simply act as intermediaries for better management and more convenient usage.
This is another reason why I say that wallets are like web browsers. It’s similar to how the information we see on browsers like Chrome or Internet Explorer is not stored on Google or Microsoft servers.
We already talked about the other non-intuitive aspects of blockchain like backups, storage, transfers, tokens, blockchain platforms, and so on and so forth, so I’ll skip over them here.
7. Regulation issues
While this industry was founded on the principles of decentralization, paradoxically, we’re largely influenced by the symbols of centralization, like governments or banks. Anyhow, when we’re evaluating the plausibility of any blockchain service, these regulatory/legal issues are oftentimes critical. I’m not a professional in this matter, so I won’t go into too much detail. I’ll just lightly touch upon some aspects that are applicable to the service and to the user.
To be honest, there aren’t many solutions to these issues. Either you leave the country and incorporate your firm elsewhere, or you just wait.
7.1. Fiat-crypto trades
We talked about this at 2. Asset purchase. In short, the fact that fiat-crypto trades are strictly regulated is a large hurdle for users.
7.2. KYC responsibilities
If you’re selling cryptos, or if you’re running some other crypto-related business which also requires fiat deposits, most of the time, you have KYC responsibilities. This is oftentimes a large inconvenience for users even before they start using the service. It’s also a large burden for the operating entity.
Ideally, we should separate wallet services which provide cryptocurrency supply/storage/deposit·withdrawal services from application services. Similar to how payment systems and games/malls are separate entities. All of us have a long way to go.
7.3. Capital markets act
You have to make sure your tokens aren’t securities as classified by the SEC — as in they can’t pay out dividends, and token prices shouldn’t affect firm valuation to the extent where you can profit from it. Also, make sure your token sales aren’t classified as illegal fundraising activities.
7.4. Cashable dApps
From this perspective, most dApps aren’t completely legal. This is because most dApps that use cryptocurrencies are structured in a way so that users have to pay money to earn money. (Excluding those that unilaterally give to the user)
The regulations regarding this aren’t yet clear enough, so for now, just check if your service falls under ‘gambling’ or not. ‘Gambling’ services pay out money, and the outcomes have to be ‘probabilistic’, that is, there’s luck involved.
Problem is, dApp games are games, and games aren’t games without a little probability. So if you’re operating a dApp game, it’s highly likely that your service falls under gambling. (This is why Korean games don’t make their in-game currencies cashable) For instance, there are legal precedents in Korea that state that while playing a game of Go or Chess with some money on the table is okay because it’s more about skill than luck, doing the same with golf is not, because the outcomes of a golf game are entangled with not only the mental/physical capabilities of the players but also probabilistic factors like the weather. Determining whether or not your service is gambling… is not an exact science.
In Conclusion
I started this article to whine about the difficulties in making crypto wallets, lengthened it by bragging about the grandiose endeavors we were undertaking, and ended up with a small voice in my mind saying ‘we have so many problems — let’s please solve these together’. The pie’s small enough as it is — let’s not be at each other’s throats trying to take bits and pieces of the shriveled pie, but rather, let’s cooperate, make the pie bigger, share tips, and pave the way for wonderful success cases.
Disclaimer: everything written here is my very personal opinion. They’re not Clay.one’s official statements and we don’t take responsibility for anything. (Whatever you’re doing, this article is merely a point of reference, so take it with a grain of salt)
This isn’t a book, report, or thesis, so the 7 sin’s aren’t MECE (Mutually Exclusive, Collectively Exhaustive), and I didn’t add any footnotes for additional explanations. TBH, the article’s long enough as it is. I’ve already spent too much time on it 😐
The Clay team is making a cryptocurrency wallet which facilitates the use of dApps. However, the future we dream of and the reality we see today are still so far apart that we’re left wondering what on earth we can do to close this gap.
Still, focusing on what we can do right now sometimes gives us insight into some baby steps we can take to achieve the future we imagine and desire. Clay will tirelessly work on the wallet side of things until true mass adoption of blockchain is achieved. Any form of support is always welcome.
