HashEx Security Blog - Medium

Top 10 Biggest Crypto Hacks of Q3 2024

Polly Traore — Sat, 05 Oct 2024 13:27:57 GMT

The third quarter of 2024 had the cryptocurrency industry facing significant challenges, with losses exceeding $409 million due to hacks. The attacks targeted both centralized finance (CeFi) and decentralized finance (DeFi) platforms, as attackers exploited both technical and non-technical vulnerabilities. Below is a breakdown of the most notable incidents, categorized into technical and non-technical hacks.

Top Tech Attacks

Penpie Protocol: $27M

Type of Attack: Smart Contract Vulnerability
Description: $27 million has been drained from the Penpie platform due to a weakness in the smart contract logic. The issue lies in the poor handling of token transfer operations within the contract: unauthorized transactions were allowed because of improper validation of conditions. This flaw was manipulated by the attackers and allowed them to siphon off the protocol’s assets.

LI.FI Protocol: $10M

Type of Attack: Smart Contract Vulnerability
Description: A cross-chain liquidity protocol, LI.FI Protocol, had its security breached as a result of vulnerabilities in its cross-chain interaction mechanism. After a flaw in the protocol’s logic has been discovered by the hackers, they could perform unauthorized transactions between different blockchains. The loophole in handling the transaction permissions led to the loss of $10 million. This issue once again highlighted the risks of cross-chain solutions that don’t go through the necessary security audits.

Ronin Bridge: $12M

Type of Attack: Smart Contract Bug in Upgrade
Description: On August 6, 2024, the Ronin Network bridge fell victim to exploitation after the contract upgrade. An uninitialized variable _totalOperatorWeight was at the root of the issue, as it disabled a crucial security parameter whose function was to verify cross-chain transactions. As a result, a malicious MEV bot managed to withdraw 4,000 ETH and $2 million in USDC, amounting to a $12 million loss.

Delta Prime: $6M

Type of Attack: Compromise of Admin Keys
Description: DeFi platform Delta Prime experienced a loss of $6 million after its admin keys were compromised. The platform’s administrative wallet was used by the attacker to manipulate proxy contracts. Delta Prime’s contracts were redirected to malicious alternatives and the ordeal resulted in the draining of liquidity pools on the Arbitrum network. Stolen USDCs in the amount of $4.5 million were converted to ETH. The first attack was quickly followed by a second wave of transactions which brought the total loss to $6 million.

Terra Blockchain: $6.5M

Type of Attack: Exploit in Third-Party Module
Description: For the Terra blockchain, July has brought a massive attack. $6.5 million was lost because of a vulnerability discovered in a third-party protocol, IBC Hooks, used for cross-chain token transfers and contracts. After the module had been patched in April of 2024, the Terra upgrade in June failed to acknowledge the patch, which left the blockchain exposed. This oversight was quickly exploited by the attacker and resulted in assets such as USDC and ASTRO tokens being drained from the protocol. Several emergency measures had been taken since, including halting the blockchain to contain the damage.

Top Non-Tech Attacks

WazirX: $235M

Type of Attack: Private Key Compromise
Description: The largest loss of the quarter was faced by the Indian cryptocurrency exchange WazirX. A sum of $235 million was stolen from the exchange in July 2024. Unfortunately, poor private key management was a reason for this attack, as it allowed hackers to gain access to the exchange’s hot wallets. Once inside, they transferred large amounts of assets to their own wallets, exploiting the platform’s lack of multi-signature defensive mechanisms.

BingX: $52M

Type of Attack: Phishing
Description: in September 2024, a Singapore-based exchange BingX lost $52 million due to a sophisticated phishing attack. The attackers employed social engineering techniques to deceive employees into revealing sensitive security information. Once obtained, the hackers executed a series of unauthorized transactions, that drained millions from the platform.

Indodax: $22M

Type of Attack: Hot Wallet Compromise
Description: An Indonesian exchange Indodax was hacked on September 10, 2024. The attack resulted in the loss of $22 million. The exchange’s hot wallets were targeted after the attackers breached the protocol’s withdrawal system. Vulnerabilities in the withdrawal processing system were specifically exploited to transfer funds from several networks, including Bitcoin and Ethereum. After converting stolen tokens to Ethereum, the hackers used Tornado Cash to obscure the transaction trail.

ETHTrustFund: $2.2M

Type of Attack: Rug Pull
Description: The project ETHTrustFund was exposed as a rug pull on July 16, 2024. After the developer, known as “Peng,” transferred over $2.2 million from the project’s treasury to personal wallets, it became obvious that the project had been rug-pulled.

Initially, ETHTrustFund positioned itself as a legitimate project that was built upon the popularity of Base and meme culture. However, it turned out to be a scam as the funds were laundered through RAILGUN, a privacy service, making it difficult to trace the transactions

Several DeFi platforms: $57M

Type of Attack: Market Manipulation
Description: On September 14, 2024, an attacker exploited low-liquidity pools across multiple DeFi platforms. The prices were manipulated so that the malicious actor managed to extract $3.3 million in Ethereum and USDC. The attacker used a flash loan to artificially inflate slippage in targeted pools, which drastically impacted the asset prices. By executing swift arbitrage trades, the attacker moved large amounts of liquidity to their own wallets. This type of exploit takes advantage of poorly balanced liquidity pools and the volatility created by price manipulation, revealing the dangers of insufficient liquidity monitoring in DeFi protocols

Conclusion

The third quarter of 2024 demonstrated that vulnerabilities persist in both CeFi and DeFi platforms. While technical flaws in smart contracts accounted for a significant portion of the losses, poor private key management, and social engineering attacks were also highly damaging. If there is a lesson to be learned from these incidents, it’s that enhanced security audits, proper management of admin keys, and stronger multi-signature protections are essential to safeguarding the cryptocurrency ecosystem from future breaches.

Follow HashEx news:
Announcement Channel | Twitter

Top 10 Biggest Crypto Hacks of Q3 2024 was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Event Horizon: Bringing DeFi Back to its Roots

Polly Traore — Wed, 04 Sep 2024 18:11:52 GMT

A true decentralized non-KYC exchange. These are the words that greet you on the website of the newest HashEx partner — Event Horizon.
The project is still in its early stages, so anyone can join the waiting list and become an early adopter of the technology that is set to put cryptocurrency back on track.
To find out more about Event Horizon and its course, we invited Thomas Kralow, the chairman of Event Horizon, to share his thoughts.

HashEx: Thank you for joining us, let’s start from the beginning, or rather, before the beginning. Your mission statement declares that “the crypto industry is steering away from its course.” Could you elaborate on that? Where, do you believe, the wrong turn has been made?

Thomas Kralow: The original vision of the crypto industry was to provide financial freedom and decentralization to everyone. However, over the years, we’ve seen a shift towards centralization, especially with the rise of centralized exchanges (CEXs) that enforce KYC and restrict user freedom. This has led to a compromise of privacy and autonomy, which are core principles of blockchain technology. The wrong turn was made when the focus shifted from empowering users to controlling them, which is why Event Horizon is committed to bringing the industry back to its roots by providing a truly decentralized and user-first platform.

HashEx: Event Horizon adopts a system of badges that can be earned prior to the release, can you tell us more about that?

Thomas Kralow: The badge system is our way of rewarding early adopters and building a strong community before the full release of our platform. Users can earn badges by participating in various pre-launch activities, such as completing certain trading tasks or referring others to the platform. These badges are more than just symbols of participation — they will unlock exclusive benefits and privileges when the platform goes live. It’s our way of saying “thank you” to those who believe in our vision and are willing to support us from the start.

HashEx: Now let’s travel a little into the future, what’s your ideal vision of Event Horizon? What do you want it to become in several years?

Thomas Kralow: My ideal vision for Event Horizon is for it to become the go-to decentralized exchange for retail traders across the globe. I want it to be known not only for its cutting-edge technology and security, but also for its commitment to empowering users by giving them full control over their assets without compromising on usability. In several years, I see Event Horizon as a major player in the DeFi space, facilitating millions of transactions daily and setting new standards for what a decentralized exchange should be.

“My ideal vision for Event Horizon is to become the leading decentralized exchange for retail traders worldwide, offering cutting-edge technology and security.”

HashEx: Projects like Event Horizon rely heavily on their communities. Are there any particular beliefs that you’d like your community to share

Thomas Kralow: Absolutely. We want our community to share our belief in financial freedom, privacy, and the importance of decentralization. We value transparency, mutual respect, and a commitment to continuous improvement. Our community is not just a user base; it’s a group of like-minded individuals who believe in the same principles that drove the creation of blockchain technology. We want them to be active participants in shaping the future of Event Horizon, providing feedback, and helping us evolve.

HashEx: HashEx is happy to fulfill Event Horizon’s development needs. Can you tell us a little about this partnership? Why did you choose HashEx over others?

Thomas Kralow: HashEx has a stellar reputation in the blockchain industry for their expertise in security audits and smart contract development. When we were looking for a partner, it was crucial to select someone who not only understood our technical needs but also shared our commitment to security and user empowerment. HashEx stood out because of their track record and deep understanding of decentralized technologies. Their involvement ensures that Event Horizon is not only secure but also scalable and robust, which are critical for our long-term success.

HashEx: What do you think a project requires today to succeed?

Thomas Kralow: To succeed today, a project needs a clear vision, strong technological foundations, and an engaged community. It’s not enough to just have a great idea; you need to execute it flawlessly while keeping your users at the forefront of every decision. Transparency, security, and continuous innovation are also key. In the fast-paced world of crypto, you have to stay ahead of the curve and be adaptable to changes in the market.

HashEx: The crypto industry seems to still be finding its footing. Do you believe it has the potential or any chances to replace the established financial system? What are the obstacles it’s facing?

Thomas Kralow: I believe that the crypto industry has tremendous potential to transform the financial system, but replacing it entirely will take time. The biggest obstacles we face are regulatory challenges, security concerns, and mainstream adoption. However, as technology continues to evolve and more people see the benefits of decentralized finance, I’m confident that we will see a gradual shift away from traditional systems towards more decentralized models. The key is to build platforms that are not only secure and efficient but also user-friendly and accessible to everyone.

HashEx: Thanks again for joining us and sharing your project! If there are any announcements you’d like to make, now would be the time!

Thomas Kralow: Thank you for having me! I’m excited to announce that we are planning several major updates in the coming months, including the launch of our mobile app and the introduction of new trading features. Stay tuned for more details, and we look forward to welcoming more users to the Event Horizon community. We’re just getting started!

Event Horizon is not yet another decentralized exchange. The project is ambitious and won’t settle for anything less than revolutionizing the rules of the crypto industry game. With a clear vision of security, community, and innovations, Event Horizon is preparing for its launch which, no doubt, will positively affect the DeFi world.

Follow HashEx news:
Announcement Channel | Twitter

Event Horizon: Bringing DeFi Back to its Roots was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is MEV and How Does It Impact Your Blockchain Transactions?

Polly Traore — Wed, 21 Aug 2024 16:09:36 GMT

Gleb Zykov, the co-founder and CTO of a HashEx Blockchain Security

In the early days of Bitcoin, miners could receive rewards for either mining a block or as commissions for a transaction with the highest gas price. The logic behind forming a block was relatively simple: get all the valid unmined transactions from the mempool, sort them according to their gas price, form them into a block, and then begin mining.

In time, as blockchain got more and more advanced, we witnessed the development of Turing-complete smart contracts on Ethereum and then the whirlwind DeFi growth. With all that, block producers received additional methods of turning profit.

It turned out that by including, excluding, and rearranging the order of transactions, block producers could now earn additional rewards. This mechanism was called MEV — maximal extractable value i.e. the biggest sum that block producers could earn.

The History of MEV

Even before Ethereum’s mainnet release, discussions regarding gaining additional profit began showing up online. Users have discovered that the public decentralized nature of blockchain allows “sneaking” a smaller transaction in front of a large one, so anyone can easily purchase assets at a lower price.

Because a larger purchase increases the asset’s value on decentralized exchanges, an earlier transaction can prove profitable, since the assets have been obtained prior to growth.

The term “MEV” was coined in 2019 after the research Flash Boys 2.0 was published. That was the first comprehensive research on the matter, that provided a detailed look into the issue.

How Does it Work?

Usually, miners, validators, or block producers have the authority to include, exclude, and rearrange certain transactions.

Imagine a scenario: you see an opportunity to earn money on a protocol. You realize that the opportunity has been available to everyone for a while, yet it hasn’t been exploited. So you prepare a transaction, send it, and eagerly await its mining to receive the desired reward. However, turns out someone jumps right ahead of you with a similar transaction and steals the reward for themselves from under your nose.

It’s only reasonable to wonder what are the chances of two people simultaneously finding the same opportunity. Pretty low, and to make matters worse, no one had been looking — there are programs and tools that automatically analyze the submitted transactions, and then modify the ones that can prove profitable for the benefit of their owner. If this works, the copycat transaction is sent ahead using frontrunning.

MEV Types

Arbitrage

Arbitrage is a way to profit from the price gaps on different platforms. Miners who notice said gaps can be the first to send their transactions to take advantage of them. These actions are considered to have a positive influence on the market because they help maintain relatively similar asset prices on different platforms and exchanges since bigger gaps can prove problematic.

Frontrunning

A MEV transaction is placed ahead of the original one. We have already discussed them earlier, noting that such a transaction is submitted ahead of the original one of a larger purchase on a DEX. Another mechanism involves copying the original transaction with small adjustments for the attacker to get the profit instead of the initial sender.

Backrunning

It’s similar to frontrunning, except the transaction is placed right after the original one. An example of this usage is buying a token first right after the project launch, as soon as it becomes available on the DEX.

Sandwich attack

It’s a combination of two previously described types of attack. The attacker sends two transactions: one before and one after the original one. This way, as opposed to a frontrun preceding a large purchase, the attacker can easily review and document their profit.

Liquidation

Lending protocols are often arranged in a way that allows a position to be liquidated by any user, which allows them to earn extra funds. Users have to compete for sending the liquidation transaction to receive the profit.

MEV prevention

It’s obvious that the possibility of using MEVs imposes additional commissions on users and brings additional risks. The Flashbots system was created specifically for combating MEVs. This system attempts to control MEVs by creating an open transaction auction.

Conclusion

The possibility of MEVs is a result of the open and decentralized structure of blockchain. This has both positive and negative effects. It’s vital for blockchain users and developers to understand the way the technology works to minimize the risks of becoming a victim of an unexpected attack.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

What is MEV and How Does It Impact Your Blockchain Transactions? was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now Live: Solana Token Auditor

Polly Traore — Mon, 15 Jul 2024 13:21:09 GMT

A quick and simple solution to your problems.

Solana has quickly conquered its segment of the crypto market and today, seemingly every day a new token appears on the platform. It’s impossible to keep an eye on all of them but investors, old and new alike, are looking for the best and safest opportunities.

To address this issue, we, within the company, have developed a quick solution for internal use. This tool has helped us obtain the necessary information regarding new Solana tokens. Today, we are happy to share it with all Solana users whether they want to invest or partner up with a new token.

Not all new projects on Solana and other chains can afford an expensive comprehensive audit to guarantee their security and best intentions. At the same time, existing explorers don’t always provide the necessary tools for a user to check the potential risks and assess the possibility of a rug pull.

A token owner may mint a large amount of tokens and rug pull.
An owner with excessive power can block any account from activities related to the token.
An owner can change any token information, including its icon, name, or anything else.

We launch Solana Token Auditor to give users an opportunity to receive the necessary data and be able to make an educated decision.

Our solution is simple and accessible to all users: Meet Solana Auditor Bot

Solana Auditor Bot is a tool bot, designed for Telegram, that quickly checks tokens for any possible risks. Any user can request the available information about tokens released on Solana and in a matter of seconds, the bot will provide them with security-related data regarding the contract.

The information includes:

Total Supply: This refers to the complete amount of tokens that are currently in circulation.

Mintable: signifies if it’s possible to increase the total supply of tokens. If an unauthorized person gains access to the minting authority, they could potentially create more tokens, which would devalue the token price. At the same time, an owner with excessive power might perform malicious actions to rug pull the project or their account might be compromised.

Freezable: indicates if it’s possible to blacklist token holders. Being blacklisted would mean that the holder’s tokens are frozen and they are unable to transfer tokens to other addresses.

Metadata: This term refers to whether the metadata of the token, such as its name, icon, and identifier, can be altered. If the metadata can be changed, the token could potentially be used for fraudulent activities. Therefore, it’s preferable for the metadata to be unchangeable.

Security rating: This rating shows the level of security of the token. A higher rating indicates a more secure token.

With this pocket auditor bot, you can make sure the token doesn’t pose any serious threats and evaluate the risks prior to investing in it. Solana Token Auditor is designed to provide the best safety practices for Solana users. With this release, we hope to uphold our main company mission of making DeFi safer and more user-oriented.

Now Live: Solana Token Auditor was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Principles of Secure Forking

Polly Traore — Mon, 22 Apr 2024 14:19:13 GMT

Earning in the crypto market has never been easier. There are thousands of successful projects and each one is waiting to be forked. Sounds extremely easy. But is it? The real deal with forks is far more complex than just adding a few changes and launching the project. In this article, we will look into security practices that can protect developers and users when it comes to creating forks.

It’s Just a Fork

Where there’s Bitcoin, there’s Bitcoin Cash. As was mentioned in the introduction to this article, forks are variations of the initial project, based on its open-source code. Usually, forks are built by users or developers, who add a missing feature or one that could improve the project. For instance, one of the differences between Bitcoin and Bitcoin Cash is that the latter offers lower fees.

The idea of creating a fork is attractive: if a project is successful, it’s easy money. There are always investors who missed a shot at partnering with the first project, just like it happened with Über and Lyft. Meanwhile, for project owners the need for extra developers and investments goes away: you add some changes and launch. You can even piggyback on the original project’s marketing campaign. In these instances, it’s not surprising that fork developers often rely on the security measures implemented by the owners of the original projects. Aside from overlooking existing issues, fork creators risk introducing new issues, as we know that every small change in a smart contract may lead to unpredictable effects.

This is an error in judgment that can potentially lead to issues in the future.

Such was the case with Cream Finance, which was hacked not once but twice in the span of 3 months. Cream Finance, a fork of the Compound protocol, lost almost $150M as the result of these attacks.

Unfortunately, this isn’t a unique case, and as we keep learning over and over again audited doesn’t always equal safe. In fact, forks of Venus protocol are at risk of being the next target.

An audit conducted by HashEx, brought to light an issue within the protocol, that may cause problems to its forks. The issue lies in the TWAP oracle, which may potentially calculate the asset’s TWAP over a single block period, and ignore the predefined window length that is initially set in the contract’s configuration.

Forking Safely

Like with every other coding case, there is a list of recommendations that follow creating a fork. There are proactive measures you can take to ensure that even if any issues arise, they aren’t a result of negligence.

Audit of the code:

When you buy a used car, you go through all the steps of checking its condition. Should it be any different with a code?

After creating a fork, it is crucial to audit the whole code, even if the original project is considered absolutely safe. Reviewing every line of code and every function, as well as its interaction with others, is an absolute must. This can help catch hidden issues.

Updates and Fixes:

After forking a project, it’s important to keep the code up to date and fix any issues as they arise. It ensures that your project stays secure and functions as intended, even when new threats emerge. It’s quite similar to regularly updating a password or running maintenance on any appliance.

Independent Verification:

No matter how reputable the original project is, independent verification of the forked code is essential. This principle was recently highlighted in the case of Venus protocol, where an issue from the project went unnoticed after several audits, and was only caught later in a fork.

Consider it akin to getting a second opinion from a doctor. Something that can save you from an incorrect approach to an issue and in the case of blockchain protocols, save funds.

Secure forking is about being diligent, thorough, and proactive. By adhering to these principles, you can create a fork that stands on its own merits, offering a secure and reliable experience for its users.

Examples like Cream Finance and the SushiSwap forks, where forks were compromised due to the addition of unsupported tokens, illustrate the severe consequences of neglecting security audits. We bring light to these situations, as well as the Venus case, to warn developers about possible outcomes.

We all have to remember that security measures are the foundation of the crypto community. It’s because of them, that we can create a secure ecosystem. And the best way to honor these principles is to audit your project, preferably in several independent auditing companies.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

Principles of Secure Forking was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Q1 2024 Crypto Hacks Report by HashEx

Polly Traore — Mon, 08 Apr 2024 12:41:08 GMT

In the first quarter of 2024, the cryptocurrency sector witnessed the theft of over $330 million, highlighting the severity and diversity of threats the industry is facing. The following analysis categorizes the incidents into two main groups: Smart Contract Vulnerabilities, which involve security breaches due to code flaws in smart contracts, and External Threats, which include attacks from outside the blockchain, such as phishing and unauthorized access. By categorizing these incidents, this report aims to provide a clearer understanding of each event’s nature and highlight the array of challenges before the cryptocurrency community.

Smart Contract Vulnerabilities

Curio Voting Power Privileges Vulnerability $16.000.000

A significant security breach has been experienced by Curio, a platform for integrating traditional and decentralized finance through tokenized real-world assets. The attack resulted in the loss of $16 million.

The news hit on March 23, 2024, as CurioDAO Association revealed that their voting protocol, based on a MakerDAO fork, was exploited. The cause for the exploit was a critical vulnerability in the project’s Ethereum-based smart contract. The vulnerability allowed the attacker to manipulate governance and mint an excessive number of CGT tokens.

After acquiring a small number of CGT tokens, the attacker increased their voting power and executed a delegate call to a malicious contract.

The attack involved complex financial strategies, including token swaps and cross-chain transfers, which led to the belief that one of the intentions was to conceal the origins of the minted tokens. Despite the attack being confined to the Ethereum side of Curio’s ecosystem, the incident has raised concerns about the security measures in place, especially since no external audits were found for Curio’s smart contracts. In response, CurioDAO has outlined a recovery plan that involves the launch of a new token, CGT 2.0, and a compensation program to mitigate the impact of the exploit.

PrismaFi Flash Loan Attack $11.500.000

PrismaFi, a platform known for liquid restaking, experienced a significant security breach on March 28, 2024, as it fell victim to a flash loan attack. The exploit led to the loss of 3258 wstETH tokens, valued at around $11.6 million. A lack of proper validation in onFlashloan() function in one of the contracts was the cause of the attack. This oversight allowed the perpetrator to manipulate input data and execute several functions not just on their own addresses, but on arbitrary ones as well. A specific address was targeted, as the attacker closed its trove and demanded a refund of 1745 wstETH. Then, a new trove was opened for 463 wstETH and after some manipulations, the attacker utilized the 1282 wstETH for their benefit. After the profits were extracted, ProsmaFi was left missing $11.6 million.

The incident was quickly detected by Cyvers, which is why PrismaFi took steps to pause the protocol and secure the remaining funds. Despite three audits conducted on PrismaFi in the past, the recent changes to the MigrateTroveZap contract, which were not audited, led to the exploit. This event once again underscores the importance of thorough and continuous security assessments, especially when significant contract modifications are implemented.

WOOFi Price Manipulation Attack $8.500.000

WOOFi, a prominent liquidity provider and trading platform, fell victim to a sophisticated price manipulation attack, resulting in a substantial loss of $8.5 million. The incident unfolded when attackers exploited vulnerabilities in the platform’s price oracle mechanism. The prices of certain assets have been manipulated to the perpetrators’ advantage.

The attackers artificially inflated the price of a specific asset on the platform by executing a series of strategic trades. The trades in question affected the asset’s price feed, which the WOO Network’s smart contracts relied upon for various operations, including loan collateralization and liquidation thresholds. Once the price was inflated, the attackers took out loans against the overvalued asset, subsequently draining the platform’s funds by withdrawing more than the actual value of their collateral. The inflated prices allowed the attackers to exploit the platform’s lending protocol, which led to an unauthorized extraction of $8.75 million. The aftermath of the attack saw a significant drop in the asset’s price to its actual market value, leaving the platform with insufficient collateral to cover the loans issued during the attack. In response to the attack, WOO Network took immediate steps to address the security breach, including enhancing their price oracle mechanisms and implementing additional safeguards to prevent similar incidents in the future. The platform also engaged with the broader crypto community to track and recover the stolen funds, although the outcome of the recovery efforts remains uncertain.

Seneca Protocol Input Validation Vulnerability $6.500.000

Seneca Protocol, a decentralized DeFi protocol, lost around $6 million due to a vulnerability in one of its contracts. The issue allowed an attacker to manipulate the contract’s actions, leading to an unauthorized redirection of users’ funds. The problem arose in a contract function that allowed the calling of other functions within the contract. The attacker exploited it to invoke a fund transfer, enabling them to redirect users’ funds to their account. This was achieved by manipulating the input data of the function, which allowed the perpetrator to specify the destination of the funds. As a result, funds have been stolen directly from users’ wallets, not from the funds deposited in the Seneca Protocol.

Gamma Strategies Flash Loan Attack $5.500.000

Gamma Strategies, a protocol on Arbitrum designed for managing concentrated liquidity, suffered a significant exploit resulting in a loss of at least $4.5 million. The incident unfolded around 03:30 UTC on January 4, with the community and Gamma Strategies quickly recognizing the breach. The exploit involved the use of flash loans to manipulate deposit values, which enabled the attacker to mint an excessive number of LP tokens. Despite having four deposit protection measures, the attack succeeded due to the wide price change thresholds in some vaults. This allowed the perpetrator to inflate the price and mint a disproportionate number of LP tokens. The majority of the stolen funds were converted to Ethereum and bridged back to the attacker’s Ethereum address, totaling 1535 ETH ($3.4M). An additional $1.1 million in DAI and gDAI remained on Arbitrum. The total losses might exceed the initial estimate, as the attack’s aftermath continues to be assessed.

Super Sushi Samurai Infinite Mint Exploit $4.800.000

Super Sushi Samurai, a game on the Blast L2 network, experienced an exploit that drained its liquidity pool (LP) of $4.8 million. The cause of the issue was a contract bug.

The incident occurred shortly after the game’s launch and caused the token price to plummet by 99.9%.

The exploit was related to a minting issue, where tokens were minted and sold into the LP, reminiscent of a similar exploit that affected Gamma Strategies earlier in the year.

The vulnerability stemmed from a coding oversight in the token contract’s transfer function. Specifically, when tokens were transferred, the contract subtracted the amount from the sender’s balance and added it to the recipient’s balance. However, if the sender and recipient were the same address, the contract failed to account for the deducted amount, effectively doubling the balance instead of keeping it unchanged. This loophole allowed the attacker to repeatedly double their balance and sell the inflated holdings. All of this resulted in a substantial loss for the project.

The attacker managed to turn $35 into $4.6 million in about an hour through a series of transactions. Despite the funds being drained, the exploiter later claimed it was a whitehat rescue hack and offered to reimburse the affected users, even providing contact details for the project to reach out.

The incident has raised questions about the effectiveness of smart contract audits, as Super Sushi Samurai’s code had been audited by Verichains, which failed to identify the infinite mint exploit.

External Threats

Chris Larsen’s Account Compromise $112.500.000

On January 30, 2024, Chris Larsen’s personal Ripple account was hacked. The attack resulted in the theft of 213 million XRP tokens. The perpetrators laundered these assets through various exchanges, including Kraken and Binance. Larsen confirmed that the compromised funds were from his personal holdings, not associated with Ripple’s corporate assets. The incident raised concerns about individual account security on blockchain networks.

Orbit Bridge Multisig Compromise $81.500.000

A security breach within an Ethereum bridge of Orbit Chain caused a loss of $81.5 million. The attack is suspected to be a multisig wallet compromise. Multiple transactions helped the perpetrator convert the assets into different cryptocurrencies. This incident from the end of 2023 highlights the vulnerabilities associated with multisig wallets and reminds security specialists of the importance of necessary measures for such critical infrastructure components in the blockchain space.

Orbit Bridge Multisig Compromise $62.500.000

Munchables, a project that had previously won the Blast L2 Big Bang award, fell victim to an exploit on March 26, 2024. The incident cost the project $62.5 million.

The exploit was executed by a rogue developer associated with the project. This developer managed to manipulate the project’s smart contract by assigning themselves a deposited balance of 1,000,000 Ether through manually altering storage slots. This issue took place before the contract was upgraded to a new version that enabled proper checks for preventing such unauthorized withdrawals.

The exploit was initially detected and reported by Munchables: the project tracked the movement of funds and attempted to halt the transactions. The developer had never transferred ownership of the smart contracts back to the Munchables team, which allowed them to execute the exploit.

In a dramatic turn of events, the rogue developer was outed by the blockchain detective ZachXBT and was subsequently persuaded to return the funds. The developer agreed to do so without any conditions, and the assets were secured in a multisig wallet by Blast core contributors. This incident not only reminds of the risks associated with smart contract vulnerabilities but also calls attention to the importance of thorough vetting and monitoring of individuals with access to critical project components.

BitForex Exit Scam $56.500.000

BitForex abruptly ceased operations after suspicious outflows of approximately $56.5 million were detected. The platform’s users encountered access restrictions, and withdrawal requests were ignored, signaling a potential exit scam. The abrupt cessation of operations and lack of communication from BitForex’s team led to immediate speculations and concern among its user base.

PlayDapp Private Key Compromise $32.500.000

Between February 9 and 12, 2024, PlayDapp, a P2E game on Ethereum, was exploited through compromised private keys. The attacker minted and stole 1.79 billion PLA tokens, converting only $32 million of the total number. The stolen funds were distributed across various addresses and platforms, including the Polygon chain and Binance exchange. The critical importance of securing private keys in the blockchain ecosystem was yet again in the spotlight after this incident.

FixedFloat Exchange Exploit $26.000.000

On February 16, 2024, FixedFloat experienced a large exploit that resulted in the loss of Bitcoin and Ethereum valued at approximately $26.13 million. The stolen funds were held primarily in Bitcoin and dispersed across multiple addresses. The Ethereum funds were moved through various exchanges, including HitBTC. The lack of detailed clarification from FixedFloat post-incident has left many questions unanswered regarding the nature and method of the exploit.

Conclusion

The first quarter of 2024 was marked by a series of notable security incidents within the cryptocurrency sector. If anything, every incident shows the continuous and sophisticated nature of threats facing this industry. From the exploitation of smart contract vulnerabilities in projects like Gamma Strategies, Seneca Protocol, and WOO Network to the external threats that led to the compromise of Chris Larsen’s Ripple account and the exit scam of BitForex. These issues have not only resulted in considerable financial losses but have undermined trust in the security of blockchain platforms and projects in general. The critical necessity for advanced security measures has once again been put to the forefront. Security experts as well as project owners must act with constant vigilance, proactively detecting threats and coming up with response strategies. As the digital asset landscape expands and evolves, these breaches serve as a crucial reminder of the importance of continuously enhancing security protocols, and ensuring monitoring in all aspects of the development and functioning of Web3 systems. This is the only way to foster a community-wide commitment to safeguarding against a wide and ever-expanding array of cyber threats. The ongoing challenge for the crypto industry is to adapt and fortify its defenses against both known and emerging security vulnerabilities.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

Q1 2024 Crypto Hacks Report by HashEx was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comprehensive vs. Partial Audits: Lessons from the Venus Protocol Forking

OlegKrylov — Wed, 28 Feb 2024 06:35:58 GMT

The audit process is essential to safeguard blockchain projects since it helps to find potential weaknesses. However, the time and money needed for audits can be significant challenges, particularly for newer initiatives. What should teams do when they are committed to ensure the security of their project but are constrained by limited resources?

The Cost of Security

Walking a tightrope when it comes to security assessments can be a common experience for blockchain projects. One major concern is the cost of an audit, which can vary greatly depending on a number of aspects. One factor is the amount of code that needs to be reviewed; the larger the amount of code, the more hours the auditors must spend, and the higher the cost. In the same way, the project’s fundamental complexity may drive up costs. Projects with complex structures or new mechanisms necessitate more time and specialized knowledge from auditors, which also drives up expenses.

On the other hand, time constraints present another significant challenge. To make sure that nothing is overlooked, security audits involve thorough investigation, testing, and validation, which take time to complete. However, the fast-paced nature of the blockchain industry, coupled with the pressure to launch projects in a timely manner, often puts teams in a bind. The urgency to move forward and stay competitive can make the lengthy audit process seem like a bottleneck, potentially tempting projects to cut corners or rush through necessary security checks.

Given these constraints, teams find themselves searching for a balance that allows them to secure their projects without breaking the bank or losing precious time. The question then becomes: Is there a solution that offers both cost and time efficiency without compromising on the thoroughness of the audit process? It is. Especially for the forks.

The Middle Ground: Comprehensive vs. Partial Audits

What if we work with the fork, which was audited a couple of times before? Should we do a new comprehensive audit or just trust the codebase? Maybe just run an audit of an updated code? There is, in fact, a workable middle ground between the complexity of full audits and the concision of partial audits. This tactic is especially applicable to projects that are forks or derivatives of codebases that have already gone through the stringent auditing procedure. Under such circumstances, the emphasis switches to examining solely the changes made to the original code. Naturally, this assumes that the base code is reliable and safe, which is a key tenet of this methodology.

Because of its advantages, this approach has become popular. Significant time and expense savings can be obtained by limiting the audit to the modifications that have been made. The cost of auditing can be significantly decreased, sometimes even by 10 times, which greatly increases the accessibility of security assessments for projects with more constrained funding. In a similar vein, the audit’s completion time might be shortened from many weeks or months to a few days. This efficiency does not necessarily come at the cost of thoroughness; rather, it represents a targeted approach that builds on the established security of the original codebase. The devil is always in the details. First let’s dive into the universal universe invariant “Quality Cost Speed”. Our cheap and fast partial audit is in the “risks” section. So what are the risks if everything is so clear?

The Deepr Case

While the partial audit approach can offer significant benefits in terms of timelines and costs, it’s not without potential pitfalls. Occasionally assuming that the original source code is completely safe can result in unanticipated difficulties. This was precisely the experience of our client, Deepr, who wisely chose to invest in a full audit for their project, a fork of the Venus protocol. Their decision to conduct a thorough review paid off, uncovering a crucial aspect that had been missed.

Despite the Venus codebase having been examined by four esteemed auditing firms — OpenZeppelin, PeckShield, CertiK, and Hacken — a critical vulnerability within the Venus TWAP Oracles went unnoticed. Rather the vulnerability was such that it did not impact the operational functionality of the Venus project itself at the time of those audits. Our detailed report brought this issue to light, emphasizing the indispensable value of comprehensive audits. This incident illustrates that even well-audited codebases can harbor overlooked vulnerabilities, underscoring the need for vigilance and thoroughness in the audit process.

The Value of Diligence

Optimizing budgets and timelines through partial audits may seem appealing, but the case of Deepr demonstrates the value of thoroughness. When resources allow, opting for a comprehensive audit is advisable. After all, it’s better to be safe than sorry. As the saying goes, “forewarned is forearmed.”

Comprehensive vs. Partial Audits: Lessons from the Venus Protocol Forking was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vulnerability Report: Venus Twap Oracle

OlegKrylov — Tue, 27 Feb 2024 13:02:52 GMT

Introduction

At HashEx, a blockchain security company, we recently undertook an audit of a fork of the Venus Oracle repository at a request of our client. In the course of our examination, we unearthed a previously undocumented vulnerability that had not been identified in any prior audits conducted on the repository.

Summary:

Project name — Venus TWAP Oracle

Platform — Binance Smart Chain

Language — Solidity

Contract — TwapOracle (0x67c549a18abfad127b13f8d56738f43a21bb62a7)

Executive summary

We’ve identified a vulnerability within the deployed Time-Weighted Average Price (TWAP) oracle, which can be exploited for price manipulation. In specific scenarios, the TWAP oracle may calculate the asset’s TWAP over a single block period, ignoring the predefined window length set in the contract’s configuration. This issue arises if the oracle does not receive updates during the designated TWAP period, allowing an attacker to influence the oracle into calculating the price based on the data of only one block.

The vulnerability presents in the deployed oracle implementation (implementation address: 0x67c549a18abfad127b13f8d56738f43a21bb62a7, proxy address 0xea2f042e1A4f057EF8A5220e57733AD747ea8867) and in the version before this commit.Although we haven’t found a TWAP oracle in use, documentation indicates it could be employed as the main oracle under certain conditions. This poses a significant risk, as a manipulated single-block TWAP can lead to the creation of unfavorable loans, representing a critical security faw for the lending platform. There are known attacks on TWAP oracles with insufficient window length, e.g. Inverse Finance hack.

Technical description

The core of the identified vulnerability lies in the update mechanism of the Time-Weighted Average Price (TWAP) oracle, particularly in how the anchorPeriod parameter functions. According to the oracle’s documentation, the anchorPeriod represents the minimum required window, in seconds, between TWAP updates. However, it has been discovered that the price may be updated more frequently, potentially as often as every block. The TWAP calculation relies on an array of Observation structs to store price information. Each Observation struct contains a cumulative price and timestamp. The asset’s price is determined from these stored observations through a public function designed to update the TWAP. This function searches for the first observation after the current timestamp minus the anchorPeriod.

function pokeWindowValues(
 TokenConfig memory config
) private returns (uint256, uint256 startCumulativePrice, uint256
startCumulativeTimestamp) {
 uint256 cumulativePrice = currentCumulativePrice(config);
 uint256 currentTimestamp = block.timestamp;
 uint256 windowStartTimestamp = currentTimestamp - config.anchorPeriod;
 Observation[] memory storedObservations = observations[config.asset];
 uint256 storedObservationsLength = storedObservations.length;
 for (uint256 windowStartIndex = windowStart[config.asset]; windowStartIndex <
storedObservationsLength; ) {
 if (
 (storedObservations[windowStartIndex].timestamp >= windowStartTimestamp) ||
 (windowStartIndex == storedObservationsLength - 1)
 ) {
 startCumulativePrice = storedObservations[windowStartIndex].acc;
 startCumulativeTimestamp = storedObservations[windowStartIndex].timestamp;
 windowStart[config.asset] = windowStartIndex;
 break;
 } else {
 delete observations[config.asset][windowStartIndex];
 }
 unchecked {
 ++windowStartIndex;
 }
 }
 observations[config.asset].push(Observation(currentTimestamp, cumulativePrice));
 ...
 return (cumulativePrice, startCumulativePrice, startCumulativeTimestamp);
}

A vulnerability arises when this update function is not invoked for a duration exceeding the anchorPeriod. In such cases, an attacker can exploit this by calling the update function twice in quick succession, specifically in two consecutive blocks. On the second call, due to the absence of updates within the anchorPeriod, the TWAP price will be calculated with a window length of just one block. This makes it highly susceptible to price manipulations.

Proof of concept

Test cases to show issue vulnerability:

it("update twap twice inside anchor window since last observation", async function () {
 ...
 await this.twapOracle.updateTwap(this.token0.address);
 console.log(
 "Price before 1 block manipulation:",
 ethers.utils.formatUnits(await this.twapOracle.getPrice(this.token0.address), 18),
 );
 console.log("Waiting less than the anchor window...");
 await increaseTime(888); // configured anchorPeriod is 900
 await this.simplePair.update(200, 100, 100, 100); // price changed x2
 await this.twapOracle.updateTwap(this.token0.address);
 await this.twapOracle.updateTwap(this.token0.address);
 console.log(
 "Price after 1 block manipulation:",
 ethers.utils.formatUnits(await this.twapOracle.getPrice(this.token0.address), 18),
 );
});
it("update twap twice after anchor window without observations", async function () {
 ...
 await this.twapOracle.updateTwap(this.token0.address);
 console.log(
 "Price before 1 block manipulation:",
 ethers.utils.formatUnits(await this.twapOracle.getPrice(this.token0.address), 18),
 );
 console.log("Waiting a bit more than the anchor window...");
 await increaseTime(901); // configured anchorPeriod is 900
 await this.simplePair.update(200, 100, 100, 100); // price changed x2
 await this.twapOracle.updateTwap(this.token0.address);
 await this.twapOracle.updateTwap(this.token0.address);
 console.log(
 "Price after 1 block manipulation:",
  ethers.utils.formatUnits(await this.twapOracle.getPrice(this.token0.address), 18),
 );
});

Test output

Price before 1 block manipulation: 1.000000000000000121
Waiting less than the anchor window...
Price after 1 block manipulation: 0.998877665544332331
  update twap twice inside anchor window since last observation (57ms)
Price before 1 block manipulation: 1.000000000000000121
Waiting a bit more than the anchor window...
Price after 1 block manipulation: 0.50000000000000006
  update twap twice after anchor window without observations (52ms

The repository with the tests can be seen at @hashex/venus-twap-vulnerabilty-proof-of-concept Github repository (file test/PivotTwapOracleBug.ts).

Conclusion

The identified issue presents a significant risk to the Venus protocol, particularly if a TWAP oracle is employed, as it could facilitate a price manipulation attack and result in the loss of user funds locked within the protocol. Although we have not discovered any instances of the TWAP oracle currently in use, documentation indicates that it may serve as the primary oracle for certain assets.

Vulnerability Report: Venus Twap Oracle was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Ultimate Guide to Secure Smart Contract Development in 2024

Polly Traore — Mon, 12 Feb 2024 12:03:25 GMT

The current popularity of blockchain technology is in many ways tied to the possibility of running smart contracts — special programs that function on blockchain.
The importance of writing secure smart contracts is hard to overestimate: practically every week brings multiple attacks on projects that result in the loss of millions of dollars. In this article, we will look at the methods that help minimize the risk of vulnerabilities in the project’s code.

Requirements for Secure Development

Secure Development

Development in blockchain follows the same good practices as in traditional projects. For the most part, the specificity lies in the use of different tools.

Writing a code

Clean code: writing code that’s as simple as possible and meets all the requirements, Such code is easier to modify and analyze during an audit. Complexity always leads to mistakes.
Following the industry standard conventions and patterns. Solidity has a style guide for writing structured code.
Adding inline comments that clarify the decisions made by the developer for the code.
Considering gas optimization.
Always checking that compilation or linter warnings don’t appear. If any of them aren’t fixed, adding an explanation for their presence is necessary.
Using only well-known and tested libraries and stable versions. Check that the used libraries don’t have bugs.
Scripts for automatic deployment. Deployment is a crucial process for blockchain projects and automating the deployment will minimize the risks of errors during the process.

Documentation

The importance of the documentation that’s required for any additional changes to the project.
The documentation must include a detailed description of the project, its architecture components, and an explanation of how the system is supposed to function.
It’s also useful to add in the documentation the conjectures, tradeoffs, and arguments in favor of the chosen system design.

Testing

Rigorous testing is especially important when developing blockchain projects. One typo may lead to severe financial losses and since it is a common practice to deploy non-upgradeable contracts, it’s very hard to fix the errors.

Automatic testing

It’s imperative to have unit tests (to test separate functions of a smart contract) as well as functional testing that tests the interactions between the functions within one smart contract and between several smart contracts.
Foundry or development tools allow to determine the code’s test coverage: which lines of code and functions have been checked by said tests and which haven’t.
It’s very important to achieve 100% (or close) test coverage for smart contracts. At this time, some of the most popular frameworks for Solidity development that allow writing automated tests and calculating coverage are Hardhat and Foundry.

Fuzz testing

Fuzz testing is a testing method that provides random and incorrect data as inputs to the contract.
Tool examples: Echidna, foundry fuzz-testing

Formal verification

Fuzzing attempts to locate a bug in a smart contract by random inputs, while formal verification proves the absence of specific bugs by using a mathematical apparatus.
Tool example: SMTChecker

Functional testing on the fork of the mainnet where the project is intended to run

After testing a project on the testnet it’s important to find out how it’s going to behave on the mainnet. For that, it’s helpful to use forks of the mainnet that allow for testing the integration of the smart contract, backend, and frontend without paying for transactions. One of the services that allow this functionality is Tenderly devnet.

Automated tools for checking

Static code analyzers can rarely be helpful in detecting vulnerabilities but they are useful for finding simple code errors: unused variables, mathematical operations that lead to bigger inconsistencies, and simple gas optimizations. That’s why they shouldn’t be underestimated in the code-writing process.

Tool examples: Slither, Mythril, Aderyn.

External Checks

Audits

Choosing a reliable auditor.
Preparing for an audit.

Determine the scope of the audit.
Provide documentation.
Describe who is going to have access to the privileged functions.
Provide instructions regarding setting up the system set up and running tests.
Explain the invariants and project characteristics to the auditors. Understanding the intended invariants can help auditors.
Point out the parts of the project that the developers are uncertain about.

Bug bounty

A reasonable bounty. Provide the contact information specifically for bounty hunters.
Bug bounty platforms: Immunefi, Codehawks.

Monitoring

Internal monitoring

Quick response is very important for the process of detecting issues. Monitoring is a vital part of any launched project. Controlling all relevant parameters is vital, especially for taking the necessary measures before it’s too late.

External monitoring

In addition to internal monitoring, it’s possible to seek assistance from external services. Such services monitor the mempool for attacks and in case of a suspicious transaction, the protocol is put on pause before the attack transaction is mined. It’s important to note that during the development process, the possibility of pausing the project by a third party has to be included in the code.

Contingency plan

A contingency plan for an emergency has to be prepared in advance. After an attack, it’s often still possible to block the funds so that the attacker couldn’t withdraw them. In case of an attack, there would be no time to decide whom to contact to block the funds

Conclusion

During the smart contract development, every detail is relevant. Because almost always smart contracts deal with valuable assets, security becomes a vital element. There are no irrelevant things and minor issues when it comes to providing security for a project. In this article, we reviewed approaches that allow to minimize the risks of successful attacks on your project.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

The Ultimate Guide to Secure Smart Contract Development in 2024 was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Proof of Work in Blockchain?

Polly Traore — Wed, 27 Dec 2023 15:53:02 GMT

Different blockchains use different consensus mechanisms. The most popular being proof of stake and proof of work. While one is quickly becoming the standard, the other has become a source of controversy and multiple public issues. Let’s take a look at Proof of Work and how it operates.

The hash from each block is used in the block that follows it when its hash is created. This creates a ledger of chained blocks that cannot be altered because the information from every block is included in the newest block’s hash.

The name Blockchain reflects the technology — it’s a series of interconnected blocks with each one containing a link to the previous. This link is included in the header of the block in the form of the previous one’s hash. This allows for the blockchain history to be unalterable — if anyone attempts to replace a block, the link to the new one becomes invalid — it will redirect to a previous block.

Proof of work is a decentralized consensus mechanism that relies on network members solving a specific mathematical problem. It’s also known as mining, since the performed action is always rewarded, usually with cryptocurrency.

The consensus mechanism decides which block is going to be added to the chain. By the time of the emergence of the first cryptocurrency — Bitcoin — there were already many consensus mechanisms available. For Bitcoin, Proof of Work was chosen. This is a consensus mechanism in which the chain participants compete to solve a mathematical problem selected by the protocol.

How does it work

As mentioned before, the PoW mechanism means finding a solution to a mathematical problem. To add a new block, miners have to form one from previously unmined transactions and calculate its hash. If the hash is lower than the predetermined value, it’s decided that the miner has found the block. If the value is higher, the miner has to change one of the parameters of the said block — nonce — and the hash is calculated again. This happens over and over until one of the miners finds a nonce that allows for the hash to be lower than the predetermined value.

After the block is found, it’s sent out along with the solution of the math problem (the nonce that allows for the desired value) to the rest of the chain participants. They then add it to their chains. For every found block the miner is rewarded.

Work in this context refers to the miners competing to be the first to solve the mathematical problem, and the data is ultimately added by the fastest one. After the other participants verify the correctness of the data, the winner can receive their reward.

Security

PoW consensus allows for the appearance of forks of the main chain. This happens when two different miners find a valid block almost simultaneously. Miners add the first valid block they see but because the system is decentralized, while some miners receive one block first, the others may receive another. As a result of this, the chain is split into two forks: all miners continue mining from the block they received first. The chain that gets mined first is accepted because when miners start mining, they normally select the longest chain. A transaction added only to the chain that’s going to be canceled will also be canceled, which is why services that work with PoW cryptocurrencies have to wait for a certain amount of proof i.e. blocks found after the one in question, prior to accepting a transaction.

When we discuss PoW consensus security, it’s imperative to mention 51% attacks. This is an attack that can happen when one or a coordinated group of participants take control of more than half of the computing power of the network. When this happens, the attackers can build alternative chains of blocks which allows them to perform double-spending attacks or censor particular transactions. Still, these attacks require huge computing power and there’s never a guarantee that all the efforts and money will in fact lead to a successful attack. At the same time, history shows us at least several successful attacks on PoW blockchains, for instance, Bitcoin Gold attacks in 2018 and 2020.

Advantages of PoW

The most well-known example of PoW consensus is Bitcoin. This mechanism allows for secure transactions from one peer to another without the use of a trusted third party.

These days, there are many successfully tested consensus mechanisms for cryptocurrencies. PoW was the first one used for that particular goal and it has proved itself as a safe and decentralized one. Anyone with the necessary equipment can participate in the mining process.

Disadvantages of PoW

Proof of Work chains tend to be slower than Proof of Stake, transactions take longer time to come through and the transactional fees tend to be more expensive.

Computational power requires powerful and expensive equipment. It’s the primary reason for the price growth of graphic cards.

Proof of Work requires a lot of energy which in turn can cause power surges. In fact, this was one of the reasons proof of stake eventually became the industry standard.

Whether the advantages of proof of work outweigh the disadvantages or not, the mechanism itself proved that innovation, while possibly controversial, can bring blockchain forward.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

What is Proof of Work in Blockchain? was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

HashEx Blog

Sharing useful information about the blockchain

Let's Work Together! Write now.