Security incident of 19 September 2026

Following the coins of the 19 September 2026 Blink attacker

On 19 September 2026 an attacker took about 6.61 BTC from 24 Blink accounts. Every customer was made whole by Blink's shareholders. This page shares everything we can about where the money went — every address and transaction below can be checked on the public blockchain — so that anyone can follow the coins, learn how they were moved, and tell us when they move again.

Loading…

Get involved

How to help

Reading the data

What the labels mean

proven
Shown by the blockchain itself: an address he typed in as the destination of a stolen withdrawal, or an address whose coins were spent in one transaction together with such an address (only someone holding both keys can do that). For Lightning: his node aegis-ln, which received the stolen Lightning payments according to Blink's records, and the channels the public Lightning graph shows for it.
traced
Followed through his own transactions: the change of a payment he made, or coins he later spent himself. Strong, but it relies on reading which output of a transaction is his change.
probable
Our best reading from patterns such as round amounts or timing. Not proven — treat with care.
third-party
A transaction made by someone else — an exchange, a swap service, a channel partner — that moved coins to or from him. Third parties are not accused of anything, and their addresses are never listed as his.
Day by day

Timeline

    Chapter 1

    The theft (19 September)

    Using a flaw in how Blink's admin tools checked permissions, the attacker gave his own free account the powers of Blink's support staff, took over 35 accounts and emptied 24 of them. The bitcoin left in two ways: on-chain withdrawals to eight addresses he typed in (12 transactions — Blink's payout system batches withdrawals), and Lightning payments, most of which went to his own Lightning node (chapter 4). Within an hour, two Lightning swap-outs brought part of the Lightning money back on chain to two more of his addresses.

    What is an address, a transaction, an output?

    Bitcoin is held in outputs — coins locked to an address. A transaction spends existing outputs and creates new ones. Anyone can see every transaction; nobody can see who owns an address unless the owner reveals it, for example by spending it together with other coins (see chapter 2).

    Chapter 2

    Following the coins (20–28 September)

    On 20 September, in a single block, he combined stolen coins with coins from three other addresses of his and split the result into new addresses. From 21 September he paid chunks into a cross-chain swap service that turns bitcoin into other coins, routing its orders through NEAR Intents. On 28 September he spent stolen coins together with coins he already controlled on 10 September (chapter 3) — proof that one person controls both. A separate 100,000,000 sats of those earlier coins went through THORChain to DAI on Ethereum.

    How do we know an address is his? (co-spend and change)

    Co-spend: spending several coins in one transaction needs the keys to all of them. When stolen coins are spent together with other coins, the same person controls those other coins.

    Change: when you pay part of a coin, the rest comes back to you in a new output — the change. Payments tend to be round amounts; the leftover is usually the change.

    Not his: a deposit into a service belongs to the service. We show those as grey boxes and do not list their addresses as his.

    Chapter 3

    Before the attack: ecash in Fedimint federations

    By 10 September — nine days before the theft — he already held about 14 BTC as ecash spread across many Fedimint federations. Between 06:08 UTC on 10 September and 02:40 on 11 September, 435 redemptions (peg-outs) paid 1,401,938,713 sats to one address. The same morning those coins were swept and arranged into two coins of about 690,000,000 sats each; one of them later merged with the stolen coins (chapter 2). On 18 September a coin from that split was spent together with the wallet that funded his Lightning node (chapter 4). He used federations again on 1 October, paying 35,000,000 sats — 5,000,000 of them stolen — back in.

    The federations are not involved. They are pre-existing community federations used by many people. Coins still inside them belong to other users.

    What is Fedimint ecash?

    A Fedimint federation is a group of operators who jointly hold bitcoin and issue ecash — digital tokens that can be passed around and redeemed for bitcoin (a peg-out) to any address. Paying bitcoin into a federation (a peg-in) turns it into ecash. The tokens are blind-signed, so a federation cannot tell who holds them.

    Peg-outs on 10–11 September, by federation

    FederationPeg-outsSats
    Chapter 4

    His Lightning nodes

    aegis-ln is his Lightning node, reachable only over Tor. Blink's payment records show at least 146,639,697 sats of the Lightning withdrawals going to it. It was set up from 9 September with coins from his wallet. Most of its channel capacity is inbound liquidity: 13 channels of 100,000,000 sats that LNBiG, a large Lightning node operator, opened towards it — that money is LNBiG's, not his. His second node, green, proved itself his on 2 October by sweeping its whole wallet together with coins his wallet had just sent it. On 6 October aegis-ln opened a new 50,000,000-sat channel with money from his collection address (chapter 5).

    What are Lightning nodes, channels and inbound liquidity?

    A Lightning node sends and receives payments through channels — bitcoin locked between two nodes in an on-chain output. To receive money a node needs inbound liquidity: channels whose funds sit on the other side. Node operators sell such channels. Channel openings and closings are on-chain transactions; payments inside channels are not.

    Chapter 5

    Second's Ark server (5–6 October)

    On 5 October he exploited a bug in the boarding flow of Second's Ark server (built on bark, Second's implementation), taking 0.75 BTC of Second's own liquidity; no user funds were affected (Second's account). On chain, his wallet paid round amounts (5,000,000–25,000,000 sats) into boarding outputs and exited them straight back to his own addresses, collecting the coins at two addresses. On 6 October he emptied collection address #2: 50,000,000 sats went into a new channel on his node aegis-ln (chapter 4).

    What is Ark?

    Ark is a way of using bitcoin off chain with the help of a server. A user boards by locking their own coins in an output they can always take back on chain (an exit). Boarding and exits are visible on chain; what happens inside the server is not. The bug described here was in Second's server software.

    Chapter 6

    His Lightning wallet

    He also used a Lightning wallet whose channel has existed since February 2026 (continuing a channel from January 2024). On 5 October 35,000,000 sats were taken out of it (a splice-out) into his wallet; part of it was paid into a boarding output at Second's Ark server and exited straight back to his collection address (chapter 5). That afternoon the channel was force-closed and the rest swept. We mark the wallet itself probable: the link to his proven addresses runs through the splice-out.

    What is a splice?

    Some Lightning wallets keep one channel and resize it on chain: a splice-in adds coins, a splice-out pays coins from the channel to an on-chain address. Each splice is a transaction, so the channel's history can be followed back.

    Everything in one list

    All indicators

    Download CSV

    Method

    How to read this

    Labels
    See What the labels mean.
    Known since
    When we first recorded the item in our private incident record (date of the first commit containing it). Our record starts on 21 September 2026, so items we knew on 19 September show 21 September. These dates are our own statement; the timestamp proofs below let anyone check that the list existed by the time it was stamped.
    Timestamps
    We timestamp this page's data on the Bitcoin blockchain with OpenTimestamps, together with a fingerprint of our full internal list (which also covers items not published here), at launch and with every update. Each manifest lists the SHA-256 of the published data files and the fingerprint (a salted Merkle root), is signed with our bounty PGP key and carries an OpenTimestamps proof.
    8 October 2026: manifest · signature · OpenTimestamps proof
    First seen on chain
    Block time of the transaction, of the first transaction touching the address, or of a channel's opening.
    What is not here
    Information partners gave us in confidence or under non-disclosure agreements, personal data, open security issues, and addresses whose owner we cannot establish. We add new findings as we confirm them and as the people involved agree.
    Verification
    Every address, transaction and channel is checked against the blockchain when this page is built. Amounts are in satoshis (1 BTC = 100,000,000 sats) unless marked BTC.
    Changes to this page

    Corrections

    Corrections are added here as dated notes; we do not silently rewrite this page. To report an error, write to bounty@blinkbtc.com with [CORRECTION] in the subject.