The DeFi segment of the cryptocurrency market has been encountering a wave of unfortunate incidents. Regrettably, hardly a week goes by without news of yet another hacking case. This worrisome trend has reached a critical point, demanding our utmost attention and concerted efforts.
Just recently, Poly Network, a prominent player in the field, fell victim to an audacious cyber attack.
Over the past seven months, a staggering $2.85 billion in funds has fallen victim to the relentless efforts of hackers within the DeFi market. Each month seems to embolden these perpetrators, leaving a trail of financial loss and uncertainty.
However, amidst these concerning circumstances, a glimmer of hope emerges from the latest breakthroughs in the field. This recent development holds the key to potentially regaining control over DeFi attacks and ending the scourge of hacking.
Let’s talk about what ERC-7265 is all about.
Introduction
ERC-7265 is a design implementation for the developers that will act as an additional layer of safety that will protect the funds of a protocol even if the core logic is exploitable.
ERC-7625 has also been termed as a ‘ Circuit Breaker ‘.
What is a circuit breaker?
Before we dive deep into how circuit breakers are going to look in implementation, let’s understand what a circuit breaker is.
In traditional finance systems, a circuit breaker is an emergency halt being put on an exchange to prevent a market crash in case of panic selling. These are pre-defined values that check for uncontrolled movement of the index in either direction.
Now let’s take a look at how circuit breakers will translate into the world of decentralization.
The reason why hacks like Poly Network, where huge sums of money get stolen, are possible is because there is a time gap between the occurrence of the hack and action from the side of developers.
It is due to this time discrepancy that the impact of the hack gets worse with each passing second.
Circuit breakers solve this problem by granting the developers the ability to intervene in case there is a malicious outbound of assets.
Since a hack involves a series of transactions to manipulate the protocol into extracting funds, circuit breakers will act as an initial warning to make the protocol aware of any suspicious activity.
They can monitor the situation and intervene before irreversible damage can take place.
Technical details
The implementation of the circuit breaker will be percentage-based rate limiting. The percentage-based rate limit is preferred to hardcoding a number since this will prevent cases like that of incorrect updation of token limit by a team member with the increase in total volume over time.
Crossing the rate limit will trigger the circuit breaker and impose a condition on asset withdrawals which can be
- Delayed Settlement – The protocol opts to custody tokens and delays settlement when a circuit breaker is triggered.
or
- Revert – The protocol opts to revert withdrawal attempts when triggering a circuit breaker.
The developer team can decide on the imposed condition.
The circuit breaker mechanism is triggered specifically in cases where assets are being withdrawn or moved out of the protocol. This feature proves highly valuable as it allows users to freely engage in various activities within the protocol while placing a temporary delay on outbound transactions. This approach ensures that any potential malicious activities or unauthorized asset outflows are promptly identified and addressed.
The proposal also emphasizes on mandatory inclusion of Post-Hack-Recovery Methods. This will ensure that funds are not locked in the circuit breakers, and admins have the ability to recover them.
A sample contract implementation can be found in the EIP itself. Here is a list of functions that have been defined in the EIP –
- registerAsset
- updateAssetParams
- onTokenInflow
- onTokenOutflow
- onNativeAssetInflow
- onNativeAssetOutflow
- claimLockedFunds
- setAdmin
- overrideRateLimit
- overrideExpiredRateLimit
- addProtectedContracts
- removeProtectedContracts
- startGracePeriod
- markAsNotOperational
- migrateFundsAfterExploit
- lockedFunds
- isProtectedContract
View Functions
- admin
- isRateLimited
- rateLimitCooldownPeriod
- lastRateLimitTimestamp
- gracePeriodEndTimestamp
- isRateLimitTriggered
- isInGracePeriod
- isOperational
Below are the different states and their transitions and diagrams accordingly.
States:
- Operational: This is the normal state of the contract where all the functions work as expected. This state is determined by the variable ‘isOperational’.
- Rate Limited: This state is determined by the variable ‘isRateLimited’. When the contract is rate-limited, certain actions, like claiming locked funds, are not allowed.
- Grace Period: This is a special state where withdrawals are still allowed even after a rate limit has been triggered. This state is determined by the timestamp ‘gracePeriodEndTimestamp’.
Transitions:
- Operational to Rate Limited: This transition happens when the rate limit is triggered, as checked in the ‘_onTokenOutflow’ function.
- Rate Limited to Operational: This transition can be triggered manually by the contract admin by calling the ‘overrideRateLimit’ or ‘overrideExpiredRateLimit’ functions or automatically when the ‘rateLimitCooldownPeriod’ has passed.
- Rate Limited to Grace Period: This transition happens when the admin manually calls ‘startGracePeriod’ function.
- Grace Period to Operational: This transition happens automatically when the grace period end timestamp is exceeded.
- Operational to Not Operational: This transition happens when the admin manually calls ‘markAsNotOperational’.
Note that the Operational and Not Operational states are more like “modes” of the contract. When the contract is not operational, it means that it’s effectively “shut down”, and most functions will not be executed.
The contract also includes a notion of ‘protected contracts‘, which can interact with it, and an ‘admin’, who has certain privileges such as triggering the grace period, adding or removing protected contracts, etc.
Security Considerations
There can be two scenarios where funds can still be stolen if there is a mistake at the implementation level of Circuit Breakers; these are:
Unsafe Arbitrary Calls – If there is an ability to delegate ownership, i.e. the ability to execute anything on behalf of the protocol coded anywhere in the smart contract, which is not safe.
Untracked or Unprotected Flow – These are the mistakes that a developer can make at the integration point of a circuit breaker, like no checking for inflows and outflows.
Despite this, these types of mistakes are limited and are easy to spot in an audit process.
Things To Note
- The proposed implementation of circuit breakers in the protocol introduces a controlled form of centralization through the role of circuit breaker admins. While centralization can be a cause for concern due to the potential risks associated with centralized control, circuit breakers offer a unique opportunity to leverage centralization in a positive manner.
- They provide a mechanism for real-time intervention in the event of a hack, effectively extending the advantages of centralization by enabling swift action to mitigate potential damages.
- Moreover, circuit breakers can be configured to respond to sudden price changes detected by oracles. By monitoring price manipulation attempts, circuit breakers add an extra layer of security and help maintain the integrity of the protocol. Such proactive measures serve to safeguard user assets and minimize the impact of potential exploits or vulnerabilities.
- Even in cases where an exploiter manages to operate within the rate limit thresholds, the implementation of a circuit breaker significantly reduces the overall impact that would have otherwise occurred. It grants additional time and opportunity to detect and address the exploit, limiting the potential damages and enabling a more thorough investigation to prevent similar incidents in the future.
- This proposed base standard for circuit breakers is designed to accommodate further extensions, such as the introduction of tokenized lock positions. This flexibility allows for the development of enhanced features and functionalities that can be built upon the existing circuit breaker framework, expanding its capabilities and adaptability to evolving security needs.
Conclusion
While circuit breakers introduce an element of centralization, they do offer significant benefits, especially for early-stage protocols that are inherently more volatile. However, it remains essential for every protocol to strive towards achieving greater decentralization.
Circuit breakers are designed with flexibility, allowing protocols to migrate away from their usage as they mature and evolve. As protocols progress, it is crucial to implement measures that gradually reduce centralization and empower community governance and control.
Although circuit breakers effectively mitigate the impact of potential damage, it is important to recognize that no security implementation can guarantee absolute protection.
Therefore, it is highly recommended for protocols to undergo comprehensive security audits conducted by reputable third-party firms.
These audits provide an additional layer of assurance and help identify any vulnerabilities or weaknesses in the protocol’s design, further strengthening its security posture.
By emphasizing the importance of decentralization, conducting thorough security audits, and continually improving protocols, the DeFi ecosystem can enhance its overall resilience, trustworthiness, and ability to withstand potential threats.
This concerted effort reinforces the commitment to creating a robust and secure environment for users and fosters confidence in the broader Web3 community.
