Mercado Bitcoin hack: wallet analysis
The withdrawal wallet retained funds after all 4,334 spends between and , before the main theft payment. Bitcoin arriving during the attack joined the theft, and two drained deposit addresses received more Bitcoin afterward.
Later incoming funds checked through .
The Bitcoin theft reached three connected parts of Mercado Bitcoin’s operation: the withdrawal balance, an established funding address and old deposit addresses. Funds reached the funding address after deposit sweeps had begun and were spent in the main theft payment. Later, two drained deposit addresses received more Bitcoin.
Historical analysis of the hot wallet
Mercado Bitcoin, the Brazilian cryptocurrency exchange, confirmed the hack and suspended deposits and withdrawals. The affected Bitcoin operation used a withdrawal wallet to hold funds for outgoing payments, individual funding addresses to supply it, and a separate deposit network that gathered funds from older receiving addresses.
The withdrawal wallet was the single Bitcoin address bc1q6gd5r…5nzfa5. From through , before the main theft payment, all 4,334 spending transactions left funds behind. Its largest earlier net balance reduction, on , removed 49.94 BTC and left 118.60 BTC behind.
The main theft transaction reduced this address’s balance by 102.03 BTC, 2.04 times that previous maximum, leaving 0.00086952 BTC. The final clearing transaction spent that remainder about eight minutes later. The chart follows the address from the preceding day through its first emptying.
The earlier maximum left 118.60 BTC behind. The main theft left less than 0.001 BTC. Times shown in UTC.
The main payment leaves 0.00086952 BTC at the withdrawal address. The final clearing transaction spends that balance about eight minutes later. Every retained transaction close is plotted.
The address had previously held as much as 238.11 BTC. Its balance at the hack was therefore within its historical range. The sharp departure was how much one transaction removed and the wallet’s subsequent emptying. Payment limits should cover the amount sent in one transaction and the total sent across related transactions, using the wallet’s own payment history.
Spending limits enforced independently of the withdrawal process constrain what one compromised payment—or a series of related payments—can remove. Here, one transaction removed almost the entire 102.03-BTC balance.
The wider address footprint and normal funding cycles
The withdrawal address and the three profiled funding addresses belong to one cluster, a group linked by transaction evidence, with 3,186 historically linked addresses. The separate deposit network has 451,341 historically linked addresses, including older deposit addresses and the addresses gathering their funds. Earlier deposit sweeps fed an address that in turn supplied the withdrawal wallet. These historical footprints include old, empty addresses.
Returning to zero was routine for the funding addresses. Before 2 November 2026, 00:00 UTC, the recurring funding address bc1qqxu9y…3av379 had emptied in 78 of 83 spends. Its median completed funding cycle was 58 minutes, measured from receiving funds at a zero balance to returning to zero. The other two profiled funding addresses were already empty before the hack.
| Address | Spends that emptied it | Median completed cycle |
|---|---|---|
| bc1qqxu9yyeumd7n73z495n5q230sas5rw933av379 | 78 of 83 | 58 minutes |
| bc1q892ez6ssj88t7u4qv73n8tgdac9k46pqx5kk26 | 15 of 16 | 77 minutes |
| bc1qa39pzmg9u3npspq8lynprpwjd9l7ycc3tlp6yf | 23 of 24 | 55 minutes |
The full withdrawal-wallet cluster sent an average of 30.92 BTC per day outside the cluster during the 31 complete UTC days from 2 October through 1 November. The median was 15.98 BTC and the busiest day was 147.48 BTC. These figures describe the wider operation’s scale; the single-address comparison above measures the change in its own spending behavior.
Funding activity during the hack
Deposit-address sweeps began at . Ten existing addresses were emptied in the opening phase. Their funds passed through an intermediate address, which forwarded 0.36934 BTC to the attacker at . A later pooled sweep sent another 1.26952 BTC and brought the entire deposit network to zero at .
During those early sweeps, before the main theft block, the withdrawal-wallet cluster still received 5.63494 BTC. That included 2.39948 BTC arriving at the recurring funding address bc1qqxu9y…3av379 at .
- Deposit sweeps begin
Ten existing addresses are swept in the opening phase.
- 2.39948 BTC arrives
The recurring funding address receives Bitcoin while the attack is under way.
- 104.43 BTC sent
The funding address and withdrawal address supply the inputs to the same payment to the attacker.
About an hour after that arrival, the funding address and withdrawal address supplied inputs to the same 104.43-BTC payment to the attacker. The 102.03-BTC net reduction shown earlier belongs to the withdrawal address alone; this larger payment also consumed the funding address’s coins.
The 2.39948 BTC at the funding address was spent alongside the withdrawal wallet’s coins. Spending controls need to cover all addresses that can contribute funds to a payment, including the funding route.
The complete drain across both networks
Across the early and later deposit sweeps, 63 pre-existing addresses were swept. The larger sweep also spent a fresh change address created in the same block. The deposit network reached zero at ; the withdrawal-wallet cluster reached zero at .
The attacker address 19qGpsHvzh1t6pVi526XNNkh6hW6prDZp received 106.06780001 BTC in seven payments. Neither affected cluster had reached zero earlier in the reconstructed period beginning 1 September 2026, 00:00 UTC. Their balances include the full linked groups under the stated membership frame.
Transaction settings and fees
The main theft transaction used the same version, lock-time setting and input-sequence setting as all 100 earlier withdrawal-wallet transactions in the selected sample. These settings describe how a Bitcoin transaction is constructed. Its fee rate, 1.21 sat/vB, also lay within that sample’s 1.20–6.00 sat/vB range.
The deposit sweep was different. It used a different combination of transaction settings from the main withdrawal-wallet payment and paid 50 sat/vB. Two earlier sweeps sharing 25 and 26 source addresses with it had paid approximately 2.00 and 1.00 sat/vB respectively.
These are two selected earlier sweeps with overlapping source addresses. The main withdrawal-wallet theft separately paid 1.21 sat/vB.
The main payment’s construction resembled the withdrawal wallet’s earlier activity even as it removed twice the previous largest amount. Familiar settings alone would therefore have been a weak basis for accepting it. Destination checks and limits on individual and cumulative payments need independent enforcement.
A transaction can use familiar settings and still empty a wallet. Destination checks and amount limits need enforcement independent of the process that builds and signs the transaction.
Transaction-comparison scope and exact amounts
The 100-transaction construction sample runs from to . The three compared properties match the main payment in every sampled transaction. The two historical deposit sweeps are selected examples with shared source addresses. Times shown in UTC.
| Transaction | Balance reduction | Balance afterward |
|---|---|---|
| Earlier maximum · | 49.93785882 | 118.60344787 |
| Main theft · | 102.02842524 | 0.00086952 |
| Final clearing · | 0.00086952 | 0 |
Funds received after the hack
After both affected clusters reached zero, eight previously used addresses received Bitcoin. Five addresses in the withdrawal-wallet cluster received 0.27434 BTC, and three in the deposit network received 0.09743 BTC. Two of those deposit addresses had already been emptied in the attack. Both had first been used in 2017.
All eight incoming outputs remained unspent at . Funds sent to the two drained addresses were exposed to further theft if the attacker retained spending access.
Bitcoin can still be sent to an existing address after an exchange suspends deposits. Saved receiving instructions can therefore keep directing funds to addresses already swept in an attack.
Stopping the withdrawal wallet does not stop funds arriving at old deposit addresses. Those receiving instructions remain an exposure wherever they are still in use.
All eight addresses receiving funds after the drain
| Address | Received · date and time | BTC | Observed role |
|---|---|---|---|
| bc1qzlp5kwm4twlfn5wk7hxgzffd25ycqhk68eew2s | 0.00423978 | Other withdrawal-wallet-cluster address | |
| bc1q3jh5x033hfnrse553qqsr48jqfyct9zuyza5ns | 0.16773086 | Other withdrawal-wallet-cluster address | |
| bc1qqlqphm5vu6lx6gazanpuh4te892ef99hxaetmw | 0.00115509 | Other withdrawal-wallet-cluster address | |
| bc1qzedc66v875rcgesp7v0yykl3lsmtz2zuzjc4g2 | 0.01526951 | Other withdrawal-wallet-cluster address | |
| 1LmgCTrjNXGwffm6WyvtRcwJkVrfwi8Ys5 | 0.09000000 | Directly drained in the attack | |
| 3BtW18rY8t85PiNv5qapMJvTHiU6syw5ZY | 0.00265452 | Other deposit-network address | |
| bc1qcs8mxacsss22kv3ymhvtgecue23p6u6563q2rk | 0.08594724 | Other withdrawal-wallet-cluster address | |
| 1NjHj1Dzfepb9e2qf964weyvh1ZgtiyWTv | 0.00477663 | Directly drained in the attack |
Sources and measurement periods
This article uses TrackBTC’s address attributions, Bitcoin transaction history and cluster accounting. The withdrawal-address comparison runs from its first activity on to its last spend before the main theft. Funding-cycle comparisons stop at 2 November 2026, 00:00 UTC.
Cluster balances are reconstructed from 1 September to 3 November 2026, 00:00 UTC under the same closing address membership at block 974317. The recent withdrawal-address graph plots all 91 retained transaction closes from . The later incoming outputs are checked again through block 974327 at .
The report of Mercado Bitcoin’s statement records the exchange’s suspension of deposits and withdrawals.
Seven payments received by the attacker
| Date and time | BTC received | Transaction |
|---|---|---|
| 0.00072720 | 85d08d7f5c01… ↗ | |
| 0.36861187 | afda480aa837… ↗ | |
| 0.00010000 | 643b3ad9b361… ↗ | |
| 1.26952011 | aa9bc710f062… ↗ | |
| 0.00010000 | 7f65ae37cb4f… ↗ | |
| 104.42787649 | ada3bb2304be… ↗ | |
| 0.00086434 | 44432ef89446… ↗ |
Read the supporting measurements. How we attribute addresses.