I originally wrote this in August 2022 when trying to evaluate the opportunities in protecting crypto users from scams. It's a bit raw. It's since become even more topical, with Elon Musk opening up twitter blue checkmarks to anyone willing to pay $8 a month.
Scams in crypto are rampant. (Scammers around the world took home a record $14 billion in cryptocurrency in 2021)
We can group virtually all scams into four categories:
Transactions where you don’t get what you expect, such as buying a fake product or signing a malicious signature that drains your wallet.
Having your secret keys stolen (by getting malicious code into your device or convincing you to send them)
Projects that don’t deliver what they promise (through misdirection, deception or rug pulls)
Security flaws in smart contracts or other code
The only problem I’ll look at here is category 1.
Problem Category 1: Phishing; Transactions where you don’t get what you expect (buying a fake product or signing a malicious signature that drains your wallet via setApprovalForAll or other)
Sub-Problem: Impersonating twitter/opensea/ENS/domains/discord users/…. via similar usernames or homoglyph attack
Solutions:
S1. Some sort of endorsement of the real thing from trusted source(s) via wallet/browser/extension
S1.1 Single “verified” or “not verified” protocol that is governed by a dao. This is kinda like a whitelist approach
Metacert was/is kinda trying to do this
The non DAO, centralized version of this is twitter blue checkmark and opensea verifications
The current versions keep the bar really high (very popular projects only) - however it might be sufficient to verify something is not an impersonation or close homonym of a well known project or better known project.
Problems with solution:
Centralized kinda “one truth” you either follow this protocol’s list or not.
Aligning token incentives could be tricky to prevent a 51% attack
Delegating trust to this list
verification can be subjective, and context dependent. A blue checkmark really needs a context, particularly for popular names like John Smith. Twitter adds additional context on the page of verified elected officials
Considerations
needs to prevent verification being continued across renames (requires reverification)
Nice parts of the solution:
if the rules for entry are objective, it’s really simple
easily understandable by end users
S1.2 Token curated registries: lists that are governed by DAOs with tokenomics
Examples
Uniswap lists
Kleros TCR
Problems with current solutions:
There is no financial reward to add to the list in Kleros’s case, and you have to risk tokens in order to submit to the list. Bad tokenomics. There is a reward for jurors paid by the submission. So it relies on lists where people want to be on it - and want to pay to be on it. Which is only some lists.
Is sort of a “solution in search of a problem” if you build a general TCR tool like Kleros has (https://www.ycombinator.com/library/6e-how-to-evaluate-startup-ideas). A general and broad tool not really being used for a specific, painful problem. Hard to grow because it's hard to explain and brand.
It’s hard to monetize list access. So who pays? how? Submitters to list? → Why would they pay to make the list better? Consumers of the list? Hard to get get adoption then - how do you moderate a list that costs to consume? If nobody pays ⇒ no tokenomics that drives list quality. Could charge for access to a more up to date list (day old list costs X, very fast list Y). But if your consumers are wallets, platforms etc are you charging per user or per company? May be difficult to get adoption if you don’t maintain the lists but are trying to sell them.
I believe the future looks less like: “everyone trusts a single TCR with the truth on a matter such as is address X the real thing or not” and more like “theres a couple organizations I trust, and they maintain lists, not necessary TCR ones that help me give choose towards whether I believe X is the real thing or not”. Lists will be derived from applications/be part of applications that have monetizable models, such as reddit communities curating lists of subject specific content and being rewarded from ad revenue.
Nice parts of the solution:
Not a single “believe us” - but you choose who to trust. There is a market for good lists
S1.3 Trust graphs - you trust X and X says that Y is the real one, so you can trust Y. This with many parties you trust can create multiple trust chains to a certain place. This is sort of where decentralized credentials, soul bound tokens are going. You choose a couple trust starting points (maybe influenced by your friend, your browser or your wallet), and then build out a trust graph from there. Tools to discover new trust points are still going to have the issue of moderating against impersonators.
Trust network based search engine
This is the most promising and exciting opportunity in my mind.
S2. Blacklists, whitelists and fuzzy matching from whitelists
Current solution being used by phishfort, metamask, and others.
Problems with solution:
blacklists are too slow (reactionary) - many scams last minutes and spin up fast
phishfort services for wallets are paid services
centralized parties managing the lists mean opaque processes you need to trust
S3. Only browse the web from trusted links (unrealistic)
S4. A search/browser engine that only gives you the real thing. This needs to be the starting point for any web3 search, such as the default wallet search engine.
Problems:
Still have the problems with third parties
Centralized censorship
S5. Bringing in social context by users or contract holders verifying ownership over domains, social accounts and other credibility giving assets. Possibly an extension of ENS or leveraging it
A version of this: https://galligan.xyz/blog/ens-proof-of-control
Problems:
Can impersonate people on twitter, can have huge following of bots on social networks. Needs a form of “trust graph” based proof of realness or other
S6. Displaying contract metadata, such as contract age or total transactions as a heuristic for the user
Problems:
Floor price, total transactions, total volume, contract age are not sybil resitant. Total transactions does have some cost associated to attacking it though.
Sub-Problem: Malicious signatures/transactions, such as “setApprovalForAll” that is called unbeknownst to the end user
Solutions:
S1. EIP-712: legible signatures + wallet signature UX that makes it safer
S2. Wallet warning on malicious contracts from a list
S3. Some sort of endorsement from trusted source(s) via wallet/browser/extension
S4. Transaction simulation + Wallet UX communicating dangers
Problems:
Transactions that are only harmful when front-run by the attacker
Currently uses centralized services for this (blocknative/tenderly) - can we done via a node but probably needs a backend where transactions are sent previously which isn’t particularly privacy friendly nor anti MEV bot friendly
It's really hard to get distribution on a 3rd party browser extension that just does transaction simulation. You really have to build this into the default wallet behaviour, and wallets will likely build this. Metamask snaps might make this possible soon, but most users are unlikely to install 3rd party wallet extensions for a while. There are also RPCs that do transaction simulation.
S5. Wallet UX & Community consensus to only interact with source code verified contracts via sourcify eth or other protocol - and automatic classification of contracts and their functions into whether they could possibly call setApprovalForAll
- Loading comments...