Attack Library

The attacker splits their stake across two validator sets. In a BFT round they sign both PREVOTE and PRECOMMIT messages for conflicting blocks and broadcast them selectively. Without equivocation detection and slashing, honest nodes see different quorums and commit different forks. In PoW the attacker builds two private chains and releases the heavier one after the victim acts on the lighter one.

Safety failure: two conflicting blocks are finalized. Liveness failure: votes are withheld and rounds time out indefinitely. Economic finality evaporates.

• Adversary controls ≥ fault-tolerance threshold of voting power
• Votes are not aggregated into accountable quorum certificates
• Slashing conditions are absent or economically weaker than the attack payoff

Accountable safety proofs, slashing for equivocation, quorum certificate verification, and a fault tolerance below the adversarial threshold.

• Theoretical for most major BFT chains; practical for smaller PoS networks and sidechains.
• Several bridge hacks have exploited weak finality assumptions after a re-org or validator compromise.

The attacker prepares transaction T1 paying the merchant and T2 sending the same UTXO/account balance back to themselves. T1 is broadcast to the merchant's view; T2 is mined into a private chain. Once the merchant ships the goods, the attacker releases enough blocks to make the private chain canonical. The merchant's payment disappears.

Direct theft of goods or funds. Confidence in payment finality collapses for high-value transactions.

• Recipient accepts payment before strong finality
• Attacker can produce a heavier private fork

Wait for probabilistic finality depth appropriate to transaction value; use checkpointing or BFT finality gadgets.

• Bitcoin Gold 51% attack (~$18M stolen from exchanges in 2020).
• Ethereum Classic multiple re-org attacks.

After unstaking, the attacker keeps old validator keys and creates an alternative fork starting from a historical block. Because the keys were once valid, naive clients accept the fork as legitimate. The attacker grows the fork until it exceeds the current chain in cumulative weight or committee endorsements.

Rewrite of history, double spends against newly joining nodes, collapse of bootstrapping trust.

• Attacker once controlled sufficient stake or keys
• No strong checkpointing or weak subjectivity assumption

Checkpoints, weak subjectivity periods, social-consensus finality, and slashing conditions that persist after unstaking.

• Primarily theoretical for major PoS chains with checkpoints; realistic for chains without them.

Using a flash loan, the attacker temporarily holds 51% or more of the voting supply. In the same transaction they delegate votes, call the governance proposal, pass it, transfer the treasury to themselves, and repay the loan plus fees. Because votes are counted at the time of the proposal execution, the attack is atomic.

Full protocol treasury drained, parameter changes, malicious upgrades, or infinite minting enabled.

• Protocol uses token-weighted on-chain governance
• Lending markets offer large quantities of the governance token
• No vote-escrow or snapshot-before-borrow mechanism

Vote-escrow locks, snapshot balances before proposal, time-locked upgrades, governance timelocks, and high quorum requirements.

• Beanstalk Farms lost ~$182M in a flash-loan governance attack (2022).

The attacker buys or borrows governance tokens over days, delegates votes from passive holders, or bribes existing voters. Once quorum is reached they pass a proposal that upgrades the protocol to a malicious implementation, drains the treasury, or changes critical parameters like minting schedules.

Protocol capture, treasury drain, unlimited minting, or permanent parameter degradation.

• On-chain governance controls protocol parameters, treasury, or upgrades
• Vote accumulation is cheaper than total value at risk
• No veto, timelock, or delegated-quorum safeguards

Quorum thresholds, timelocks, veto councils, vote-escrow, delegated-vote caps, and immutable core invariants.

• Several DAOs have faced governance crises from concentrated token accumulation.

In Tendermint-style protocols a faulty leader triggers a timeout, after which validators move to the next view. If timeouts are too short, frequent false positives degrade throughput; if too long, a malicious leader can halt the chain cheaply. In DAG-based protocols a missing leader slows vertex availability.

Chain halts, mempool backs up, fees spike, users cannot move funds, downstream services fail.

• Single leader drives each round or view
• Timeout and view-change mechanism is slow or buggy

Robust leader rotation, deterministic timeout certificates, optimistic responsiveness, and multiple concurrent proposers where feasible.

• Several Cosmos SDK chains have experienced short stalls from leader failures during upgrades.

The attacker mines privately, maintaining a lead over the public chain. When the public chain catches up by one block, the attacker releases two blocks, orphaning the honest effort. With ≥33% of hash rate this becomes profitable; with ≥50% it dominates completely.

Honest miners lose rewards, pool centralisation incentives increase, effective network security drops.

• Attacker controls >25% of block production share
• Network propagation is not instantaneous

Uniform propagation policy, uncle/orphan rewards, fork-choice rules that penalise selfish behaviour.

• Demonstrated theoretically for Bitcoin; observed in smaller PoW coins.

Fake-stake attacks exploit the asymmetry between header validation (cheap) and full state validation (expensive). The attacker creates blocks that satisfy syntactic PoS rules but reference outputs that do not exist or have already been spent. Nodes that accept header-first sync or do not fully validate the stake kernel can be fooled into a shadow chain.

Light clients follow the wrong chain, exchange deposits may be spent on a worthless fork, and honest full nodes waste resources before rejecting.

• Proof-of-stake protocol validates block headers before full UTXO/account state
• Attacker can craft headers that pass cheap checks but contain no real stake backing

Require full stake-kernel validation before accepting headers, checkpointing, and validate every spent stake output.

• Disclosed against several PoS coins; mitigated by full-kernel validation and header pre-sync limits.

The leader's mempool is inspected for sender addresses, protocol identifiers (e.g., specific contract addresses), or transaction types. Matching transactions are dropped or delayed beyond their validity window. Without encrypted mempools or fair ordering, this is trivial and undetectable at the consensus level.

Liveness violation for targeted accounts; DeFi liquidations fail; option expiries miss deadlines; protocol neutrality is compromised.

• Leader / sequencer can choose which transactions to include
• No encrypted mempool or inclusion proof mechanism

Leader rotation, encrypted mempools, fair ordering, inclusion proofs, and builder diversification.

• Flashbots Relay has historically filtered OFAC-sanctioned transactions, illustrating how infrastructure can censor.

If the randomness is derived from block hashes, the last proposer can grind extra nonce values until the next leader set is favourable. If it uses an external oracle, the attacker can front-run the reveal. In committee lotteries, a bias of even a few percent can give the attacker supermajority control of a shard or round with high probability over time. Once in control, the attacker can reorder transactions, censor withdrawals, or sign fraudulent checkpoints.

Predictable committee capture, targeted eclipse, censorship, fraudulent finality, and in lottery-based DeFi: extraction of jackpots, airdrops, or validator rewards.

• Leader, committee, or lottery selection uses weak or manipulable randomness
• Attacker can influence one entropy source or predict output before commitment

Verifiable Delay Functions (VDFs), commit-reveal with hash bonds, distributed randomness beacons (drand), and multiple independent entropy sources.

• Weak randomness has been exploited in on-chain lotteries and NFT mints; larger protocol RNG attacks remain a looming risk.

Key extraction can occur via side channels (timing, power, cache), malware on the validator host, unencrypted backups, or weak key derivation. Once the key is stolen, the attacker can equivocate, sign invalid blocks, or participate in a long-range attack.

Equivocation, safety violation, slashing of honest validator, reputation damage.

• Validator signs with a key held in software or weak HSM
• Side-channel, malware, or memory-dump access is possible

HSMs, threshold signing, remote signers, encrypted key storage, secure enclaves, and continuous attestation.

• Several bridge and validator hacks began with compromised keys or signing infrastructure.

The attacker computes the next seed from public inputs (e.g., block hash, timestamp). With the seed known in advance, the attacker identifies which validators will be leaders, which shards they will validate, and which lotteries they will win.

Targeted eclipse, DDoS, or collusion against selected leaders; grinding attacks on lotteries.

• Leader / committee selection depends on weak randomness
• Entropy is observable before it is committed

Verifiable Delay Functions (VDFs), commit-reveal schemes, distributed randomness beacons.

• Many early PoS designs used block-hash randomness and were vulnerable to grinding.

By flooding the target's address table with attacker-controlled IPs and rapidly opening connections, the attacker becomes the target's only peer. The target sees only blocks and transactions the attacker chooses. In validator nodes this is a stepping stone to double signing, censorship, or partition.

Target accepts attacker-selected blocks, misses honest consensus messages, or is partitioned without knowing it.

• Target node has limited peer diversity
• Attacker controls addresses or routing near the target

Random peer selection, anchor connections, outbound connection minimums, address diversity, and feeler connections.

• Demonstrated against Bitcoin nodes in academic research; realistic against validators with poor peering.

The attacker uses BGP hijacking, DDoS on critical links, or geographic firewalling to split validators. Each side continues producing blocks. When the partition heals, the chain with less weight is orphaned and its transactions are reversed.

State divergence, double-spend opportunities across partitions, and safety violations on reconnection.

• Network connectivity can be split by geography, AS, or routing
• Consensus cannot bridge the partition

Geographically diverse validators, partition-aware consensus, and checkpointing / finality gadgets.

• Several smaller chains have experienced partition-induced forks.

Each identity requires only an IP address or a low-cost stake unit. The attacker runs thousands of nodes from cloud providers, dominates DHT routing tables, and can bias gossip, eclipse targets, or manipulate peer scoring.

Topology bias, eclipse facilitation, or disproportionate committee representation depending on Sybil resistance mechanism.

• Protocol identity is cheap to create
• Network discovery weights peers by identity count

Strong identity cost (PoW, PoS, social graph, stake), peer diversity requirements, and identity sampling bounds.

• Common in DHT-based networks and protocols with weak identity costs.

The attacker becomes a peer and sends fake time samples, skewing the victim's median time. The victim then rejects blocks with valid timestamps or accepts stale blocks, causing divergence or DoS.

Isolation from the honest network, stale block acceptance, or liveness failure.

• Protocol uses peer-reported timestamps for block validity
• No strong network time synchronisation

Use multiple NTP sources, ignore extreme peer timestamps, and decouple consensus from local wall-clock time.

• Known vulnerability class in Bitcoin and similar timestamp-dependent networks.

The attacker finds a transaction sequence that triggers an arithmetic error, reentrancy, or storage collision in the state machine. The resulting state root differs from the correct value, but the block header may still validate if the bug is in the execution client.

Incorrect balances, broken consensus, and inability to validate new blocks.

• State transition depends on untrusted input
• Storage layer lacks integrity checks

State root commitments, Merkle proofs, deterministic execution, formal verification, and multi-client diversity.

• Several L1 and L2 bugs have caused state-root mismatches requiring emergency fixes.

Without chain IDs or account nonces, the same signed transaction can be replayed on a fork, a testnet, or a sister chain. The recipient sees a legitimate-looking inbound transfer a second time.

Unauthorised repeated transfers; state inconsistency across networks.

• Transactions lack unique nonces or chain identifiers
• Signatures are valid across different contexts

Account nonces, chain IDs, replay protection in signature payload.

• Ethereum / Ethereum Classic replay incidents before chain IDs were standard.

Examples include quadratic complexity in transaction validation, deeply nested EVM calls, oversized blocks, rapid connection churn, or memory leaks in deserialization. The goal is to crash validators or make them too slow to keep up.

Denial of service, sync failure, and potential crash of validators.

• No bounded validation cost per message
• Network / CPU / memory limits can be triggered

Strict size limits, gas / resource metering, rate limiting, and quadratic-cost protection.

• Multiple Ethereum DoS incidents in 2016 exploited gas-cost asymmetries.

The attacker crafts a block that passes lightweight syntactic checks but fails deeper semantic validation. Different node versions may disagree, causing a chain split or crash loop.

Node crash, state corruption, or chain split if validators disagree on validity.

• Block validation does not cover all fields
• Serialization parser accepts invalid inputs

Comprehensive block validity checks, fuzz testing, and canonical serialization.

• Several chains have temporarily halted due to malformed block parsing differences between versions.

Examples include non-canonical ECDSA signatures, integer overflow in amount fields, or RLP/protobuf edge cases that parse differently in different implementations.

Mempool pollution, invalid block inclusion attempts, or resource drain.

• Transaction parser accepts edge-case encoding
• Signature verification can be bypassed

Strict schema validation, canonical encoding, and mempool admission rules.

• CVE-2018-17144 in Bitcoin allowed double-spending via malformed transaction.

Supply-chain attacks target the least audited part of the stack: a popular logging library, a base Docker image, or a CI secret. A single compromised dependency can exfiltrate validator keys, bias consensus messages, or silently diverge state.

Mass validator compromise, arbitrary code execution, silent consensus manipulation, and complete loss of trust in the binary.

• Protocol relies on pre-built binaries, Docker images, or npm/cargo packages
• Attacker can compromise a dependency or build pipeline

Reproducible builds, dependency pinning, SLSA provenance, multi-sig release keys, SBOMs, and deterministic deployment images.

• SolarWinds and XZ Utils backdoor demonstrate the pattern; blockchain nodes are equally vulnerable.

Public RPC endpoints often expose methods like `debug_traceTransaction` or `eth_call` with no cost limits. Attackers can use these to reconstruct private state, DoS the node, or discover vulnerable accounts.

Information disclosure, denial of service, or unauthorised state access.

• Publicly exposed RPC endpoints
• Weak authentication, authorisation, or rate limiting

Authentication, authorisation, rate limiting, input validation, and admin endpoint isolation.

• Many node operators have had RPC endpoints abused for free compute or data scraping.

The attacker observes a pending swap or liquidation, submits a transaction with higher gas price to trade before it, then another to trade after it. The victim receives worse execution; the attacker captures the spread. In PoS this is often done through private relays or proposer-builder agreements.

User value extraction, degraded execution, centralisation of block building, and validator revenue that disturbs staking economics.

• Transaction ordering is centralised or predictable
• Value can be extracted from user transactions (arbitrage, liquidations, front-running)

Encrypted mempools, fair ordering protocols, proposer commitments, and application-level slippage protection.

• MEV-Boost relays on Ethereum process billions in MEV per year.

In mining pools, a participant can find a valid share but not submit full blocks, reducing the pool's revenue. In PoS variants, a validator can refuse to propose, forcing reorgs and lowering overall throughput.

Reduced pool efficiency, lower network throughput, and centralisation pressure.

• Attacker is a miner/staker with block production rights
• Rewards depend on publishing blocks quickly

Pool reward schemes that detect withholding, redundant block templates, and penalty mechanisms.

• Observed in Bitcoin mining pools as a theoretical and occasional practical issue.