Introduction
We're thrilled to publish the first version of Map3, a protocol for safe crypto assets interoperability.
Map3 helps developers scale support for crypto assets and networks in their apps. We do this by hosting an open source index of assets across networks with rich assets metadata. These assets are linked to each other via an on-chain data verification protocol. We call these links 'maps' and they help you understand the relationship between assets across protocols and networks. This data can be easily accessed programmatically and is community owned. Think of us as NPM (a code package manager) for crypto assets.
We think Map3 is a critical missing piece of Web3 interoperability infrastructure.
The Problem
As the number of interoperable crypto assets and networks grows, it's become increasingly difficult to establish the relationship between assets within and across networks. Developers historically have to manually group assets that are equivalent or related to each other in order to build good customer experiences or in order to trade or transact.
Let's look through an example:
Searching for the popular crypto asset "USDC" on Nomics returns hundreds of different versions of USDC. However, USDC is centrally issued on 8 networks by Centre.
So what's going on here? As canonical assets are held by on-chain contracts, these protocols usually issue an I Owe You ("IOU") derivative of the asset that it holds back to the user. This re-tokenisation enables use cases such as bridging of assets across networks, liquid staking and yield-bearing tokens.
Imagine being a developer tasked with creating a UI that displays the USDC balance of a user across networks. You're going to need a map with pointers for the instances of USDC on the different networks. Think about how many you'd need to group today for that single asset in order to get your app completed! But how bad could this problem get?
The rise of app-specific Layer 3 networks
The number of crypto networks continues to increase. Both in the form of new Layer 1 networks that offer novel execution and consensus models and also in the form of Layer 2 networks. Layer 2 networks usage is exploding. For example, L2Beat estimates that the amount of ETH locked in L2 EVM networks is up 20x YoY.
Our thesis is that we will also continue to see an increase in the number of single-app Layer 3 networks. Apps will do this to take advantage of the higher bandwidth available at a lower cost. These apps, with varying degrees of decentralisation, will utilise fraud proofs to commit checksums of their internal ledgers to L2 networks, yielding low-cost consumer applications that unlock the power of Web3. Modular network development kits like Celestia, Cosmos, Polkadot and Polygon Supernets enable this future.
This trend will not be limited to decentralised applications. The recent cases of contagion in the crypto lending industry have demonstrated the need for more transparency and accountability among 'CeFi' platforms. Brian Armstrong, the CEO & Founder of Coinbase mentioned in his recent Lex Fridman podcast appearance that in the not-so-distant future even current off-chain peer-to-peer transfers within Coinbase might be done in a lower-cost, public and transparent Blockchain network.
Trustless sells — and apps want need this.
In a world where assets can flow across these networks in a permissionless way and assets can be tokenised (and re-tokenised!), we will see billions of unique asset<>network combinations that live in thousands of interoperable and often domain-specific Blockchains.
We have now established that it will get more complicated to manage this asset metadata. How big of a deal is it if this data is wrong?
Getting some of this metadata wrong can have disastrous consequences for users. A user might be tricked into thinking they're receiving payment in an asset (i.e. USDC) when in fact they're receiving a look-alike version of it. Theoretically speaking, if someone managed to insert a phishing address in place of a popular asset metadata repository such as on the popular self custody Wallet Trustwallet's, tens of millions of dollars would be lost in the first few hours by unsuspecting users.
This is the reason why most crypto platforms manually verify and curate this data themselves. In fact, our research shows that all the major crypto platforms have a dedicated 'Assets Metadata' engineering team in-house.
This natural risk aversion is holding back innovation and liquidity agglomeration in the space.
The Solution
Rich Cross-chain Metadata
Our goal has been to create an index of rich and trustless crypto assets metadata that was generalised enough to cover different crypto network architectures.
We started by manually compiling data for the top assets and networks with semantic data that we wished we had readily available to us when building consumer products like blockchain.com, monolith.xyz and coinfloor.co.uk.
We're quite excited to be raising the bar by including data that increases the possibilities of things you can build with it. Beyond the regular name, address and symbol, our repo data includes vectors, contracts, i18n, identifiers, regexes and other semantic data. It also maps assets across networks, so you know, without having to do the work. All the data is hosted on Github and is Open Source.
Trustless Verifications
Given the sensitivity of this data, we then researched the best way to make it possible for the community to aggregate this data while giving a path for the data to ultimately become trustless. This is a particular challenge in a world of permissionless innovation, where anyone, anywhere can issue an asset or network.
Prior art such as Tokenlists relies upon social vetting to address the trust, curation and discoverability problems in crypto assets. It builds on ideas such as Web of Trust. Putting aside the fact that it's only an EVM-native standard, list publishers quickly find the problems with curation (source):
Unfortunately, most of these curated lists are effectively dead. That's understandable. They take real work — and real risks with little reward to maintain them. This is to the detriment of the community.
Our model will be different. Anyone anywhere can add a crypto asset to our list as long as it passes our CI integrity checks. In fact, developers can write modules for our assets indexer that automatically monitors networks and other popular registries and adds them to Map3. However, unless the data is verified it will not appear by default in the results of our official open source APIs and SDKs.
How will this data be verified?
We settled to build on top of the Kleros Curate protocol in order to power our verification process. Kleros Curate is a dapp that uses the Kleros decentralised dispute resolution protocol in order to verify the validity of assertions on-chain. It leverages financial incentives, blockchain technology and its network of jurors to arbitrate claims in a trustless way.
We find that it's the perfect abstraction for our use case. Let's go through an example:
Powerful Self-hosted APIs
These assets and networks metadata is needed by every system that interacts with crypto protocols or displays information about them. This means that developers end up having to waste time building processes to deliver this data to those systems in a high-performance way and keep it up to date.
We understand that your systems need the assets & networks metadata to be highly available, secure and instantly accessible. Our open source, self-hostable APIs use local caching and automatic refresh to give you the lowest latency.
Looking Ahead
In the near future, we will be releasing a series of blog posts and technical documentation to go deeper into the topics discussed.
What's Next?
- More Assets and Networks : We're focused on bootstrapping our dataset by expanding the reach and depth of our indexer. Initially, we will be focused on expanding fungible assets indexed on EVM networks.
- API : We want to make it easy for developers to consume the assets' data via HTTP. They can self-host the API or use our community version.
- Assets App and Indexer : We want to make it easy for the community to add, map and verify assets, both manually and programmatically.
Longer Term Roadmap
- Console : To initially monetize our project and make it sustainable, we will eventually offer a premium hosted version of the OSS API with high throughput, SLAs and a portal to configure the data returned by the APIs. This will enable organisations to set overrides and custom fields using Role Based Access Control (RBAC) that map to the workflows in their organisation.
- Protocol Extensions : We have an exciting set of improvements to the protocol and repo such as community Sorter and Selectors (as OSS composable pure functions), introduce community maintainers (CASA styled) and weighted staked verifications - leveraging Kleros' upcoming Stake Curate.
- Custody Gateway : We will build software that aggregates decentralised custody networks programmatically in order to make it easier to scale into crypto networks and take advantage of interoperability.
Our Vision
We want to make crypto interoperability accessible.
In the process, we will disintermediate critical centralised infrastructure providers and create a more resilient ecosystem. Our customer is the crypto developer; who struggles to thread the line between shipping often and building safe systems that protect customers while preserving censorship resistance.
Our customers should be able to switch us off and their apps should continue to work. Otherwise, we're just adding to the problem. We will be the champions of the community, spearhead some of its most important missions and contribute; to open-sourcing our code where it makes sense to do so while building a valuable AND sustainable business. We will gain the respect of and our place in the community through the quality of our work.
We are here for the long term and make decisions as such. We value Optimism, Persistence, and Candour.
Join us!
-A