Research/Education/What Is a 51% Attack? How Real Is the Risk for Bitcoin
# Bitcoin

What Is a 51% Attack? How Real Is the Risk for Bitcoin

BloFin Academy03/27/2026

A 51% attack is when a single actor controls majority proof-of-work hashrate, secretly mines a longer chain, and releases it to overwrite recent confirmed blocks so the same coins can be spent twice. Bitcoin's one-hour rental-equivalent attack cost is $1,648,584 against 962.71 EH/s at 0% NiceHash-rentable share as of May 2026 (source: Crypto51).

51% attacks in one screen, what actually matters in 2026:

  1. Majority hashrate buys probabilistic power to rewrite recent transaction history; it does not break secp256k1 signatures, mint new bitcoin, lift the 21-million cap, or move coins from addresses without private keys (source: Bitcoin Wiki)

  2. Bitcoin sits near 962.71 EH/s on Crypto51's May 2026 reading, so renting half is ~$1.65 M per hour before accounting for 0% NiceHash-able share (source: Hashrate Index)

  3. Bitcoin Gold lost ~$18M in May 2018 plus ~$72,000 across two January 2020 reorgs; Ethereum Classic suffered four attacks in 2019-2020 with one August 2020 reorg exceeding 7,000 blocks; Bitcoin Cash saw a coordinated 54%-pool reorg in May 2019; Vertcoin took 22 deep reorgs in late 2018 (source: CoinDesk)

  4. Bitcoin's closest concentration event was GHash.io reaching ~55% for ~24 hours in mid-June 2014; no malicious action followed, miners voluntarily exited, and GHash pledged below 39.99% within 48 hours (source: Wikipedia)

  5. Selfish mining (Eyal and Sirer 2014, "Majority Is Not Enough") is a distinct attack class profitable above ~25-33% hashrate without needing 51%; treated separately later (source: arXiv)

This guide walks through 51% attacks the way exchanges, custodians, and researchers want them explained: the mechanic, what Nakamoto consensus means for confirmed history, what an attacker can and cannot do, the actual 2026 cost to attack Bitcoin versus smaller chains, the four named real-world incidents (BCH, ETC, BTG, Vertcoin), why Bitcoin specifically has not been attacked, the 6-confirmation rule's origin, and how selfish mining differs. For vocabulary, the Bitcoin glossary covers reorg, double-spend, hashrate, longest chain, and confirmation depth.


What a 51% attack mechanically is

A 51% attack is one actor commanding more than half of a proof of work chain's hashing power long enough to mine a private chain overtaking the public one in cumulative work, then releasing it so honest nodes adopt it and discard the original tip.

Component

What it means

Majority hashrate

More than 50% of the network's hashes per second on the attacked algorithm

Private chain

Blocks the attacker mines secretly without broadcasting, built on a chosen earlier block

Cumulative work

Sum of difficulty across a chain's blocks; the chain with more wins under Nakamoto consensus

Reorganization (reorg)

Nodes switching their tip to a different chain with more work

Double-spend

The economic payoff: same coins paid twice across the erased and new chain tips

The 51% threshold is a simplification. With 51% an attacker wins reorg races on average; at 60% success against deeper depths climbs sharply; at 40% they can still occasionally beat 6 confirmations (~50% per Bitcoin wiki). Half is the strict mathematical-edge threshold per round, not an absolute switch (source: Bitcoin Wiki).

For how proof of work secures Bitcoin, block discovery is a memoryless random search over hash space; whoever has more hashes per second wins more often.


What an attacker can and cannot do

The most common confusion blurs consensus-layer manipulation with cryptographic theft. A majority-hashrate attacker operates inside the mining layer; they choose which valid blocks to extend, but cannot break secp256k1 signatures, derive private keys, or forge transaction authorizations.

Attacker CAN do at 51%+

Attacker CANNOT do even at 100%

Rewrite recent block history by releasing a longer private chain

Steal coins from addresses without the private key

Double-spend their own coins by reversing a recent payment

Forge ECDSA or Schnorr signatures (secp256k1 stays secure)

Censor transactions by refusing to include them

Mint bitcoin outside the issuance schedule (3.125 BTC subsidy)

Prevent other miners from confirming blocks (denial of service)

Lift the 21-million supply cap or change consensus rules

Reverse confirmations seen during the attack window

Reverse old confirmations cheaply (cost scales with depth)

Force targeted addresses to 0 confirmations indefinitely

Override full-node consensus; invalid blocks get rejected regardless of work

The Bitcoin wiki Weaknesses page enumerates these limits: an attacker "cannot create coins out of thin air" and "cannot send coins that never belonged to him" (source: Bitcoin Wiki). Full nodes verify every block against consensus rules independently of mining power; even a 100%-hashrate adversary mining rule-violating blocks would have them rejected by every honest node.

Self-custody bitcoin is not at risk from this class. Risk is to recently confirmed reversible transactions: deposits credited at 1 confirmation, payment processors releasing goods at 3, settlement layers accepting unconfirmed payments. For how miners, nodes, and wallets divide responsibilities, 51% attacks live in the miner layer; wallets and full nodes are out of scope as theft surfaces.


The double-spend mechanic, step by step

The economic payoff of a 51% attack is almost always a double-spend: pay once, receive value, erase the payment, spend the same coins again.

  1. Attacker broadcasts transaction A paying coins to a victim (exchange deposit, payment processor, OTC counterparty).

  2. Honest miners include A in block N; victim sees 1 confirmation. Most processors require more.

  3. Attacker simultaneously mines a private chain forked from block N-1, containing transaction B that respends the same UTXOs back to an attacker address.

  4. As public confirmations accumulate, the private chain extends in parallel. With 51%+ hashrate, the private chain grows faster on average.

  5. Victim eventually credits the deposit and releases withdrawn funds, goods, or trade settlement. This is the moment of value transfer.

  6. Attacker continues extending the private chain past the public tip in cumulative work.

  7. Attacker releases the private chain. Honest nodes switch via Nakamoto consensus and discard the public blocks including transaction A.

  8. Transaction B is now canonical. A is gone. Attacker keeps the released value and the original coins.

Each confirmation forces the attacker to mine extra blocks ahead privately. Six blocks at 51% costs ~12 blocks of forgone honest revenue plus electricity and hardware financing. For how Bitcoin transactions work in the UTXO model, double-spend only works because reorg replaces which "once" is canonical.


Reorgs, longest chain, and Nakamoto consensus

A reorganization is when a node replaces its current chain tip with a different valid chain that has more cumulative work. The network doesn't vote; every node independently runs the same rule and converges on the heaviest chain.

  • Natural reorgs happen when two miners find a valid block nearly simultaneously. The network briefly sees both tips until one side extends. These are typically 1-block reorgs occurring a few times per year on Bitcoin. They are normal consensus events, not attacks. The chain reorganization reference at learnmeabitcoin.com walks through the mechanic (source: Learn Me a Bitcoin).

  • Malicious reorgs happen when an attacker intentionally builds a longer private chain from a block deep in the past, then releases it to invalidate everything between. Depth scales attack difficulty. A 1-block reorg can happen by accident; a 100-block reorg is engineered.

Foundry USA's seven-blocks-in-a-row in late March 2026 produced a rare two-block reorg. Statistical analysis confirmed this was within expected behaviour for a pool at ~31% share; nodes accepted it cleanly with no double-spend (source: Cryptotimes).

Each additional confirmation roughly doubles the work an attacker must outpace. Six confirmations is the historical rule because Satoshi whitepaper Section 11 showed an attacker with 10% hashrate has effectively zero chance of catching up after 6 blocks; at 30% ~5%, at 40% ~50%, at 50%+ the attacker wins given time (source: Bitcoin.org).

For how the Bitcoin blockchain orders blocks under this rule, longest-chain switching makes shallow confirmations probabilistic and deep confirmations economic guarantees.


Bitcoin's 2026 attack cost and why the math is unfavorable

Crypto51's May 2026 snapshot puts Bitcoin's one-hour attack cost at $1,648,584 against 962.71 EH/s, with 0% NiceHash-rentable (source: Crypto51). Those three numbers explain why Bitcoin has not been attacked.

Chain

Hashrate (April 2026)

1-hour attack cost

NiceHash-able %

Bitcoin (BTC)

962.71 EH/s

$1,648,584

0%

Bitcoin Cash (BCH)

4.94 EH/s

$8,461

0%

Ethereum Classic (ETC)

191 TH/s

$3,283

0%

Bitcoin Gold (BTG)

201 KH/s

$5

7%

Source: Crypto51.app snapshot May 15, 2026

The $1.65M is rental-equivalent if hashrate were available. It is not. NiceHash's 0% means the open rental market cannot supply meaningful BTC-relevant capacity at any price; SHA-256 ASICs sit with industrial miners at roughly cost-of-electricity revenue. An actual attempt would require fabricating ~481 EH/s of new ASICs (entire annual capacity of multiple Bitmain factories) or coercing existing operators. The calculator understates real difficulty.

A sustained multi-hour attack beating 3-6 confirmation policies compounds the problem. At 51% over 6 blocks the attacker pays $1.65M per hour for the full reorg race; median overtake at 51% advantage is multiple hours. Realistic attack cost reaches tens of millions per double-spend.

BTG's 5/hour at 7% NiceHash-able share lets an attacker rent capacity for a sandwich. ETC's $3,283/hour was the same dynamic in 2019-2020 against deposits Coinbase credited at 100-200 confirmations but smaller exchanges at 7-12.

Bitcoin's daily honest mining revenue exceeds $30M. Any actor with attack-relevant hashrate has higher expected return mining honestly; the attack must net a double-spend exceeding forgone revenue. For how Bitcoin mining generates revenue, the attacker competes with their own honest income.


Real-world 51% attacks: BCH, ETC, BTG, Vertcoin

Four named proof-of-work chains have suffered documented 51% attacks. None is Bitcoin. All four had a structural feature Bitcoin lacks: rentable or readily available hashrate at meaningful scale relative to network total.

Network

Date

What happened

Why possible

Documented loss

Bitcoin Cash (BCH)

May 2019

BTC.top + BTC.com (~54% combined) reorged blocks to undo an attacker's post-fork coin grab

SHA-256 chain at ~1% of BTC hashrate; two pools alone exceeded 51%

Reversed transactions, no third-party loss

Ethereum Classic (ETC)

Jan 2019

First confirmed double-spend; ~$1.1M ETC double-spent on exchanges

Ethash GPU-mineable; cheap NiceHash rental against diminished hashrate

~$1.1M

Ethereum Classic (ETC)

Aug 2020

Three reorgs in one month; one exceeded 7,000 blocks (two days of mining)

Same Ethash-rental dynamic; attacker rented daggerhashimoto

$5.6M + $1.68M (major exchanges)

Bitcoin Gold (BTG)

May 2018

Double-spent ~388,000 BTG (~$18M at the time) across exchanges

Equihash GPU-mineable; tiny network against rentable cloud capacity

~$18M

Bitcoin Gold (BTG)

Jan 2020

Two reorgs (14 blocks then 15) within 7 hours

Same Equihash-rental dynamic

~$72,000 combined

Vertcoin (VTC)

Oct-Dec 2018

22 deep reorgs, 15 with double-spends; one 300-block reorg

Lyra2REv2 rentable on NiceHash; ASIC-resistant by design

~$100,000+ across attacks

Sources: CoinDesk Aug 2020 ETC writeup CoinDesk; Messari BTG 2020 report; CoinDesk May 2019 BCH writeup (source: CoinDesk); Distributed Networks Institute Vertcoin incident page (source: Dn).

The pattern is consistent. Every attacked chain had either (a) a small share of a SHA-256 ecosystem where Bitcoin-grade ASICs could redirect cheaply, or (b) a non-SHA-256 algorithm where rented GPU/ASIC hashrate from NiceHash could match the network. Bitcoin has neither: SHA-256 ASIC capacity outside BTC is essentially nil (BCH+BSV combined are ~1% of BTC hashrate) and no comparable rental market exists.

Vertcoin's response is instructive: developers changed the proof of work algorithm to Lyra2rev3 to invalidate the attacker's hashrate. That is the canonical defense under sustained attack. Bitcoin has never needed it.


Why Bitcoin specifically has not been attacked

Bitcoin's defense comes from compounding factors, not a single moat. Each is necessary; together they make a sustained attack economically irrational for any plausible adversary.

Factor

What it does

2026 magnitude

Network hashrate scale

Capacity the attacker must match

962.71 EH/s (source: Crypto51, May 15, 2026)

ASIC specialization

SHA-256 ASICs work only on BTC family

No general-purpose substitute hardware

No rental market at scale

NiceHash supplies 0% of attack-relevant BTC

0% NiceHash-able (Crypto51)

Capex intensity

New SHA-256 ASICs cost $40-80 per TH/s retail

~$18-37B to fabricate 481 EH/s new

Honest-mining opportunity cost

Attacker forgoes 50% of $30M+/day honest revenue

$7.5M+/day forgone sustained

Price-impact self-harm

Successful attack crashes BTC price, destroying hardware value

Hardware depreciation tracks BTC

Visibility

Hashrate concentration publicly observable real-time

mempool.space, hashrateindex.com

Hardware redirection

Miners can switch pools in minutes if pool turns hostile

GHash.io 2014: 55% → 38% in 48 hours

GHash.io 2014 is the closest concentration event Bitcoin has had. The pool reached ~55% for ~24 hours in mid-June 2014 (source: Wikipedia). No malicious action followed. Miners voluntarily exited, GHash committed to staying below 39.99%, share dropped to ~38% within 48 hours. The episode showed concentration risk is real and that the community self-corrects without a protocol change.

In 2026 the equivalent risk sits in the pool layer: Foundry USA ~30.95% plus AntPool ~20.55% produce ~51% of recent blocks. Two-pool collusion requires operators with reputational, regulatory, and financial reasons to defect. Pool-share is not machine ownership; ASICs belong to thousands of independent operators who can redirect within hours. For how Bitcoin mining pools coordinate hashrate, pool concentration is a censorship concern, not an automatic 51%-attack condition.

From Blofin's exchange-operator vantage point, the signal that matters for BTC credit-policy thresholds is the joint distribution of pool concentration plus active reorgs plus rental-market depth, not any single number. All three currently sit at structural floors for BTC, which is why our Bitcoin deposit policies remain calibrated to consensus risk rather than active-attack risk.


Defense for users and platforms: The 6-confirmation rule

The practical defense is confirmation depth scaled to value at risk. Each additional confirmation roughly doubles the work an attacker must outrun, exponentially against shares below 50%.

Confirmation thresholds by value (industry ranges):

  • < $1,000: 1 confirmation; 0-conf only for tiny value with merchant tolerance

  • $1,000-$10,000: 2-3 confirmations for retail exchange deposits

  • $10,000-$100,000: 3-6 confirmations standard at major exchanges

  • $100,000-$1M: 6 confirmations (Satoshi-derived); OTC and institutional floor

  • $1M+: 6-12 confirmations or org policy; some institutions wait 60+ minutes

Six confirmations come from Section 11 of the Satoshi whitepaper, deriving attacker-catch-up probability via Poisson. At 10% attacker share the probability of overtaking 6 blocks is ~10^-6; at 30% ~5%; at 50%+ the attacker wins given time (source: Bitcoin.org). The rule defeats realistically-rentable shares, not 51%+ attackers (which depth alone cannot defeat).

For platforms: tier requirements by value, not flat thresholds; monitor live reorg depth via mempool.space and flag any ≥3 blocks; track NiceHash rental depth per chain (>1% warrants tighter policy); hold institutional deposits at higher depth post-credit; maintain attack-response runbooks per supported chain.

At Blofin our deposit-confirmation thresholds across the listed SHA-256 family scale to chain-specific 51% economics rather than a single BTC-equivalent default. The rental-market depth and ASIC moat that make BTC's 6-confirmation rule sufficient do not transfer to BCH or smaller forks; that chain-by-chain calibration is the practical answer once you cross from Bitcoin into smaller proof of work.

For how many Bitcoin confirmations you actually need, the same Poisson math underlies every modern exchange deposit-credit policy.


Selfish mining: A related but distinct attack class

Selfish mining is a different attack family from 51% attacks, often confused with it. The Eyal-Sirer 2014 paper "Majority Is Not Enough" formalised it: an attacker with substantially less than 51% hashrate can extract a higher relative share of block rewards by withholding newly mined blocks and releasing them strategically (source: arXiv).

Attribute

51% attack

Selfish mining

Hashrate threshold

>50% required for sustained success

~25-33% sufficient depending on network propagation assumptions

Goal

Double-spend or censor specific transactions

Capture disproportionate share of block rewards

Mechanism

Build longer private chain, release to overwrite

Withhold blocks, strategically release to invalidate honest blocks

Public visibility

Visible only after release as a deep reorg

Visible as elevated orphan/stale rate on competitor blocks

Defense

Confirmation depth; algorithm change as last resort

Faster block propagation; uniform tiebreaker rules

The original paper showed that with 33% hashrate plus γ=1 (selfish miner wins tie races), the attack is profitable; with γ=0.5 (random tiebreakers) the threshold drops to ~25%. Subsequent work refined these and proposed mitigations (Heilman's "Fresh Bitcoins" 2014, uniform-random tiebreakers).

In practice selfish mining has never been definitively detected on Bitcoin. The small revenue uplift comes with high reputational cost (miners would exit), and at ~30% pool size requires network propagation strongly favouring the attacker, which is no longer obviously true. It remains academic in 2026.

For how Bitcoin difficulty adjustment works, neither attack changes the difficulty target directly; both manipulate which valid blocks become canonical.


What pool concentration risk is, and is not

Pool concentration is the most common live source of 51% concern in 2026. It is a real risk, not an attack-in-progress.

Common claim

More accurate framing

"Foundry + AntPool = 51%, Bitcoin is under attack"

Two pools together produce ~51% of recent blocks; neither is attacking; pool concentration ≠ attack execution

"If a pool reaches 51% they can attack"

The pool operator must actively choose to attack at enormous reputational, legal, and financial cost; miners would defect within hours

"Pool hashrate is pool-owned hashrate"

Pools coordinate independent miners; ASICs belong to thousands of independent operators who can redirect in minutes

"Concentration is fixed and worsening"

Hashrate distribution shifts constantly; GHash.io 55% in 2014 → 38% in 48 hours after community pressure

"Stratum V2 has fixed centralization"

V2 moves template selection to miners (limits censorship), not pool aggregation; aggregation and template selection are separate problems

No precedent exists for a Bitcoin pool operator choosing to attack. The May 2019 BCH event came closest in mechanics but operated on a smaller chain where operators had structural reasons (post-fork coin recovery) that made the action defensible.

For whether Bitcoin is meaningfully centralized at the consensus layer, the centralization-vs-attack distinction is fundamental: pools are settlement intermediaries, not network operators with unilateral attack authority.


Common confusions worth flagging

"A 51% attack steals coins from wallets." 

No. It rewrites recent transaction history. Coins protected by private keys the attacker does not hold cannot be moved by any mining power. Risk is reversible recent transactions, not self-custody balances.

"Difficulty adjustment defends against 51% attacks." 

No. Difficulty responds to total hashrate over 2,016-block epochs. A 51% attacker becomes part of that total; difficulty rises with their hashrate, not against it.

"Bitcoin can't have a 51% attack because it never has." 

Past absence is structural evidence, not a guarantee. Defense rests on cost economics holding under current conditions; future shifts in ASIC supply, energy markets, or network design could change the calculation. The honest answer is "extremely difficult and economically irrational" not "impossible."

"Owning 51% of all bitcoin lets you attack the network." 

No. The 51% refers to mining hashrate, not coin ownership. Owning every BTC grants no special ability to influence block ordering. Ownership and hashing power are entirely separate resources.

"Selfish mining and 51% attacks are the same thing." 

No. Selfish mining (Eyal-Sirer 2014) is a distinct attack capturing disproportionate block-reward share without needing 51%. Threshold (~25-33%), goal (revenue not double-spend), and mechanic (block withholding) all differ.


FAQ

Can someone steal my bitcoin in a 51% attack?

No. A 51% attack targets recent transaction ordering and block history, not private keys. Without your private key an attacker cannot produce a valid signature spending from your address regardless of mining hashrate control. The risk is to recently confirmed reversible transactions: exchange deposits credited at low confirmation depth, payment processors releasing goods at 1-3 confirmations, OTC trades settled before sufficient confirmation. Self-custody bitcoin in wallets you control is not at risk from this attack class. Phishing, malware, supply-chain attacks, and exchange insolvency are distinct vectors that should not be conflated with majority-hashrate attacks.

How much would a 51% attack on Bitcoin cost in 2026?

Crypto51's May 15, 2026 reading puts the rental-equivalent cost at $1,648,584 per hour against 962.71 EH/s, but the figure understates real cost because NiceHash-able share is 0%. There is no spot rental market for SHA-256 ASICs at attack-relevant scale. An actual attempt would require fabricating ~481 EH/s of new capacity (~$18-37 billion in retail capex) or coercing existing industrial miners. A sustained attack capable of beating 6-confirmation exchange policies pushes total realistic cost into the tens of millions per double-spend before counting forgone honest mining revenue.

Has Bitcoin ever had a 51% attack?

No malicious 51% attack has been confirmed on Bitcoin. The closest concentration event was GHash.io reaching ~55% hashrate for ~24 hours in mid-June 2014; no double-spend or censorship followed, miners voluntarily exited, and GHash committed to staying below 39.99% within 48 hours. Bitcoin sees small natural 1-2 block reorgs several times yearly, including a March 2026 two-block reorg when Foundry USA mined seven blocks consecutively at ~31% share with no double-spend. Bitcoin Cash, Ethereum Classic, Bitcoin Gold, and Vertcoin have all suffered documented attacks; Bitcoin has not.

Why do exchanges require 6 confirmations for Bitcoin deposits?

Requiring six confirmations comes from Section 11 of the Satoshi whitepaper, which derived the probability an attacker with a given hashrate share could overtake a given depth using Poisson math. At 10% attacker share the probability of catching up to 6 blocks is effectively zero; at 30% it is ~5%; at 50%+ the attacker eventually wins given time regardless of depth. The 6-block threshold defeats realistically-rentable attacker shares on Bitcoin while remaining practical (~1 hour wait). Exchanges scale depth to deposit value: 1-3 confirmations for small, 10+ for large.

What chains have actually been 51% attacked?

Four chains have documented 51% attacks. Bitcoin Cash saw a coordinated May 2019 reorg by BTC.top + BTC.com (~54% combined) reversing post-fork coin grabs. Ethereum Classic was hit in January 2019 (~$1.1M double-spent) and three times in August 2020, including one reorg exceeding 7,000 blocks with ~$7.3M exchange losses. Bitcoin Gold lost ~$18M in May 2018 and ~$72,000 across two January 2020 reorgs. Vertcoin took 22 deep reorgs in October-December 2018 with 15+ double-spends, ultimately changing its algorithm. All four had cheap rentable hashrate; Bitcoin has neither.

Why is Bitcoin Gold attackable for $5 per hour but Bitcoin costs $1.65M?

Bitcoin Gold uses Equihash, mineable on consumer GPUs and rentable on NiceHash; Crypto51 shows 5% of BTG hashrate is rentable on demand. Bitcoin uses SHA-256, mineable only on specialised ASICs; the rentable fraction is 0% because no spot SHA-256 market exists outside the BTC ecosystem itself. Two compounding factors drive the gap: BTG's tiny 201 KH/s hashrate versus Bitcoin's 962.71 EH/s means matching costs nothing, and the GPU rental market actually supplies relevant capacity. Both conditions are required; Bitcoin defeats the attack by failing both.

Is selfish mining the same as a 51% attack?

No. Selfish mining is a separate attack class introduced by Eyal and Sirer in 2014's "Majority Is Not Enough" paper. The threshold is ~25-33% rather than 51%; the goal is capturing disproportionate block-reward share rather than double-spending; the mechanic is withholding mined blocks and releasing them strategically rather than overtaking the public chain. Selfish mining has never been definitively detected in production on Bitcoin and remains primarily academic, while 51% attacks are operationally relevant for chains with cheap rentable hashrate. The two should be distinguished in any serious threat model.

 


Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Factual claims independently verified against the Bitcoin Wiki Weaknesses page Bitcoin Wiki, the Satoshi Nakamoto whitepaper Section 11 Poisson analysis on Bitcoin.org, live Crypto51 attack-cost data snapshot May 15, 2026 on Crypto51, Hashrate Index Q2 2026 hashrate heatmap, learnmeabitcoin.com's chain-reorganisation reference, the CoinDesk reporting on the May 2019 Bitcoin Cash and August 2020 Ethereum Classic incidents, the Distributed Networks Institute Vertcoin 2018 incident page, the GitHub gist documenting the Bitcoin Gold 2018 attack, the Wikipedia GHash.io 2014 concentration record, the Eyal and Sirer 2014 selfish-mining paper at arXiv:1311.0243, and the CryptoTimes report on the Foundry USA seven-blocks-in-a-row two-block reorg of March 2026.

 

Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.