The blockchain space has been fortunate with a creativity burst that resulted in impressive product abundance. Yet, an uneven distribution of liquidity together with a rapid rise of DeFi created an urgent need for interoperability between blockchains.
Bridges are a set of smart contracts that promise to enable information exchange between protocols at lower fees than more traditional means. In the present blog post, we propose a mental framework that could ease the work on such a demanding project for managers, developers, and product managers.
Introduction to the DeFi space
The recent explosion in the blockchain space could be intimidating. At the time of writing the present blog post, there are around 140 blockchains that are the backbone for approximately 19,577 cryptocurrencies. Their overall market capitalization is estimated at 1.27 trillion dollars USD. Within it, NFT collections like Bored Ape Yacht Club or CryptoPunks have an estimated market cap of 1,097,268.38 ETH and 417,239.67 ETH, respectively. This abundance comes with a very particular set of pros and cons.
Namely, on the one hand, this fragmentation is excellent. It gives freedom to the blockchain creators, so they can investigate different design options in search of more effective consensus methods, faster transaction rates, or more versatile smart contracts languages. As a result, users have a plethora of options to choose from, so they can find a protocol that suits them best. This opens a door for fierce competition between blockchains and pushes their evolution even faster. During this process, new stars are born, and their early adopters are handsomely rewarded.
On the other hand, this fragmentation is terrible. Tokens from blockchains are locked within a confined space, resulting in data isolation. In addition, despite having potential, many protocols are struggling to attract liquidity as movement between protocols is costly. Finally, smart contracts from distinct blockchains cannot exchange information, which limits their use cases.
Motivations to building bridges between blockchains
We should add two peculiarities to the mentioned market characteristics that recently started to play an important role. First, most of the market liquidity is divided only among two contenders, i.e., Bitcoin and Ethereum. Secondly, the rapid rise of decentralized finance (DeFi) pushes protocol creators to attract liquidity quickly. Yet, how to get liquidity if it is locked among competitors? Currently, the answer for many clients is to use a bridge.
In essence, the bridge is a set of smart contracts that lock tokens on root blockchains and mint a wrapped equivalent of them on a target one. Such a project is interesting for a developer because of a distinct set of inherent challenges. Namely, because a bridge links blockchains that usually use different programming languages, a developer needs to be fluent in them. Moreover, a developer needs to understand protocols to a great degree, as most of the work will be spent on consolidating their discrepancies.
Let’s be clear. The work will be demanding as even running a test version of the product will be a dev-ops project of its own. Finally, you need to have a substantial budget for the project. As building and auditing, the code is expensive. Nevertheless, this is the current frontier in computer science, and there is a joy in being the explorer of it.
Design phase
As the market research progresses and the management decides to start the project, it is essential, in our opinion, to explore the following topics that will help to shape the product:
User personas
This section covers the most fundamental problem that a bridge must resolve, i.e, a bridge needs to be a response to the client’s needs. These in turn will vary based on numerous factors like:
user experience: how will we explain how our bridge works? If an inexperienced user makes an error will we have a way to recover the funds?
products that the user is using: are we dealing with a sophisticated DeFi trader that is interested in high volume and frequent bridging or crypto enthusiasts that just occasionally is exchanging tokens
tokens that the user is holding in the wallet: if our bridge is linking blockchains with small liquidity it is possible that a user will not have its native currency;
trust level: during exploring the different personas that are going to interact with the product it is worth noting that each of them could have a different trust level, e.g, an advanced user with coding experience would prefer a fully decentralized solution, whereas a user that just explores the space would prefer a system with a way to recover the funds, i.e., less decentralized.
Technology
The crucial decision to be made is to choose the proper level of bridge decentralization. Do we want to have an administrative user? How much power should this user have? Should it have the authority to recover some funds, change the contracts, or freeze assets? If we want to have an administrator with all mentioned features, should we create an administrative panel for its role?
Next, the developer team needs to choose tools to create a solution to the described user needs and decided level of decentralization. During the research, it is worth answering the following questions:
- Is the tool open source and has a permissive license? Is the project active and backed by some organization? How many people are using it? Are developers familiar with the programming language of the tool? Was the tool audited for security? How easy will it be to implement proper tests with it?
Fees
This could be one of the most tricky features to implement. On the one hand, your client wants to use the bridge to lower the costs that are imposed by more traditional exchanges. On the other hand, your product needs to create revenue. Balancing these conflicting requirements requires careful calculations.
A minor issue that the team needs to resolve is in what currency the fees are going to be taken.
Monitoring
Finding quickly if there is a problem with bridge assets could be critical to the project’s success in the long term. Thus, it is important to have in mind a logging/monitoring function for each feature of the bridge.
Discrepancies between blockchains
The effective philosophy of unifying differences between blockchains is the key to the bridge’s success. It needs to resolve issues like:
- Different number of decimals in tokens
- Managing distinct data types
- Separate ways of creating tokens
Scenarios
During the design phase, it is also worth spending some time exploring different scenarios that could happen, mostly including the edge ones, by creating spreadsheet simulations. Your team needs to be able to answer questions like:
- What is the plan if the bridge is hacked like the Wormhole bridge?
- How to omit a situation in which the bridge will not be able to back all the users claims, a case that allegedly happened to EVODeFi Bridge?
Implementation
For product managers (PM) the implementation phase could be particularly demanding. Projects using blockchain as its backbone are not easily adhering the mainstream Agile values, e.g.:
- How to make frequent releases and respond to change if smart contracts code is immutable? How to adhere to the principle of working software over documentation if auditors and more advanced users want a detailed code description?
These are just a few problems that a PM will face while working on a project. As a result, similarly to the developers, the bridge will open a new perspective and challenges for PM.
In our opinion, given that smart contracts are currently facing a lot of technological constraints and orchestrating interactions between them on distinct blockchains is time-consuming, the cost of change is substantial. Thus, the design and planning phase is more important than in typical IT projects.
Testing
While creating a financial product, testing is the most crucial part of the development process. There is no room for error, as even a tiny bug could result in significant damages that could hamper the bridge’s reputation. Thus, testing should be an iterative process split into separate phases. We propose the following ones:
- Unit tests of functions inside smart contracts End-to-end tests of the whole bridge process Tests on the chosen test network Code audit by a separate institution Tests on mainnet
Conclusion
DeFi expansion with its need for liquidity together with the smart contract dominance created a significant need among users for bridges that connect previously isolated blockchain. Projects like that are demanding as they force managers, developers, and project managers to quit their comfort zones and quickly adapt to a mostly unknown environment. Yet, in the present post, we presented a mental framework that could help reduce the cognitive burden.
Disclaimer
All data is based on: coinmarketcap.com . Data related to cryptocurrencies is subjected to rapid changes and could change substantially when the reader is checking it.
The present blog post is for informational purposes only and is neither legal nor financial advice/statement. Cryptocurrencies are high-risk investments with the potential to lose all invested capital. Thus, before you invest, consult proper authorities and perform due diligence.
