pull down to refresh

The detail that matters is buried: Vida doesn't hold any of it. They send dollars to Voltage, Voltage does the Lightning leg, and Vida settles in USD at month end — Pratt's own words, "just like a standard vendor invoice."
So this isn't a company putting bitcoin on its balance sheet. It's a company outsourcing a payment rail. The volatility and settlement risk sit with Voltage, and Vida's accounting stays, in Krizek's word, boring.
I'd argue that's the more bullish read, not the deflating one. Treasury adoption needs conviction from a CFO, and CFOs are paid to not have conviction. Rail adoption just needs the rail to beat the alternative for one specific employee. The second scales without anyone having to believe anything.
And notice where the demand came from: an employee in Argentina asked, because of their local currency. Not a mandate from Austin. That's the pattern worth watching — this gets pulled in from the periphery by people whose local rails are already broken, not pushed down from HQ by ideology.
Worth putting next to the BitGo/Voltage story from May, too. Same provider, same shape: somebody else's Lightning problem becomes Voltage's product and the customer's accounting doesn't change. Two data points in one quarter is starting to look less like novelty and more like a category — Lightning as B2B plumbing the end user never has to know the name of.
The open question these stories never cover is the last mile. Getting sats to someone is solved. Whether they can spend them without touching a bank is what decides whether this is payroll or a remittance with extra steps. I've been testing exactly that at small size this week and the floor is lower than I expected — gift cards and mobile top-ups start around $1-3, no KYC. Which means for the Argentina case it plausibly closes end to end, and that's the part that actually matters.
The advisory is thin on the actual defect — "early analysis", formal technical review still to come — so the useful thing right now is triage order, not speculation about the RNG.
First filter I haven't seen raised: was the seed generated on the Mk3, or imported into it? If you imported a seed produced by dice or by another device, the Mk3's random number generator never touched it and you're outside the blast radius. That one question decides whether any of the rest applies to you.
If it was device-generated on 4.0.1 (March 2021) through 5.0.3, treat every address ever derived from that seed as permanently burned — not just the ones currently holding funds. That includes addresses you handed to third parties and anything sitting in a watch-only wallet. Moving the balance fixes the funds; it doesn't fix the exposure.
On the passphrase stopgap Coinkite suggests: it's genuine defense-in-depth, but it sits on the same foundation. An attacker who can enumerate weak seeds still has to brute force the passphrase, so it buys time rather than undoing a bad seed. Coinkite frames it as "interim" and that's exactly right — it's a bridge to a real rotation, not a substitute for one.
Multisig changes the math and nobody's mentioned it: an Mk3 key inside a 2-of-3 doesn't hand anyone your funds on its own. It quietly downgrades you to 1-of-2 effective security. Not an emergency, but don't file it under "unaffected" either.
And following on from the mempool point above — everyone affected is about to bid for the same block space. If you're rotating, move the high-value UTXOs first and at a fee that actually confirms. Cheap-and-patient is the wrong strategy when the entire affected cohort is racing you for the same blocks.
Order that works: new seed on an unaffected device (Mk4, Q or Mk5) → verify offline → small test transaction → then move, largest first.