Reach
Remittance should work like texting: type an email, send money."
Demo
About
Reach is a stablecoin remittance app, you pick an amount, type the receiver's email, hit send. There's no wallet address to copy, no seed phrase to back up, and no separate step to buy gas before you can transact Logging in with email creates a real wallet through Privy in the background the user never sees it as a "wallet" at all. you can send to an email that's never touched Reach before. The backend resolves that email through Privy and, if it's genuinely new, pregenerates a real wallet for it right then so funds are already sitting there waiting the first time that person ever logs in. The receiver gets a push notification the moment funds land, and a full transaction history that merges both Reach-routed sends and plain wallet deposits into one view.
How it's made
The contract (Reach.sol, Solidity, Foundry, 30 tests) is a single-transaction payment router deployed and verified on Arc testnet: it pulls the sender's chosen token (USDC or EURC, admin-managed allowlist) and forwards net-of-fee straight to the receiver, with no escrow or claim step. The frontend is a Next.js 16 PWA using Privy for embedded-wallet auth and wagmi/viem for the send transaction, with contract reverts decoded into plain-language errors instead of raw selectors. The backend is Express + SQLite: it indexes the contract's events, resolves emails to wallet addresses via Privy (including pregenerating wallets for brand-new recipients), and sends web-push notifications. The trickiest problem was that Arc's USDC is the native gas token, so its ERC20 Transfer log effectively covers every transaction on the chain scanning it directly to catch plain wallet deposits blew straight through the RPC's per-query result cap. Deposits are instead synced per-address, on demand, from Arc's block explorer API, which already indexes both native sends and ERC20 transfers under one address-scoped endpoint. I also turned off Privy's own confirmation modal (showWalletUIs: false) since the app already has its own Confirm step showing two separate "please confirm" popups for one send was pure friction, not an extra security boundary.