This post was originally published on this site.
On Monday, 5 October 2026, an attacker exploited a bug in the server that powers Bark, the Ark implementation built by Second. They walked away with 0.75 BTC, about $62,000 at the time. Second says none of it belonged to users.
The amount is small by this year’s standards, but the incident matters for a different reason. Second is the first Ark operator to be exploited on mainnet, and it happened four months after Bark launched.
It tests Ark’s central promise: you can use a server-coordinated payment system while keeping your coins safe from the server’s mistakes.
What Happened?
Second disclosed the incident in a short thread on X on 8 October. Its account, which other outlets (Bitcoin.com News, KuCoin, Binance Square and RootData) repeated, goes like this:
- The bug was in the boarding flow. Boarding is how on-chain bitcoin moves onto Ark. The server is supposed to co-sign it.
- The attacker bypassed the co-signature. In Second’s words, “a bug let the attacker register boards with only his own signatures.”
- The same coins were used twice. The attacker exited those boards back to their own wallet while “also spending the same VTXOs out of our node via Lightning.”
- The loss was Second’s own liquidity. The 0.75 BTC came from the server’s operational funds, not from user balances.
My reading of that description is a classic double-spend. The attacker deposited coins, fooled the server into treating the deposit as valid, got the money back through an on-chain exit, and also got paid through Second’s Lightning node for the same coins.
The net effect was a payment from Second’s liquidity with nothing behind it. Second hasn’t published a technical post-mortem, so treat that explanation as an interpretation, not a confirmed account.
The Response
According to Second, it caught the attack within hours, blocked the source, briefly took the server offline and shipped a fix. The attacker kept probing through Tuesday, which led to a denial-of-service condition that degraded Lightning receives on Bark-based wallets.
Second flagged that publicly on Tuesday.
There was one further detail. Second said the attacker tried to use bitcoin linked to the Blink Wallet breach of 19 September, in which an attacker drained a “few dozen” custodial accounts.
That attempt failed, and the attacker had to fund the boards from their own address before exiting back to it. The reports don’t say how Second linked the two, so this is worth treating as the company’s claim for now.
“The Design Did Its Job”
Second’s own summary was blunt: “User funds were never at risk because VTXOs sit on pre-signed exit paths the server can’t spend. The only bitcoin the vulnerability exposed was our own liquidity. The design did its job, even if we’d rather have demonstrated it another way.”
That deserves to be taken seriously, and also examined. It is the best argument for Ark over a custodial service. In a custodial service, a bug like this would hit customer balances. Here, the cost landed on the operator, because the user’s coins are protected by pre-signed transactions the server cannot override.
But the claim has limits.
- The server still holds real money. Ark operators fund liquidity so users don’t have to manage it, including the Lightning node that pays invoices. That liquidity is a target, and a bug that lets someone draw on it is a real loss for the operator, even if users are shielded.
- Availability is not covered by the exit guarantee. Users didn’t lose coins, but they did feel the DoS. Lightning receives were degraded, and the server went briefly offline. The pre-signed exit protects your funds, not your convenience, and “I can always exit” is a weaker comfort when you want to pay a bill now.
- The claim is unverified. “No user funds were affected” comes from Second. I couldn’t find an independent review, and the technical details of the bug haven’t been published.
- Unilateral exit has costs. If an operator failure had affected users, getting out unilaterally means paying on-chain fees and waiting. For small balances, that can be uneconomical.
What It Says About Ark Operators
Earlier articles in this series described the operator as the party that coordinates Ark: gathering funds into shared on-chain outputs, co-signing payments and providing liquidity.
This incident shows what that role costs.
Operators are software, and software has bugs. The boarding flow is a place where the server’s co-signature is supposed to be a safety check. When that check failed, the attacker only needed their own keys. A signature-validation mistake in the right place is enough.
It also shows how concentrated the risk is. Second runs the public mainnet server that Bark wallets connect to, and other projects build on it. Noah, Arke and Second’s own Bark Wallet and BTCPay plugin all depend on that server being up, as does ArkPool, which uses Bark to pay out miners. A single incident at a single operator touches all of them.
Finally, the incident illustrates the trade-off Ark makes. Lightning pushes liquidity and uptime onto each user, and Ark moves it onto the operator.
That is simpler for users, but it makes the operator the place where failures show up.
Does This Affect Arkade?
Arkade, built by Ark Labs, is a separate implementation with its own server software, so Second’s bug doesn’t automatically apply to it.
I didn’t find any reports of a similar incident on an Arkade operator, nor any independent confirmation that it is immune. Different codebases can fail in different ways, and a boarding-validation bug is worth checking for in any Ark server.
A Bad Season for Bitcoin Infrastructure
Second’s incident comes during a run of security events: the Liquid Network exploit in September, Core Lightning’s emergency patch in August and the Blink breach on 19 September.
Bitcoin.com’s headline called this “another Bitcoin project” being attacked, and that framing is fair. As covered in “Hack or Be Hacked”, attackers now have cheap tools for probing code at scale, and young systems with real money in them are attractive targets.
Second’s loss is also the smaller kind of failure.
0.75 BTC from the operator’s own funds, caught in hours and with no user losses reported, is the best version of how an incident like this can go. A similar bug in a more mature system with more at stake would look very different.
What Users Should Do
Second hasn’t asked users to take action, but sensible habits apply.
- Update your wallet to the latest version, and watch Second’s channels for the post-mortem.
- Keep balances modest. Ark on mainnet is four months old. Second itself launched with “start small” guidance.
- Know your exit path. Understand how a unilateral exit works in your wallet before you need it.
- Keep refreshing. Keep your coins refreshed and your recovery phrase and wallet data backed up.
- Don’t assume the same risk everywhere. Check which operator your wallet connects to.
Ark Operator in Shaky Waters
Second’s hack is a small loss with a large lesson. It shows that Ark’s safety design works as advertised in the way that matters most: the operator took the hit, not the users.
It also shows that operators are a real attack surface, that outages still affect people, and that the claim “users were never at risk” needs a published post-mortem to be fully credible.
Ark is still new technology, and incidents like this are part of how it earns, or loses, trust.
The post Ark Operator Second Gets Hacked appeared first on The Bitcoin Manual.
