“… it took only five hours to protect 350 million USD from falling into the wrong hands.”

Writes samczsun as he describes the infamous rescue of MISO protocol’s funds involving the historically perfect case study of such an attack that could have easily made it to the top 10 of the largest blockchain security hacks to date. In an almost poetic way, this case study covers the step-by-step story experienced first-hand by samczsun himself when he describes the “encounter, discovery, disclosure, preparation, rescue, and reflection” on the MISO fiasco. Write-ups and disclosures guide us towards the elegant handling of war-room cases and how to go through such situations following a standardized approach.

Let’s continue infiltrating the EVM

In our article series, we move on with the 4th part today, focusing on some of the writeups in the web3 security space that educate the readers on how to handle the situations that always inflict a 0-day attack. The list covers some well-known writeups, such as the paradigm’s write-ups of the MISO attack, Ethereum is a Dark Forrest, and the industrially standardized Yearn’s public disclosures (and others).

The emphasis will be on learning about situations and environments of how a bug discovery, rescue, and fix are deployed in a war room, some of which end up happily ever after, and others teach us more valuable lessons. This teaches us how strategies are created and practiced setting up standards throughout the industry.

Amidst the fascinating narratives of blockchain security challenges, one particular incident stands out as a testament to swift action and proactive auditing. Let's first delve into the gripping tale of the MISO rescue mission, where $350 million was at stake, and the clock…; the clock is always ticking.

From Crisis to Triumph - The MISO Battle for Security

On August 18, 2021, samczsun reported a critical vulnerability in SushiSwap’s MISO smart contracts, which put ~350 million USD (109 thousand ETH) at risk.

In the ever-evolving landscape of DeFi, where fortunes are made and the stakes run high, the tale of the MISO protocol's rescue mission stands as an epic saga of audacity and triumph. Picture this - $350 million hanging perilously on the edge, teetering between salvation and the abyss of the wrong hands. As the clock ticked, the guardians of MISO stepped forward, ready to shield their treasure from the clutches of lurking adversaries.

Finding The Familiar Foe

This gripping saga begins with samczsun, a keen-eyed auditor, stumbling upon a discussion about a raise on SushiSwap's MISO platform. Driven by curiosity, he delves deeper, scrutinizing the Dutch auction contract, hoping to ensure the system's integrity.

Drawing from past experiences with Opyn, samczsun realizes the eerie similarity between the vulnerabilities. Inside a delegatecall, msg.sender and msg.value persist, opening the door to reuse msg.value across multiple commitments, aka batchcalls.

The magnitude of what this bug could bring was a staggering amount of ~$350M.

Ticking Time

In the fast-paced world of DeFi, where transactions occur rapidly, every moment counts, as opportunistic hackers could discover the vulnerability at any time. Hence, the team had to act swiftly and strategically to safeguard the funds and neutralize the immediate threat posed by the vulnerability before it could be exploited. The clock was ticking, and the safety of a substantial amount of funds hung in the balance, making it a race against time to protect the treasure from falling into the wrong hands.

The team precisely acts, finalizing the Dutch auction and neutralizing the immediate threat. Yet, challenges arise as they encounter an active batch auction. A quick decision is made to prioritize safeguarding the 350 million USD while mitigating the risks in the batch auction.

Creating a rescue strategy is paramount, as determined by the MISO Sentinels. To gain an advantageous position in a war room scenario, it is imperative to explore all possibilities, which is precisely what the MISO war room team is doing. To achieve this objective, the team reaches the conclusion of implementing a smart contract that utilizes one of the protocol’s features as a pause functionality. The team consisting of esteemed experts, namely Samczsun, Mudit, Dan, Georgios, Keno, and Omakase, with Joseph Delong from the Sushi protocol, plays a crucial role in the process.

Key Takeaways

Here we list down a couple of lessons learned, in the words of the sentinels, as the first-hand experience is the best of the teacher. samczsun states covering the Reflection of the whole fiasco as follows;

More importantly, samczsun mentions the one thing that is at the core focus of DeFi SRs at BlockApex as well, as below;

You can read how the whole scenario unfolded in this blog. (source: Two Rights Might Make A Wrong)

This incident also brings forth the depiction of Ethereum to mind the "Dark Forest" concept in the Ethereum mempool, where opportunistic arbitrage bots lie in wait to exploit profitable opportunities. The term was coined by Dan Robinson and Georgios Konstantopoulos in Aug 2020.

Race Against Predators: Navigating The Dark Forest

It all began when a user inquired about recovering Uniswap liquidity tokens mistakenly sent to the pair contract. Dan Robinson knows two things when he officially terms the Ethereum blockchain as a Dark Forest;

  1. “This is a horror story”, as the team got knocked out in the MEV colosseum in the first round.
  2. “Except… I knew it wouldn’t be simple.“, and the fact. Obviously.

In mempool, arbitrage bots lurked like apex predators, ready to exploit any profitable opportunities they detected. Known as "generalized frontrunners," these bots could copy and manipulate transactions to their advantage. This created a challenging environment for the rescue mission, as any attempt to claim the tokens could be instantly targeted and stolen by these savvy predators. An intricate plan was crafted to recover the funds without drawing attention from the bots. Custom contracts were deployed to obfuscate the rescue transactions and make them less conspicuous.

Finer details make all the difference

The obfuscation looked like this, to veil the call as an internal transaction, the sentinels decided to break down the transaction into two pieces:

Quoting Dan below, the implementation detail need to be executed in the following order;

  1. “Deploy a Getter contract which, when called by its owner, would make the burn call ONLY if activated, and otherwise revert.
  2. Deploy a Setter contract which, when called by its owner, would activate the Getter contract.
  3. Submit the set transaction and the get transaction in the same block.”

As the pressure mounted, a critical oversight proved costly. In their haste to execute the rescue, a key detail was missed—the get transaction slipped into a later block, providing a window of opportunity for the bots to strike.

As expected,

Bots struck… Bots won.

Key Takeaways (1)

Readers are here for the lesson, which is what they shall get.

The entire scenario's account, written by Dan Robinson and Georgios Konstantopoulos, can be read in this blog.

While the rescue faced setbacks, it highlighted the need to address MEV and front-running attacks in DeFi. Promising solutions, such as Optimism's vision for redirecting MEV and StarkWare's verifiable delay function service, offer hope for a more secure future. As the DeFi landscape evolves, staying vigilant and proactive in securing the ecosystem becomes paramount.

Coup de Grâce: SirenMarket V1

Once hailed as an innovative DeFi protocol offering options and automated liquidity provision, Siren Markets was at the center of a high-stakes exploit that threatened its users' funds. The vulnerability lay hidden within the Automatic Market Maker (AMM), presenting attackers with a unique opportunity to game the system and profit at the expense of the protocol.

At the heart of the vulnerability were bTokens and wTokens, the twin tokens representing different sides of the options contracts. Armed with this knowledge, attackers devised a cunning plan. They strategically acquired equal amounts of bTokens and wTokens to neutralize their exposure to the underlying asset, laying the groundwork for their assault.

Round 1: Ready, Fight

The attackers bided their time, waiting for the opportune moment: when the market was about to expire. As the countdown neared its end, two potential scenarios emerged. If the options expired from the money (OTM), the attackers swiftly exercised their wTokens, recuperating their losses.

However, the "in the money" (ITM) scenario showed their strategy's brilliance. Just before the bTokens' expiration, the attackers made a bold move: they sold these tokens back to the AMM. Unbeknownst to the AMM, the attackers cleverly exploited its lack of action. The AMM, unsuspectingly, bought the bTokens at their current valuation without exercising the option.

The plot thickened with the application of block stuffing!

Block stuffing is a type of attack in blockchains where an attacker submits transactions that deliberately fill up the block’s gas limit and stall other transactions. To ensure the inclusion of their transactions by miners, the attacker can choose to pay higher transaction fees. By controlling the amount of gas spent by their transactions, the attacker can influence the number of transactions that get to be included in the block.

Round 2: Ready, Fight

Siren Market assumed that the bug fix was a transaction that would be handled gracefully, i.e., eliminate the ITM option, but this is the prime example we are trying to share with our readers. By setting higher gas fees than honest users, the adversary ensured miners would prioritize their transactions, creating a temporary denial-of-service (DoS) effect. This sneak attack made it challenging for the Siren team to execute their fix, ultimately forcing them to exercise ITM options.

K.O. Key Takeaways (2)

In this series of articles, we explored a new attack vector revealed by the vulnerability in the Siren Market. Our goal is to educate Blockchain Sentinels on the surprises the blockchain has up its sleeves, even when it comes to something as important as a bug fix for a transaction. The key takeaway is considering how an attacker could bypass your vulnerability fix.

A cherry on the top: Yearn’s Disclosures

After covering a number of war room stories, we wrap up echoes of the past with Yearn’s public disclosures. Yearn Finance has worked on its small and large vulnerability identification and fixes for almost two years. The list on their GitHub repository covers the details of all hacks organized by date and time, with a template set as a standard for bug fixes. The template covers the segments of hacks or reported findings by including a description of the summary, background, details of the vulnerability, details of the fix, an attribute of the timeline of events, and important links relevant to the said hack.


The article "Infiltrating The EVM IV - Echoes of the Past, Visions for Tomorrow" takes readers on a captivating journey through real-life incidents in the realm of blockchain security. Three gripping narratives stand out: the MISO rescue mission, the Dark Forest of Ethereum, and the Siren Market exploit.

In each case, the common theme is the urgency of swift action and proactive auditing to protect massive sums of money at risk in DeFi protocols. These stories serve as powerful reminders of the high stakes involved and the ever-evolving challenges faced by auditors and security experts.

Key lessons emerge from these experiences. First, secure composability is crucial. Combining safe contract-level components does not always guarantee overall safety, as seen in the MISO case. Second, the DeFi ecosystem must address risks like MEV and front-running attacks, which can threaten funds at any moment.

Transparency and accountability are paramount. Protocols like Yearn Finance, with their public disclosures and standardized templates for bug fixes, set a commendable example for the industry. Sharing insights and vulnerabilities openly can foster trust and strengthen the community.

This is the Fourth part of the series Infiltrating the EVM.

This is the second part in the Infiltrating the EVM series.

In September 1947, Grace Hopper found a bug, “a moth in the inner working of the Harvard Mark II computer.” The legendary machine was debugged, literally, and the moth was removed. This incident catalyzed a coordinated awareness within the burgeoning field of computer science, emphasizing the importance of attention to detail, perseverance, and problem-solving.

A decentralized system such as web3 fundamentally differs when debugging and removing errors from a computer system or its applications. One cannot simply restart the world computer or take the software offline to implement fixes.

In the fast-paced world of decentralized applications (dApps), where every second counts and user trust is paramount, a malfunction can quickly escalate into a crisis. When the stakes are high, and downtime is not an option, merely adding to a to-do list won't suffice.

Enter the War Room.

War Room is an immersive, high-energy environment incorporating a dedicated team of experts that comes together to form the backbone of the War Room. These professionals encompass a wide range of talents, including but not limited to blockchain engineering, smart contract security, cryptography, and DevOps. Combined with the urgent nature of the problem, their collective knowledge qualifies for a comprehensive analysis of the issue, ensuring no stone is left unturned.


Imagine this scenario: a heavy-traffic DApp, with tens (or even hundreds) of millions of dollars invested in it, suddenly collapses due to a bug. Transactions fail, data becomes unreachable, monetary value is locked, and panic spreads. If you have experience in the blockchain industry, you know that panic is not uncommon.

In these high-pressure moments, traditional troubleshooting processes fall short and swift action is the only acceptable course. What we need is a War Room!

Within the War Room, clear communication channels are paramount. Efficient collaboration hinges on effective information sharing. A monitoring system is a watchful eye, tracking user activity and contract behavior. Real-time data feeds into the War Room, providing crucial insights into the malfunction's scope and impact. Vital to the War Room's success is access to the contract's source code and documentation in the realm of blockchain, where transparency and security reign supreme, a thorough understanding of the codebase is imperative. Testing environments and tools are indispensable to navigating the treacherous terrain of troubleshooting. Simulating scenarios within controlled environments allows the team to recreate issues, observe their behavior, and test potential fixes. These testing mechanisms provide a safe space for experimentation, minimizing the risk of unintended consequences. In the face of unexpected challenges, a robust incident response plan guides the team's actions.

This plan outlines the necessary steps to be taken in the event of a security breach or bug discovery. The team can respond swiftly and efficiently by establishing a predefined roadmap, minimizing downtime, and mitigating potential damage.

War Room - in Short

The War Room is a high-energy environment with a diverse team of experts tackling critical dApp issues. Their collaborative knowledge and skills ensure a comprehensive analysis of the problem. Clear communication channels, monitoring systems, access to source code, testing infrastructure, and sandbox environments are crucial for effective collaboration and troubleshooting. A robust incident response plan guides the team's actions, enabling swift and efficient resolution of security breaches or bugs.

When the War Room Calls!

In the realm of Blockchain Security, there exists an exhaustive list of scenarios that demand the presence of a War Room. Within this dynamic environment, the team of experts converges, ready to confront the challenges that arise. These challenges can be very diverse in their nature, some of which are chosen explicitly from real-world experiences and listed below;

A Security Breach Occurs

A security breach in the context of a smart contract refers to unauthorized access, manipulation, or exploitation of vulnerabilities present within the contract's code or associated applications. The magnitude of the harm caused by a security breach can be significant. It may result in losing or locking funds from and within the smart contract, compromising user data, disrupting services to users, negatively impacting the contract's reputation, and potentially triggering legal and regulatory consequences.

SushiSwap, a top DeFi protocol, where the admin turned rogue by executing the perfect rug pull ever to exist; such a protocol is liable to attacks as the contracts remained unaudited even when the TVL touched its first 9 digits. And when the audits did happen, according to Finematics, “… no critical or high severity issues found.“ It's crucial to voice these concerns and take proactive measures to prevent such incidents. Take the SushiSwap case for instance, the single admin should have been flagged as high-severity as the centralization risk lied to a pseudo-anonymous owner, Chef Nomi. Although, the psuedo-anonymous owner did apologize for the consequences, this does not guarantee that similar situations will always result in the rightful compensation for affected individuals. Therefore, it is wise to prioritize safety and precaution, as demonstrated by SBF's immediate implementation of a multi-sig contract. This not only enhances security measures but also helps to rebuild users' confidence in the platform.
At BlockApex, we believe that ensuring a secure user experience goes beyond just examining the codebase. Security experts shoulder a significant responsibility in identifying potential attack vectors that could harm users and damage the overall blockchain ecosystem.

Substandard audits of SushiSwap Protocol - BlockApex's Opinion

User Identifies Some Discrepancy

In the ever-evolving landscape of smart contracts, users play a crucial role in identifying potential vulnerabilities. Their vigilance and attention to detail can uncover bugs that may compromise the security of the contract. Such issues are usually reported through several channels, for instance, a list maintained by Crytic containing contact details for all hot and trending DApps, social media like Discord and Telegram, or even public bug-bounty programs to handle responsible disclosures.

Unexpected Behaviour Of Contact

Smart contracts are intended to consistently and predictably carry out transactions and specific tasks. However, there may be instances where a contract displays unexpected behavior, indicating the presence of a potential bug. This issue could be detected by a legitimate user, an adversary, the protocol itself, or even a random developer experimenting. In some cases, such behaviors may not immediately lead to an exploit; failing to address them could draw unwanted attention.

Security Audit is Due for Smart Contract

Before a smart contract progresses to the next phase of its journey, it undergoes a critical evaluation—an independent security audit. This evaluation aims to uncover potential vulnerabilities and weaknesses in the contract's design, code, and functionality.

REMEMBER, provided enough time and set of eyes, any bug can be identified!

Fortify the War Room, First. Period.

When setting up a War Room, it is imperative to prioritize the security of this critical environment. The following measures can help fortify the War Room and ensure its integrity:

Multi-Factor Authentication

A Secured Physical Location

Encrypted and Secure Communication Channels

Limited Access to Vulnerable Code

Team-wide Awareness

By incorporating these strict security measures into the War Room's setup, the team can establish a fortified environment where the focus remains on effectively addressing smart contract security challenges and protecting the project's integrity.

Like any code, smart contracts aren’t immune to bugs and vulnerabilities. Fixing bugs in smart contracts requires careful attention to detail and a comprehensive understanding of the underlying code. Addressing and resolving bugs in these contracts is paramount with the potential for substantial financial losses and reputational damage.

Complexities Of Fixing Bugs in Smart Contracts

Fixing smart contract bugs in production is one intricate and multifaceted endeavor. With the potential for significant financial losses and reputational damage, addressing and resolving bugs requires a meticulous approach and a deep understanding of the underlying technology. Auditors face challenges while fixing bugs!

Spotting Bugs in Smart Contracts

Bugs have the potential to inflict significant financial losses, tarnish the project's reputation, and even lead to legal consequences. Identifying and confirming the presence of a bug requires meticulous analysis of the contract's code. This task is particularly arduous due to the intricate nature of the code and the intricate web of interactions between different code segments.

To tackle this challenge, the team must create a testing environment and develop comprehensive test cases encompassing various potential interactions. Any deviations in the test results necessitate a thorough investigation to determine if a bug exists.

Creating a Robust Task Force For Bug Resolution

Addressing and fixing a bug in a smart contract demands the expertise of a highly technical team proficient in understanding the contract's code and the underlying blockchain technology. This team should encompass individuals well-versed in software engineering, cryptography, blockchain technology, DevSecOps, and security auditing.


A prime example of assembling such a team can be found in the Yearn Finance emergency procedure, designed in response to a critical vulnerability discovered in the platform's code. The procedure outlines the formation of an "emergency multi-sig" composed of the project's core team and trusted external experts. This multi-sig possesses the authority to make decisions on behalf of the project during emergency situations.

Assets and Risks in the War Room

Within the war room, the most crucial assets at stake are the funds belonging to users and the project's hard-earned reputation. Failing to promptly and effectively address the bug can lead to substantial financial losses for users and the project.

Additionally, there exists a risk that the team's actions during the war room process might inadvertently exacerbate the problem or introduce new vulnerabilities. However, meticulous planning and execution of each step and a comprehensive understanding of individual roles and responsibilities can minimize this risk.

Confirming the Implementation of Top-Quality Fixes

After the team identifies and fixes the bug, it is imperative to conduct rigorous testing to confirm the implementation of a high-quality solution free of new issues. This process typically involves automated testing, manual testing, and thorough code review.

The initial testing phase should occur in a staging environment resembling the production environment. This testing should encompass various scenarios to ensure the fix's effectiveness.

Following testing, the team should engage in an exhaustive code review. This review aims to identify and address any potential new vulnerabilities or issues.

Finally, considering a third-party security audit can provide an additional layer of assurance, validating the fix and instilling confidence in its robustness.


The discovery of a bug in a smart contract deployed in production raises significant concerns due to potential financial losses and reputational damage. Identifying bugs requires thorough code analysis, while fixing them necessitates a highly technical team of experts. Assets at risk include user funds and the project's reputation. Confirming high-quality fixes involves comprehensive testing, code review, and potentially third-party security audits. Diligent adherence to these steps ensures the resolution of bugs and upholds the utmost level of security.

This is the third part in the Infiltrating the EVM series.

Fixing a bug in traditional software development is often likened to solving a difficult puzzle, each presenting its own challenges. This task has always been complex and time-consuming. However, resolving bugs in a blockchain system is even more demanding due to its transparent & permissionless nature and the high stakes involved with users' funds. The intricacies of this task are significant and call for developers to think creatively and critically to come up with a solution. Let's examine these complexities in more detail.

In blockchain, transparency refers to the public availability of the smart contract's code. This unique characteristic enables anyone to review the code, scrutinize its logic, and identify potential bugs or vulnerabilities. The ability to access and examine the code fosters a collaborative environment where developers and security experts can come together to identify and address any issues they discover.

Blockchain systems are designed to be permissionless, meaning anyone can access and interact with the smart contract without requiring approval. This aspect can be both advantageous and challenging for bug fixing. On the one hand, it allows a wide range of white hat security experts to contribute to solving an identified bug while, in the meantime, opening up the possibility of black hat hackers exploiting it.

Bugs in smart contracts can put users' funds at risk. If a vulnerability is exploited, users can suffer financial losses. This factor adds urgency and pressure to fix the bug promptly and effectively to minimize user impact and safeguard the protocol’s reputation.

In this third part of our article series, we infiltrate the Ethereum Virtual Machine with our team of seasoned blockchain security sentinels. Till now, we dove deep into the internals of how a code is executed on the EVM’s world computer, going through the intense environment of a war room where responsible experts take up the duty to handle any and all critical conditions at hand, considering up to hundreds of millions of dollar value at stake.

Cracking The Code: Bug Fixing On Blockchain

Identify and Select a Patch

Once a bug is identified, the development team will work on a fix. The war room engineers at this point in time will;

Let's delve into the various approaches taken to resolve these elusive issues while deploying a bug fix in a mission-critical financial instrument coded in the smart contract on the blockchain.

  1. To identify the bug, refer to the previous article where we discuss the multiple scenarios of how a bug can be identified and fire up a war room where a team of experts treats it as an operation theatre, performing diagnosis and surgery for the exploitable (or already exploited :skull: ) bug.
  2. Once the issue is confirmed, a list containing multiple possible fixes may be devised as a reflex action.
  3. When evaluating fixes from the list above, several factors impact the feasibility of selection, with the nature of the bug being the most critical. However, the bug's severity also plays a significant role in determining the appropriate fix.

At this point, the security partners of the protocol may be consulted to evaluate and finalize the fix as a patch.

  1. Once a bug fix is finalized, we move on to the next phase, executing it as a transaction within the dark forest of the Blockchain.

Implementing the Bug Fix as a Transaction on the Blockchain

The bug fix for the identified vulnerability will be executed as a transaction on the blockchain. This transaction includes relevant information such as the smart contract's address, the function signature to be called with the necessary parameters required for executing the fix, and the values supplied in the function arguments.

When the bug fix transaction is broadcasted on the blockchain, it enters the mempool, awaiting confirmation and validation from the network. At this stage, the transaction becomes visible to all participants on the network. However, the transparency and permissionlessness of blockchain acts as a double-edged sword.

All the while the transaction sits there, ready to be executed, and is visible to the public, the possibility of an attack increases by the passing second. Envision a zero-day at this point and multiply the intensity of damage to the protocol’s reputation by incorporating factors such as the users' funds, the permissionless ness to interact with the smart contract infrastructure, and the transparency, providing ease-of-access to an adversary to understand and grab the problem to turn it around for their own benefit.

Say hello to Front-running

Front-running is a technique where an attacker observes a transaction before it is processed and executes a similar transaction with a higher gas price to ensure it gets prioritized. If the bug fix is not carefully crafted, an attacker may still be able to exploit the identified bug despite the fix attempt by a privileged goodwill user.

A whitehat hacker named @trust__90 found a vulnerability in a protocol that brought risk to almost 100 ETH of users' funds. They tried to execute a white-hat rescue, only to get frontrun on the way and losing about 90% of the funds at risk by some MEV Bots.

Front-running at any cost?

When it comes to web3 security, front-running remains a persistent attack vector that continues to pose a significant threat despite being identified as a vulnerability. This leads us to many of the scenarios where not even bug-fix transitions are secured from it.

From a common person's perspective, front running might involve obstructing or delaying transactions that directly involve money or may have some financial gain in the future. However, there have been instances where even attempts to fix vulnerable code, such as with the SirenMarketV1 protocol, (the exploitable vulnerability could have allowed an attacker to get free leverage) have been front-run to an extent that a new attack vector named, Block-Stuffing Attack was discovered. The attacker provided a large number of high-gas transactions which in the rational environment of a blockchain’s mempool were (and are always) prioritized for the miner’s profit basically stopping the fix to be deployed for almost 30 blocks, hence the 0-day in this case extended by the will of an adversary.

Block stuffing is a technique where an attacker submits tons of transactions with a higher gas fee than an honest user. Miners will fill their blocks with just those transactions until the block gas limit is reached. Hence, an honest user gets completely ignored if they keep following a standard way of executing transactions on the blockchain* aka the public mempool.
(*Hint: Flashbots)

Front-running, is it something new?

Frontrunning refers to the unethical practice in financial markets where a trader or broker uses advanced knowledge about upcoming large buy or sell orders. This occurs when the frontrunner executes their own trades ahead of the client's order, utilizing the imminent price increase or decrease to gain a profit. By front-running, the frontrunner essentially jumps in front of the client's order and capitalizes on the anticipated price movement.

Context: In blockchain networks, transactions are typically held in a mempool, a pool of pending transactions, before being added to blocks through a consensus mechanism like proof-of-work or proof-of-stake. Miners or validators are responsible for selecting transactions from the mempool to include in the next block. Front running in blockchain occurs when a participant, often a watcher, miner, or validator, obtains information about a pending transaction and rapidly executes a competing transaction to capitalize on it. This is commonly done to exploit price fluctuations in DeFi platforms where the order of transactions on the blockchain determines transaction execution.

Unravel the Impact Of Blockchain On Bug Fixing - 02
Credits: Simple Explanation of Front Running by Wes Draper - Source Youtube

Already H4cked -> Negotiations

If an attacker successfully front-runs the bug-fix transaction and exploits the bug, it is crucial to negotiate with the attacker to mitigate the damage and protect users' funds. In such cases, working with experts in the field and involving law enforcement might be necessary to resolve the situation.

Trust Security lays out a standard for the lines of defense in such scenarios where negotiations are inevitable. The main pointers from their piece for the context focus on the fact that “a sophisticated negotiation plan needs to be put in place to prepare for all eventualities.” And that a good strategy must take into consideration the following:

Source: Case for the defense

Circuit Breakers: Pause, Emergency, Exits, or actions that fall in the category are components that reduce the potential of overall loss and play n essential role in the line of defense. As stated in the linked article above, we find a relevant fact: “Limited-loss schemes are incredibly powerful because ideally, they are independent of the rest of the functionality.”

User Communications

If the attacker is not caught and the incident passes the initial response period, it is vital to handle the situation transparently. Users should be provided with detailed information about the attack, the bug, and the measures taken to resolve the issue. Additionally, steps should be communicated to prevent similar incidents in the future. Consideration should be given to compensating affected users to restore their trust in the smart contract and the development team.

In a war room, DevSecOps is a crucial part of the team. Their main responsibility is to manage patch transactions while being transparent with the affected community. Transparency is an essential blockchain component; trust cannot be effectively established in the wider blockchain landscape without it. Therefore, it's necessary to replace trustlessness with transparency to ensure confidence in the blockchain.

Disclosure and Post-Mortem Report

After successfully patching the code, it is important to disclose the issue professionally and safely to the user base. A comprehensive post-mortem report should be shared detailing the bug, its impact, the steps taken to address it, and the measures implemented to prevent similar incidents. The team may also consider hiring third-party auditors to conduct regular security audits to minimize the likelihood of future bugs. These steps aim to ensure transparency, accountability, and the protection of users' funds when addressing and fixing bugs in a blockchain system.


Fixing bugs in blockchain systems involves unique considerations due to transparency, permissionlessness, and users' funds at risk. Once a bug is identified, the development team analyzes the code and creates a fix implemented as a transaction on the blockchain. However, the transparent nature of blockchain introduces the risk of front-running, where an attacker exploits the bug fix. Negotiation and collaboration with experts may be necessary in case of exploitation. Transparent handling, user communication, and compensation may be required to restore trust. After patching, a detailed disclosure and post-mortem reports are essential. Regular security audits can help prevent future bugs.

This blogpost focuses on Demystifying Smart Contracts & Auditing and is the first part of the audit course. See primer here.

Definition of Smart Contract (feel free to skip :p)

A smart contract is a software program written in a contract-oriented programming language such as Solidity. The beauty of a smart contract lies in its ability to operate autonomously without the need for a central authority to oversee its processes. This means that once implemented, the contract can run without human intervention and enforce its terms autonomously.

Some more redundant stuff; expand to get a refresher on the basics

Smart contracts can interact with other contracts, users, or external systems through APIs. They are able to receive and process inputs by performing computations, access and update data stored on the blockchain, and trigger events based on predefined conditions. The code within the smart contract can include conditional statements, loops, and data structures to handle complex logic and decision-making. Different blockchains and blockchain ecosystems use different languages to write smart contract code. For example, Solana uses Rust, Cosmos uses Go or Rust, Bitcoin uses scripts, and Ethereum uses Vyper or Solidity.

Behind the Scenes of Auditing Smart Contracts

This article series is targeted to an audience comprising of seasoned blockchain security professionals.

As discussed in the primer blog, we at BlockApex Labs have picked the flag to lead the standardization of an advanced knowledge base for blockchain security.

It is now common knowledge that Solidity is a contract-oriented programming language used to write smart contracts on Ethereum Blockchain, so let’s start and ponder over the several phases a solidity smart contract goes through before its equivalent bytecode is generated and is ultimately stored on the EVM.

Solidity Code

The process begins with the developer writing Solidity code. This code can be written in the Solidity programming language and may contain bugs, vulnerabilities, or other syntactical, semantical, logical, or run-time issues.

The Solidity compilation process involves several stages of transformation, analysis, and optimization, resulting in the final EVM bytecode that is stored on the Ethereum network. The steps of the Solidity compilation process are susceptible to manipulation, and an advanced adversary can exploit them for personal gain.

Rememeber, an adversary/ malicious actor with an advanced knowledge set can cause harm to the system as all of the stages mentioned hereon are prone to manipulation.

Infiltrating the EVM-I: Demystifying Smart Contracts & Auditing

Compilation Breakdown

Solidity code goes through two main passes during compilation: the first and second phases.

1. First Pass Compilation

The first pass of the compilation process involves the following steps:

1.1 Lexical Analysis/ Tokenization

During the first phase of compilation, which is lexical analysis, the Solidity code is tokenized, broken down into a series of tokens (the arrangement of characters that defines a unit of information in the source code), which includes individual words, symbols, and operators. This step helps identify the fundamental elements of the code as defined in the Solidity Lexer.

1.2 Syntax Analysis/ Parsing

The tokens are parsed to generate an Abstract Syntax Tree (AST), representing the structure of the Solidity code in a hierarchical manner. This step ensures that the code is syntactically correct and conforms to the rules and specifications of the Solidity programming language defined in the Solidity Parser. The steps involved are; noting syntax errors, helping in building a parse tree, acquiring tokens from the lexical analyzer, and scanning for syntax errors, if any.

1.3 Semantic Analysis/ Type Checking

The AST is subjected to type checking, where the compiler verifies that the code follows the type rules defined by Solidity. It checks that variables are declared and used correctly, function calls are valid, and data types are compatible. Type checking helps identify type-related errors and ensures type safety within the code.

1.4 Intermediate Representation

Solidity can generate EVM bytecode in two different ways: Either directly from Solidity to EVM opcodes (“old codegen”) or through an intermediate representation (“IR”) in Yul (“new codegen” or “IR-based codegen”).

  1. EVM Opcode
    At this point, the AST is subjected to one of the two intermediate representations, called assembly-based IR, aka EVM opcodes. This stage introduces an additional level of abstraction, enabling optimizations based on the rules defined below in the optimization cycle defined in section 2.1.a. below.
  2. YUL IR
    The Solidity code’s AST can also be converted to an intermediate representation known as YUL IR, a low-level language resembling EVM bytecode. This allows further optimization, using the Yul IR’s LLVM-based optimizer, as the Solidity code is transformed into a structured format.

2. Second Pass Compilation

The second pass of the compilation process involves code optimization and artifacts generation.

2.1 Code Optimizations

The bytecode can be supplied to the respective optimizer based on the type of IR codegen, either the EVM opcode or the Yul IR codegen. The “old” optimizer operates at the opcode level and the “new” optimizer that operates on the Yul IR code.

  1. The opcode-based optimizer
    This module operating on assembly code applies a set of simplification rules. It also combines equal code sets and removes unused code. The old optimizer performed some basic optimizations, which are set by default in the versions of solidity language; however, for extra optimizations like 
  2. The Yul-based optimizer
    This module is much more powerful because it can work across function calls. It consists of several stages and components (such as SSA Transform, Common Subexpression Eliminator, Expression Simplifier, Redundant Assign Eliminator, and Full Inliner) that all transform the AST in a semantically equivalent way with the goal of ending up either with shorter or at least marginally longer code that will allow further optimization steps.

Some of the common compiler optimizations utilized by both modules are discussed below.

Compiler Optimization Techniques

Following the conversion to an assembly-based IR or the Yul-IR, the code again undergoes optimization techniques such as reordering instructions, removing irrelevant operators, etc. These optimizations go beyond simple transformations and delve into more intricate modifications that can significantly impact the execution of the code.

Some of the commonly employed techniques at this stage are:

  1. Instruction Reordering
    The order of instructions within the assembly-based IR can be rearranged to optimize the flow of execution and minimize overhead. Think of it like rearranging puzzle pieces to create a smoother path. The compiler aims to reduce redundant computations and minimize memory access by strategically reordering instructions, resulting in faster and more efficient code execution. 
  2. Common Subexpression Elimination
    This optimization technique identifies repetitive subexpressions within the code and replaces them with a single calculation, eliminating redundant computations. Think of it as simplifying equations. By reducing the number of repeated operations, the compiler minimizes execution time and improves the overall efficiency of the code.
  3. Constant Folding
    Constant folding involves evaluating and simplifying expressions that involve only constants at compile time. Think of it as simplifying mathematical equations with known values. The compiler eliminated the need for runtime calculations by precomputing constant expressions, leading to faster execution and reduced computational overhead.
  4. Loop Optimization
    Loops play a critical role in many smart contracts, and optimizing their performance is crucial. The further optimization stage applies loop-related techniques such as loop unrolling, loop fusion, and loop-invariant code motion. These techniques aim to reduce loop overhead, minimize branch instructions, and optimize memory access patterns for improved performance.
    Loop fusion is a gas optimization pattern that comes highly recommended, but it is currently not a built-in feature of Solidity.
  5. Control Flow Optimization
    The compiler analyzes the code's control flow and applies transformations to optimize branch instructions and minimize conditional checks. Techniques like branch prediction, jump threading, and loop inversion are used to streamline the control flow and reduce the number of unnecessary branches. Think of it as optimizing a roadmap for efficient travel that results in faster and more efficient execution.

The compiler strives to extract maximum efficiency from the assembly-based IR by employing these advanced optimization techniques. Each optimization is carefully designed to minimize unnecessary computations, memory access, and branch instructions, ultimately resulting in highly optimized code that can be executed more rapidly and efficiently on the Ethereum Virtual Machine (EVM).

2.2. EVM Bytecode Generation

Once the IR is optimized, either assembly-based (EVM opcode) or Yul IR-based, it is transformed into the final EVM bytecode. The EVM bytecode is a low-level binary representation that the Ethereum Virtual Machine (EVM) can understand and execute. It consists of instructions and data representing the smart contract's behavior and logic.

What happens once the solidity code is finally converted into its final form of EVM Bytecode will be covered in the article series and in-depth in the Smart Contract Security Auditing 401 by BlockApex.
Let's remember for now that until the smart contract is deployed, the attack windows are shaded. This means that a malicious actor cannot view the contents of a legitimate protocol.
However, the tables turn once the EVM bytecode is formed and the smart contract goes live.

3. Artifacts Generation

Along with the EVM bytecode, the compilation process also generates the Contract Application Binary Interface (ABI). The ABI provides a standardized way for external entities to interact with the smart contract, defining the functions and their inputs/outputs.

Enter the Dark Forest

Solidity code is part of a larger system, i.e., the blockchain. Blockchains are of adversarial nature; participants can engage in strategic and competitive actions to gain advantages or exploit vulnerabilities.

For instance, participants can observe pending transactions and choose to exploit this information by engaging in front-running or sniping activities, attempting to execute their own transactions ahead of others.

It's important to note that the components of the blockchain system can be manipulated if individuals possess advanced and appropriate knowledge to do so.

Let’s look at a blockchain's components and how they may be manipulated.

1. Consensus Algorithm

Malicious actors can exploit vulnerabilities in the consensus algorithm to gain control over the network or disrupt the consensus process via various types of attacks such as 51% attacks, selfish mining attacks, double-spending attacks, etc.

2. Transaction Pool

Manipulating the transaction pool can involve prioritizing certain transactions over others or spamming the pool with invalid or malicious transactions by 

  1. submitting a high gas tx to push other txs out of the pool
  2. submitting spam txs to increase the size of the pool in order to slow down the tx processing

3. Block Creation

Malicious actors can manipulate block creation by creating invalid blocks or withholding valid blocks to perform selfish mining attacks

4. Smart Contract Execution

Smart Contracts are prone to vulnerabilities in code and logic. Or the execution environment can be tested to perform attacks such as reentrancy attacks or integer overflow attacks, which can lead to unauthorized access, financial losses, or unintended consequences.

5. Forking

Forking can have ill intentions, such as performing double-spending attacks, altering transaction history, or manipulating the consensus algorithm.

6. Network Protocol

Network protocols can have various types of attacks,
such as Sybil attacks, eclipse attacks, and routing attacks.

7. Node Software

Vulnerabilities in the node software can be exploited to perform various types of attacks, such as denial-of-service attacks or remote code execution attacks.

8. Miner Extractable Value (MEV)

Miner Extracted Value (MEV) is performed at the expense of other users via Uncle-bandit attacks, time-bandit attacks, sandwich attacks, or frontrunning and backrunning attack.

9. Governance Mechanisms

Malicious actors can exploit governance mechanisms to introduce malicious changes, manipulate decision-making processes, and control the network for personal gain.

In the adversarial ecosystem of Blockchain, each interaction stage has seen several exploits over the span of time. These attack windows can be made vulnerable by an actor having a higher knowledge set. For a blockchain security researcher, it is vital that these stages are never hidden from one’s PoV.

Smart Contracts Hold Valuable Data

If you’re following the blog by now, you must be quite familiar with the idea of smart contracts. 

Smart contracts hold valuable data. The term "valuable data" refers to information that has inherent worth, whether it is in the form of financial assets, digital assets, intellectual property, personal information, or any other type of data that holds value to individuals or organizations.

The valuable information that smart contract hold includes, but not limited to, are Tokenized assets, financial information, digital property, intellectual property, personal and identity data, supply chain and logistics data, and data marketplaces.

Why protect smart contracts from the start?

We are aware that smart contracts have the primary purpose of executing agreements and removing intermediaries; they are immutable, and most importantly, they hold valuable data. Yet they are written and designed by humans. People like you and me are very much capable of making mistakes, so a need arises that the development of such crucial components of the blockchain ecosystem is made secure by design.

Why is that? A couple of key reasons that prove effective are as follows.

Immutability of Deployment: Once a smart contract is deployed on the blockchain, the code is essentially immutable. Therefore, ensuring the contract's security before deployment is crucial to mitigate any potential risks.

Permissionless Nature of Interaction: Smart contracts operate in a permissionless environment; this means that adversaries and potential attackers also have unrestricted access to the contract's code.

Considering the above factors, malicious actors can scrutinize the contract for vulnerabilities, attempt to exploit weaknesses, or launch attacks to extract rewards or disrupt the contract's functionality. It is essential to proactively secure the contract to protect it from such adversarial actions.

We hereby conclude that developers are responsible for making their smart contracts secure by default, and therefore, they must take measures to identify and address potential security risks during development.

In a nut shell (TL;DR)

Blockchain technology offers more than just decentralization and addresses the limitations of centralized systems. Smart contracts, which are pieces of code stored on the blockchain, automate and execute agreements without the need for intermediaries. They provide efficiency, security, and transparency. However, smart contracts and the components of the blockchain ecosystem are prone to manipulation and vulnerabilities at the finer steps of their execution.

Smart contract auditing is crucial to identify and address these vulnerabilities, ensuring the security of valuable data held within smart contracts. Auditing helps developers protect user funds, maintain contract integrity, and foster trust in the blockchain ecosystem. Thorough security audits and best practices during development are essential to make smart contracts secure by default and prevent the challenges of fixing bugs once deployed on the immutable blockchain.

TL;DR: BlockApex is revolutionizing the smart contract audit industry by offering an advanced auditing course for seasoned professionals to learn advanced strategies for blockchain security guardians. With a focus on the Ethereum Virtual Machine (EVM) niche areas, the course skips the basics and provides practical and advanced insights. The article series offers a sneak peek into the course, covering the journey of a smart contract from its Solidity version to bytecode on the EVM. It explores security vulnerabilities at each stage and highlights the importance of thorough auditing. BlockApex aims to enhance the industry and prevent financial losses by equipping auditors with comprehensive knowledge. Join us in the article series and course to stay ahead in the evolving world of blockchain security.

Spilling the Beans

27 months back, code4rena released its first report, showcasing the top 10 auditors who participated in the first-of-its-kind open audit contest. Featuring a bug bounty-hunting approach, code4rena boldly entered the competitive audit industry, going head-to-head with established names like Trail of Bits, ConsenSys Diligence, and Certora. C4 turned the tide when just after two years, we now see a whopping increase in smart contract auditors and security researchers contributing to various security niches of the wider blockchain ecosystem.

What do you deduce then?

We need to remind ourselves of the fact that a smart contract audit serves a mightier purpose beyond just finding bugs; it's about ensuring the security of the application, its users, and the blockchain at large.

So, what exactly is your plan?

At BlockApex, we firmly believe that a standardized auditing approach that exceeds the fundamentals and caters to seasoned professionals in the industry is crucial in today's increasingly competitive landscape.

We at BlockApex are leading the charge in this field. With a specialized curriculum designed specifically for experts is currently in development based on extensive research from in-depth technical grounds supplied with statistics and psychological behaviors, we aim to provide a 401 university-level course that skips auditing basics, focuses on niche areas of EVM with an auditor’s lens, and has a prerequisite of solid practical experience for our potential audience.

Hmm, Tell me more!

Following this, BlockApex will share some teasers on the course via an article series, for which the first part will be shared in the upcoming week!

The article series will focus on visualizing what a smart contract looks like as it is compiled and deployed on the blockchain. First, we explicitly go through the shape and form a contract takes from its solidity version to a Yul IR format, finally to the bytecode form, then to be stored as executable opcodes on the EVM. Once the definition is covered, the course steers toward emphasizing the aspects of security that open up potentially weakening windows at each step the contract takes. This will unlock an auditor's mind on what to look for, where to look for, and how to approach such windows only once the atomic stages are well defined.

And what should I expect?

The article's outset offers a mere glimpse of the course, indicating the extent of what will be uncovered later. For instance, defining the smart contract is not going to say that a smart contract is a piece of code that runs on the world computer.

We equally hate that all that basics resurfacing time and again! Come on, peeps! Let's accept it and spread the word that starting off with defining what’s a blockchain is really old school

Instead, here you will see how the contract goes through the compiler's semantic tokenization and how the compiler embraces the tokens to parse the instructions before transpiling it to Yul and Assembly for an intermediate Representation. We further expand on the optimizations the transpiled code goes through as it is converted to the EVM executable bytecode.

The article series dives deeper into exploring the attack surfaces during the stages of smart contract deployment along with the components of blockchain that are prone to impact those stages. The fact that components of the wider blockchain ecosystem are permissionless to interact with allows an adversarial actor with an advanced knowledge set to bring harm to it in any sense that was not unveiled before or that might have been missed, neglected, or stepped over during the security iterations.

Closing Off

We believe that the audit space is expanding like never before, and we are contributing in the way we found it fit. It is high time that we learn more from our previous experiences, not make the same old mistakes and not just keep making people lose their money, trust, hopes, and lives over mere insecure code. See you in the article series and course.

Demystify Smart contracts and Auditing in the first part of our series.

Designed & Developed by: 
All rights reserved. Copyright 2023