I have a great idea for a DeFi protocol. Where should I deploy it?

(Security Edition)

Coming on the heels of a recent Terra IBC re-entrancy exploit that caused major losses for token holders of various applications such as ASTRO (Astroport) just a couple weeks ago, where smart contract applications were affected by an underlying chain issue, we decided to put together a brief guide for developers on what to pay attention to when selecting a chain for smart contract deployment, citing real-world exploits that serve as stark reminders of each case study.

When you have a great smart contract idea, your focus tends to be on the push to market, or economic and marketing aspects rather than the security of the underlying chain. We believe it’s crucial to do proper due diligence on each potential chain candidate in order to understand the risks and weigh in the trade-offs that contribute to its security and long-term stability. Not only will these characteristics affect the reliability of your application, but they can also impact your users’ trust, investors’ trust, and bring with it potential legal and regulatory compliance requirements.

Here are some key research topics you should consider when selecting a chain:

Check the Basics: Network Size and Decentralization

The primary security benefit of decentralization is its resistance to single points of failure. In a highly decentralized network, there’s no central point of authority that can be easily compromised to bring down the entire system. This distribution of power and data across many nodes makes it extremely difficult for malicious actors to manipulate the network.

However, most of the modern chains are decentralized to some extent making marginal trade-offs to balance security and latency. This degree of decentralization can vary widely between different blockchain networks, and this marginal variation can have profound implications for smart contract security.

• Validator Size & Diversity: Make sure the validators are plenty and diversified among groups. More validator nodes controlled by many different entities make the network more resilient to attacks.

Case in Point: Ronin Bridge Hack (2022): The Ronin network, which powers the popular game Axie Infinity, suffered a major hack resulting in the loss of over $600 million. The attack was possible because the network relied on only 9 validator nodes, 5 of which were compromised. On top of the already low total number of validators, it’s important to note that 4 of them were controlled by the same entity — Sky Mavis and the remaining by Axie DAO and other parties. In late 2021, Sky Mavis requested temporary authorization from Axie DAO to use their validators in order to help manage the increased network load. Once this arrangement was made, it was never revoked, and Sky Mavis was in possession of the majority of the validators on the network. Once the attacker had compromised Sky Mavis systems, they were able to gain control of the majority of Ronin network validators and approve transactions. In essence, an attacker needed to compromise just one target to gain control of the entire network.

• Node Client Software Diversity. Consider chains where multiple mature node clients are utilized by node operators to enhance resilience against potential node client vulnerabilities. In addition to validator diversity, it’s beneficial to have variety in the node client software they use. Many prominent chains are working on diversifying their client software. Ethereum, for instance, has made progress in diversifying both consensus and execution clients in recent years. In the Cosmos ecosystem, an alternative client implementation of Cosmos SDK, Gears, is currently under development, and an alternative client implementation of Tendermint/CometBFT, tendermint-rs, exists. Other efforts such as Orga, Grug, or CosmosSwift do not currently aim for compatibility with Cosmos SDK, but may serve as a base for future clients. Solana has seen contributions from Jump Crypto and Syndica to increase diversity. Typically, more established networks have had a longer opportunity to cultivate a wider range of client implementations. It’s advisable to research and understand the risks in this area.

Case in Point: An attack happened in 2016 via an out-of-memory attack on geth, the Go Ethereum client, affecting ~7000 nodes, and more recently, another attempt had occurred in 2021, where a vulnerability in the Ethereum Nethermind client was used to trick nodes to endorse a particular branch of the chain (Chain overtake attempt via Nethermind).

• Geographical Node Distribution: Find out who hosts the nodes of your chain of choice and how well are they distributed across different data centers. Widely distributed nodes protect against data center bans, outages, and regulatory censorship.

Case in Point: While today, Solana’s validators are evenly distributed across various data centers, a prominent historical incident in 2022 rings a bell. On Nov 2, 2022, one of the key cloud providers for Solana validators (Hetzner) suddenly blocked all Solana activity due to breach of ToS taking 1000 validators offline. While the network had recovered, as this share was roughly equal to a quarter of the network’s security vote, it still acts as a stark warning to distribute the validators across a large enough group of providers geographically in order to avoid losing supermajority.

Understand the Inner-Workings: Consensus, Cryptography and Upgradability

While you don’t need to know exactly how everything works on your chain of choice, there are three key areas that you should have a good understanding of, as they are core to ensuring the security of the system you’ll be developing on.

Consensus mechanism: Make sure your chain uses a robust and secure consensus algorithm (like Proof of Stake or derived versions of it). This helps prevent attacks and ensures network integrity. Each mechanism has trade-offs in terms of security, decentralization, and scalability. Knowing how nodes agree on the state of your chain, and where your chain lands in this scalability trilemma is a must.

Cryptographic robustness: The security of a blockchain relies heavily on its cryptographic foundations. The strength of the cryptographic algorithms used is crucial for long-term security. Check the following three requirements are implemented:

• Hash Functions: Should be collision-resistant and preimage-resistant.
• Digital Signatures: Must use strong algorithms like ECDSA or EdDSA.
• Key Management: Secure key generation and storage practices are implemented.

Upgradeable contracts: The ability to upgrade smart contracts allows developers to patch vulnerabilities or improve functionality without completely redeploying. Understand your path to upgradability in case an urgent patch is needed. Also, understand the chain’s ability to implement upgrades and improvements. While there are various upgrade mechanisms present that balance flexibility, security, and complexity differently, the choice depends on specific project requirements and risk tolerance. As this is quite a deep topic in itself, we will dive into these trade-offs in a future article.

Beware of Complexity: Interoperability and Protocol Dependencies

We started this article with the Terra incident affecting Astroport and other applications, because we wanted to highlight the hidden dangers associated with underlying interoperable systems.

In this particular incident, while the smart contracts themselves weren’t exploited, a vulnerability in the underlying protocol’s dependency caused its token to become a target of collateral damage due to its liquidity value, as we examine later in this article.

Let’s unravel the Astroport chain of dependency to understand what had happened:

Case in Point: Astroport is a decentralized exchange deployed on multiple blockchains, including Terra. Terra, in turn, uses the Inter-Blockchain Communication (IBC) protocol to enable interoperability with other compatible blockchains. As part of this interoperability, the IBC protocol leverages a third-party module called ibc-hooks that provides an enhancement ability to execute callbacks on the source chain after an IBC transfer is completed on the destination chain.

In this hierarchy, the IBC-hooks middleware interacts with the core IBC functionality. Thus, when IBC-hooks is exploited with a severe vulnerability, its impact, if unchecked, can extend all the way back up the chain of dependency. One such exploit was discovered in April 2024 known as the IBC reentrancy infinite mint bug. While IBC itself had this hole quickly patched that same month and took the initiative to coordinate with all affected chains to incorporate the fix, Terra had accidentally re-introduced the outdated fork of its ibc-go implementation in June, allowing this vulnerability to re-surface. As this vulnerability traveled back up the dependency chain, it found Terra welcoming it with open arms. Astroport, being the largest liquidity provider on Terra, naturally became the target for the attacker, who then proceeded to mint 58 million ASTRO tokens artificially inflating its supply and causing the token price to drop by around 70%. While the Astroport team had demonstrated commendable diligence in auditing their code and swiftly addressing the problem by freezing some of the stolen ASTRO tokens, this specific attack was beyond their control.

This incident highlights a crucial lesson for blockchain developers: while cross-chain functionality can significantly boost an application’s utility, it also introduces layers of complexity that can harbor unforeseen vulnerabilities. Especially when developing smart contracts that rely on multiple chains like a decentralized exchange, be aware of the complexity of cross-chain protocols and other inter-dependent modules, which carry hidden dangers and require especially rigorous security reviews. Here are some pointers:

• Analyze Dependencies: Treat each point of interaction with another system as an increase to the application’s attack surface. Security flaws in connected chains can potentially impact the primary chain. Similarly, a flaw in a dependent module can propagate up the dependency chain to your application. One such common example in cross-chain systems is the reliance on price oracles. Oracles might have different levels of security and implementation on various chains. As a result, a vulnerability in one chain’s oracle integration could potentially be used to indirectly attack another chain that relies on that data. More generally though, each point of interaction with another dependent system is a potential vulnerability and thus increases the attack surface.
• Complexity of Asset Representation: Look for chains that provide built-in safety checks to prevent common errors in asset transfers, offer standardized interfaces, automated conversion processes, and unified representations eliminating the need for custom code. When dealing with bridges, the process of transferring assets from one chain to another utilizes several moving parts that all have to work together in order for the operation to succeed. This typically involves a multi-step process: locking an asset on the source chain, relaying the lock information to the destination chain, verifying the validity of the relay, and minting an equivalent representation asset on the destination chain. The complexity of managing these cross-chain asset representations makes it difficult to secure due to the size of the attack surface.
• Complexity of Security Audits: Interoperable systems require more comprehensive, lengthy, and highly specialized security audits with multiple firms that know the nuances of that particular dependency chain. The risks of missing vulnerabilities are higher the deeper the dependency chain goes. As system complexity is increased and the attack surface gets larger, significantly more time is required to understand the design and possible attack vectors, check all the dependencies, assess economic incentives, test invariants, fuzz, etc.

Case in Point: Poly Network, a cross-chain protocol that allows users to transfer tokens across different blockchains had suffered a major hack on August 10, 2021, resulting in the theft of approximately $610 million worth of cryptocurrencies across Ethereum, Binance Smart Chain, and Polygon networks. The attacker exploited a vulnerability in the cross-chain contract that allowed them to modify the keeper role (which manages the transfer of assets) and execute unauthorized transactions. Despite previous audits, the complexity of the cross-chain protocol made it difficult to identify this specific vulnerability. The hack affected multiple blockchains simultaneously due to the interoperable nature of Poly Network.

Know Who’s in Control: Governance Model

Even if the network itself is properly distributed and secured, its governance model can override the protection mechanisms in place. With the constantly changing landscape of cryptography and potential attack vectors over time, all systems must have a way to propagate updates and improvements. Effective governance allows for timely responses to newly discovered vulnerabilities, implementation of enhanced security measures, and scalability. Moreover, governance determines how conflicts are resolved and how the community responds to external threats or internal disputes.

The flip side of this is that governance itself can become a target for adversaries seeking to manipulate the direction of the protocol, making the security of the governance process itself a crucial consideration. Thus, it is paramount to ensure that the governance model of a given chain is fair, decentralized, and transparent, with proper checks-and-balances mechanisms implemented.

Look for the following properties to be present:

• multiple layers of approval for significant changes
• wide distribution of voting rights among stakeholders
• mandatory waiting periods before significant changes
• transparency in decision-making process with publicly available participation results
• mechanisms to prevent concentration of voting power (i.e. quadratic voting)
• clear dispute resolution process
• path of upgrading the governance model itself
• activeness, engagement, and responsiveness of voters

Case in Point: Tornado Cash Sanctions and Ethereum’s Censorship Resistance. In August 2022, the U.S. Treasury sanctioned Tornado Cash, a popular Ethereum mixer. While not a direct protocol governance decision, this external action led to a significant portion of Ethereum validators choosing to censor Tornado Cash transactions to comply with regulations. By February 2023, over 78% of blocks were being built by OFAC-compliant MEV-Boost relays, potentially allowing for transaction censorship at scale. This situation highlighted how external pressures and validator decisions can lead to decreased network neutrality and potential centralization of block production, undermining the security principles of the blockchain.

• Development Control: It’s important to note that development control must also adhere to the overall governance model. If a small group of developers has control over the codebase and doesn’t follow the instituted checks-and-balances system, it introduces risks of centralized technical decision-making and potential vulnerabilities.

Case in Point: In February 2020, when Justin Sun’s Tron Foundation acquired Steemit Inc., the Steem community became concerned about the centralization of power. In an attempt to prevent this, the community Witnesses (block producers) implemented a soft fork to temporarily freeze the voting power of a large stake of STEEM tokens owned by Steemit Inc. However, a centralized Steemit development team, now under new ownership, pushed a hard fork to reverse the community’s soft fork, using their influence and connections to mobilize exchanges to vote with customer funds.

Verify Security Hygiene

No system offers perfect security. With any protocol, the introduction of new features will require a continuous peer review process. Make sure the security lifecycle of your chain includes the following:

• Consistent Security Audits with Competent Firms: Blockchain protocols must undergo continuous security audits with multiple prominent firms and publish the report findings. Pay attention to the quality of the auditing firms, as they vary drastically.
• Presence of Bug Bounty Programs: Look for the presence of active bug bounty programs that incentivize the community to find and report vulnerabilities.
• Formal Verification Support: Platforms that support formal verification of smart contracts can mathematically prove the correctness of their code, reducing the risk of bugs and vulnerabilities.
• Auditing Tools: Blockchains that have built-in or widely available auditing tools signal maturity and help developers check their code for vulnerabilities before deployment.
• Track Record of Incidents: Perhaps most importantly, research the frequency of incidents on this chain. Look at the amount and frequency of downtime encountered and what was affected. This can serve as a preview of the level of stability you can expect from this chain.
• Circuit breakers: A common safety mechanism that can be integrated to prevent unintended consequences of errors or malicious attacks is a circuit breaker. By implementing a circuit breaker, developers can ensure that, in the event of unforeseen circumstances, the smart contract execution can be halted, preventing further damage or exploitation. While this is generally considered a good practice, circuit breakers pose a centralization concern and could potentially be exploited by a malicious party, for example by triggering a halt while shorting the protocol’s token. Consequently, one must ensure that the specific circuit breaker clauses implemented do address these concerns and do not accidentally disrupt the natural market dynamics.
• Rate limits: Another good security practice in smart contracts is the presence of rate limits. These can be used to time-limit access to high-value functions, restrict voting frequency in governance contracts, or limit the frequency and amount of token transfers over time.

Assess Platform Maturity

While some newer protocols may flaunt a game-changing consensus mechanism, or exhibit a novel governance model, the stability and wide acceptance of other less exciting chains may in the end count for more. Shiny new features are not always perceived safe until proven stable by time, load, and lack of incidents. When selecting a chain, pay attention to the following signals of maturity:

• Incident-free uptime and reliability (typically found on dashboard stats)
• Number of daily active users and transactions
• Number of active developers
• Quality and number of smart contracts deployed
• Venture capital funding in this platform
• Adoption by mainstream companies and institutions

In Summary, remember that security and stability often involve trade-offs with performance and features. While you won’t likely find a chain that satisfies all the mentioned attributes in this guide, decide on what matters most in your case and what shortcomings your application can deal with. Once you’ve selected your platform, always stay informed about the latest developments to ensure your application remains secure.

If you have any questions about how to choose your platform or any other security-related concerns, get in touch here!