QuickSend and Shake-to-Send: Building a Social UX for Crypto Transfers

As developers, we’re constantly pushing to reduce friction in crypto UX. Traditional wallets and address-based transfers scare off newcomers with irreversible mistakes and cryptic hashes. So when I discovered how WhiteBIT implemented QuickSend and Shake-to-Send, I was intrigued—not just from a product standpoint, but from an architectural one.

In this article, I’ll break down what these features offer, what they likely look like under the hood, and how hard (or surprisingly doable) it might be to implement similar systems in your own crypto project.

What Is QuickSend?

At its core, QuickSend allows you to send crypto using nothing but a user’s nickname—no wallet address, no QR codes, no middle steps. Think Venmo or Cash App, but for blockchain.

The transaction goes straight to the recipient’s main balance within the exchange. There’s also a chat thread associated with each transfer, giving it a social layer—messages, transaction history, and reusability.

Even better? There are zero fees.

Enter Shake-to-Send

This is where things get spicy. On mobile, WhiteBIT introduces a proximity-based feature: Shake-to-Send.

Here’s the idea:

• Open the app, shake your phone.
• If someone else is doing the same nearby (within 30 meters), the app detects them.
• Select the user, pick your asset and amount, and boom—instant transfer.

This isn't just UX candy. It’s a mini-protocol combining Bluetooth, proximity awareness, user validation, and secure transaction logic. WhiteBIT is (reportedly) the first exchange to launch this for crypto.

How It Might Work (Backend + Frontend Breakdown)

As a full-stack dev, here’s how I’d approach building something like this:

1. Username-Based Transfers (QuickSend)

Frontend:

• Basic form for amount, asset, and recipient nickname.
• Message field (optional).
• Transfer confirmation modals and chat UI for threads.

Backend:

• Username resolution → internal account ID
• Pre-transfer validation (KYC, balance check, limits)
• Atomic DB operation: transfer from user A to user B
• Logging transaction with metadata (message, timestamp, chat thread ID)

Database Models:

Users(id, nickname, balance, ...)
Transfers(id, from_user, to_user, asset, amount, message, timestamp)
Chats(id, user_a, user_b)
Messages(id, chat_id, sender_id, text, timestamp)

2. Proximity-Based Detection (Shake-to-Send)

Frontend (Mobile Only):

• Shake detection via accelerometer API
• Proximity scan using Bluetooth Low Energy (BLE)
• Device discovery, ephemeral identity exchange
• UI for selecting nearby users and sending funds

Backend:

• Temporary session mapping BLE IDs to account IDs
• Secure pairing and permission confirmation
• Short-lived token or handshake to allow single transfer

Challenges:

• BLE accuracy and spoof resistance
• Privacy and security: users must verify before sending
• Session expiry and race condition handling (i.e. two users shaking at once)

Security Considerations

• Rate Limiting: Prevent spam or abuse of proximity detection
• Encryption: BLE session handshake must be secure (use ephemeral keys)
• Message Signing: Transfer requests should be signed by the sender
• Audit Trail: Every transfer must be traceable and logged server-side

How Hard Is It to Build?

QuickSend: Medium complexity. Once usernames are part of your system, mapping them to internal IDs and automating transfers is straightforward. The messaging layer adds a social twist, but it’s mostly about good schema design.

Shake-to-Send: High complexity. You need native mobile SDKs, BLE integration, proximity session handling, and tight security protocols. However, it’s also what makes your app feel like the future.

So,

QuickSend and Shake-to-Send are perfect examples of user-first crypto UX. They lower barriers, mimic familiar financial tools, and—most importantly—build social habits around decentralized finance.

If you’re building a Web3 app or exchange, these features aren’t just gimmicks. They’re tools for growth, retention, and usability.

So, should your team add this? If your users trade frequently and your app’s architecture can support fast internal transfers—absolutely.