After Ethereum’s long-awaited Merge, it’s an ideal time to think about how we can also improve smart contracts. Essentially apps that run on blockchains, smart contracts are a vital component of our Web3 applications. But interacting with them remains quite dangerous, especially for non-developers. Many of the incidents where users lose their crypto assets are caused by buggy or malicious smart contracts.
As a Web3 app developer, this is a challenge I think about often, especially as waves of new users keep onboarding into various blockchain applications. To fully trust a smart contract, a consumer needs to know exactly what it’s going to do when they make a transaction — because unlike in the Web2 world, there’s no customer support hotline to call and recover funds if something goes wrong. But currently, it’s nearly impossible to know if a smart contract is safe or trustworthy.
One solution is to make wallets themselves smarter. For instance, what if wallets could tell us if a smart contract is safe to interact with? It’s probably impossible to know that with 100% certainty, but wallets could, at minimum, aggregate and display a lot of the signals that developers already look for. This would make the process simpler and safer, especially for non-developers.
Here’s a deeper look at the advantages and disadvantages of smart contracts, why they seem like the Wild West now, and how we might improve the UX for using them.
The promise and peril of smart contracts
For developers, using a smart contract as the backend for their app has enormous potential. It also increases the potential for bugs and exploits. It’s great that smart contracts can be created by developers without asking anybody for permission, but that can also expose users to considerable risk. We now have apps transacting hundreds of millions of dollars with no safety guarantees. As it stands, we simply have to trust that these apps are bug-free and do what they promise.
Many non-developers aren’t even aware of the safety issues involved and don’t take the appropriate precautions when interacting with blockchain-based apps. The average user might sign a transaction thinking it’s going to do one thing, only to discover the smart contract does something else entirely. It’s why malicious smart contracts are a primary attack vector for bad actors.
Why are smart contracts the Wild West?
When a Web3 app makes a smart contract call, you don’t know exactly what the transaction will do until you actually do it. Will it mint your nonfungible token (NFT), or will it send your money and tokens to a hacker? This unpredictability is true of any online application, of course, not just Web3 apps; predicting what code will do is very hard. But it’s a bigger issue in the Web3 world since most of these apps are inherently high stakes (they’re built for handling your money), and there’s so little protection for consumers.
The App Store is largely safe due to Apple’s review process, but that doesn’t exist in Web3. If an iOS app starts stealing users’ money, Apple will take it down right away to mitigate losses and revoke the account of its creator.
Malicious smart contracts, on the other hand, can’t be taken down by anybody. There’s also no way to recover stolen assets. If a malicious contract drains your wallet, you can’t simply dispute the transaction with your credit card company. If the developer is anonymous, as is generally the case with malicious contracts, there often isn’t even an option to take legal action.
From a developer’s perspective, it is much better if the code for a smart contract is open source. Popular smart contracts do typically publish their source code — a huge improvement over Web2 apps. But even then, it’s easy to miss what’s really going on. It can also be very difficult to predict how the code will run in all scenarios. (Consider this long, scary Twitter thread by an experienced developer who almost fell for a complex phishing scam, even after reading the contracts involved. Only upon a second closer inspection did he notice the exploit.)
Compounding these problems, people are often pressured to act quickly when interacting with smart contracts. Consider an NFT drop promoted by influencers: Consumers will be worried about the collection quickly selling out, so they’ll often try to make a transaction as fast as they can, ignoring any red flags they might encounter along the way.
In short, the very same features that make smart contracts powerful for developers — such as permissionless publishing and programmable money — make them quite dangerous for consumers.
I don’t think this system is fundamentally flawed. But there is a ton of opportunity for Web3 developers like me to provide better guardrails for consumers using wallets and smart contracts today.
The UX of wallets and smart contracts today
In many ways, wallets like MetaMask feel like they were created for developers. They display a lot of deep technical details and blockchain minutiae that are useful when building apps.
The problem with that is that non-developers also use MetaMask — without understanding what everything means. Nobody expected Web3 to go mainstream so quickly, and wallets haven’t quite caught up with the needs of their new user base.
MetaMask has already done a great job of rebranding the “mnemonic phrase” to “secret phrase” to prevent consumers from unwittingly sharing it with hackers. However, there’s plenty more room for improvement.
Let’s take a look at MetaMask’s user interface (UI), followed by a couple of mock-ups I created outlining some potential improvements that could guide consumers into the “pit of success.” (By the way, MetaMask here serves as a reference since it’s heavily used across the Web3 world, but these UI ideas should also apply to pretty much any wallet app.) Some of these design tweaks could be built today, while others might require technical advances on the smart contract side.
The image below displays what the current MetaMask smart contract transaction window looks like.
We see the address of the smart contract we’re interacting with, the website that initiated the transaction, and then a lot of details about the funds we’re sending to the contract. However, there’s no indication of what this contract call does or any indicator that it’s safe to interact with.
Potential solutions to improve smart contracts
What we’d really like to see here are signals that help us as end users to determine whether we trust this smart contract transaction or not. As an analogy, think about the little green or red lock in the address bar of modern web browsers, which indicates whether the connection is encrypted or not. This color-coded indicator helps guide inexperienced users away from potential dangers, while power users can easily ignore it if preferred.
As a visual example, here are two quick user experience (UX) design mock-ups of MetaMask transactions — one that’s likely to be safe, and one that’s less certain.
Here are a few of the signals in my mock-up:
- Is the contract source code published? Open-source contracts are generally more trustable because any developer can read them to find bugs and malicious code. MetaMask already includes various links to Etherscan, so this would be a simple and convenient signal to add.
- Audit score. A third-party audit is another signal that can determine trustworthiness. The main implementation question here is how to determine this score. Are there any accepted standards for this already? If not, a simple way could be to use Etherscan, which supports uploading audits. MetaMask, in this example, could also maintain its own list of auditors, or rely on a list of third parties. (From what I can tell, MetaMask already does this for NFT APIs and token detection.) In the future, it’s easy to imagine a decentralized autonomous organization for determining audit scores in a more decentralized way.
- What can this transaction do? Can it call external contracts, and if so, which ones? This would be very difficult to determine perfectly, but I wonder if a simple version for open-source contracts would be feasible. There are already plenty of automated smart-contract vulnerability scanners out there. If this isn’t possible for Solidity, I wonder if we could design a smart contract programming language that does allow this level of static analysis. Perhaps individual functions could declare the permissions they need, and the compiler could guarantee conformance.
- Security tips and education. If a smart contract doesn’t have many signals of trustworthiness (see mock-up above on the right), the UI could recommend an appropriate set of precautions to take, such as checking if the contract address is correct and using a different account. These are suggestions made in the orange text, as opposed to red, since a lack of signals isn’t necessarily dangerous; here, we’re simply recommending that users opt to be a bit more cautious about their next steps.
Like many existing features in MetaMask, these proposed features could be turned off in the settings.
Toward a safer future
In the future, there will likely be many safety-focused tools built on the primitive components that blockchains provide. For instance, it’s likely we’ll see insurance protocols that protect users from buggy smart contracts become commonplace. (These exist already, but they’re still fairly niche.)
However, consumers are already using Web3 apps, even in these early days, so I’d love to see the dev community add more protections for them now. Some simple improvements to wallets could go a long way. Some of the aforementioned ideas would help protect inexperienced users while simultaneously streamlining the transaction process for Web3 veterans.
From my perspective, anything outside of trading crypto assets on Coinbase (or other big companies) is still far too risky for the average consumer. When friends and family ask about setting up a self-custody crypto wallet to use Web3 apps (let’s face it — usually, in order to buy NFTs), always start by warning them of the risks. This scares some of them away, but the more determined people want to use them anyway. When our wallets are smarter, we’ll be able to feel much better about onboarding the next wave of new users to Web3.
Devin Abbott (@dvnabbott) is the founder of Deco, a startup acquired by Airbnb. He specializes in design and development tools, React and Web3 applications, most recently with The Graph.
This article is for general information purposes and is not intended to be and should not be taken as legal or investment advice. The views, thoughts, and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.