The ability to bring your own account to different applications is one of the most interesting, foundational aspects of web3. Even more powerful is the fact that you truly own your account without relying on centralized gatekeepers. Many startups and dapps are predicated on relying on their users’ wallet (calling it an “account” for the sake of simplicity for the rest of this post) to do things like:
- Gauge reputation
- Build a social graph
- Customize experiences or target ‘ads’
- Reward for certain activities
Unfortunately, identity is still an unsolved problem, and an account alone isn’t sufficient to fill the gaping hole of identity in web3.
Anyone active in the web3 ecosystem is likely aware of decent crypto hygiene and opsec. Their personal setup probably looks something like this:
In this example, the person has accounts at various centralized crypto companies as well as many self-custody accounts. Some of the self-custody accounts are only used for longer-term storage of higher value NFTs or cryptoassets, while others contain smaller amounts and are intended to be used for frequent interactions with dapps (these are the “hot wallets”). And much of this is duplicated across chains.
When a startup, developer, or dapp treats an account as an “identity,” they are likely viewing only one of the user’s hot wallets, for a single chain. They’re literally ignoring everything else the person owns and the activities they do elsewhere. They’re looking at a tiny, curated portion of the user, as shown below. I have well over 30 different accounts. Just looking at jsfranklin221.eth would give you a tiny glimpse into my on-chain activities. You couldn’t build a remotely accurate profile of that account. You also can’t know if I even possess that account or if I gave it to someone else. The only thing you know is that someone has access to that private key because of some recent activity.
Some of the major flaws include:
1. It’s possible to lose access to the account, forever. It could be by accident, purposefully by transferring (sometimes selling) it to someone else, or it could be stolen. In all of these cases, it could be permanent. Most importantly, nobody would be able to determine if ownership changed hands from the outside. Crypto accounts and wallets aren’t tied to your actual identity, in any way, whatsoever. And having a name service like ENS associated with your address doesn’t solve that either.
2. A single address provides an incomplete view of whoever possesses the seed or private key. As demonstrated in the diagram above, many people could and should have multiple accounts on individual chains for different purposes.
3. Privacy barely exists, which is partly why people go to great lengths to split activity across different accounts.
4. Users have limited control over what’s in their wallet. You can’t reject incoming transfers like Ether from Tornado Cash or inappropriate NFTs.
Account aggregation as a stop-gap solution
Until identity is a solved problem, I think some form of account aggregation may be the next best thing because it helps address aspects of problems #1 and #2. A challenge will be getting the incentives right so that users are encouraged to authenticate with all their accounts across all chains for you to get their complete picture. In the case of financial use cases, centralized tax software such as Plaid and HatchFi are aggregation service providers. Users are incentivized by the sheer utility it provides.
Ledger Live and DeFi dashboards like Debank, Zapper, and Zerion are similar, more web3 native examples. The Ledger Live app helps you track all of your assets across multiple chains, which means they have a significantly clearer picture of your on-chain life than most dapps, even those which are more social in nature.
In both examples, users are incentivized by the utility they get from doing so, even many who are more OpSec-conscious.
Some bridges are designed to have the user authenticate with multiple wallets from multiple chains. For example, users of StacksBridge authenticate with an Ethereum wallet and the Hiro wallet before bridging, proving ownership of both accounts. In the case of these bridges, users are incentivized by the utility they provide by transferring an asset. And they’re usually not connecting with a wallet used for larger amounts and longer-term storage.
Aside from these examples, I really haven’t seen solutions that help centralized and decentralized app developers aggregate a bunch of users’ accounts in an effort to paint a more holistic picture of their activities to infer things like their interests. There’s a reason a bank wants you to provide your complete financial picture, including all credit cards, loans, and assets, to underwrite you for a loan. Similarly, protocols and apps need to have a more comprehensive view of their users to build an accurate social graph, customize experiences, target promotions, and offer financial services. Short of solving directly for identity and having a mapping of an identity to activities and audience classification, I think figuring out how to get users to connect more than one of their accounts is better than just one like the status quo today.
Is ‘Plaid for web3’ the answer?
“Plaid for web3” came to mind since we’re talking about account aggregation. After all, their flagship offering enables a user to securely prove they have access to each of their independent financial accounts. It makes it easy for end-users to link each and easy for application developers to retrieve the linkages, clean balance and transaction data, and ultimately focus on their core competency without having to worry much about this aspect of their application. Removing the friction for both parties contributed to a burgeoning fintech ecosystem over the past decade.
As elegant as this analogy sounds, I don’t necessarily think the solution to the problems outlined will just look like a Plaid for Web3. All Plaid use cases are financial in nature and usually the incentives are clear to the end user. It makes their life easier than the alternative, which in many cases, one doesn’t even exist. But web3 use cases are more broad than financial, and asking someone to link all their accounts across all their chains each time they interact with a new financial, social, media, or shopping application will never happen due to the frequency and questionable incentives for the end-user. I think the killer implementation has to live closer to the wallet authentication level. Perhaps it’ll be web3auth, WalletConnect, or someone new. I recognize that dapps would need cross-chain interoperability to be aware of multiple accounts across multiple chains. Nonetheless, I think the solution has to mirror something closer to if ‘Login with Plaid’ existed, where that’s your authentication mechanism into an app, in addition to coming preloaded with verified accounts in your possession and perhaps some summary info such as audience labeling.
While there have been a lot of projects aimed at solving identity, bridging, and various wallet problems, critical flaws still exist that are holding many web3 companies back from being able to live up to their potential. Until identity becomes a solved problem, the next best thing might just be a solution that aggregates accounts and makes it easy for developers to actually get a comprehensive picture of a user from their on-chain activities. It’ll be really hard to juggle UX, centralization, interoperability, privacy, opsec, incentives, compliance, and beyond. As my friend Thomas said to me, “the alternative take is that for the first time ever, people can have different profiles for different aspects of their life – gambling, professional, savings, etc. There’s a battle brewing between businesses wanting a complete picture for customized experiences and users purposefully wanting information segregated for privacy reasons.” I’m not sure what the proper solution looks like, but the leading assumption that an address is a user’s web3 identity is flawed.
Reach out if you’re building with this thesis in mind.