Vol. 11 — Electrum Made You Sign for the Thief, CoinDCX Called It a False Alarm, Yapeswap Handed Over the Keys for 0.000055%
Three incidents this week, and none of them broke cryptography. A wallet trusted a server, an exchange trusted its own press release, and two governance systems trusted parameters nobody checked.
9 min read · The Weekly
On this page
Three stories this week, and none of them looks like a heist movie. No private key was cracked, no curve was broken, no zero-day was sold on a forum. Electrum’s problem was written in its own documentation. CoinDCX’s problem was written on its own blog, three days late. Yapeswap’s and X100’s problems were written in governance parameters that nobody set. The common thread is the same in all three: the last step of verification was outsourced to an interface, a press release, or a voting rule.
1. Electrum: you paid the fee, the thief got the address
On October 24, Electrum shipped 4.8.3 and published advisory GHSA-6jp4-8v48-cc5v. Severity High, no CVE, affected versions everything before 4.8.3. The advisory says it plainly: some servers are running this attack in the wild, two users reported it privately, and one of them lost money.
The chain is not complicated. Electrum is a light client. It asks a server for balances, history, fees and mempool contents. Confirmed transactions get SPV-checked against headers. Unconfirmed ones are taken on trust, which is documented light-client design and has been for years. A malicious server exploits exactly that. It swallows the transaction you just broadcast, call it tx1, and does not relay it. Then it pushes a different transaction, tx2, into your wallet history, with outputs paying the attacker. tx2 has invalid signatures. Old Electrum does not verify signatures on unconfirmed transactions, so it displays tx2 as a pending payment. You see a stuck payment and hit the fee bump button. Electrum signs what it believes is pending, which is tx2.
The signature is valid. The transaction is real. It is simply not the payment you meant to make. The advisory lists the timeline: October 11, the first user reports a replaced transaction without realising the fee-bump path; October 18, a second user, Raju-K12, reports losing money after approving a bump; October 23, the fix lands in git; October 24, binaries and public disclosure. The stolen amount has not been disclosed.
Two details turn this from theory into something that works. First, the attacker’s address was ground so its last four characters match the real recipient. When a payment is late, people compare the first and last few characters and move on. Second, the fake transaction in the second report paid zero fee. A zero-fee transaction looks stuck, and a stuck transaction is what makes a user reach for the fee bump. The trap is built around your next click.
The fix is commit 90fe308. Before an unconfirmed transaction enters local history, Electrum now verifies the signatures on inputs that spend the wallet’s own coins. If the parent is known, the fake transaction is rejected with InvalidTxSignature. If the parent arrives later, the spending transaction is removed. The boundary moved inward, it did not vanish. The advisory admits the client still only validates is_mine inputs. Incoming transactions are not script-checked, and covering them would mean recursively validating unconfirmed parents back to mined transactions, which is a full node’s job.
Three practical conclusions. Upgrade to 4.8.3 from electrum.org and verify the GPG signature. Treat every fee bump as a fresh signature, and read the full address, not the first and last four characters. If the amount is meaningful, run your own server, because the attack requires a server that can lie to you. Hardware wallets still help here for a specific reason: the address appears on the device’s own screen, and the four-character lookalike has to survive that screen too.
The full breakdown is on Onchain Diary: Electrum 4.8.3 and the fee bump that signed the theft.
2. CoinDCX: the on-chain timeline versus a denial
The second story is about communications, not cryptography.
On October 21, CoinDCX noticed unusual activity in its systems. On October 22, irregular fund movements appeared on-chain. Early that morning, Darcy, co-founder of FlashRescue, posted on X: roughly 15.99 million USDT and 5,783.81 TRX had left CoinDCX hot wallets and deposit addresses, all into one Tron address, with a single largest transfer of 15,819,002 USDT, then split toward Binance, OKX and Gate deposit addresses.
CoinDCX responded quickly. CEO Sumit Gupta replied within three hours: the addresses had been compromised in July 2025, the hackers appeared to be reusing old addresses, and this sounded like a false alarm. The company account followed four minutes later, calling the claims misleading and saying those addresses had not been used since July 2025.
Then ZachXBT produced the timeline. One of those addresses, labeled TQKJQ, had been used by a liquidity provider for ten months after the July 2025 incident, and was still sweeping user deposits into CoinDCX’s current hot wallet as recently as April and May 2026. This was not a hacker digging through old trash. It was an address still receiving customer deposits.
On Sunday, CoinDCX changed its story in a blog post. The wallet belonged to deprecated infrastructure from the July 2025 breach and carried unknown vulnerabilities. The automated sweeping service failed for a period, so deposits piled up at the old address. The loss was 15.99 million USDT, absorbed by the company. User funds sat in segregated cold wallets, and trading, deposits and withdrawals continued.
Two things deserve to be separated. On the technical side, the failure was not “we got hacked.” It was an abandoned address still accepting deposits, a sweeping service that stopped without anyone noticing, and old infrastructure with unknown holes still online. Three operational misses stacked on top of each other. On the communications side, the exchange denied the obvious while on-chain evidence was public, then reversed when an analyst showed the address usage. A denial is not evidence. A block explorer is.
CoinDesk quoted CoinDCX’s own line: “We could have been more proactive, but we shared this update as soon as we had the complete picture.” Translated: first we said we did not know, then we said we did.
Background: the July 2025 server intrusion cost the exchange about $44 million. This week’s loss is the aftershock from the same deprecated infrastructure, fifteen months later. The company can absorb $16 million on its balance sheet. Trust is not a balance sheet item.
3. Governance’s two zeroes: zero quorum, zero timelock
The third story has two halves, one almost comic, one textbook.
Yapeswap first. On October 25, SlowMist flagged an attack with losses around $21,900. Small money, clean method. WorkersUnion governance required zero quorum, so a proposal backed by roughly 0.000055% of voting power transferred YapeFactory’s feeToSetter role to the attacker. The attacker then deployed a malicious Registry contract whose latestVault() returned a fake vault while vaults() still listed the real ones. YapePair counted the diverted deposits as farming assets without receiving redeemable shares, and the money was gone.
Zero quorum means no one has to agree, and no one has to disagree. One vote and the proposal passes. 0.000055% would not clear a proposal threshold in any sane governance system. Here it was enough to take a critical permission.
X100 is the larger one. At 14:11:47 UTC on October 24, a single transaction borrowed 1,942,457.64 USDT through an Aave flash loan, bought about 38,200 X, split it into two helper contracts of roughly 19,100 X each. Each helper locked 19,000 X into the Freezer and paid a 100 X registration fee, which put it into the Senate. X100’s Senate has three seats ranked by frozen balance. Two seats are a majority.
The decisive detail is one millionth of a token. Each helper locked 0.000001 X more than the incumbent it needed to beat, just enough to rank higher at the moment the contract read balances. The attack did not need real capital, only temporary capital. Borrow, buy, lock, propose, vote and execute all happened inside one transaction, leaving no block in which anyone could react. The on-chain description of the proposal read testnet flash governance proof, which is either a taunt or an honest label.
The result: the Freezer sold 400,000 X into a PancakeSwap pool the attacker had created minutes earlier with almost no liquidity, and received 35.68 USDT. At market prices those tokens were nominally worth about $20 million, but a thin pool would never pay that, and the attacker did not need it to. It recovered the tokens from its own pool, sold into the real Uniswap X/USDT pool, and walked away with about $4.75 million after repaying the loan.
Bitquery’s forensics name the two missing controls: a voting-power snapshot and a timelock. If voting weight were fixed at a block before the proposal, flash-loaned tokens would not count. If execution were delayed by hours, someone could see the proposal and react. X100 had neither, so buying seats, voting and emptying the treasury became atomic. At a 04:19 UTC checkpoint on October 25, two of the three Senate seats were still held by the attacker’s helper contracts, which accepted calls from anyone. The damage was limited only because the treasury’s allowance for market pools was nearly exhausted and user frozen stakes sat outside the tradable assets.
Put Yapeswap and X100 side by side and the conclusion is identical. A governance attack does not need a majority. It needs the blank space in the rules. One had no minimum quorum. The other had no snapshot. Both are configuration mistakes, not code bugs. A wrong parameter does the same damage as a vulnerability, and it is usually cheaper to fix. The problem is that nobody audits parameters before the money leaves.
Closing notes
A few threads worth keeping:
- Electrum’s advisory admits the fix only covers the wallet’s own inputs. Incoming unconfirmed transactions are still not script-verified. The light-client trust boundary does not disappear, it moves
- CoinDCX says user funds are safe, and technically they are, because the company absorbed the loss. But deposits still landing at a deprecated address means address rotation and sweep monitoring never formed a closed loop
- Yapeswap had not published a fix at the time of writing. A governance contract where 0.000055% can change critical permissions should not hold anything valuable
- X100’s attacker still held two Senate seats at the checkpoint. Governance capture and treasury drain are two different problems, and the first one usually gets ignored
- Across all three, the only action a user could take was upgrading Electrum and checking an address. In the other two, users could do nothing but wait for the operator to explain itself
Three stories, three outsourced checks. Electrum outsourced verification to a server. CoinDCX outsourced disclosure to a PR calendar. Yapeswap and X100 outsourced safety to governance parameters. The lighter the client, the heavier the trust, and trust only gets audited on the day it is taken.
Sources: Electrum advisory GHSA-6jp4-8v48-cc5v and commit 90fe308, CoinDCX’s official blog, CoinDesk, The Block, on-chain records from ZachXBT and Darcy, SlowMist and Bitquery reports. Views are the author’s own, not investment advice.