By Jonathan Pan · Wallet: 0xb75f2B6d02C5fab595446158645FB272eCdffD5A

• 1.8715 ETH stuck in Trust Wallet's Kiln staking integration

• Support ticket #2684399, opened via chatbot on May 13, 2026

• 6 unanswered follow-ups from me between May 25 and June 12, after Trust Wallet promised a "5-7 working days" update

• 52% opportunity cost — my ETH lost half its value while I waited

• $3,400 in mark-to-market loss between when I first tried to claim and when I finally self-rescued

• 1 signature on Etherscan, using Kiln's own official contract, to end it

None of this had to happen. Trust Wallet's own product was broken. Their own support team went silent. And in the end, the only party that actually solved my problem was me, calling a Kiln contract directly through a competing wallet.

Here's the full record — receipts included.

Over a year ago, I staked 1.86356603 ETH through Trust Wallet's "Trust Nodes" feature — which is a white-label wrapper around Kiln, an institutional-grade ETH staking service used by Trust Wallet, Ledger, Coinbase, Crypto.com, and others.

On October 31, 2025, I initiated a Request Exit. This burned my ocsETH position tokens and minted me a Kiln Exit Queue NFT (vEQ) — a debt receipt saying "Kiln owes you 1.8715 ETH once a cask arrives to fulfill your ticket."

Timing matters here. In September 2025, Kiln announced an infrastructure security incident and began an orderly exit of all its Ethereum validators. Withdrawal times ballooned. That's context — not an excuse. When my ticket finally became fulfillable, it should have been a routine claim. It wasn't.

When I tried to claim on May 19, 2026, both Trust Wallet clients failed:

Chrome Extension (v2.90.2 — the latest, verified against Chrome Web Store): The Earn > ETH page correctly showed Claimable: 1.8715 ETH. Tapping "Claim" opened the confirmation page displaying 1.871500027333535479 ETH (greyed out). But on the final "Confirm Claim" screen, the transaction amount displayed as:

Amount: 0.0048629589 ETH

Trust Wallet's Confirm Claim page. The Amount field shows 0.0048629589 ETH — my entire free ETH balance minus gas, not the 1.8715 ETH I was trying to claim.

Not 0 ETH (which would be the normal display for a contract call). Not 1.8715 ETH (the amount I was trying to claim). But 0.0048629589 ETH — which happened to equal my entire wallet's free ETH balance, minus the gas fee.

I didn't sign. Something was clearly wrong.

Android App (v8.70.1): Tapping Claim threw a bare An exception happened error and refused to load the staking detail page at all.

Two completely independent platforms, two different failure modes, one common denominator: Trust Wallet's Kiln claim integration. This was not a version issue. This was not a wallet-state issue. This was a code issue in Trust Wallet's product.

I opened support ticket #2684399 on May 19. Here's the actual sequence:

May 13 — Ticket #2684399 auto-created when I submitted a Bug Report through Trust Wallet's in-app chatbot. My original submission was already precise: category "Unable to Unstake/Frozen," device "Desktop, Windows 10," and a detailed description explicitly noting the "Confirm Claim page shows a significantly different amount: 0.0048629589 ETH." I also stated that Etherscan confirmed 1.87 ETH was NOT in my wallet.

Everything a support engineer would need to diagnose the issue was in the original ticket.

May 19 — I resent full details. Screenshots, transaction hashes, on-chain evidence, wallet version — the whole package.

May 19 — Support reply. This one is worth reading twice:

"Could you please confirm that you are unable to claim the claimable amount: 1.8715 ETH?"

That was the entire message. Six days after my original chatbot ticket, and immediately after I had sent a second full package of evidence, support asked me to confirm — the thing my ticket had said explicitly since day one. This is not engagement. This is a template.

I confirmed. Then things sped up briefly.

May 20 — Support reply (support@trustwallet.com, 17:56):

"We have reviewed your case and currently, 1.8715000273335354790 ETH is available as Claimable Amount. Given your current issue, it suggests that you may be using an outdated version of the app. Updating to the latest version is a necessary step for troubleshooting."

Support confirmed the exact amount was available on-chain — then suggested the fix was updating my app. I responded: I'm already on Chrome Extension v2.90.2, verified as the latest version on the Chrome Web Store, updated May 11, 2026. Both my extension and my mobile app fail differently. This is not a version issue.

May 22 — Support reply #2:

"This scenario could be fixed by re-importing your wallet. Please backup your secret phrase before you proceed to delete the wallet from the app."

The suggested fix — delete my wallet, re-import it — could not have addressed the problem. Re-importing clears local wallet state. My problem was not local wallet state. Two independent platforms had failed on the same underlying claim integration. That is a code-level issue, not a device-level one. Suggesting I delete my wallet to fix it was not just wrong; it introduced risk that a professional support process should never invite a user to take.

I responded again, this time with the exact function signatures from Kiln's own GitHub, the cask ID from the exit queue contract, and the specific parameters that should be passed to multiClaim. I asked four clear questions about whether this was a known integration bug, when it would be fixed, and whether they could confirm safe parameters for a direct Etherscan call.

May 23 — Support reply #3 (12:58). This is the one worth pausing on:

"We are going to work on it and will update you within 5-7 working days. This ticket will be opened until the problem is resolved."

That is a written commitment. Five to seven working days from May 23 puts the promised update on or before June 1.

Then it stops. Not "we need more time." Not "our IT team is still working on it." Not "we can't fix this." Silence.

I followed up. Six times. Here's the record:

• May 25: "awaiting your information, thanks"

• May 29: "any information update?"

• June 2: "pls let know any feedback on this? two weeks back and forwards already"

• June 4: "What is the progress on this issue? Why is there still no reply? If you are continuing to work hard on resolving this bug, you should at least let me know, or perhaps you have given up, right?"

• June 9: Same message, sent again.

• June 12: A full technical restatement of the issue with the ticket ID, resolve() output, cask ID 722, and both platform failure modes. I gave them everything they needed to route it correctly one more time.

Six follow-ups. Zero replies. The 5-to-7-working-day commitment came and went. The ticket that was "opened until the problem is resolved" was, in practice, ignored until the user gave up.

June 26 — I sent a final email, Subject: "Ticket #2684399 — Professional Courtesy Request." Not asking for a fix. Asking a simpler question:

Why has no one responded in over two weeks? If your IT team needs more time — say so. If you cannot fix the issue — say so. If you have decided this case is too complex — at minimum, tell me that. Silence is the only unacceptable answer.

I set a five-business-day deadline. I said I would escalate publicly if there was no substantive reply.

Deadline came and went. No reply.

I posted on X. Still no reply. As of writing, that ticket has been open for 50 days since Trust Wallet's own 5-to-7-working-day promise. No one has written another word.

While support was silent, I did what should have been unnecessary: I read Kiln's actual smart contract on Etherscan.

The Kiln Exit Queue contract at 0x8d6Fd650500f82c7D978a440348e5a9b886943bF exposes a resolve(ticketIds) function. According to the contract's own source, it returns either a positive cask ID (funds ready), or a negative error code:

• -1 = TICKET_ID_OUT_OF_BOUNDS

• -2 = TICKET_ALREADY_CLAIMED

• -3 = TICKET_PENDING

I called resolve([myTicketId]). It returned [722].

A positive cask ID. Not -2 (already claimed). Not -3 (pending). My funds were fulfillable, allocated to cask #722, waiting to be claimed.

I called ticket(id) for confirmation. It returned:

size:        1744624477822745885 wei  (1.7446 ETH, principal)
maxExitable: 1871500027333535479 wei  (1.8715 ETH, total claimable)

The exact same number Trust Wallet's UI had been showing me for weeks. The funds were real, they were mine, and they were ready.

Then I found Kiln's official ExitQueueClaimHelper contract at 0x8fe52F7FcE2eD6304aca6D45D5c993D5be06852A, verified source on Etherscan, exposing a multiClaim(address[] exitQueues, uint256[][] ticketIds, uint32[][] casksIds) function. Kiln's own docs describe this as the manual claim path for exactly this situation.

Everything I needed was public, on-chain, and documented. It took me a few hours of contract-reading to find. Trust Wallet's support team had two months.

Two things I want to flag before describing this.

First, I did not do this lightly. Kiln's own documentation says: "We recommend not doing this next part alone on Etherscan, please wait for the UI to be back online." That's sound advice for most users. But after 60+ days and no reply, "wait" was no longer an answer.

Second, Trust Wallet's own Chrome extension refused to connect to Etherscan (dapp.frames-disallowed error) and its Android app was still throwing exceptions. I could not sign this transaction with Trust Wallet even if I had wanted to.

So I did what I should not have needed to do: I installed Rabby Wallet (verified extension ID acmacodkjbdgmoleebolmdjonilkdbch, 800,000+ users, developed by rabby.io), imported the same 12-word seed phrase, and connected it to Etherscan's Write Contract interface.

Rabby's pre-signature transaction preview showed exactly what I expected:

• + 1.8715 ETH (≈ $3,089)

• − 1 Kiln Exit Queue NFT (burned as debt fulfilled)

• Target contract: 0x8fe52F...06852a (Kiln ExitQueueClaimHelper)

• Function: multiClaim

• Gas fee: $0.15

I signed. 30 seconds later, my wallet balance went from 0.005 ETH to 1.8764 ETH. The exit queue NFT was gone from my wallet. The debt was fulfilled.

Gas cost: $0.15. Time to execute: 30 seconds.

Sixty days of support "investigation" produced nothing. Fifteen cents and half a minute of my own execution produced the exact outcome I had been asking for.

This is where the specific numbers matter.

When I initiated my Request Exit on October 31, 2025, ETH was trading around $3,500. My 1.8715 ETH was worth approximately $6,550.

Today, July 2, 2026, ETH is trading around $1,650. My 1.8715 ETH is worth approximately $3,090.

Loss of value while my funds were trapped: ~$3,460. That's a 52% mark-to-market loss.

I'm not claiming Trust Wallet's team caused ETH to fall. That's the market. But here's the point: had the claim process worked as designed, I could have taken my ETH the moment my ticket became fulfillable, and made my own decision about whether to hold, sell, or reallocate. That decision was taken away from me for 60+ of the most volatile days of the cycle, by a support process that never actually engaged with the problem.

The 52% is not on Trust Wallet's balance sheet. It is on mine. That's exactly the issue.

I'm not going to tell anyone what wallet to use. That's a personal decision based on threat model, use case, and preference. But I do think the last 60 days raised three questions worth asking about any self-custody wallet you're trusting with meaningful assets:

1. Does the support team engage with the actual technical problem, and does it honor its own commitments? Three of Trust Wallet's first replies were "update your app," "re-import your wallet," or requests for information I had already provided. None engaged with the on-chain evidence I supplied. When they finally committed in writing to a 5-to-7-working-day update, they missed that window by over a month — and never sent another word. If a vendor won't answer its own written SLA, what happens when your problem is genuinely urgent?

2. Does the product cross-check its own UI against on-chain state? The Confirm Claim page showing 0.0048629589 ETH — which just happens to equal my wallet's free balance minus gas — is not a random glitch. It's a UI that's not reading the actual claim amount from the contract. A wallet that transacts on-chain should verify what it's about to sign against on-chain state. Mine didn't.

3. What is your escape hatch when the wallet's UI fails? This is the one I care about most now. If your wallet's integration with a third-party protocol breaks, and your support team can't or won't fix it, do you know how to interact with the underlying contract directly? For 90%+ of users, the honest answer is "no." That is a fair choice — but it means you're depending entirely on your wallet vendor's competence and responsiveness. Ask yourself if the vendor has earned that trust.

I've moved my day-to-day signing to Rabby. Not as a recommendation — Rabby has its own tradeoffs — but because the specific feature I needed on day one (a pre-signature transaction simulation showing exactly what will change in my wallet) exists there and doesn't in Trust Wallet.

I still have the Trust Wallet extension installed, disabled. My seed phrase works everywhere it always did. And I now know exactly how to talk to Kiln's contract without any wallet's help at all.

That last one is the actual lesson. The wallet is a client. The blockchain is the source of truth. When those two disagree, believe the blockchain. When your wallet vendor's support goes silent for weeks, remember that you never needed their permission to spend your own funds. They were only ever an interface.

Trust Wallet built a bad interface, staffed a support process that didn't investigate, and stayed silent when a user handed them the exact bug on a plate. I lost 60 days and $3,400 in opportunity cost finding that out.

Ticket #2684399 is still open, as far as I know. If Trust Wallet's team is reading this: I don't need a reply anymore. I already claimed my ETH.

But maybe fix the bug for the next user.

Full evidence: All transaction hashes, contract addresses, and screenshots are on-chain and verifiable. My wallet address at the top of this piece is public — audit anything I've claimed.

Jonathan Pan is the founder of DaTong AI LLC , building AI voice ordering agents for restaurants. This is his first public writing on a Web3 experience.