Introduction

Welcome to the Blockchain Weakness Classification (BWC) and Bug Bounty Utilities repository. This project is designed to be a comprehensive resource for security researchers, developers, and anyone interested in the security of blockchain and decentralized applications.

The core of this repository is the Blockchain Weakness Classification (BWC), a hierarchical framework that categorizes vulnerabilities and weaknesses found in the blockchain ecosystem. The BWC covers a wide range of risks, from off-chain infrastructure to low-level smart contract code, providing a structured way to understand and address security issues.

In addition to the BWC, this repository provides a collection of resources and utilities to aid in bug bounty hunting and security analysis. These include:

• Hunting Notes: A collection of notes, tips, and frequently used addresses for various DApps and chains, designed to streamline the bug hunting process.
• Incidents: A database of real-world smart contract vulnerability incidents, classified using the BWC framework. This serves as a valuable learning resource for understanding how vulnerabilities are exploited in practice.
• Service Level Agreement: A template for a smart contract audit service level agreement, providing a starting point for auditors and clients to define the scope and terms of an audit.
• X-Tweets: A collection of tweet templates and examples for disseminating information about security incidents and vulnerabilities.

This repository is intended to be a living project, and contributions are welcome. Whether you're looking to learn about blockchain security, find your next bug bounty, or improve your security analysis workflow, we hope you find the resources in this repository to be valuable.

Blockchain Weakness Classification (BWC)

This document provides a hierarchical classification of weaknesses and vulnerabilities found in blockchain and decentralized application (DApp) ecosystems. The BWC framework covers risks from off-chain infrastructure to low-level smart contract code.

Table of Contents

• Blockchain Weakness Classification (BWC)
  • Table of Contents
  • BWC 1.0: Ecosystem & Off-Chain Risks
    • BWC 1.1: Identity & Key Management Failures
      • BWC 1.1.1: Compromised Device/OS
      • BWC 1.1.2: Private Key Leakage
      • BWC 1.1.3: Insider Threat
      • BWC 1.1.4: Wrench Attacks
      • BWC 1.1.5: Vulnerable Vanity/Address Generators
    • BWC 1.2: Social Engineering & Deception
      • BWC 1.2.1: Social Engineering Exploits
      • BWC 1.2.2: SIM Swap Attack
      • BWC 1.2.3: Front-End Hijack/Spoofing
      • BWC 1.2.4: Fake Wallet Applications
      • BWC 1.2.5: Malicious Browser Extensions
      • BWC 1.2.6: Malicious RPC Provider
    • BWC 1.3: Infrastructure & Supply Chain Integrity
      • BWC 1.3.1: Compromised Validator/Node
      • BWC 1.3.2: DNS Hijacking Attacks
      • BWC 1.3.3: Compromised Communication Platforms
      • BWC 1.3.4: Supply Chain Attacks
      • BWC 1.3.5: Ruggable Contract Design
    • BWC 1.4: Nation-State & Advanced Persistent Threats (APTs)
      • BWC 1.4.1: Coordinated Multi-Vector Attacks
      • BWC 1.4.2: State-Sponsored Infrastructure Compromise
      • BWC 1.4.3: Geopolitical Economic Warfare
      • BWC 1.4.4: Cross-Jurisdictional Regulatory Exploitation
  • BWC 2.0: Access Control Vulnerabilities
    • BWC 2.1: Missing or Improper Authorization
      • BWC 2.1.1: Missing Access Control
      • BWC 2.1.2: tx.origin Authorization
    • BWC 2.2: Flawed Permission Management
      • BWC 2.2.1: Lingering Approvals
      • BWC 2.2.2: Misconfigured Proxy
      • BWC 2.2.3: Untrusted Arbitrary Calls
      • BWC 2.2.4: Cross Contract Untrusted Arbitrary Calls
    • BWC 2.3: Callback & Hook Vulnerabilities
      • BWC 2.3.1: Missing Validation in Flashloan Callbacks
  • BWC 3.0: Smart Contract Logic & State Manipulation
    • BWC 3.1: Reentrancy Attacks
      • BWC 3.1.1: Standard Reentrancy
      • BWC 3.1.2: ERC-777 Reentrancy
      • BWC 3.1.3: Read-only Reentrancy
    • BWC 3.2: Flawed State Management
      • BWC 3.2.1: Improper Initialization
        • BWC 3.2.1.1: Proxy/Contract Initialization Front-Running
      • BWC 3.2.2: Faulty Contract Checks
      • BWC 3.2.3: Forced Ether Balance
      • BWC 3.2.4: Self Transfers and Transaction Timing Attacks
      • BWC 3.2.5: Broken State Adjustment
    • BWC 3.3: Token Standard & Logic Issues
      • BWC 3.3.1: Double EntryPoint Tokens
      • BWC 3.3.2: Fee-on-Transfer & Rebase Accounting Issues
      • BWC 3.3.3: Improper Handling of Native Tokens
      • BWC 3.3.4: Weird ERC20 Behaviors
    • BWC 3.4: Governance & System Logic
      • BWC 3.4.1: DAO Governance Attacks
      • BWC 3.4.2: Flawed Reward Systems
      • BWC 3.4.3: Bridge Status Mismatch
  • BWC 4.0: Input & Data Validation Vulnerabilities
    • BWC 4.1: Insufficient Input Validation
    • BWC 4.2: Oracle Manipulation & Data Integrity
      • BWC 4.2.1: Insufficient Oracle Validation
      • BWC 4.2.2: Oracle Manipulation
      • BWC 4.3: Cryptographic Signature Flaws
      • BWC 4.3.1: Missing Signature Validation
      • BWC 4.3.2: Incomplete Signature Schemes
      • BWC 4.4: Address Spoofing in Meta-Transactions
  • BWC 5.0: Economic & Game-Theoretic Vulnerabilities
    • BWC 5.1: Miner Extractable Value (MEV) Attacks
      • BWC 5.1.1: Front-Running
      • BWC 5.1.2: Back-Running
      • BWC 5.1.3: Sandwich Attacks
      • BWC 5.2: Price & Liquidity Manipulation
      • BWC 5.2.1: Price Manipulation
      • BWC 5.2.2: First Deposit / Inflation Attack
      • BWC 5.2.3: Hardcoded Price
      • BWC 5.3: Transaction Execution Risks
      • BWC 5.3.1: Lack of Slippage Control
  • BWC 6.0: Arithmetic & Numeric Vulnerabilities
    • BWC 6.1: Integer Overflow & Underflow
      • BWC 6.2: Precision Loss & Rounding Errors
      • BWC 6.3: Unsafe Type Casting
      • BWC 6.4: Calculation Errors
      • BWC 6.5: Inconsistent Scaling Bugs
  • BWC 7.0: Low-Level & EVM-Specific Vulnerabilities
    • BWC 7.1: Unchecked Return Values
      • BWC 7.2: Unsafe Storage & Memory Handling
      • BWC 7.2.1: Unsafe Storage Use
      • BWC 7.2.2: Deleting Dynamic Data in Structs
      • BWC 7.2.3: Broken EIP-1153 Transient Storage Use
      • BWC 7.3: Weak Cryptographic Primitives
      • BWC 7.3.1: Weak Random Number Generation
      • BWC 7.3.2: Malleable ecrecover
      • BWC 7.3.3: Second Pre-image Attacks
      • BWC 7.3.4: Forgetting to Blind Polynomials in ZK Protocols
      • BWC 7.4: EVM Interpretation Issues
      • BWC 7.4.1: Incorrect VM Gas Charges
      • BWC 7.4.2: Two-Parser Bugs
  • BWC 8.0: Denial of Service (DoS) Vulnerabilities
    • BWC 8.1: DoS via External Calls
    • BWC 8.2: DoS via Malicious Receivers
    • BWC 8.3: DoS via Non-Reentrant Locks
    • BWC 8.4: DoS via Numeric Calculation
    • BWC 8.5: DoS via Block Gas Limit
    • BWC 8.6: DoS via Hook Griefing
    • BWC 8.7: DoS via Return Data Bomb
    • BWC 8.8: DoS in Cross-Chain Messaging Protocols
  • BWC 9.0: Emerging Technology Vulnerabilities
    • BWC 9.1: Quantum Computing Threats
    • BWC 9.2: AI/ML Integration Attacks
      • BWC 9.2.1 Unrestricted Large Language Models (LLMs)
    • BWC 9.3: Hardware-Level Exploits
  • BWC 10.0: Network & Consensus Evolution Attacks
    • BWC 10.1: Advanced P2P Network Attacks
    • BWC 10.2: Novel Consensus Mechanism Exploits
    • BWC 10.3: Cross-Protocol Interoperability Attacks
    • BWC 10.4: Protocol Upgrade-Induced Vulnerabilities
  • BWC 11.0: Privacy & Regulatory Attack Vectors
    • BWC 11.1: Privacy Protocol Compromises
    • BWC 11.2: Regulatory Weaponization

BWC 1.0: Ecosystem & Off-Chain Risks

Vulnerabilities that exist outside the core blockchain logic but are critical to the security of the overall system. Every off chain component you incorporate add to you attack surface.

BWC 1.1: Identity & Key Management Failures

BWC 1.1.1: Compromised Device/OS

Vulnerabilities in user devices or operating systems leading to private key theft, session hijacking, or malicious transaction approvals

Device Exploit Methods

• Malware laced PDF files and ZIP files

• Fake Telegram Manual Verification leading to user running malware

• Running untrusted code.

• Mitigation:

  • Separate Signing devices.
  • Wipe Device after 3 months. Assume Device is compromised after every 3 months.
  • Enable two-factor authentication.
  • Keep software up-to-date.
  • Avoid all attachments and links.

BWC 1.1.2: Private Key Leakage

Exposure of private keys through insecure storage, transmission, or handling.

• Mitigation:
  • Always use Multi signature. With multiple Signers. Don't Use fancy UI(safe). Verify Calldata manually.

BWC 1.1.3: Insider Threat

Malicious actions by team members or contractors with privileged access.

• Mitigation:
  • Privilege Separation.
  • Enhanced KYC.
  • Need to Know Access Control.
  • On site Verification for remote workers.

BWC 1.1.4: Wrench Attacks

Refers to a situation where attackers bypass technical security entirely and instead use coercion, threats or physical violence such as kidnapping to force victims to surrender their passwords or assets.

• Mitigation:
  • Decoy Wallets.
  • Family Security Protocols.
  • Avoiding Identity Exposure.
  • Keep you circles tight and cautious.
  • Nuke passwords.

BWC 1.1.5: Vulnerable Vanity/Address Generators

Flaws in tools used to generate custom addresses, potentially leading to predictable private keys.

• Mitigation:
  • Avoid vanity address generators. It's vanity.

BWC 1.2: Social Engineering & Deception

BWC 1.2.1: Social Engineering Exploits

Tricking users into revealing sensitive information or transferring funds.

• Recruitment Scam
• Investment Scam/Pig Butchering Scam
• Crypto Recovery Scam
• Fake AirDrop Scam
• Address Poisoning Scam
• DeepFakes -Fake celebrity endorsements to promote investments -Deepfake-Impersonated Zoom Meetings
• Google Search Ad Phishing Attack
• Email Phishing Attacks: New Login of Google Account, New login of X account.

BWC 1.2.2: SIM Swap Attack

Taking control of a user's phone number to bypass two-factor authentication.

BWC 1.2.3: Front-End Hijack/Spoofing

Modification of DApp interfaces to trick users into approving malicious transactions.

• Mitigation:
  • Bookmark trusted URLs.
  • Verify URL from multiple Sources.
  • Perform a trial run first.

BWC 1.2.4: Fake Wallet Applications

Malicious applications impersonating legitimate ones to steal credentials and funds.

BWC 1.2.5: Malicious Browser Extensions

BWC 1.2.6: Malicious RPC Provider

BWC 1.3: Infrastructure & Supply Chain Integrity

BWC 1.3.1: Compromised Validator/Node

Validators who control block production are compromised, leading to transaction censorship, reordering, or other malicious activities.

BWC 1.3.2: DNS Hijacking Attacks

Redirecting traffic from legitimate websites to fraudulent phishing sites by compromising DNS servers.

BWC 1.3.3: Compromised Communication Platforms

Hijacking of official Discord, X (Twitter), or email accounts to spread misinformation or phishing links.

BWC 1.3.4: Supply Chain Attacks

Compromises in the development pipeline, dependencies, or deployment processes.

• Mitigation:
  • Create a Software Bill Of Materials Check. Ensuring that dependencies and packages undergo rigorous security screening.
  • Source Code Analysis Check.

BWC 1.3.5: Ruggable Contract Design

Architectural design that intentionally allows malicious developers to steal user funds.

• Mitigation:
  • Verify the source code.

BWC 1.4: Nation-State & Advanced Persistent Threats (APTs)

BWC 1.4.1: Coordinated Multi-Vector Attacks

BWC 1.4.2: State-Sponsored Infrastructure Compromise

BWC 1.4.3: Geopolitical Economic Warfare

BWC 1.4.4: Cross-Jurisdictional Regulatory Exploitation

BWC 2.0: Access Control Vulnerabilities

Failures in how permissions and privileges are managed and enforced within a smart contract.

BWC 2.1: Missing or Improper Authorization

BWC 2.1.1: Missing Access Control

Failure to implement proper authorization checks on sensitive functions.

BWC 2.1.2: tx.origin Authorization

Using the volatile tx.origin address instead of the stable msg.sender for authorization checks.

BWC 2.2: Flawed Permission Management

BWC 2.2.1: Lingering Approvals

Token approvals that remain active beyond their intended lifespan, creating security exposures.

BWC 2.2.2: Misconfigured Proxy

Errors in proxy contract setup leading to upgrade vulnerabilities, function collisions, or unauthorized access.

BWC 2.2.3: Untrusted Arbitrary Calls

Functions that allow calling arbitrary external contracts without proper security measures or validation (e.g., unsafe delegatecall).

BWC 2.2.4: Cross Contract Untrusted Arbitrary Calls

This vulnerability occurs when a contract executes a call to an external contract using untrusted or user-supplied calldata, but the vulnerability is only exposed through a series of interactions between multiple contracts. An attacker can exploit this by crafting malicious calldata that causes a trusted contract to perform an unauthorized action on their behalf against another contract in the system. This is particularly dangerous when the exploited contract has special privileges on the target contract.

BWC 2.3: Callback & Hook Vulnerabilities

BWC 2.3.1: Missing Validation in Flashloan Callbacks

Inadequate verification in callback functions that can be exploited during flash loan execution.

BWC 3.0: Smart Contract Logic & State Manipulation

Flaws in the business logic, state machine, and core functionality of a contract.

BWC 3.1: Reentrancy Attacks

BWC 3.1.1: Standard Reentrancy

Calling back into a vulnerable contract before its state updates are completed, allowing for multiple withdrawals or other exploits.

BWC 3.1.2: ERC-777 Reentrancy

Exploiting token hooks in the ERC-777 standard to reenter contracts during a tokensToSend or tokensReceived call.

BWC 3.1.3: Read-only Reentrancy

Reentering a contract to read state that is inconsistent or in the process of being changed, leading to logic errors.

BWC 3.1.4: Cross-Contract Reentrancy

A Cross-Contract Reentrancy differs from standard reentrancy in that it arises when a reentrancy occurs in a complex and often unforeseen call chain. This can happen when Contract A calls Contract B, which calls Contract C, which in turn calls back into Contract A or another related contract in an unexpected way, exploiting the system's state before the initial function call has completed.

BWC 3.2: Flawed State Management

BWC 3.2.1: Improper Initialization

Contracts deployed with incorrect initial state, missing initialization, or unset flags.

BWC 3.2.1.1: Proxy/Contract Initialization Front-Running

A specific type of front-running where an attacker observes a transaction that deploys a contract and immediately sends a transaction to initialize the contract with their own address as the owner. This is possible when the contract's initialization function is public and does not have proper access control.

BWC 3.2.2: Faulty Contract Checks

Logic errors in mechanisms that check the status or code of other contracts.

BWC 3.2.3: Forced Ether Balance

Manipulating a contract's Ether balance to disrupt logic that depends on address(this).balance.

BWC 3.2.4: Self Transfers and Transaction Timing Attacks

Exploiting state changes caused by transfers to the same address or by the ordering of transactions.

BWC 3.2.5: Broken State Adjustment

Errors in logic that is supposed to modify or correct contract state.

BWC 3.3: Token Standard & Logic Issues

BWC 3.3.1: Double EntryPoint Tokens

Contracts where a native token also has an ERC-20 representation, potentially leading to inconsistent state or accounting.

- *Example: Celo, Polygon (MATIC), zkSync ERA (ETH)*

BWC 3.3.2: Fee-on-Transfer & Rebase Accounting Issues

Incorrect handling of tokens that deduct fees during transfers or have an elastic supply (rebase tokens).

BWC 3.3.3: Improper Handling of Native Tokens

Errors in managing the blockchain's native currency (e.g., ETH, BNB) alongside other tokens.

BWC 3.3.4: Weird ERC20 Behaviors

Failure to handle non-standard implementations of the ERC20 interface, such as tokens without return values.

BWC 3.4: Governance & System Logic

BWC 3.4.1: DAO Governance Attacks

Exploiting voting mechanisms, proposal processes, or timelocks to pass malicious proposals.

BWC 3.4.2: Flawed Reward Systems

Exploitable incentive structures or reward calculation errors.

BWC 3.4.3: Bridge Status Mismatch

Inconsistencies between cross-chain bridge endpoints leading to fund loss or transaction failure.

BWC 4.0: Input & Data Validation Vulnerabilities

Weaknesses related to processing untrusted external data and inputs.

BWC 4.1: Insufficient Input Validation

Failure to properly sanitize or validate transaction inputs, enabling malicious or unexpected data to be processed. This includes missing zero-address checks.

BWC 4.2: Oracle Manipulation & Data Integrity

BWC 4.2.1: Insufficient Oracle Validation

Inadequate verification of external data feeds (e.g., price feeds), allowing manipulation of critical on-chain information.

BWC 4.2.2: Oracle Manipulation

Actively compromising or gaming the data feeds that DApps rely on for external information.

BWC 4.3: Cryptographic Signature Flaws

BWC 4.3.1: Missing Signature Validation

Improper or missing verification of cryptographic signatures, enabling transaction forgery.

BWC 4.3.2: Incomplete Signature Schemes

Flaws in the implementation of transaction signing cryptography.

BWC 4.4: Address Spoofing in Meta-Transactions

Exploitation of meta-transaction frameworks like ERC-2771 by impersonating authorized forwarder addresses.

BWC 5.0: Economic & Game-Theoretic Vulnerabilities

Flaws that can be exploited by rational economic actors to manipulate markets or extract value unfairly.

BWC 5.1: Miner Extractable Value (MEV) Attacks

BWC 5.1.1: Front-Running

Placing a transaction in the queue before a known future transaction to exploit the order of execution.

BWC 5.1.2: Back-Running

Placing transactions immediately after targeted transactions to exploit their effects.

BWC 5.1.3: Sandwich Attacks

Combining front-running and back-running to trap a victim's transaction and extract value.

BWC 5.2: Price & Liquidity Manipulation

BWC 5.2.1: Price Manipulation

Artificially influencing asset prices through market actions to exploit DApp mechanisms.

BWC 5.2.2: First Deposit / Inflation Attack

Exploiting initialization conditions in liquidity pools or staking systems to claim a disproportionate share of rewards.

BWC 5.2.3: Hardcoded Price

Using a fixed, hardcoded price for an asset instead of a dynamic feed, creating an easily exploitable arbitrage opportunity.

BWC 5.3: Transaction Execution Risks

BWC 5.3.1: Lack of Slippage Control

Missing or insufficient protection against price movement between the time a transaction is submitted and when it is executed.

BWC 6.0: Arithmetic & Numeric Vulnerabilities

Errors in mathematical calculations and data type handling.

BWC 6.1: Integer Overflow & Underflow

Exceeding the maximum or minimum value for an integer type, causing it to wrap around.

BWC 6.2: Precision Loss & Rounding Errors

Issues arising from integer division, order of operations (division before multiplication), or inconsistent decimal scaling.

BWC 6.3: Unsafe Type Casting

Improper or unchecked conversion between numeric types, potentially leading to overflow or precision loss.

BWC 6.4: Calculation Errors

General mathematical mistakes in contract logic, such as in liquidity or reward formulas.

BWC 6.5: Inconsistent Scaling Bugs

Errors in managing precision during unit conversion between different tokens or values.

BWC 7.0: Low-Level & EVM-Specific Vulnerabilities

Vulnerabilities related to the specifics of the Ethereum Virtual Machine (EVM), cryptographic primitives, and data handling.

BWC 7.1: Unchecked Return Values

Failing to verify the success status of external calls, leading the contract to incorrectly assume success.

BWC 7.2: Unsafe Storage & Memory Handling

BWC 7.2.1: Unsafe Storage Use

Improper handling of contract storage slots, leading to collisions or data corruption.

BWC 7.2.2: Deleting Dynamic Data in Structs

Memory corruption from improper deletion of complex data structures.

BWC 7.2.3: Broken EIP-1153 Transient Storage Use

Misuse of transient storage, which can enable reentrancy or state corruption due to improper clearing.

BWC 7.3: Weak Cryptographic Primitives

BWC 7.3.1: Weak Random Number Generation

Using predictable or manipulable sources of on-chain entropy (e.g., block.timestamp).

BWC 7.3.2: Malleable ecrecover

Vulnerabilities in signature recovery allowing for signature reuse or forgery.

BWC 7.3.3: Second Pre-image Attacks

Cryptographic vulnerabilities allowing for collisions in hash functions used by the contract.

BWC 7.3.4: Forgetting to Blind Polynomials in ZK Protocols

Weaknesses in zero-knowledge proof implementations that expose underlying data.

BWC 7.4: EVM Interpretation Issues

BWC 7.4.1: Incorrect VM Gas Charges

Logic that becomes vulnerable due to miscalculations of transaction execution costs.

BWC 7.4.2: Two-Parser Bugs

Inconsistencies between different parsers in the software stack, leading to unexpected execution.

BWC 8.0: Denial of Service (DoS) Vulnerabilities

Attacks designed to render a contract or system unusable, often by causing transactions to revert or consume excessive gas.

BWC 8.1: DoS via External Calls

Blocking contract functionality through external calls to malicious or non-functional contracts.

BWC 8.2: DoS via Malicious Receivers

A recipient contract designed to revert or consume excessive gas when receiving tokens or Ether.

BWC 8.3: DoS via Non-Reentrant Locks

Exploiting reentrancy guards to permanently or temporarily lock functions.

BWC 8.4: DoS via Numeric Calculation

Causing numeric underflows, overflows, or division-by-zero errors that block contract execution.

BWC 8.5: DoS via Block Gas Limit

Crafting operations that exceed the block gas limit, making certain state transitions impossible.

BWC 8.6: DoS via Hook Griefing

Exploitation of token standard callbacks (e.g., ERC777/721/1155) to cause denial of service.

BWC 8.7: DoS via Return Data Bomb

Exploitation of unbounded return data from an external call to cause an out-of-gas error.

BWC 8.8: DoS in Cross-Chain Messaging Protocols

Specific vulnerabilities in protocols like LayerZero or their integrations that can halt message passing.

BWC 9.0: Emerging Technology Vulnerabilities

BWC 9.1: Quantum Computing Threats

BWC 9.2: AI/ML Integration Attacks

BWC 9.2.1 Unrestricted Large Language Models (LLMs)

BWC 9.3: Hardware-Level Exploits

BWC 10.0: Network & Consensus Evolution Attacks

BWC 10.1: Advanced P2P Network Attacks

BWC 10.2: Novel Consensus Mechanism Exploits

BWC 10.3: Cross-Protocol Interoperability Attacks

BWC 10.4: Protocol Upgrade-Induced Vulnerabilities

Vulnerabilities that emerge in previously secure contracts when a network or protocol upgrade (like an EIP implementation) changes the behavior or security assumptions of the underlying platform. The contract code itself doesn't change, but its execution context does, rendering existing security patterns ineffective.

BWC 11.0: Privacy & Regulatory Attack Vectors

BWC 11.1: Privacy Protocol Compromises

BWC 11.2: Regulatory Weaponization

BWC Review

Bug Hunting Utilities Notes

Top DApps

DApp address

EVM Notes

1. ERC1967Proxy Slot Addresses

   • Admin Address: 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103
   • Beacon Address: 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50
   • Logic Address: 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
   • Old OZ implementation slot address: 0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3;

2. Topic 0 Proxy Events

   • Upgraded Event: 0xbc7cd75a20ee27fd9adebab32041f755214dbc6bffa90cc0225b39da2e5c2d3b
   • Ownership transferred Event: 0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0
   • Initialized Event: 0x7f26b83ff96e1f2b6a682f133852f6798a09c465da95921460cefb3847402498

FAQ

• How to report Cryptocurrency scams?
  • Contact SEAL 911
  • Visit ic3.gov, the FBI's Internet Crime Complaint Center, to file a report.

EVM Contract Vulnerability Incidents.

This database uses the BWC to classify Contract Vulnerability Incidents. Note off-chain issues have been excluded they're the most prevalent and resulted in more values lost. Humans remains to be the weakest point human stupidity is infinite.

2025-07-28 - {Count}

Date: Project: Value Lost: Chain: BWC:

• Broader Classification:
• Primary Classification: Description: References: Tx Postmortem

2025-07-28 - 7

Date: 2025-07-28 Project: SuperRare Value Lost: $ 730,000 Chain: Mainnet BWC:

• Broader Classification: BWC 2.0 Access Control Vulnerabilities.
• Primary Classification: BWC 2.1.1: Missing Access Control

Description:

• The core of the vulnerability is that the require statement, which is intended to enforce permissions, is logically flawed.

  // Flawed Code
  require((msg.sender != owner() || msg.sender != address(0xc2...)), "Not authorized...");

• This condition evaluates to true for any caller because an address cannot be two different values at the same time.
• This logical error means the authorization check fails to perform its function, rendering it ineffective.
• Therefore, even though an access control check appears to be present in the code, it is functionally missing.

References:

• Vulnerable Contract Proxy
• Vulnerable Implementation

2025-07-16 - 6

Date: 2025-07-16 Project: VDS Value Lost: $ 13,000 Chain: BSC BWC:

• Broader Classification: BWC: 3.2 Flawed State Management
• Primary Classification: Unknown Unerified Contract Description: The deposit function in the 0x6ce69d7146dbaae18c11c36d8D94428623B29D5A contract somehow mints more tokens than has been deposited flawed accounting of some sort. References: Address Tx 1

2025-07-15 - 5

Date: 2025-07-15 Project: Arcadia Value Lost: $ 3,600,000 Chain: Base BWC:

• Broader Classification: BWC 2.1 Missing or Improper Authorization
• Primary Classification: BWC 2.2.4 Cross Contract Untrusted Arbitrary Calls Description:
• The attacker exploited a missing validation vulnerability in the Asset Manager contracts. By supplying malicious calldata to a rebalancing function, the attacker tricked the Asset Manager into making an arbitrary call to a victim's Arcadia Account. Since the victim had authorized the Asset Manager, this call was successful, allowing the attacker to impersonate the Asset Manager and drain the victim's funds. A flash loan was used to temporarily clear the victim's debt, ensuring the account remained healthy and the malicious transaction would not revert. References: Tx 1 Tx 2 Tx 3 Tx 4 Postmortem

2025-07-10 - 4

Date: 2025-07-10 Project: Kinto Value Lost: $ 1,550,000 Chain: Arbitrum. BWC:

• Broader Classification: BWC 3.0 Smart Contract Logic & State Manipulation
• Primary Classification: BWC 3.2.1.1 Proxy/Contract Initialization Front-running Description: Attacker front ran initialization of Proxy upgraded the proxy installing a backdoor proxy. References: Tx 1 Tx 2 Postmortem

2025-07-09 - 3

Date: 2025-07-09 Project: GMX Value Lost: $ 42,000,000 Chain: Arbitrum BWC:

• Broader Classification: BWC 3.0: Smart Contract Logic & State Manipulation
• Primary Classification: BWC 3.1.4: Cross-Contract Reentrancy
• Secondary Classification: BWC 5.2.1: Price Manipulation

Description:

• The GMX protocol was exploited via a sophisticated cross-contract reentrancy attack.
• The vulnerability was in the PositionManager.executeDecreaseOrder() function, which made an external call (an ETH refund) to the attacker's contract.
• The attacker's contract then re-entered the GMX protocol, opening a large leveraged position before the initial transaction was complete.
• This manipulation artificially inflated the Assets Under Management (AUM) of the GLP pool, allowing the attacker to redeem their own GLP tokens at a much higher price, draining the vault.

Tx 1 Postmortem 1 Postmortem 2

2025-07-09 - 2

Date: 2025-07-09 Project: ZKSwap Value Lost: $5,000,000 Chain: BWC:

• Broader Category: BWC 4.0: Input & Data Validation Vulnerabilities.
• Primary Classification: BWC 4.3.1 Missing Signature Validation. Description:
• The verifyExitProof() function contained a hardcoded return true; statement, which effectively disabled the cryptographic verification of withdrawal proofs.
• An attacker activated the emergency "Exodus Mode" and repeatedly called the exit() function with fabricated proofs.
• Since the proof verification was skipped, the contract accepted the fake proofs, allowing the attacker to drain funds. References: Postmortem

2025-07-02 - 1

Date: 2025-07-02 Project: Quickswap Value Lost: Unknown Chain: Polygon BWC:

• Broader Classification: BWC 10.0: Network & Consensus Evolution Attacks
• Primary Classification: BWC 10.4: Protocol Upgrade-Induced Vulnerabilities eip 7702 Description: The contract implemented an onlyEOA() modifier, likely checking address(msg.sender).code.length == 0, to prevent contract-based calls, specifically to mitigate flash loan exploits. An attacker leveraged a type 4 transaction (EIP-7702) to bypass this check. EIP-7702 allows a contract to execute a call while setting the msg.sender to the Externally Owned Account (EOA) that signed the transaction. This makes the onlyEOA() check return true, as it sees the caller as a codeless EOA, while still allowing the attacker to use contract logic (and potentially flash-loaned funds) to execute the restricted function. This is a vulnerability induced by a protocol upgrade that broke the security assumptions of a previously standard check. References: Tx 1 Vulnerable Address

2025-06-23 - 2

Date: Project: Unverified Contract Value Lost: $ 610,000 Chain: Mainnet BWC:

• Broader Classification:
• Primary Classification: Description: It appears that the 0xf8c03cc4() function of the contract 0x16d7 lacks proper access control and swaps specified tokens on unverified pairs from the users who have granted approvals to this contract.

(0x16d7c6f43df19778e382b7a84bcb8c763971a551) on the Binance Smart Chain (BSC), with losses exceeding $600K. Since the contract is not open-source, our investigation indicates the root cause lies in a lack of slippage protection. This vulnerability allowed attackers to exploit the contract by using a fake liquidity pool to harvest #TA tokens (0x539ae81a166e5e80aed211731563e549c411b140), which were then sold in the legitimate pool to make profits.

Its 0xf8c03cc4() method seems to let anyone buy tokens that have been approved to it, through an intermediary DEX. The attacker created a new skewed TA-BSCUSD pair with fee=500 as intermediary and drained victims of TA tokens before dumping them on the fee=100 pair and profited ~$600K at 0x9c9a853f9245e88b09346268f3466372dfc3b638.

References: Tx 1 Tx 2 Tx 3

2025-06-08 - 1

Date: Project: PeapodsFinance Value Lost: $ 230,000 Chain: Mainnet BWC:

• Broader Classification:
• Primary Classification: Description: Likely Price Manipulation or sth References: Tx 1 Tx 2

2025-06-10 - 1

Date: Project: @BankRoll_Status Value Lost: $ 113,000 Chain: Mainnet BWC:

• Broader Classification:
• Primary Classification: Description: References: Tx 1

2025-06-10 - 1

Date: Project: Unverified Value Lost: $ 88,000 Chain: Mainnet BWC:

• Broader Classification:
• Primary Classification:
• Classification: Description: It appears that the registerProtocol() and setMasterContractApproval() in the vicitm contract 0xcfe0 lack proper access control, allowing anyone to withdraw the #RICE token from the contract. References: Tx 1

2025-05-26 - 1

Date: 2025-05-26 Project: @DexodusFinance Value Lost: $ 291,000 Chain: Base BWC:

• Broader Classification:
• Primary Classification: Description: References: Tx 1

2025-05-26 - 1

Date: 2025-06-02 Project: #FPC Value Lost: $ 4,700,000 Chain: Base BWC:

• Broader Classification:
• Primary Classification: Description:

It appears that the token employs a flawed burn mechanism, which burns tokens from the pool when a user sells. The attacker simply used a flash loan to buy tokens from the pool, pushing the price extremely high, and then sold the tokens back to the pool—effectively sandwiching the burn to make a huge profit.

References: Tx 1

2025-05-26 - 1

Date: 2025-06-02 Project: Old Contract Value Lost: 32,000 Chain: BWC:

• Broader Classification:
• Primary Classification: Description:

References: Tx 1

2025-05-26 - 1

Date: 2025-06-02 Project: UsualMoney Value Lost: 43,000 Chain: BWC:

• Broader Classification:
• Primary Classification: Description: The VaultRouter contract executes a swap from USD0++ to sUSDS by calling arbitrary calldata via ParaSwap, allowing the attacker to arbitrage between unwrapped USD0++ and the USD0++ liquidity pool.

References: Tx 1

2025-05-26 - 1

Date: Project: Value Lost: Chain: BWC:

• Broader Classification:
• Primary Classification: Description:

A complex exploit involving flash loans and repeated skim() calls was detected! 🧠 Full tx: https://bscscan.com/tx/0x78f242dee5b8e15a43d23d76bce827f39eb3ac54b44edcd327c5d63de3848daf

Attacker drained tokens from a liquidity pool by abusing skim and transfer.

⚡ Exploit Method:

1️⃣ Flash loan taken (zero collateral) 2️⃣ Tokens swapped via PancakeSwap 3️⃣ Unlimited allowance set 4️⃣ Repeated skim() calls abuse Token logic 5️⃣ Token reserves manipulated via sync() 6️⃣ Liquidity pool drained for profit 📊 Root Cause:

Missing checks in skim/reserve logic enabled attacker to extract residual tokens repeatedly. 💥 Impact:

Token balance and reserve manipulation led to massive fund extraction. No external collateral or prior holdings needed.

🛡️ Recommendations: Add validation, monitor for abnormal reserve changes Improve reserve accounting

References: Tx 1

Services Agreement for Smart Contract Audit

This Services Agreement ("Agreement") is entered into between [Client Name], hereinafter referred to as "Client," and [Auditor Name], hereinafter referred to as "Auditor," collectively referred to as the "Parties."

• Services Agreement for Smart Contract Audit
  • 1. Scope of Work
  • 2. Audit Process
  • 3. Timeline
  • 4. Pricing and Payment Terms
    • 4.1 Pricing Formula
    • 4.2 Deposit
    • 4.3 Final Payment
    • 4.4 Payment Method
    • 4.5 Late Payments
  • 5. Responsibilities
  • 6. Changes and Unforeseen Circumstances
  • 7. Intellectual Property
  • 8. Liability Limitations
  • 9. Cancellation Policy
  • 10. Dispute Resolution
  • 11. Compliance and Legal Framework
  • 12. Miscellaneous
  • 13. Signatures

1. Scope of Work

The Auditor agrees to perform a security audit of the Client's smart contracts deployed on [blockchain network], specifically [list contract addresses or repository links]. The audit will assess the code for vulnerabilities, logic errors, and compliance with industry best practices.

2. Audit Process

• Initial Review: The Auditor will perform an initial assessment of the smart contract code and share preliminary findings.
• Client Feedback: The Client may address the findings and implement fixes based on the initial review.
• Final Review: The Auditor will review the updated code and prepare a final audit report.
• Report Delivery: The final report will detail vulnerabilities, recommendations, and an overall security assessment.

3. Timeline

The audit will begin on [start date] and is expected to conclude by [end date], with the final report delivered by [report delivery date]. The Auditor is available to work from the 1st to the 21st of each month, dedicating 12 hours per day, 7 days a week, for a total of 21 consecutive days.

4. Pricing and Payment Terms

4.1 Pricing Formula

The total fee for the audit is calculated based on the number of Solidity lines of code (SLOC), determined using the following method:

• Code Formatting: The Solidity code must be formatted using forge fmt with the following settings:

   export FOUNDRY_FMT_SINGLE_LINE_STATEMENT_BLOCKS="multi"
   export FOUNDRY_FMT_LINE_LENGTH=90
   export FOUNDRY_FMT_TAB_WIDTH=4
   export FOUNDRY_FMT_MULTILINE_FUNC_HEADER="params_first_multi"
   export FOUNDRY_FMT_BRACKET_SPACING=false
   export FOUNDRY_FMT_INT_TYPES="long"
   export FOUNDRY_FMT_QUOTE_STYLE="double"
   export FOUNDRY_FMT_NUMBER_UNDERSCORE="thousands"
   export FOUNDRY_FMT_HEX_UNDERSCORE="remove"
   export FOUNDRY_FMT_OVERRIDE_SPACING=false
   export FOUNDRY_FMT_WRAP_COMMENTS=false
   export FOUNDRY_FMT_CONTRACT_NEW_LINES=true
   export FOUNDRY_FMT_SORT_IMPORTS=true
  

• Counting Lines of Code: After formatting, the SLOC will be calculated using cloc, a GNU utility, based on its output for Solidity files.
• The total fee is determined by the formula:

$Total Fee=(a×testing factor200+12)×200 USD\text{Total Fee} = \left( \frac{a \times \text{testing factor}}{200} + 12 \right) \times 200 \text{ USD}\text{Total Fee} = \left( \frac{a \times \text{testing factor}}{200} + 12 \right) \times 200 \text{ USD}$

Where:

• ( a ) = SLOC, as calculated by cloc after formatting with forge fmt using the settings above.

• Testing factor = 2 (if the Client provides tests) or 3 (if the Auditor must write tests for Proof of Concept (POC)).

• Audit Time: The adjusted SLOC (after applying the testing factor) is divided by 200 (assuming the Auditor audits 200 SLOC per hour).

• Report Compilation: An additional 12 hours is added for compiling the audit report and quality-of-life (QOL) documentation.

• Hourly Rate: The total hours are multiplied by the Auditor’s rate of {200 USD} per hour.

4.2 Deposit

The Client shall pay a 30% non-refundable deposit of the estimated total fee upon signing this Agreement. The estimate will be based on an initial SLOC count provided by the Client.

4.3 Final Payment

The final payment will be adjusted based on the actual SLOC count at the time of the audit and is due upon delivery of the final audit report.

4.4 Payment Method

Payments shall be made in [cryptocurrency, e.g., ETH, USDC] to the Auditor’s wallet address [wallet address].

4.5 Late Payments

Late payments will incur interest at [rate] per [time period].

5. Responsibilities

Client Responsibilities:

• Provide the final commit of the smart contracts by [date].
• Indicate whether tests are provided or if the Auditor must write tests for POC.
• Be available for meetings and discussions as required.
• Implement recommended fixes from the audit findings.

Auditor Responsibilities:

• Perform the audit with professionalism and diligence.
• Deliver a comprehensive final report by the agreed delivery date.
• Maintain confidentiality of the Client’s information.

6. Changes and Unforeseen Circumstances

• Scope Changes: Any changes to the scope must be agreed in writing and may adjust the timeline and fees. New functionality added during the fix audit may incur additional costs.

• Auditor Unavailability: If the Auditor cannot perform the audit due to unforeseen circumstances, a qualified replacement will be provided, or the timeline will be adjusted.

• Client Delays: If the Client is not ready by the start date, the Auditor may reschedule or charge additional fees.

• SLOC Disputes: Any disagreements over the SLOC count will be resolved by re-running cloc on the code formatted with the specified forge fmt settings.

7. Intellectual Property

The Auditor retains ownership of any tools, methodologies, or concepts developed during the audit, unless otherwise agreed.

8. Liability Limitations

The Auditor is not liable for undetected vulnerabilities or exploits after the audit. The Client understands that the audit is a point-in-time evaluation and does not ensure absolute security.

9. Cancellation Policy

The Client may cancel with at least 7 days’ notice, forfeiting the deposit. Cancellations with less than 7 days’ notice will incur a fee of 50% of the estimated total fee. The Auditor may cancel if the Client fails to meet their obligations, with the deposit remaining non-refundable.

10. Dispute Resolution

Disputes arising from this Agreement will be resolved through [mediation, arbitration, or jurisdiction-specific legal process].

11. Compliance and Legal Framework

The Client confirms that all funds used for payment are from legitimate sources and comply with anti-money laundering (AML) regulations. The Auditor may require the Client to complete know-your-business (KYB) procedures before starting the audit. Both Parties agree to adhere to applicable laws and regulations.

12. Miscellaneous

Confidentiality: Both Parties will protect sensitive information shared during the engagement. Report Publication: The Auditor may publish the audit report after 30 days from delivery, unless the Client objects in writing. Governing Law: This Agreement is governed by the laws of [jurisdiction].

13. Signatures

By signing below, both Parties confirm they have read, understood, and agree to be bound by this Agreement.

[Client Signature] [Date] [Auditor Signature] [Date]

X Post Alerts

X Post 2

🚨4.35 BTC Stolen
🔧Vulnerability:
• BWC 1.3.4: Supply Chain Attacks
• BWC 1.1.2: Private Key Leakage
• BWC 1.2.1: Social Engineering Exploits
🗡️Attack Method: Social Engineering ➡️ Unofficial Purchase of compromised hardware wallethttps://t.co/AyMLaAMuQY

— Emile Sean (@emilesean_es) July 29, 2025

X Post 1

🚨Instructive Multi Vector Attack.
🔧Vulnerability:
• BWC 5.1.1: Front-Running
• BWC 3.2.1: Improper Initialization
• BWC 1.2.3: UI Spoofing
🗡️Attack Method: Front-ran init tx ➡️ malicious upgrade ➡️ spoofed Etherscan UI & events.https://t.co/apuqnYuSde

— Emile Sean (@emilesean_es) July 13, 2025