Kraken asks, Railgun stalls
Two decisions this week: do not buy XMR through Kraken; 0xNull Lending v2 will not integrate Railgun. The first concerns the identity records an exchange keeps after a withdrawal. The second concerns whether a lending integration can rely on its withdrawal path. Both decisions require a precise account of what happened, including what the evidence does not establish.
What Kraken did
Following the public complaints on 23 October, Kraken co-CEO Arjun Sethi acknowledged the requests in a statement published early on 24 October: “the $XMR emails were us. they were wrong.” He said clients who bought Monero with their own money and withdrew it had been asked for their employer, source of funds and intended use of the coins. According to Sethi, no rule required those requests; a young client with a large balance had been treated as a red flag.
Kraken withdrew the requests and told affected clients that nothing further was required. Sethi rejected the intended-use question, defended source-of-funds enquiries and said XMR would remain listed. That last statement does not mean it is available in every jurisdiction. Read Sethi’s full statement.
View the supplied screenshot of Sethi’s statement, circulated by Wu Blockchain. This is a screenshot of his acknowledgement, not a copy of a recipient’s email. The statement does not establish the number of recipients or their jurisdictions.
Credit to Sethi for the reversal. It does not remove the records behind the account: a KYC exchange can associate a customer’s identity with their trading history and withdrawal destination. Withdrawing Monero does not retrospectively erase that association, although it does not give the exchange a transparent view of every subsequent Monero transaction.
Kraken’s standing policy, updated on 1 October, says an unanswered information request may lead to a pause in some activity, including trading and deposits. It expressly says withdrawals are not affected. The withdrawn XMR questionnaire and that continuing policy are different things; neither supports a claim that these clients’ withdrawals were blocked. Kraken’s additional-information policy.
Reduce the identity trail without promising its absence
Our preference is to minimise the personal information collected when acquiring XMR. 0xNull swaps use Trocador and AnonPay without requiring a 0xNull account or email address. That is not a guarantee that every underlying exchange will complete every transaction without KYC: Trocador’s terms say its partners may request verification under their own compliance policies. Check the selected provider’s terms before sending funds. Trocador’s terms.
P2P trading with appropriate escrow can reduce reliance on a custodial exchange, but a bank transfer or counterparty can still reveal identity. Escrow manages a trade’s settlement risk; it does not erase the fiat payment record. Running a wallet against your own node can reduce another dependency. These are practical reductions in disclosure, not a promise that the only record left is on-chain.
Railgun: seven reports, with their limits
The following log covers seven reports published between August and October. Some describe overlapping problems, so they must not be counted as seven independent outages. Issue states below were checked on 24 October 2026.
- 21 October — wallet issue #148, open. A reporter describes transact proofs from one wallet being rejected while other wallets’ proofs were accepted. Crucially, the underlying unshield transactions had landed; the reported problem concerned missing PPOI verdicts for unshield and fee notes, with implications for change notes. It is not evidence that every attempted withdrawal failed. Issue #148.
- 20–21 October — wallet issue #147, closed. The reporter records no shield verdicts on Ethereum between 17:59 UTC and 04:16 UTC, leaving 51 shields pending for about ten hours. That is 51 shields, not an independently established count of 51 wallets. Transact and unshield verdicts continued, and the shield problem reportedly resolved without intervention by the reporter. Issue #147.
- 20 October — Railway Wallet’s acknowledgement. The wallet team addressed 502 and PPOI-sync errors experienced over the preceding 48 hours. It attributed the gateway problem to general IPFS traffic and said developers had made garbage collection more aggressive; users were asked to update and retry. Railway Wallet’s statement.
- 20 October — wallet issue #146, open. A fresh-install report describes a single hard-coded proof-artifact gateway without a fallback. It records 25 HTTP 502 responses and identifies 24 requested artefacts; an alternative gateway worked. The distinction between fresh downloads and already-cached artefacts matters when assessing the scope. Issue #146.
- 16–19 October — wallet issue #145, closed on 20 October. Reports combine rejected proofs and gateway errors, with users describing funds they could not move while awaiting PPOI generation. The issue’s closure is recorded here; it does not independently establish that every affected balance was resolved. Issue #145.
- 2 September — wallet issue #140, open and disputed. A user alleges that a PPOI block and fallback refund path following a Beefy/Morpho vault exit left 50,551 USDC unrecovered. A third party disputes ownership in the thread. This is a serious reported integration failure, not a verified finding that Railgun stole or currently holds that amount. Issue #140.
- 10 August — MigaLabs disclosure, vulnerability fixed in July. The auditor describes a permissionless way to freeze roughly $2.6 million of distributable DAO treasury funds, reported on 22 June and fixed through proposal 24 on 18 July. It criticises the disclosure process and the proposal’s presentation as “gas and process optimisations” with “No other improvements”. This concerns a patched treasury vulnerability, not proof of a currently exploitable flaw or an actual $2.6 million loss. MigaLabs’ account.
View the supplied Railway Wallet support-form screenshot. It includes a Railscan system-liveness check among optional troubleshooting steps and explicitly allows a ticket at any time. A status page is useful operational tooling; its existence alone does not establish that outages are routine.
Why Lending v2 will not integrate Railgun
These reports are enough to reject the operational dependency for our planned integration without overstating what the protocol requires. Railgun’s documentation describes private proofs of innocence as separate from its core contracts and explains an unshield-to-origin route. Broadcasters are not an exclusively controlled service that nobody else can run. It would therefore be wrong to say that every possible Railgun exit is universally hostage to one gateway or PPOI node. Railgun’s PPOI documentation.
Our concern is the wallet and SDK path a lending service would actually use: obtaining proof artefacts, receiving the required verdicts and completing composed DeFi operations when needed. Delays or failures in that path matter even when another protocol-level route exists. The disputed vault report warrants investigation; it does not establish that all vault liquidity carries someone else’s taint.
We mothballed our Railgun routing in September because of cost and RPC load. October’s operational reports reinforce that decision. The Lending v2 design instead proxies DeFi positions through a single 0xNull address and uses commingling to reduce direct user-to-position attribution. Commingling is not a zero-knowledge privacy guarantee: public transactions remain visible, correlation risks remain and the operator remains a trust dependency. That is the design boundary we can explain; it is not a claim of cryptographic unlinkability.
Questions
Did Kraken withdraw the XMR information requests?
Yes. Sethi said the specific requests were withdrawn and affected clients had nothing further to provide. Kraken’s broader source-of-funds policy remains separate.
Do the reports prove every Railgun withdrawal was blocked?
No. They describe particular wallet, proof and gateway failures. One report explicitly says transact and unshield verdicts continued while shield verdicts stalled.
Is the Lending v2 decision changing?
No. We will not integrate Railgun. The decision concerns our operational requirements; it does not require treating disputed reports as established losses.