| | | The system violates the "No Indispensable Intermediaries" law. It relies on specific actors (sequencers, relayers, provers, admin keys) that cannot be replaced by an ordinary participant. If these actors misbehave or disappear, the system halts or censors. | Mandatory Gatekeepers: Requiring a whitelisted relayer to execute transactions.Liveness Failure: The system fails the "Walkaway Test"—if the team's node dies, the chain stops.Admin Keys: Multisigs with the power to override consensus or pause the chain indefinitely. | Ensure permissionless participation for all infrastructure roles.Design for redundancy; any honest actor should be able to advance the state.Remove "Training Wheels" (admin keys) as the system matures. |
| | | The system is theoretically open but practically closed due to excessive complexity or resource requirements. This violates the "Accessibility" principle, creating a class system where verification is a privilege for specialists, forcing users to "trust the dashboard." | Hardware Exclusion: Verifier nodes requiring enterprise-grade RAM/Storage, pricing out community auditors.Closed Source/Obfuscation: Proprietary code prevents independent reasoning about state validity. | Prioritize Light Clients that can run on consumer hardware.Ensure all components are Free Open Source Software (FOSS). |
| | | The system violates the "No Critical Secrets" law. It relies on private information (mempools, off-chain order books, server-side keys) held by a single actor to function or determine state transitions. | Mempool Manipulation: A centralized sequencer exploits its private view of pending transactions to extract MEV or censor users.Opaque Execution: Transaction outcomes depend on off-chain data that is not cryptographically committed to the chain. | No Private State: All data required to verify a transition must be public.Use Threshold Encryption to protect pre-execution state without centralizing trust. |
| | | The system replaces Delegation (optional convenience) with Dependence (mandatory reliance). Users cannot interact with the protocol directly but must route through a specific UI, API, or relayer that acts as a landlord. | Interface Censorship: The protocol is open, but the only UI is hosted and blocklisted (e.g., Tornado Cash UI).Gateway Lock-in: Users sign "intents" that can only be solved by a closed set of solvers. | Ensure direct contract interaction is always possible.Build Client Diversity to prevent interface-level capture. |
| | | The base layer discriminates against specific users or use cases. Instead of "math and consensus," the protocol enforces policy, becoming a "Platform" rather than a neutral "Protocol." | Protocol-Level Censorship: Validators filtering transactions based on real-world identity or geography.Governance Capture: A token distribution that allows a small oligopoly to change the rules arbitrarily. | Minimize Governance: Governance should be minimized or removed ("Ossification") for base layers.Blind Execution: The protocol should process any valid transaction regardless of origin. |
| | | The system violates the "No Unverifiable Outcomes" law. Effects on the state cannot be strictly reproduced from public data, requiring "Blind Trust" in an oracle or multisig. | Multisig Bridges: State updates based solely on "7 of 10 people signed this," with no cryptographic proof of the source event.Opaque Upgrades: Logic changes instantly via admin key without a timelock or user opt-out. | Use Validity Proofs (ZK) or Fraud Proofs to replace human attestation.Ensure Data Availability (DA) so state can always be reconstructed. |
| | | The system prioritizes corporate metrics (market cap, engagement) over user sovereignty. It uses "corporate optimization power" and a "respectable aura" to mask behavior that extracts value from users rather than empowering them. This manifests in four key ways:
1. Attention & Dopamine Extraction: Hijacking attention for short-term engagement (addiction).
2. Surveillance & Data Commodification: Needless data collection to create sellable assets.
3. Walled Gardens: Preventing exit or interoperability (Monopolistic Lock-in).
4. Predatory Financialization: Marketing high-risk gambling as "investing" (Gamblification). | Gamified Addiction: Using "loot box" mechanics, streaks, or manipulative notifications to force daily interaction without utility.Wallet Doxing: RPCs or front-ends that link wallet addresses to real-world identities/IPs without consent.Vendor Lock-in: Proprietary standards or bridges that prevent users from exporting keys or moving assets to competitors.Default Leverage: UIs that default to high-risk settings (e.g., 50x leverage) to maximize liquidation fees at the expense of user solvency. | Sovereign Tools: Build privacy-preserving, local-first applications where the user owns the data.User-Controlled Algorithms: Allow users to choose their own content filters and sorting logic.Credible Exit: Users must always be able to withdraw assets/data to a neutral standard (e.g., raw ETH, raw Text).Wealth-Building Design: Focus on tools that encourage saving and utility rather than impulse and speculation. |
| | | Vulnerabilities in user devices or operating systems leading to private key theft, session hijacking, or malicious transaction approvals. | Infecting a device with malware via malicious downloads or phishing links.Exploiting unpatched OS vulnerabilities to gain root access. | Use dedicated, air-gapped devices for signing critical transactions.Keep all software, including OS and browser, up-to-date.Employ hardware wallets to isolate keys from general-purpose devices. |
| | | Accidental or intentional exposure of private keys, granting unauthorized access to funds. | Hardcoding keys in public code (e.g., GitHub).Phishing attacks tricking users into revealing their seed phrase.Insecurely storing keys in plaintext on a compromised server. | Store keys in hardware security modules (HSMs) or hardware wallets.Never store seed phrases digitally.Use multi-signature (multisig) wallets to require multiple keys for a transaction. |
| | | Current or former employees, contractors, or partners intentionally misusing their authorized access to compromise a system. | A rogue developer inserting a backdoor into a smart contract.A disgruntled employee stealing funds from protocol-owned wallets. | Implement strict access controls and the principle of least privilege.Use timelocks for critical administrative actions.Conduct thorough background checks on individuals in sensitive roles. |
| | | An attacker uses physical violence, coercion, or threats (shifting toward psychological warfare and AI-enhanced tactics) to force a victim to surrender their private keys or assets, bypassing all technical security measures. | Armed Robbery: Theft using lethal weapons.Blackmail: Threats to reveal compromising info.Extortion: Prolonged pressure or threats against loved ones.Home Invasion: Forceful entry, often by posing as utility/delivery workers.Kidnapping: Abduction, often via social engineering honey pots (fake meetings).Murder: Killing of a victim during theft.Physical Assault: Inflicting bodily harm to intimidate.Ransom: Demanding payment for victim release.Robbery: Theft using force/fear without lethal weapons.Torture: Inflicting severe pain to force disclosure.
Threat Evolution:Deepfake Extortion: Hyper-realistic proof of life (fake kidnapping).AI-Scaled Honey Pots: Autonomous agents managing thousands of fake relationships. | Early Detection: Watch for unsolicited 2FA (digital compromise) or physical anomalies (unexpected visitors).Decoy Wallets: Maintain a plausible "duress" wallet.Segregation: Store seed phrases in bank vaults, separate from hardware wallets.OpSec: Remove crypto apps from daily phones; stop flexing; use dedicated hardware.Advanced Defense: Use Multi-Sig and Time-Locks to remove human single points of failure. |
| | | Flaws in tools used to create custom, human-readable addresses (e.g., starting with 0xdead...) that result in predictable or non-random private keys. | Using a generator with a weak source of randomness.Exploiting bugs in the generation algorithm to brute-force the private key. | Only use well-audited, reputable vanity address generators.Understand that vanity addresses may reduce privacy by linking an identity to an address. |
| | | Tricking users into revealing sensitive information or performing actions against their interest through deception. Many modern campaigns are executed via "Drainer-as-a-Service" platforms, where affiliates use sophisticated kits to target users. | Trusted Notification Phishing: Abusing the notification systems of legitimate platforms (e.g., fake GitHub grants notifications, Google Docs comments) to send phishing links from an official source.Recruitment scams (e.g., fake job offers requiring a "test" transaction).Investment/Pig Butchering scams.Malvertising: Using compromised ad network accounts (e.g., Google Ads) to target users searching for crypto-related keywords.Spam Campaigns: Creating mass spam on trusted platforms like GitHub issues to lure victims with fake airdrops or grants.Address poisoning (sending dust to an address to pollute transaction history). | Verify the source of all requests, even if the notification comes from a legitimate domain. Navigate directly to the official project's website or platform to confirm any offers or alerts.Implement protocol-level safeguards (e.g., time-delayed withdrawals).User education on common scams and the function of transaction signing. |
| | | An attacker illegally obtains a new SIM card for a victim's phone number, allowing them to intercept 2FA codes sent via SMS. | Bribing or tricking mobile carrier employees.Using leaked personal information to impersonate the victim to their mobile provider. | Use non-SMS based 2FA (e.g., authenticator apps, hardware keys).Set up a PIN or password with your mobile carrier for account changes. |
| | | Modifying a DApp's web interface to trick users into approving malicious transactions or revealing secrets. Attackers often use advanced "cloaking" to hide malicious payloads from security researchers while presenting them to targeted victims. | DNS hijacking to redirect users to a fake site.Abuse of Trusted Hosts: Hosting a clean landing page on a high-reputation domain (e.g., Google Sites) while loading malicious drainer scripts from other trusted sources (e.g., jsDelivr, Google Cloud Storage) to evade blocklists.Re-registering Expired Domains: Acquiring the expired domains of defunct but previously legitimate crypto projects to inherit their established trust.Browser Fingerprinting: Using scripts to filter traffic, showing the malicious site only to specific targets (e.g., by geolocation) while redirecting researchers or bots to a benign page or a fake CAPTCHA.Compromising the front-end hosting server to inject malicious code. | Users should verify domain names and look for SSL certificates, while remaining aware that even trusted domains can be abused to serve malicious content.Use hardware wallets to verify transaction details on a trusted screen.Protocols can use ENS and IPFS for decentralized, content-addressed front-ends that are more resistant to hijacking and spoofing. |
| | | Malicious mobile or desktop apps that impersonate legitimate wallets to steal private keys or seed phrases. | Distributing fake apps via unofficial app stores or phishing links. | Only download wallet software from official, verified sources.Verify checksums of downloaded binaries. |
| | | Browser extensions that steal secrets or inject malicious scripts into DApp front-ends. | An extension requests excessive permissions to read all site data. | Regularly audit browser extensions and their permissions.Use a separate, clean browser profile for crypto activities. |
| | | A custom RPC endpoint that returns false data to trick a user or wallet into signing a malicious transaction. | An RPC provider can lie about on-chain data, such as token balances or contract code, to deceive a user.They can route your transaction through a public mempool where it might be exposed to MEV.They can MEV your transaction themselves as an adversarial RPC provider.They can log your IP and transactions for surveillance. | Use well-known, reputable RPC providers.Verify critical transaction details on a trusted third-party explorer. |
| | | Design flaws in critical off-chain components (e.g., keeper bots, oracle nodes) that are essential for protocol health, causing them to fail under stressful or unexpected conditions like high network congestion. | Liquidation keeper bots fail to submit transactions during high network congestion because their gas price logic is not adaptive, allowing auctions to fail. Oracle nodes fail to update prices in a timely manner, leading to the use of stale data. | Treat critical off-chain components with the same security rigor as smart contracts, including robust design and audits. Design bots with adaptive strategies for handling network congestion, such as dynamic gas price calculation. Promote a diverse and decentralized ecosystem for off-chain roles to avoid single points of failure. |
| | | A single entity creates a large number of pseudonymous identities to gain a disproportionate advantage in a system. This undermines mechanisms that assume unique participants, such as airdrop distributions, governance voting, and reputation systems. | Airdrop Farming: Creating thousands of wallets with minimal activity to unfairly claim rewards intended for a broad user base.Governance Takeover: Using a large number of Sybil-controlled wallets to amass enough voting power to pass or block proposals maliciously. | Implement Sybil resistance mechanisms, such as Proof-of-Humanity (e.g., Worldcoin, BrightID) or knowledge-based authentication.Use on-chain heuristics to detect coordinated wallet activity (e.g., identical funding patterns, synchronized transactions).Design governance and reward systems that favor long-term engagement and stake-weighting over simple address counts. |
| | | A validator or node operator is compromised, leading to malicious activities like transaction censorship, reordering, or double-spending. | Private key theft from a validator node.Malicious software running on node infrastructure. | For stakers: use robust, dedicated infrastructure.For protocols: ensure a high degree of validator decentralization to minimize the impact of a single compromised node. |
| | | Redirecting traffic from a legitimate DApp website to a fraudulent phishing site by compromising DNS servers. | Compromising a domain registrar account.BGP hijacking. | Use DNSSEC to authenticate DNS responses.Users should use DNS-over-HTTPS (DoH) and a trusted resolver. |
| | | Hijacking of official project accounts (Discord, X/Twitter, Telegram) to post phishing links or spread misinformation. | Theft of social media admin credentials via phishing or malware. | Secure all team accounts with hardware key-based 2FA.Establish an emergency communication channel separate from social media. |
| | | Compromises in the development pipeline, including malicious dependencies, backdoored developer tools (compilers, IDEs), or insecure deployment processes. | Injecting malicious code into a popular library (e.g., NPM package).Backdoors in developer tools like compilers, IDEs, or extensions.Compromising a developer's machine to inject code at build time. | Pin dependencies to specific, audited versions.Use trusted developer tools and vet third-party extensions.Create a Software Bill Of Materials (SBOM).Conduct regular dependency scanning and audits of the development environment. |
| | | A bug in a client's implementation of a core protocol rule (e.g., state root computation, block validation) that causes it to fail to reach or maintain consensus with the rest of the network. | A client incorrectly computes a state root, causing it to be rejected by other clients (e.g., the 2025 Reth bug).A client fails to properly validate a block according to network rules. | Run a diverse set of clients to prevent a single client's bug from halting the network.Implement rigorous testing and fuzzing of client software. |
| | | A bug in a client's RPC/API layer that returns incorrect or misleading data to users or applications, potentially leading to flawed transactions or an incorrect view of on-chain state. | An RPC call returns a stale or incorrect balance for an account.An API endpoint for transaction simulation provides a result that differs from actual execution. | Cross-reference data with multiple independent sources (e.g., different block explorers or nodes).DApps should have robust error handling for unexpected API responses. |
| | | Failure to maintain ownership of critical communication links (e.g., social media vanity URLs), allowing scammers to claim the expired links and impersonate the project. This turns all historical references to that link into phishing traps. | Allowing a custom Discord or Telegram vanity URL to expire, which is then registered by a scammer.Attackers weaponizing outdated links in project documentation, social media profiles (CoinGecko, CMC), and historical tweets to direct users to phishing sites. | Continuously monitor and renew all custom vanity URLs and branded links.Regularly audit and update all public-facing profiles and documentation to ensure links are current and active.Establish a clear process for deprecating and removing old links from all platforms. |
| | | Sophisticated, large-scale attacks, often attributed to nation-states or organized crime (e.g., Lazarus Group), that combine multiple tactics simultaneously. | Combining social engineering (fake job offers), malware (laced PDFs), and smart contract exploits in a single, coordinated campaign. | Extreme operational security (OPSEC) for team members.Compartmentalize roles and permissions.Constant vigilance and employee training. |
| | | Nation-state actors targeting core internet infrastructure (e.g., DNS, BGP, certificate authorities) to intercept or redirect traffic for entire ecosystems. | BGP hijacking to reroute traffic to state-controlled servers.Compromising a certificate authority to issue fraudulent TLS certificates. | Use of decentralized infrastructure (e.g., ENS, IPFS).DNSSEC and other cryptographic verification methods.User-side vigilance (e.g., using trusted VPNs). |
| | | Using blockchain and DeFi protocols as instruments of economic warfare, such as evading sanctions or destabilizing the financial systems of rival states. | State-sponsored entities using mixers and privacy coins to launder stolen funds.Targeting a country's financial infrastructure by attacking its digital currency systems. | Regulatory compliance (where applicable).On-chain monitoring and heuristics to detect sanctioned activity.International cooperation between law enforcement agencies. |
| | | Exploiting inconsistencies and loopholes in regulations across different legal jurisdictions to conduct malicious activities that are difficult to prosecute. | Hosting different parts of a malicious operation in countries with lax regulations.Using shell corporations in multiple jurisdictions to obscure ownership. | Harmonization of international regulations.Enhanced due diligence and Know Your Customer (KYC) processes.Chain analysis to trace fund flows across jurisdictions. |
| | | The intentional or unintentional creation of extreme market volatility and network congestion stemming from major geopolitical events. This stress can cause cascading failures in critical on-chain and off-chain infrastructure, leading to mass liquidations, oracle failures, and protocol insolvency. | Tariff Wars & Sanctions: Sudden, severe economic actions causing market panic and a flight to safety, triggering massive sell-offs and extreme network congestion.Physical or Cyber Attacks: Major real-world events (e.g., terror attacks, critical infrastructure sabotage) that create global market instability, directly impacting crypto asset prices and network usability.Targeted Economic Destabilization: A nation-state intentionally creating market chaos to exploit protocol weaknesses that only emerge under extreme stress, such as oracle failures or liquidation system collapse. | Robust Systemic Design: Protocols must design their economic and liquidation mechanisms to withstand "black swan" events and extreme, sustained market volatility.Diversified and Resilient Oracles: Oracles should not rely on a single source of truth and must have mechanisms to remain reliable during periods of intense network congestion.Decentralized and Adaptive Keepers: Liquidation and auction systems should not rely on a centralized or homogenous set of keepers. The system should incentivize a diverse set of participants who can operate under high-cost network conditions.Circuit Breakers: Implement automated "circuit breakers" that can pause critical protocol functions during periods of unprecedented volatility to prevent catastrophic failure and allow for manual intervention. |
| | | Failure to implement any or sufficient authorization checks, allowing sensitive functions to be called by any user. | Calling a function like initialize() or setOwner() that was intended to be called only once but was left public. | Use function modifiers (e.g., onlyOwner).Set correct visibility (e.g., internal, private).Follow the principle of least privilege. |
| | | Using tx.origin for authorization, which is insecure as it makes the contract vulnerable to phishing attacks where a user is tricked into calling a malicious intermediary contract. | A victim calls a malicious contract A, which then calls the vulnerable contract B. Inside B, a check for tx.origin == victim_address passes, granting A the victim's privileges. | Always use msg.sender for authorization, as it identifies the immediate caller. |
| | | Granting excessive or indefinite token allowances (ERC20.approve) to smart contracts, which can lead to fund theft if the approved contract is compromised or malicious. | A user approves a contract for an unlimited amount of tokens. The contract is later exploited, and the attacker calls transferFrom to drain the user's wallet.Granting token approvals to permissionless "helper" or "executor" contracts (e.g., multicall or settler contracts). Since anyone can call these contracts, an attacker can instruct the contract to transfer the approved tokens to themselves. | Approve only the exact amount needed for a transaction.Use standards like EIP-2612 (permit) for gasless, single-transaction approvals.Regularly revoke old allowances using tools like Revoke.cash. |
| | | Errors in deploying or managing proxy patterns (like Transparent or UUPS proxies) that can lead to storage collisions, lost implementations, or unauthorized upgrades. | Forgetting to initialize the implementation contract, allowing an attacker to claim ownership.Storage layout of the proxy and implementation are not compatible, leading to data corruption.Constructor State Initialization: Using a constructor in the implementation contract to set storage variables. Since the constructor runs in the context of the implementation address, the proxy's storage remains uninitialized. | Use well-audited, standard proxy implementations (e.g., from OpenZeppelin).Follow documented procedures for deployment and upgrades carefully.Use tools to check for storage layout compatibility. |
| | | The contract allows an attacker to specify the target and calldata for a low-level call (e.g., .call()). This allows the attacker to force the contract to execute any action in its own context, effectively impersonating it. | Stealing User Funds (via Approvals): The attacker forces the contract to call token.transferFrom(victim, attacker, amount). Since the victim has approved the contract (BWC 2.2.1), the token contract accepts the request.Stealing Contract Funds: The attacker forces the contract to call token.transfer(attacker, amount) to drain assets held by the contract itself. | Avoid allowing arbitrary calls to user-supplied addresses.Use a whitelist of trusted contracts.If arbitrary calls are required, blacklist sensitive selectors like transferFrom or approve. |
| | | An exploit where composing multiple, individually secure contracts allows an attacker to make a contract perform a malicious, arbitrary call that would not be possible in isolation. | A DeFi protocol allows users to execute a sequence of operations. An attacker crafts a sequence that causes an intermediate contract to call a third, unrelated protocol in an unexpected way. | Carefully audit and reason about all possible interactions with external protocols.Implement checks to prevent unexpected external calls within a multi-step operation.Use reentrancy guards. |
| | | Architectural design that intentionally allows privileged developers to steal or freeze user funds without warning. | A contract owner has a function to withdraw all user deposits.A proxy implementation can be changed to a malicious contract at any time. | Use timelocks for all privileged operations.Decentralize or burn ownership where possible.Ensure proxy upgrade paths are controlled by a DAO or secure multi-sig. |
| | | Failure to verify the caller or parameters of a public callback function. These functions (e.g., flashloan receivers, token hooks like onERC1155Received) must act as gatekeepers, but if they fail to authenticate that the caller is the specific trusted contract (e.g., the lending pool or the token contract), an attacker can invoke them directly to spoof events. | Spoofing Deposits: Calling onERC1155Received or onERC721Received directly to simulate a deposit and trigger internal accounting logic (e.g., minting wrapper tokens) without actually transferring assets (e.g., the TSURU exploit).Malicious Flashloan Data: An attacker invokes a flashloan callback directly, passing malicious data to bypass checks or manipulate state intended only for the legitimate lending pool execution context. | Authenticate msg.sender: Strictly verify that the caller is the expected token contract or lending pool address.Verify State Changes: Ensure that the assets associated with the callback (e.g., loan principal, deposited tokens) have actually been received or transferred. |
| | | An attacker's contract calls back into a vulnerable contract before its state updates are completed, allowing for multiple withdrawals or other exploits. | A contract withdraws Ether, then re-enters the withdrawal function before its balance is updated, draining the contract. | Use the Checks-Effects-Interactions pattern.Use reentrancy guard modifiers (e.g., OpenZeppelin's nonReentrant). |
| | | Exploiting token hooks in the ERC-777 standard (tokensToSend or tokensReceived) to reenter contracts during a token transfer. | An attacker crafts a malicious contract as the recipient of an ERC-777 token. The tokensReceived hook on the malicious contract calls back into the victim contract. | Use reentrancy guards.Be aware of the reentrancy possibilities when using ERC-777 tokens. |
| | | Reentering a contract to read a state that is inconsistent or in the process of being changed, leading to logic errors, even if no state is written in the second call. | An attacker calls a function that changes state, and in the same transaction, re-enters to read that state before the change is finalized, leading to incorrect calculations. | Use view/read-only reentrancy guards.Ensure all state is updated before any external calls. |
| | | A reentrancy attack that becomes possible due to unforeseen interactions between multiple, otherwise secure, contracts. The vulnerability emerges from the composition of protocols. | Protocol A calls Protocol B. An attacker finds a way to make Protocol B call back into Protocol A, bypassing its reentrancy guard because the direct caller is Protocol B. | Use context-aware reentrancy guards if possible.Thoroughly audit all integrations with external protocols. |
| | | Contracts deployed with incorrect initial state, missing initialization, or unset flags, often leaving them ownerless or in a vulnerable state. | Deploying a proxy contract but failing to call the initialize function on the implementation, allowing an attacker to claim ownership. | Use constructor initialization where possible.Ensure initializer functions can only be called once. |
| | | Logic errors in mechanisms that check the status or code of other contracts, such as verifying if an address is a contract or not. | Using extcodesize to check for an EOA, which can be bypassed if the check is performed during contract construction. | A more reliable check for contract existence is address.code.length > 0. |
| | | Manipulating a contract's Ether balance to disrupt logic that depends on address(this).balance. | An attacker can forcibly send Ether to any contract via selfdestruct(victim_address). | Avoid using address(this).balance for critical logic. Design contracts to be agnostic to their Ether balance. |
| | | Exploiting state changes caused by transfers to the same address or by the ordering of transactions within a block. | In a token contract, transferring tokens to oneself might bypass certain checks or trigger reward logic incorrectly. | Add checks to prevent transfers where the sender and recipient are the same. |
| | | Errors in logic that are supposed to modify or correct contract state, leading to inconsistent or exploitable conditions. | A function that is supposed to burn tokens fails to update the total supply correctly. | Rigorous unit testing of all state-changing functions.Use formal verification to prove state consistency. |
| | | An attacker observes a transaction that deploys a contract and immediately sends a transaction with a higher gas fee to initialize the contract with their own address as the owner. | An attacker sees a new proxy contract deployment in the mempool and rushes to call its initialize function before the legitimate deployer does. | Combine deployment and initialization into a single transaction using a factory contract.Ensure initializer functions have proper access control. |
| | | A vulnerability created when a child contract inherits from a parent (e.g., an OpenZeppelin standard) and overrides an internal function. By altering the logic or removing critical checks in the overridden function, the child contract breaks the security assumptions (invariants) of other, non-overridden public functions in the parent contract that rely on the original internal function's behavior. | An attacker identifies a public function (e.g., mint) in a parent contract that relies on an internal function (e.g., _deposit) for a critical check.The child contract has overridden the internal function but failed to replicate the critical check, often moving it to a different public function (e.g., deposit).The attacker calls the original, non-overridden public function, which then executes the new, insecure internal logic, bypassing the critical check and leading to exploits like free mints or unauthorized withdrawals. | Thoroughly Review Parent Contracts: When inheriting, developers must understand all internal dependencies of the parent contract. All public functions that rely on an internal function must be considered before that internal function is overridden.Preserve Invariants: If overriding an internal function, ensure that all of its original security guarantees (invariants), such as asset receipt checks or access controls, are either preserved in the new implementation or explicitly replicated in every public function that depends on it.Favor Composition over Inheritance: Where possible, use composition (i.e., using external libraries or contracts) instead of inheritance to avoid complex and fragile dependency chains. |
| | | Logic errors arising from the improper manipulation, validation, or searching of array data structures. This includes failing to sanitize inputs for duplicate entries or using search algorithms (like binary search) on arrays that violate uniqueness assumptions (e.g., duplicate timestamps), leading to incorrect accounting or stale data retrieval. | Duplicate Asset/Reward Exploits: An attacker creates an offer or interaction supplying an array of tokens that contains duplicates. If the protocol iterates through the array to issue rewards without deduplicating, the attacker drains the system by claiming the reward multiple times for a single action (e.g., the Royco exploit).Binary Search Failure via Duplicates: In systems that track historical data (checkpoints), an attacker triggers multiple updates in a single block to create entries with duplicate timestamps. If the binary search implementation assumes unique keys, it may return the first (stale) entry instead of the latest one, leading to incorrect calculations (e.g., the Alchemix exploit). | Input Sanitization: Explicitly validate array inputs to ensure there are no duplicate entries, or use a mapping to track processed items during iteration.Enforce Uniqueness: Ensure data structures used for historical lookups enforce strict uniqueness of keys (e.g., overwrite existing checkpoints if the timestamp is the same).Robust Search Logic: When using binary search on potential duplicates, ensure the algorithm is designed to find the specific bound (e.g., the last occurrence) required by the protocol's logic. |
| | | Contracts where a native token also has an ERC-20 representation, potentially leading to inconsistent state or accounting if not handled carefully. | A bridge or protocol only accounts for the ERC-20 version, while value is moved via the native transfer mechanism, leading to a desync. | Ensure the contract logic correctly handles both the native and ERC-20 representations and keeps their states synchronized. |
| | | Incorrect handling of tokens that deduct fees during transfers or have an elastic supply (rebase tokens), leading to incorrect balance calculations. | A protocol assumes that if it transfers X tokens, the recipient will receive X tokens, which is not true for fee-on-transfer tokens. | Cache token balances before and after a transfer to determine the actual amount received.Avoid using tokens with non-standard mechanics if possible. |
| | | Errors in managing the blockchain's native currency (e.g., ETH, BNB) alongside other tokens, often related to payable functions or msg.value. | A function incorrectly uses msg.value or fails to check it, leading to over or underpayment. | Always validate msg.value in payable functions.Use the Checks-Effects-Interactions pattern when sending Ether. |
| | | Failure to handle non-standard implementations of the ERC20 interface, such as tokens that do not return a boolean on success for transfer or approve. | A contract calls transfer on a non-compliant token, and the call succeeds but does not return true, causing the calling contract to revert. | Use OpenZeppelin's SafeERC20 library, which handles these edge cases. |
| | | A contract implements a feature based on a non-token EIP standard (e.g., ERC-3156 for flash loans, ERC-721 for NFTs) but deviates from the standard's required logic. This leads to broken interoperability with other compliant contracts and creates unexpected behaviors or logical flaws. | A compliant external contract attempts to interact with the non-compliant function, leading to reverted transactions or incorrect state changes because the expected interface and behavior do not match.The non-compliant implementation may lack critical safety checks or return values specified in the EIP, which other protocols rely on for safe integration. | Adhere Strictly to Standards: When implementing a feature based on a public EIP, follow the specification precisely, including function signatures, return values, and required checks (e.g., pulling funds back after a flash loan).Use Standard Libraries: Rely on well-audited, community-vetted implementations of common EIPs (e.g., from OpenZeppelin) to ensure compliance and avoid introducing subtle deviations.Test for Composability: Actively test integrations with other known, compliant contracts to ensure the implementation behaves as expected within the broader ecosystem. |
| | | Exploiting voting mechanisms, proposal processes, or timelocks to pass malicious proposals or seize control of a protocol. | Using flash-loaned tokens to gain enough voting power to pass a malicious proposal. | Require a minimum token holding period before votes are counted.Implement a reasonable timelock duration for proposal execution. |
| | | Exploitable incentive structures or reward calculation errors that allow attackers to claim unfair rewards. This includes design flaws in penalty or slashing mechanisms where the funds are "donated" in a way that allows the penalized attacker to also be the beneficiary, effectively negating the penalty. | An attacker finds a way to repeatedly claim staking rewards without locking up any real assets.Self-Serving Penalty: An attacker uses a secondary account to become the sole recipient in a penalty distribution zone. They then perform the penalized action with their primary account, and the penalty is "paid" directly to their secondary account, resulting in no net loss. | Thoroughly model and test all reward and penalty logic.Implement caps on rewards or use a time-weighted system.Ensure penalty funds are sent to a neutral, non-manipulable destination (e.g., a treasury or burn address).Design penalty mechanisms to prevent reflexive scenarios where the payer and payee can be the same entity. |
| | | Inconsistencies between cross-chain bridge endpoints leading to fund loss or transaction failure, often due to one side of the bridge being paused or upgraded while the other is not. | A user sends funds to a bridge on Chain A, but the contract on Chain B is paused, trapping the funds. | Implement a cross-chain mechanism to pause the entire bridge simultaneously.Provide clear status indicators on the bridge interface. |
| | | Failure to properly sanitize or validate transaction inputs, enabling malicious or unexpected data to be processed. This includes missing zero-address checks. | A user can pass a zero address for a critical parameter, leading to burned funds or locked contracts.Passing a malicious contract address where an EOA is expected. | Validate all inputs for correctness (e.g., check for zero addresses, ensure values are within expected ranges). |
| | | Inadequate verification of external data feeds (e.g., price feeds), allowing manipulation of critical on-chain information. | A protocol uses a price oracle but fails to check if the returned price is recent or if the oracle round is complete, leading to the use of stale data. | Use reputable oracle providers like Chainlink.Check oracle heartbeat and timestamp to ensure data freshness.Implement circuit breakers to halt operations if prices move too drastically. |
| | | Actively compromising or gaming the data feeds that DApps rely on for external information, often by manipulating the price on a low-liquidity decentralized exchange that an oracle uses as its source. | Using a flash loan to execute a large trade on a DEX, momentarily skewing the price, and then using that manipulated price in another protocol to take out an unfair loan. | Use oracles that aggregate prices from multiple, high-liquidity sources.Use Time-Weighted Average Price (TWAP) oracles, which are more resistant to manipulation. |
| | | Improper or missing verification of cryptographic signatures, enabling transaction forgery or replay attacks. | A contract allows an action based on a signature but fails to check that the signature is valid or has not been used before. | Use a nonce to prevent signature replay attacks.Use well-audited libraries for signature verification (e.g., OpenZeppelin's ECDSA library). |
| | | Flaws in the implementation of transaction signing cryptography, such as vulnerability to signature malleability or improper use of EIP-712. | An attacker can slightly modify a valid signature without invalidating it, potentially causing issues in contracts that rely on the signature hash. | Use EIP-712 for structured, typed data signing to prevent phishing and replay attacks across different contracts.Ensure the signer address recovered from ecrecover is not the zero address. |
| | | A vulnerability where a contract uses both ERC-2771 for meta-transactions and a Multicall-type contract as its trusted forwarder. If the forwarder does not properly append the original caller's address to the callData of each sub-call, an attacker can control the data that the receiving contract mistakes for the caller's address, thus impersonating any account. | An attacker calls a vulnerable Multicall forwarder, crafting the callData of a sub-call so that its last 20 bytes contain the address of the victim they wish to impersonate (e.g., the contract owner).The Multicall contract forwards this callData to the target contract without appending the real msg.sender.The target contract, using ERC2771Context, extracts the last 20 bytes of the received callData, trusting it to be the sender's address. It then grants the attacker the privileges of the impersonated victim. | Ensure any trusted forwarder correctly appends the original msg.sender to the end of the callData for all sub-calls (e.g., abi.encodePacked(call.callData, msg.sender)).Use standard, audited implementations of Multicall and ERC2771Context from libraries like OpenZeppelin, which have patched this specific interaction.Avoid using generic, non-ERC2771-compliant Multicall contracts as trusted forwarders. |
| | | Occurs when different components or execution paths interpret or validate the same input data differently. This creates a security gap where checks enforced in one context (e.g., immediate execution) are missing or implemented differently in another (e.g., retry logic, off-chain indexing vs on-chain execution). | Path Bypassing: Forcing a transaction into a secondary state (like "Retriable" in a bridge) to exploit the fact that the secondary execution path lacks the validation checks present in the primary path.Format Discrepancies: Exploiting differences in how two libraries decode the same data (e.g., a JSON parser vs a Solidity decoder) to smuggle malicious payloads. | Centralize Validation: Use a single, shared library or modifier for validation across all execution paths.Canonical Data formats: Ensure strictly typed and canonical data formats are used throughout the lifecycle of a message. |
| | | Placing a transaction in the queue before a known future transaction to exploit the order of execution. This is often possible when a transaction's input data contains sensitive information (like a password or a solution to a puzzle) that is publicly visible in the mempool. | Sniffing sensitive data (e.g., passwords, answers to puzzles) from transaction input data in the public mempool and using it in a competing transaction with a higher gas fee. | Never pass cleartext secrets (like passwords or private keys) as function arguments. Sensitive data in a transaction's payload is publicly visible.Use a Commit-Reveal Scheme to prevent exposing the secret before execution.Use Off-Chain Signatures (EIP-712) where a user signs a message containing the secret, and the contract verifies the signature.Make use of offchain MEV protection mechanisms such as Flashbots. |
| | | Placing a transaction immediately after a targeted transaction to exploit its effects. | Observing a large swap on a DEX and immediately placing a trade to profit from the price slippage caused by it. | Make use of offchain MEV protection mechanisms such as Flashbots. |
| | | Combining front-running and back-running to trap a victim's transaction and extract value. | An attacker front-runs a victim's buy order to drive the price up, lets the victim's trade execute at the higher price, and then back-runs it with a sell order to profit from the price difference. | Use DEX aggregators that offer sandwich protection.Set a tight slippage tolerance on trades.Use private transaction relays (e.g., Flashbots). |
| | | Artificially influencing asset prices through coordinated market actions to exploit DApp mechanisms, liquidate other traders, or create false impressions of market activity. | Wash Trading: Generating massive, artificial trading volume using bots to create the illusion of high demand and liquidity.Engineered Short Squeezes: Using a large, often Sybil-acquired token supply to intentionally drive up the spot price and trigger mass liquidations of short positions.Using a flash loan to execute a large trade on a DEX, momentarily skewing the price, and then using that manipulated price in another protocol to take out an unfair loan. | Use manipulation-resistant oracles (e.g., TWAP oracles).Don't use on-chain DEX spot prices as a direct price feed.Monitor for anomalous trading patterns, such as statistically improbable volume or liquidity spikes that do not align with user growth. |
| | | Exploiting initialization or low-liquidity conditions in liquidity pools or token vaults (e.g., ERC4626) to manipulate the share price and claim a disproportionate share of assets. | Front-running the first depositor with a tiny amount of assets to control the initial share price.Donating assets to a vault to inflate the value of existing shares. This causes subsequent depositors' assets to be rounded down, resulting in them receiving fewer or zero shares. | Initial Liquidity: The deployer should securely deposit a substantial amount of initial assets to make inflation attacks economically unfeasible.Slippage Control: Revert transactions if the number of shares received is outside an acceptable slippage range.Virtual Liquidity: Implement logic that behaves as if the pool has a minimum amount of "virtual" assets and shares, preventing rounding errors on initial deposits. |
| | | Using a fixed, hardcoded price for an asset, or implicitly assuming a fixed price ratio (e.g., assuming 1 USDC = 1 USD), instead of using a dynamic oracle feed. This creates arbitrage opportunities when the asset's real market price deviates from the assumed price. | Exploiting stablecoin de-peg events to buy protocol assets at a discount or borrow against them at an inflated value. | Use reliable price oracles for all assets involved in value calculations, including those presumed to be stable.For any exchange between Asset A and Asset B, the protocol must dynamically determine the price of A relative to B. |
| | | The protocol's design encourages or allows for excessive leverage, making the system fragile and susceptible to cascading liquidations ("death spirals") during periods of high market volatility. The risk is amplified when the collateral used is itself volatile, illiquid, or subject to de-pegging. | A significant market event triggers an initial price drop, causing the first wave of liquidations.These forced sales create further downward price pressure on the collateral, leading to more liquidations in a self-reinforcing feedback loop.Protocols with insufficient liquidity or flawed auction mechanisms are unable to handle the cascade, resulting in bad debt or insolvency. | Protocol Mitigation: Implement conservative collateralization ratios and debt ceilings. Use circuit breakers to pause liquidations during extreme volatility. Design robust liquidation engines that can handle high-stress scenarios without causing market collapse.User Mitigation: Exercise extreme caution with leverage. Understand the liquidation parameters and the risks of the collateral being used. Avoid high leverage, particularly during periods of market instability or with volatile assets. |
| | | Missing or insufficient protection against price movement between the time a transaction is submitted and when it is executed, making it vulnerable to sandwich attacks. | A user submits a trade on a DEX without specifying a maximum slippage, allowing an attacker to execute the trade at a much worse price. | DApp front-ends should enforce a default slippage tolerance and allow users to customize it.Smart contracts should allow users to specify a minimum output amount or maximum input amount. |
| | | A systemic failure where extreme network congestion (leading to high gas fees) and rapid asset price volatility cause critical off-chain infrastructure (like oracles and keeper bots) to fail or lag. This can lead to cascading liquidations, failed auctions, or other unintended economic consequences because the system's assumptions about timely and affordable transaction inclusion are violated. | During a market crash, high gas prices prevent liquidation/auction keeper bots from submitting bids, as their hardcoded or non-adaptive gas price settings are too low.Price oracles lag in updating on-chain prices due to network congestion, causing a sudden, large price adjustment that triggers mass liquidations simultaneously.An attacker, prepared for high gas conditions, can win collateral auctions for little to no cost because other bidders are effectively priced out of the network (DoS via gas). | Ensure critical off-chain software (keepers, oracles) is robust, audited, and designed to function under extreme network congestion and gas price volatility.Encourage a diverse and decentralized ecosystem of keeper bots through grants or built-in incentives to avoid single points of failure.Implement more robust on-chain auction mechanisms, such as starting with a reserve price or using mechanisms less sensitive to gas prices (e.g., Dutch auctions).Design liquidation thresholds and system parameters to handle sudden, severe price drops without causing a death spiral. |
| | | Exceeding the maximum or minimum value for an integer type, causing it to wrap around. | An attacker transfers a large number of tokens to a contract, causing its balance to overflow and wrap around to a small number. | Use modern Solidity versions (>=0.8.0), which have built-in overflow and underflow checks.Use libraries like OpenZeppelin's SafeMath for older Solidity versions. |
| | | Issues arising from integer division, order of operations (division before multiplication), or inconsistent decimal scaling. | A calculation involving division results in a rounding error that can be exploited over many transactions to drain funds. | Perform multiplication before division to maintain precision.Be mindful of the decimal precision of different tokens when performing calculations. |
| | | Improper or unchecked conversion between numeric types, potentially leading to overflow or precision loss. | Casting a uint256 to a uint128 without checking if the value fits, leading to truncation and unexpected behavior. | Validate that a value is within the bounds of the target type before casting. |
| | | General mathematical mistakes in contract logic, such as in liquidity or reward formulas. | A simple typo or incorrect formula in the code that calculates interest payments or rewards. | Thoroughly test all mathematical logic with a wide range of inputs.Get an external audit to review all calculations. |
| | | Occurs when a smart contract performs math on numbers that have different decimal precisions (e.g., mixing a token with 6 decimals and one with 18) without proper normalization. | A contract incorrectly adds the value of a 6-decimal USDC token to an 18-decimal DAI token, leading to a massive accounting error. | Normalize all token amounts to a consistent precision (e.g., 18 decimals) before performing any mathematical operations. |
| | | Failing to verify the success status of external calls, leading the contract to incorrectly assume success when the call actually failed. | A contract calls ERC20.approve() but doesn't check the boolean return value. The approval fails silently, but the contract proceeds as if it succeeded. | Use OpenZeppelin's SafeERC20 library, which handles return value checks.Explicitly check the success boolean returned from low-level calls. |
| | | Improper handling of contract storage slots, leading to collisions or data corruption, especially in proxy patterns. | An upgradeable contract adds new state variables that overwrite existing storage slots from the proxy contract. | Follow a standard for storage layout in upgradeable contracts (e.g., EIP-1967).Use tools to check for storage collisions. |
| | | Vulnerabilities arising from the improper deletion of complex data types (e.g., arrays of mappings, structs containing mappings). Operations like delete may not clear the underlying storage for nested mappings, leading to old data persisting and being misinterpreted later. | Deleting an array of mappings and re-allocating it, causing old values to reappear as if they were valid new entries.Deleting a struct containing a dynamic array can lead to unexpected behavior or data corruption in older Solidity versions. | Avoid deleting structs with complex data types; if necessary, implement a function to explicitly zero out all members.For iterable data, use libraries that provide key tracking to allow for proper deletion. |
| | | Misuse of transient storage (TSTORE, TLOAD), which can enable reentrancy or state corruption due to improper clearing or assumptions about its lifecycle. | A contract uses transient storage as a reentrancy lock but fails to clear it properly on all execution paths, allowing a reentrancy attack. | Ensure transient storage slots are cleared after use.Understand that transient storage is cleared at the end of a transaction, not a call. |
| | | Using predictable or manipulable sources of on-chain entropy (e.g., block.timestamp, blockhash). | A lottery contract uses block.timestamp to determine the winner, allowing a miner to influence the outcome. | Use a commit-reveal scheme.Use a verifiable random function (VRF) from an oracle like Chainlink. |
| | | Vulnerabilities in signature recovery (ecrecover) allowing for signature reuse or forgery if not handled correctly. | An attacker can slightly modify a valid signature without invalidating it, which can be used to bypass replay protection that relies on the signature hash. | Use OpenZeppelin's ECDSA library, which protects against signature malleability. |
| | | Cryptographic vulnerabilities allowing for collisions in hash functions used by the contract, although this is generally considered infeasible with modern hash functions like SHA-256. | An attacker finds two different inputs that produce the same hash, potentially bypassing a check that relies on the hash. | Use strong, standard hash functions (e.g., keccak256). |
| | | Weaknesses in zero-knowledge proof implementations that expose underlying data by failing to properly randomize cryptographic commitments. | A ZK-SNARK implementation that does not properly blind polynomials can leak information about the secret inputs. | Use well-audited, standard implementations of zero-knowledge proof systems. |
| | | Using sound cryptographic primitives (e.g., keccak256) but combining them in a way that creates a flawed or insecure algorithm. This is a design-level cryptographic flaw rather than a weakness in the primitive itself. | Using XOR to combine multiple hashes into a single fingerprint, which allows for collision attacks. | Use standard, well-vetted cryptographic constructions for commitments, such as Merkle trees or simple hash concatenation. |
| | | Logic that becomes vulnerable due to miscalculations of transaction execution costs or changes in gas costs from network upgrades. | A contract's logic relies on a specific gas cost for an operation, which then changes in a hard fork, breaking the contract. | Avoid writing logic that depends on specific gas costs. |
| | | A bug in the compiler that causes it to generate incorrect bytecode, or vulnerabilities arising from improper compiler version management. | Floating Pragma: Using a floating pragma (e.g., ^0.8.0) allows a contract to be deployed with different compiler versions, some of which may contain bugs.Outdated Version: Compiling a contract with an older compiler version that has known, publicly disclosed vulnerabilities. | Lock the Pragma: Use a fixed compiler version (e.g., pragma solidity 0.8.21;) in source code to ensure deterministic builds.Always use the latest, well-audited version of the Solidity compiler. |
| | | Blocking contract functionality through external calls to malicious or non-functional contracts. This often occurs when using low-gas-forwarding functions like .transfer() to send Ether to a contract that requires more gas for its fallback function than is provided. | Using .transfer() or .send() to a smart contract wallet (e.g., Gnosis Safe) whose fallback function consumes more than the 2300 gas stipend, causing the transaction to revert.If this call is part of a critical workflow like withdrawals, it can permanently lock funds for users of contract wallets. | Avoid using .transfer() and .send() for sending Ether.Use .call{value: ...}("") instead, as it forwards all available gas.Prefer pull-over-push patterns for payments, where users call a function to withdraw their funds rather than having the contract send it to them automatically. |
| | | A recipient contract designed to revert or consume excessive gas when receiving tokens or Ether, causing the sender's transaction to fail. | An auction contract that automatically sends funds to the previous highest bidder can be blocked if a malicious bidder sets their address to a contract that reverts on receiving funds. | Favor pull payments over push payments. |
| | | Exploiting reentrancy guards to permanently or temporarily lock functions if the lock is not properly cleared on all execution paths. | A function with a reentrancy guard calls an external contract that reverts. If the lock is not unwound, the function may be permanently locked. | Use try/catch blocks to ensure reentrancy locks are always cleared, even if an external call fails. |
| | | Causing numeric underflows, overflows, or division-by-zero errors that block contract execution. | An attacker forces a variable used as a divisor to zero, causing all future transactions that use that calculation to revert. | Add checks to prevent division by zero.Use safe math libraries to prevent overflows and underflows. |
| | | Crafting operations that exceed the block gas limit, making certain state transitions impossible, often by making an array or loop too large. | An attacker adds many addresses to a distribution list, causing the function that iterates through the list to distribute rewards to run out of gas. | Avoid unbounded loops.Provide ways for users to withdraw or claim funds individually rather than relying on a single distribution transaction. |
| | | Exploitation of token standard callbacks (e.g., ERC777/721/1155) to cause denial of service by making them revert. | An attacker registers a malicious contract as a token recipient that always reverts in its onERC721Received hook, preventing transfers to that address. | Be aware of the potential for hooks to revert when interacting with these token standards. |
| | | Exploitation of unbounded return data from an external call to cause an out-of-gas error when the data is copied to memory. | A contract calls an external malicious contract that returns a very large amount of data, causing the calling contract to run out of gas when it tries to process the return data. | If possible, limit the size of return data from external calls. |
| | | Specific vulnerabilities in protocols like LayerZero or their integrations that can halt message passing or cause messages to be delivered incorrectly. | An attacker exploits a bug in the relayer or oracle configuration of a cross-chain protocol to prevent messages from being confirmed on the destination chain. | Use well-audited, reputable cross-chain messaging protocols.Implement monitoring to detect stalled or failed cross-chain messages. |
| | | A denial-of-service attack where an attacker exploits unreliable on-chain data sources or checks to block critical operations. A common example is manipulating the state of an address to make a check like address.codehash return an unexpected value, thereby preventing contract deployment. | Sending 1 wei to a pre-determined contract address to change its codehash from bytes32(0) to keccak256(""). | Avoid relying on address.codehash to determine if a contract exists. A more reliable check is address.code.length > 0. |
| | | Occurs when a contract uses a recursive function (a function that calls itself) to iterate through a data structure. An attacker manipulates the contract's state to create an excessively long chain of data (e.g., nodes in a tree, linked list), forcing the recursive function to exceed the EVM's call stack limit (1024 frames). This causes any transaction calling the function to fail, permanently locking funds or functionality. | An attacker repeatedly triggers a state-changing operation with minimal effect (e.g., tiny liquidations) to build a long chain of nodes in a data structure that a recursive function must traverse.When a legitimate user tries to access a function that relies on this recursion, the transaction reverts with a "stack too deep" error. | Use Iteration over Recursion: For traversing data structures that can grow based on user input, always prefer iterative loops (for, while) over recursive patterns. Iteration does not consume the call stack and is not vulnerable to this attack.Implement Depth Limits: If recursion is unavoidable, implement a hard-coded counter to strictly limit the maximum recursion depth, causing the function to fail safely before hitting the stack limit. |
| | | Blocking a user's valid transaction by front-running it to alter the underlying state conditions required for success. Unlike MEV, the attacker does not necessarily profit; the goal is to cause the victim's transaction to revert. A common vector is "Permit Griefing," where an attacker observes a transaction containing a signed permit, extracts the signature, and submits it independently. The permit is executed, consuming the nonce. When the victim's transaction attempts to execute the permit again, it reverts due to the invalid nonce, failing the entire operation. | Permit Griefing: Front-running a transaction that calls permit() by submitting the signature separately, causing the user's batch transaction to revert.Initialization Griefing: Front-running the initialization of a contract to set parameters that force the legitimate deployer to redeploy. | Use Try/Catch: Wrap calls to permit() in a try/catch block. If the call fails (e.g., nonce already used), verify if the allowance is sufficient and proceed.Check State First: Check if the necessary state change (e.g., allowance increase) has already occurred before attempting the state-changing call. |
| BWC 9.2: AI/ML Integration Attacks | | Vulnerabilities arising from the corruption of an AI/ML model's training data or the exploitation of its inherent biases. This is an attack on the integrity of the model itself. | An attacker could "poison" the training data of an AI-powered oracle to make it produce incorrect but seemingly valid outputs.Exploiting biases in a model to cause it to behave in unintended and harmful ways. | Ensure AI/ML models used in decentralized systems are robust and have transparent, verifiable inputs and outputs.Implement continuous monitoring and validation of model outputs against known ground truths. |
| | | Occurs when a system allows untrusted external data (e.g., emails, calendar invites, web pages) to be interpreted as trusted commands by an AI agent. The AI is "jailbroken" by malicious data, causing it to perform unauthorized actions or leak sensitive information. | Data Source Poisoning: An attacker injects a malicious prompt into a data source that an AI agent will later read (e.g., a calendar invite, email, or document).Hijacking User Sessions: When a legitimate user prompts the AI to interact with the poisoned data source (e.g., "summarize my upcoming events"), the AI executes the hidden malicious command.Exfiltration & Malicious Actions: The malicious command can instruct the AI to exfiltrate private user data (from emails, documents) and send it to an attacker, or to subvert on-chain AI governance by tricking it into allocating funds or voting maliciously. | Strict Data/Instruction Separation: Design systems to maintain a robust separation between trusted instructions (user prompts) and untrusted external data. An AI should treat external data as content to be analyzed, not as commands to be executed.Avoid Naive AI Governance: Do not hardcode a single AI model with direct control over critical functions like fund allocation.Institutional Design (Info Finance): Create open, competitive environments where multiple AI models can be submitted and are subject to spot-checking and evaluation by human juries, creating incentives for flaw discovery.User-Side Caution: Users should be extremely cautious when granting AI agents broad, read-write access to sensitive personal data sources. |
| | | Attacks that target the underlying hardware on which nodes or validators run, such as Rowhammer or Spectre, to corrupt memory or leak sensitive data. | A sophisticated attacker uses a hardware vulnerability to extract validator private keys from a server's memory. | Use secure, enterprise-grade hardware.Keep server firmware and software up-to-date with security patches. |
| | | Sophisticated attacks on the peer-to-peer networking layer of a blockchain, such as eclipse attacks or network partitioning, to isolate nodes or disrupt consensus. | An attacker controls all of a node's incoming and outgoing connections, feeding it false information about the state of the network. | Increase the number of peer connections for nodes.Use diverse and decentralized node discovery mechanisms. |
| | | Vulnerabilities specific to newer or more complex consensus mechanisms beyond traditional Proof-of-Work or Proof-of-Stake. | Exploiting a flaw in the finality gadget of a PoS chain to cause a re-organization of the chain. | Rigorous academic peer review and formal verification of new consensus protocols.Extensive testing on public testnets before mainnet deployment. |
| | | Vulnerabilities that emerge from the complex and often unaudited interactions between different blockchain protocols, especially in the context of DeFi composability. | An attacker combines features from three different DeFi protocols in an unforeseen way to create an exploit that would not be possible with any single protocol. | Deep understanding and auditing of all integrated protocols.Defensive design that anticipates unexpected interactions. |
| | | 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. | A network upgrade changes the gas cost of an opcode, breaking a contract that relied on the old gas cost. | Contract developers should stay informed about upcoming network upgrades.Avoid writing code that depends on specific, hardcoded network behaviors. |
| | | With the adoption of EIP-7702, Externally Owned Accounts (EOAs) can temporarily delegate their capabilities to a smart contract. This blurs the line between EOAs and contracts, breaking fundamental security assumptions. For example, the invariant that tx.origin is always an EOA is no longer true, rendering checks like msg.sender == tx.origin unsafe for reentrancy protection. | Reentrancy: An account can call itself, making msg.sender == tx.origin true, bypassing old reentrancy guards.Initialization Front-Running: An attacker can front-run the delegation and initialize the contract to seize control.Storage Collisions: Switching between delegation contracts without clearing storage can lead to data corruption if storage layouts differ.Phishing: Users can be tricked into delegating to a malicious contract, granting full asset control to an attacker, especially when using a global chain_id=0. | Reentrancy: Use audited reentrancy guards (e.g., OpenZeppelin's nonReentrant modifier) instead of tx.origin checks.Initialization: Secure initialization by requiring user signatures on parameters (initWithSig) or restricting calls to the ERC-4337 EntryPoint.Phishing: Wallets must clearly display the delegation target. Users should only delegate to immutable, audited contracts deployed via CREATE2 and avoid chain_id=0.Design: Keep delegation contract logic minimal and well-audited to reduce the attack surface. |
| | | A reentrancy vector introduced by a proposed change to SSTORE gas costs in EIP-1283 for the Constantinople hard fork. This change would have made .send() and .transfer() unsafe, breaking a core security assumption for many contracts. The hard fork was delayed to remove this vulnerability. | An attacker could have used the low gas stipend from a .send() or .transfer() to call back into the victim contract with enough gas to perform malicious state changes. | The vulnerability was mitigated at the protocol level by reverting the EIP-1283 gas changes before the hard fork was deployed. |
| | | A historical DoS vector, mitigated by the EIP-150 hard fork, where an attacker could recursively call a contract to exhaust the 1024 call depth limit, causing any subsequent external calls within the transaction to fail. | Forcing a legitimate contract's external call (e.g., a payout) to fail by ensuring the call stack is already at its maximum depth. | Mitigated at the protocol level by EIP-150, which changed gas calculation rules to ensure gas would be consumed long before the call depth limit is reached. |
| | | The effectiveness of a privacy protocol (especially mixers) relies on a large and diverse set of users to create a "crowd" to hide in. When the number of users or the volume of transactions is low, the anonymity set shrinks, making it easier for observers to statistically link deposits and withdrawals. | Transaction graph analysis on mixers with low liquidity.Timing analysis when few users are active. | Designing protocols to incentivize a large and active user base.Users choosing privacy solutions with demonstrably high volume and usage. |
| | | User-side errors in operational security that undermine the privacy protections offered by a protocol. Even a perfectly designed privacy protocol can be rendered ineffective if the user fails to follow best practices for maintaining their anonymity. | Reusing withdrawal addresses.Linking deposit/withdrawal addresses via on-chain activity or unique amounts.Allowing browser extensions to link transactions by not clearing browser data (cookies).Withdrawing too quickly, enabling timing-based correlation.Exposing the private note required for withdrawal.Revealing IP address by not using a VPN or Tor. | User education on best practices (e.g., using fresh addresses, waiting before withdrawal).Using privacy-preserving tools like Tor or a reputable VPN.Securely storing private notes for withdrawal.Regularly clearing browser data. |
| | | Using patents, often acquired for the sole purpose of litigation, to file infringement lawsuits against open-source protocols or developers. The goal is typically to stifle competition, extract settlement fees, or create legal uncertainty, rather than to protect a genuine invention. | Filing broad or frivolous patent infringement lawsuits against blockchain projects.Acquiring patents from defunct companies to assert them against active developers. | Proactive use of defensive patent pools (e.g., Crypto Open Patent Alliance).Challenging the validity of overly broad patents through legal processes like Inter Partes Review (IPR).Maintaining legal defense funds to fight frivolous lawsuits. |
| | | The use of state power, including sanctions, subpoenas, or regulatory enforcement actions, to target protocols, developers, or users in a manner that exceeds clear legal mandates or stifles innovation. | Intentionally mischaracterizing a competitor's technology to fit existing regulatory frameworks (e.g., falsely equivocating a sequencer with a traditional exchange) to invite targeted enforcement.A government agency sanctioning addresses associated with a privacy protocol without due process.Issuing subpoenas to open-source developers for information about users.Classifying decentralized protocols as unregistered securities or money transmitters. | Maximizing decentralization to reduce single points of failure or control.Proactive policy advocacy and education for regulators to clarify technical nuances.Legal challenges to contest regulatory overreach in court. |
| | | An attacker performs an economically harmful exploit and subsequently uses the legal argument that their actions were permissible because they were allowed by the smart contract's code. This strategy exploits the difficulty legal systems face in applying traditional statutes for fraud or manipulation to autonomous, decentralized protocols. | Performing an economic attack (e.g., oracle manipulation) and arguing in court that it was a legitimate "highly profitable trading strategy" permitted by the protocol's rules.Citing legal precedents where judges have dismissed charges due to a lack of "material misrepresentation" to a smart contract, which cannot be deceived like a human. | On-Chain Terms of Service: Implement explicit, legally-vetted Terms of Service that define malicious use and can be referenced in legal proceedings.Circuit Breakers & Governance: Design protocols with emergency pause or intervention mechanisms to demonstrate clear intent to prevent economically harmful outcomes.Policy Advocacy: Engage with policymakers to help develop clear, digitally-native legal frameworks that distinguish between legitimate use and malicious exploitation. |
