on-chain realtime hack prevention

we are building on-chain firewalls

What is an On-Chain Smart Contract Firewall?

Smart contract hacks have been plaguing DeFi protocols, bridges, and more.

Today, in order to defend themselves, protocols perform audits, open bug bounties, and implement monitoring.

All of these steps are absolutely crucial. Nevertheless, whenever a vulnerability is discovered by an attacker, most exploits can drain funds in a very short period of time, sometimes even within a single transaction. To prevent these hacks from happening, we need an on-chain tool.

You can think of the Smart Contract Firewall as an additional layer of security for DeFi protocols.

Our Firewall is a set of Solidity Smart Contracts that allow you to:

• Define critical parameters for your protocol (e.g., TVL) and track these parameters over time.
• Detect that a transaction (or multiple) is causing the protocol to operate outside its normal activity (e.g., unusual liquidity outflow, indicative of a potential hack happening).
• Implement a set of protective measures, including transaction blocking, protocol pausing, fund freezing, or controlled fund withdrawal, before the transaction is committed and funds exit the protocol.

The Firewall provides a way to detect abnormal changes in your protocol directly on-chain, that could be indicative of a hack. That means that you can act upon abnormal activity, whenever it occurs, directly on the blockchain.

Our Roadmap

Phase 1: Research & Proof-of-Concept

• Estimated Duration: 1 Month
• Estimated delivery date: 30th August 2023

This phase will focus on in-depth research and the creation of proof-of-concepts demonstrating how tailored firewall can enhance the security and functionality of protocols.

Milestone 2: Prototyping & Production

• Estimated Duration: 2 Months
• Estimated delivery date: 30th October 2023

The second phase will concentrate on the development and testing of firewall prototypes based on the findings of the first phase. The prototypes will showcase the practicality and benefits of integrating on-chain firewalls into DeFi Protocols.

Milestone 3: Testnet Deployment

• Estimated Duration: 1 Month
• Estimated delivery date: 30th November 2023

The final phase will involve the testnet deployment of all firewall components, followed by rigorous testing and refinement to ensure the system is ready for potential mainnet audits and protocol implementations.

Our Goals

• Reliability
• Inexpensive in gas terms. The overhead must remain negligible.
• Not adding complexity to the protected contract(s): Implementing the Firewall must not require more than a few lines of Solidity code.
• It must scale

TL;DR ⤵️

How Does It Work?

You can track any critical metric that could be indicative of an exploit happening for your protocol.

Let's take the example of TVL:

Every time there is an inflow or outflow of liquidity, you add a call to the Firewall contract to track the TVL at this point in time within your protocol. The Firewall will keep a history of your TVL over time. This allows you to define a threshold so that if more than X% of the TVL exits the protocol in less than Y number of blocks, the Firewall triggers. When this happens, the Firewall status is updated before the transaction is committed, which allows you to implement a set of defensive strategies to prevent the transaction from going through, such as rejecting the transaction or freezing the funds.

All of this happens synchronously, at the contract level in Solidity. This means that exploits are prevented from happening automatically, and directly on-chain.

You can find a more detailed explanation of the Firewall here.

Protective Measures

Once the Firewall gets triggered, protocols can use it in various ways to protect their assets. Here are some of the protective measures that can be taken:

Implementation and Integration

1. Setup configuration: Define the parameter you want to track (e.g: TVL) and a maximum threshold that should not be reached within a custom time period.
2. Identify Entry Points: This step consists of listing functions that affect your parameter. For TVL, that would be functions that increase or decrease liquidity (e.g., deposit & withdraw).
3. Integrate the Firewall: For each entry point, you must add a single line of code to call the Firewall to track this parameter.
4. Choose and Implement a Defensive Strategy: Every time you call the firewall, it returns its status. If the firewall triggers, you implement one of our strategies: reject transaction, freeze funds, pause protocol, etc.
5. Monitor and Adjust: After integration, you can monitor the operation of the firewall and adjust the parameters as needed. This allows you to fine-tune the system to better protect your protocol.

Remember, the key to effective use of the Firewall is understanding your protocol's specific needs and adjusting the parameters accordingly. With the right configuration, the Firewall can provide a robust line of defence against potential hacks and unauthorized fund withdrawals.

What does a Solidity integration look like?

function withdraw(uint256 withdrawAmount) external override {
	[...]
	// Firewall implementation
	bool firewallTriggered = IFirewall(firewall).decreaseParameter(withdrawAmount);
	if (firewallTriggered) return;
	[...]
}

Why it is important what we build

Most established exploit prevention procedures like performing security audits are important, yet, we must understand that these have limitations and cannot asses risks beyond code produced by the engineering team. External dependencies as potential attack vectors are frequently being disregarded or assumed to be safe, as they lies outside a single protocol’s spectrum of actionable security measures. Given the example of the most recent curve exploit: Auditing legacy versions of the Vyper compiler, was undoubtably out of the protocol’s security scope.

Even when exploring hypothetical scenarios, e.g.: All protocols using Vyper coming together beforehand and collectively sourcing audits for Vyper versions 0.2.15, 0.2.16, and 0.3.0, it still would not have solved the underlying problem: The unknown (un)knowns of vulnerable external dependencies. Given the infinite amount of unknowns, it is merely impossible to effectively draw the line between where to start and stop security audits.

This is why protocols have to hope for the best while keeping their fingers crossed🤞once deploying code to production. In essence: Hoping they won’t have to face any unknown (un)knowns in production, but if so, hopefully only through bug bounties programs and whitehats. Usually, the financial incentives for blackhat hackers largely outweigh bug bounty initiatives, leading to exploits of undiscovered attack vectors. Furthermore, in accordance to Murphy’s Law, the above strategy would lead to a hack in any case, sooner or later.

Actionable opportunities to protect the protocol

Adding Firewalls to the protocols production deployments

As an additional layer of protection to the protocol Firewalls can be added to mitigate in-production risks.

Even tough, the way the protocol gets exploited relies on an unknown (un)known, the target of the exploit always is a KNOWN KNOWN, being liquidity.

→ Therefore, we can work with the known characteristics of every exploit happening, instead of trying to solve what we cannot know.

We are aware of the attackers target: extracting Liquidity.

We are aware of external dependencies, will most likely lead the attacker to his target.

→ knowing and understanding these two crucial pieces of information, we can design a security system around these two vectors.

As a wrapped layer of security around the protocol, the attacker will not be able to reach his intended target: extracting liquidity, with external dependencies as his attack vector. Even when vulnerabilities occur (e.g. faulty compilers), an attacker will not reach his target, as the Firewall system operates as an independent layer of security for the protocol.

Whenever abnormal activity occurs, on-chain Firewall’s offer a range of protective measures, including blocking of transactions, pausing the protocol, freezing of funds, or controlled fund withdrawal, thereby providing a robust on-chain defence against potential hacks.

Resources:

• Twitter
• Team’s Website
• Docs
• Team’s Github Organization
• Demo Repository
• relevant Firewall Demo of a L&B Market