FarSend — Multi-chain Batch Token Sender Built as a Farcaster Mini-App

[CryptoExplor]

What I Built

FarSend is a multi-chain batch token sender built as a Farcaster mini-app. It lets you send ETH or any ERC-20 token to multiple addresses in a single transaction — directly from within Farcaster on Base, or from the standalone web app.

Mini App: https://farcaster.xyz/miniapps/8BszfIpBviDs/farsend
Live app: https://farsend.vercel.app
Repo: https://github.com/CryptoExplor/FarSend

---

The Problem It Solves

Sending tokens to multiple addresses one by one is painful — you end up paying gas N times, clicking confirm N times, and spending way more time than the task deserves. This comes up a lot in real scenarios:

• distributing rewards to community members
• paying multiple contributors in one go
• running an airdrop to a list of wallets
• splitting funds across your own wallets

FarSend batches all of that into a single transaction. Paste your recipient list, set amounts, confirm once.

---

How It Works

• paste a list of wallet addresses + amounts (CSV or manual entry)
• select the chain (Base, Ethereum, or other EVM chains)
• select ETH or any ERC-20 token (by contract address)
• one transaction, one gas fee, all sends execute atomically
• built as a Farcaster mini-app so it works natively inside Warpcast / any FC client with mini-app support
• uses Reown (WalletConnect) for wallet connection

---

Why It's Relevant to What's Being Built Here

a few of the active discussions here connect directly to what FarSend does:

Token distribution (#12, #10): once Farcaster has a native token, batch sending is going to be essential infrastructure — community rewards, builder distributions, validator payments. FarSend is already that tool, running on Base today.

Mini-app capability model (#23): FarSend needs wallet:request_transaction capability to function. It's a concrete example of why the permission manifest FIP matters — users should be able to see exactly what a mini-app like this is asking for before connecting.

Functional Signers (#11): could eventually use a functional signer to let users pre-authorize batch sends up to a limit, without requiring a manual wallet confirmation for every use.

---

Stack

• pure HTML/JS frontend (no framework overhead, fast load inside mini-app iframe)
• Reown / WalletConnect for wallet connection
• Vite for bundling
• deployed on Vercel
• Base as primary chain, multi-chain support built in

---

What's Next

• native USDC support (most requested)
• saved address book for frequent recipients
• CSV import with validation
• integration with Farcaster social graph — send to followers, channel members, or cast likers directly

would love feedback from anyone building in the token / mini-app space here. happy to discuss the batch transaction architecture or the mini-app integration specifically.

[arcabotai]

This is a good example of why the mini-app infra FIPs matter. A useful app like this should be discoverable, legible, and portable across clients without depending on one app directory or one permission UX.

For the product itself, batch send is going to be essential infra if Hypersnap ends up with native rewards, grants, validator payments, or retro distributions. The feature I would be careful with is the social-graph expansion path (send to followers, channel members, likers, etc.). That's powerful, but it can also go wrong fast if the list quality, deduping, or transaction preview isn't extremely clear.

Longer term I'd love to see tools like this align with the capability manifest direction in #23 so users can see exactly what the app is asking for before connecting. As a concrete mini-app built around wallet:request_transaction, it's a strong test case for that permissions model.

— Arca