Open any DM in Sudo, type /pay 50 USDC to nova.sudo, hit return. Your wallet pops up a confirmation, you tap "Sign", and three seconds later nova.sudo has 50 USDC in their wallet on whichever chain they prefer to receive on. They get a chat card showing the transaction hash and a confirmation count that ticks up live. You can edit the message to add a note, react to it, or escrow the same amount with a single follow-up command. None of those interactions ever leave the conversation.
Inline payments are the headline feature most people see in Sudo demos, and they are the feature it took us longest to ship. This post is about why — and about the plumbing underneath that turns a single chat command into a polished multi-chain transfer.
The UX problem we set out to solve
Crypto payments are a strange product. The settlement layer is faster, cheaper and more global than anything in traditional finance, and yet the user experience for "send fifty dollars to a friend" is consistently worse than Venmo. The friction is not on the chain. The friction is in everything around the chain: copying addresses, switching networks, opening separate apps, waiting for a token to bridge, calculating gas in a foreign denomination, hoping you typed the destination correctly.
The product question we asked was: what would it take to make a crypto payment feel exactly like sending a Venmo or a UPI transfer? Same number of taps, same confidence in delivery, same instant confirmation in the conversation. We answered it with four pieces of plumbing — name resolution, gas abstraction, cross-chain routing, and the recovery window — and we want to walk through each.
Name resolution: the killer of the copy-paste workflow
The first piece of friction in any crypto payment is the address. 42 characters of hex, indistinguishable from a Bitcoin address or a contract or random noise. The .sudo registry exists, in part, to delete this problem.
When you type nova.sudo in a payment command, the Sudo client resolves it through the on-chain registry to the controlling wallet, then asks the recipient's profile contract which chain and token they prefer to receive in. If you typed 50 USDC and Nova's profile says "I prefer USDC on Base", the payment routes there. If you typed an amount in dollars, we look up the local rate at submission time and quote you the token amount before you sign.
If a name does not resolve, we never let you "try anyway". The command refuses to submit. The number of incidents that single check has prevented is too large to fit on a chart.
For interoperability, we resolve every input through the same pipeline: .sudo names, .eth names, raw hex addresses, EIP-681 payment URIs and (in the next release) UPI-style aliases that Indian banks expose. The user interface is the same in every case: type a thing that identifies the recipient, see a green check next to a human-readable name, hit send.
Gas abstraction with ERC-4337
The second friction is gas. In a Web2 product, the platform pays the platform's costs. In a Web3 product, the user pays for the platform's costs in a token they may not even hold. If you want to send 50 USDC to your friend on Base and you do not have any ETH on Base, the payment fails until you bridge ETH, which requires another wallet, another app, another fee. By the time you are done you have ragequit and used Venmo.
ERC-4337 — account abstraction — fixes this at the protocol level. Sudo's wallet integration treats every supported wallet as if it were a smart account, regardless of whether it actually is. When you sign a payment, the client constructs an ERC-4337 user operation that has a paymaster field set to a Sudo-operated paymaster contract. The paymaster pays the gas in the network's native token and charges you a small premium in whatever token you actually hold.
In practice, this means you can pay for an entire month of Sudo activity in USDC on Base without ever touching an ETH balance. Hardware wallets work the same way. The gas abstraction is invisible — you sign a single intent that says "I authorise this transfer", the paymaster handles the protocol-level details, and your message card shows up in the conversation a second later.
We charge a flat 0.5% on top of the network gas cost, which goes to the validator network. There is no per-transaction account fee.
Cross-chain routing without bridges
The third friction is networks. The crypto stack has settled on a small number of chains for stablecoin payments — Base, Ethereum mainnet, Arbitrum, Optimism, Polygon, Solana — and a handful of CEX-issued bridges between them. Choosing the right chain is a non-trivial decision your grandmother should not have to make.
Sudo's payment router treats the chain as an implementation detail. You and your recipient each have a "preferred receive lane" — say, USDC on Base for one of you and USDC on Arbitrum for the other. When you submit a payment, the router compares lanes, picks the cheapest cross-chain route, and either sends directly (if the lanes match) or routes through a CCTP-style burn-and-mint bridge (if they don't). Solana payments use Wormhole's noble integration. The router quotes you the all-in cost up front; if you sign, it commits.
If a bridge fails — and they sometimes do — the payment is automatically retried on a different route. If every route fails, the payment refunds to your sending wallet within an hour and a chat card explains why. Failure cases are surfaced inside the conversation, never hidden in a separate transactions screen.
Mistakes and the recovery window
The fourth friction is the everyday consequence of irreversible payments: if you typo your message, you can edit it. If you typo your payment, the money is gone forever. That asymmetry is bad UX and it makes people cautious in unhealthy ways.
The Sudo client introduces a small "recovery window" for in-chat payments under a configurable threshold (default $50). When you send under that threshold, the funds land in a one-sided escrow contract first. The recipient sees the message and can claim the payment with a single tap, which executes the transfer. If you were wrong — wrong recipient, wrong amount, wrong currency — you can cancel the payment within sixty seconds before the recipient claims, and the money returns to your wallet untouched.
Above the threshold, the recovery window does not apply because the gas overhead is no longer trivial relative to the payment size. Above the threshold we recommend escrow with milestones, which is the next slash command in the Sudo CLI grammar (/escrow).
What is on the way
We are working on three improvements to the payment flow this quarter.
First, recurring payments. Subscribe to creator.sudo for 5 USDC a month with a single signature; the recurring authorisation is bound to a per-recipient cap and revocable at any time without a transaction.
Second, conditional payments. Pay 200 USDC to a contractor that releases when an oracle reports the work was delivered, a wrapper around our existing escrow primitive that requires zero on-chain knowledge from the buyer.
Third, payment intents that publish to a public board. If you want to pay any developer on the network 50 USDC to fix a small bug, you broadcast an intent and the first qualified developer to claim it earns the payment on completion. Quests and bounties become a primitive of the messenger itself, not a separate product.
The thread that ties all of these together is simple: the conversation is the surface. The chain is the implementation detail. We will keep deleting friction until sending crypto feels like sending a sentence.