eSend
Send funds to any email address, Interac-style. The recipient gets an email with a claim link and chooses where to receive it: the same asset, or another through an instant exchange (BTC, ETH, LTC, DOGE, SOL, BCH and more). Nothing leaves your wallet until they claim - and every release is signed by your own wallet (your U App, or a wallet you connect in the console), never by the platform.
How it works#
eSends are intent-based push payments on non-custodial rails. There are no contracts, no escrow addresses, and no platform keys anywhere: pay.u.cash coordinates (intents, emails, matching, fee ledger) while your own wallet is the only signer - your U App, or a wallet you connect in the console.
- Create the intent in your U App (or the console): recipient email, amount, asset, expiry, and a claim code the app generates
- Share the claim code with the recipient out of band (the app hands you copy / SMS / WhatsApp buttons) - the code never touches the server
- The recipient is emailed automatically a private claim link; they open it in any browser or in their own U App - no account needed, no gas, no crypto experience
- They enter the claim code and their wallet address (or tap "Use my U App wallet"); their browser turns the code into an unforgeable proof over the destination
- Your wallet completes the release: the U App verifies the proof and signs under your auto-release policy, or you approve it once in the console with a connected wallet; the recipient's page flips to delivered
- If nobody claims by expiry the intent simply expires - no funds ever moved, so there is nothing to refund
Direct sends. If the recipient has a U Account with saved wallets, your app offers to send straight to their wallet with one tap - the destination is displayed before you sign, and their receipt arrives by email. Recipients can opt out of wallet visibility in their account settings.
Security model#
The design rule: the platform can never cause a signature without either (a) a proof it cryptographically cannot forge, or (b) an explicit human approval showing the destination.
- Claim code binding. The code exists only on your device and the recipient's screen. Their client derives an HMAC-SHA256 proof over the destination from it; your app verifies before releasing. A compromised server sees the link, the database, everything - and still cannot redirect a coded transfer
- Codeless means taps. Console-created transfers have no code; each of their releases requires an explicit approval in your app with the full destination shown
- Zero keys server-side. pay.u.cash holds no crypto keys, signs nothing, broadcasts nothing; there is nothing to steal, audit, or rotate
- Device policy. Auto-release runs under a daily USD cap you control (with an optional tap-above threshold); funds sit in your own wallet until the moment of release
- Hash-at-rest links. Claim tokens are stored as hashes; a database dump alone yields no live claim URLs
Fees#
Recipients always receive the full amount; fees are charged to the sender's account only when a transfer is delivered. Network gas is paid by the sender's wallet as part of signing.
- Two-tier: 1% of the send up to $25, then a flat $0.25 - a $1 send costs one cent, a $100 send costs $0.25
- Free tier: verified U Accounts get 5 free delivered sends every month
- Nothing for nothing: expired, cancelled, and declined transfers never cost a fee
Assets and chains#
| Asset | Chain |
|---|---|
| USDC | Base |
| USDC / USDT | Polygon |
| USDC / USDT / ETH | Arbitrum |
| USDC / USDT / ETH | Optimism |
| USDC / USDT | Avalanche |
| USDC | Ink |
| USDT | BNB Chain (18-decimal BSC-USD) |
| ETH | Base |
| UCASH | Base (the UCASH omnichain token) |
| cbBTC | Base (Bitcoin is sent as cbBTC on Base; receiving as BTC pays out native BTC to a bc1 address) |
At claim time the recipient picks "receive as" the same asset, BTC, or ETH. BTC and ETH payouts settle through the U.CASH instant exchange rail - the provider pays true native BTC/ETH to the recipient's own address.
Waiting, offline senders, and retries#
Completion depends on the sender's device being reachable: the app picks up pending completions whenever it opens. If the sender's device is offline, the recipient's page says so, both sides get reminder emails, and the intent expires harmlessly if nothing happens. A sender whose wallet lacks balance at release time is prompted to top up; the transfer waits in a retryable state rather than failing. Three failed release attempts close the transfer as failed (nothing further leaves the wallet).
Cancel, decline, and reissue#
- Cancel any time before delivery - a plain status flip, because nothing was ever signed or sent
- The recipient can decline from the claim page; the link closes and the sender keeps their funds
- Reissue to a different email address generates a fresh claim link; in the U App the new link keeps the same claim-code binding
- An optional security code (4 or 8 digit PIN, or a 4+ character passphrase) gates the claim page's detail reveal; five wrong attempts start a 15-minute cooldown, three cooldowns lock the transfer until unlocked from the console