A platform's deposit dashboard records the deposits that worked. Every completed transfer leaves a row: amount, asset, chain, timestamp, user. A user who opened the funding screen, saw a 42-character address and a network picker, and closed the tab leaves nothing.
So the deposit problem gets measured by the one artefact it never produces. Teams read their own numbers, conclude that users do not fund with stablecoin and crypto very often, and move engineering effort elsewhere. That conclusion comes only from the users who succeeded.
Why does a failed crypto deposit leave no record?
A declined card payment is an event inside the payments system: an authorisation request, a response code, an issuer, a retry. The platform owns the whole record. That is why card teams can measure approval rates precisely.
A stablecoin deposit fails outside the platform's view, and it fails in several different ways.
- The user never starts. They open the funding screen, see an address and a chain selector, and leave. No transaction exists, so nothing is logged beyond a page view.
- The asset is wrong. Funds leave the wallet and never arrive as a credit. Your record of this is a support ticket.
- The chain is wrong. The same thing happens, and recovery may not be possible at all.
- The user has no gas. The transfer cannot be signed, because paying for it requires a third asset the user does not hold.
- The amount is below a minimum. The transfer succeeds on-chain and still does not become a balance. It sits pending, invisible from both directions.
- The address was poisoned or mistyped. The funds are lost, not declined.
Only the first is abandonment in the conventional sense. The other five are completed blockchain transactions that failed as deposits. On-chain success and product success are not the same event.
Users are overwhelmed. Asset, chain, gas, minimum, address: five decisions, all irreversible, all made at the moment someone is trying to give you money. Five of the six failures are those decisions going wrong. The sixth is the user looking at them and deciding not to try. These users are not indifferent to funding. They are being asked to get five things right in a row, with no way to check their work first.
Most of those users already know the alternative. WalletConnect is the connection standard 700+ wallets already ship, reaching 900M+ users, with $400B+ moved across the network in 2025 and $207B+ in the first half of 2026. Connect and approve is the interaction they have already completed on the last several apps they opened. Most of this piece is about measuring the failure honestly, because most platforms cannot yet avoid it. The alternative is to stop asking the five questions.
How this distorts your own numbers
Deposit success rate is a ratio of credited deposits to the deposits your system saw. None of the six failures above reliably enters either side of it, so the number can improve while the problem does not. Keep the list. Every item on it is answered below.
What does a platform's own help centre tell you?
Public documentation is the closest thing this category has to primary evidence, and Polymarket publishes more of it than its peers. Funding is crypto-only. Deposit addresses are fixed per network. Minimums are enforced per chain, at $20 on Ethereum and $3 on Solana. Transactions sent to the wrong chain or address cannot be reversed.
The measurement point is what comes next. Polymarket runs a dedicated on-chain recovery tool, with documented routes per chain, support-assisted handling for four more networks, and a list of what cannot be recovered at all. On Ethereum, the user has to send gas to a specified address before their own funds can be returned.
Where the cost actually lands
A recovery portal, the gas to fund it and a support path behind it are not built for an edge case. The failure is already being paid for, in support load and engineering time, under a line item nobody calls deposit conversion. Polymarket documents this. Most platforms publish neither a minimum nor a recovery route, and that silence does not mean the problem is smaller.
Is there published data on crypto deposit conversion?
No. The reason is structural. Nothing is published, by any platform or any independent source:
- No deposit conversion or drop-off rate
- No KYC abandonment rate
- No deposit-to-first-trade lag
- No share of deposits arriving in the asset the platform settles in
Card networks can publish approval rates because a decline happens inside a system one party owns end to end. An address-based deposit has no such party. The wallet knows what the user signed. The chain knows what settled. The platform knows what arrived. None of them holds the step where it went wrong. Nobody is withholding the number. Nothing generates it.
How does WalletConnect remove these failures instead of recovering from them?
Every item on that list is a decision handed to the user at the worst moment. WalletConnect does not detect these failures faster or recover from them better. It stops handing the decisions over.
This works because the connection already exists on both sides. The platform integrates once. The user does nothing new, because the wallet they would fund from already ships the standard. There is no new account to link and nothing to install.
Every row works the same way. The variable the user could get wrong is removed from the flow. The failure does not become easier to measure. It stops happening.
What can you finally see?
Removing the failures fixes the funnel, but it does not tell you what your funding path is doing.
That takes a connection, and this funding path already runs on one. The deposit is a live session rather than a copied address, so WalletConnect's Reporting covers sessions, funding, drop-offs, and wallet and chain behaviour. It shows the sessions that started, where they stopped, and which wallets and chains those users were on, rather than only the deposits that completed.
You cannot report on a drop-off that happened in a wallet you have no connection to. That is why an address-based path cannot produce this data and a connected one can.
What should you measure before you get there?
If you run an address-based funding path today, the failure still leaves no record. Instrument the surfaces that do.
- Funding screen opens against completed deposits. Crude, but it is the only abandonment proxy you fully own.
- Support tickets tagged wrong chain, wrong asset or missing deposit, as a rate against completed deposits rather than a count.
- Pending sub-minimum balances. These are failed deposits you can already see.
- First deposit to second deposit rate. A user who loses funds once tends not to try again.
- Share of deposits arriving in the asset you settle in. That ratio is your asset mismatch, measured on your own users.
None of those is deposit conversion. They approximate what you cannot measure directly, and they are enough to show whether it is improving.
Users will fund. The record a platform keeps only covers the ones who managed it. Both halves are fixable: remove the decisions that break the transfer, then instrument what is left.
Why do crypto deposits fail more often than card payments?
They fail differently, and the difference is where. A card decline is generated inside the payments system and arrives with a response code you can count. A crypto deposit is initiated in the user's wallet, so the common failures happen outside your view: wrong asset, wrong network, no gas, or an amount below an enforced minimum. In that last case the transfer succeeds on-chain and still never becomes a balance. Several of these are successful blockchain transactions, which is why they never appear in a failure metric.
What is a payment intent, and how does it stop a deposit failing?
A payment intent fixes the exact asset, chain and amount before the user signs anything. Those values are set rather than chosen at the moment of transfer, so the wrong-asset, wrong-chain and below-minimum failures cannot occur. There is no field in which the user can supply a wrong value. The failure is removed rather than detected afterwards.
Can we get visibility into deposits that do not complete?
Yes, once the funding path runs through a connected session rather than a copied address. Reporting covers sessions, funding, drop-offs, and wallet and chain behaviour, so a journey that stopped partway becomes a recorded event. An address-based flow cannot produce that data, because nothing about the abandoned attempt ever touches your systems.
Does accepting deposits from 700+ wallets mean maintaining every chain?
No. One integration covers the wallet network and all major blockchains, and new chains are added without you re-integrating. Smart routing handles the gap between what the user holds and what you settle in, so you configure the receive token once instead of maintaining a matrix of assets and networks.
Do users have to hold the asset our platform settles in, or a gas token?
Neither. Users fund with any asset on any chain, and smart routing delivers the token you configured. Gas is sponsored, so the user does not need a separate network token to complete the transfer. Those two together account for a large share of the failures in an address-based flow.
What compliance data arrives with a stablecoin deposit?
Two controls run inside the funding flow itself. Sanctions & IP screening screens wallets and users against OFAC and global sanctions lists, and blocks restricted-region IPs before a payment clears. Configurable Travel Rule capture collects required Travel Rule data, customisable to your compliance requirements. Both arrive in the formats your existing controls already read, so there is no parallel compliance system to stand up beside the funding path. Where you need proof that the funding wallet belongs to the user, Wallet Verification runs on the same flow and produces a reusable, audit-ready record rather than a per-transaction check.