Wallet transfers usually expose a low-level identifier at the start of the user flow. The recipient finds a blockchain address, copies it, sends it through another channel, and the sender pastes it into the wallet. With multiple networks, the sender must also validate the network before signing.
DARCA treats this as an interface problem around an unchanged transaction primitive. When two users are nearby, Bluetooth can help the application discover a nearby DARCA profile. The sender can select that profile instead of manually exchanging an address.
The security boundary is important: Bluetooth is a discovery channel, not a value-transfer channel. No cryptocurrency, seed phrase, or private key is sent over Bluetooth. The nearby signal only helps the application identify a candidate recipient. The blockchain destination and transaction construction remain part of the wallet flow.
After selection, DARCA keeps the normal controls. The sender chooses the asset and amount, reviews the recipient, network, and fee, and confirms with a PIN or biometrics. The transaction is signed locally on the user's device and broadcast to the selected blockchain network.
This separates two operations that are often collapsed in the interface. First, the application resolves which human the sender means. Second, the wallet builds and signs a blockchain transaction. A successful discovery event must not be treated as transaction authorization.
The model also preserves the non-custodial boundary. The service does not receive the private key merely because a nearby profile was selected. The owner still authorizes the transaction locally. Bluetooth does not make the payment reversible, and it does not turn the transfer into an internal movement between DARCA accounts.
The remaining threat is user confirmation. A recognizable profile can reduce address-copying mistakes, but it cannot replace checking the asset, network, amount, and fee. A blockchain transaction remains final after confirmation.
The engineering change is therefore deliberately narrow: use proximity to resolve recipient intent, then use the existing local-signing and broadcast path. The address remains a technical requirement, but it no longer has to be the first thing two people exchange in person.
For engineers building wallet UX, where should the boundary sit between recipient discovery and transaction authorization?
Top comments (1)
I really like the separation between recipient discovery and transaction authorization. Using Bluetooth just to find the right person, while keeping signing completely local, feels like a much cleaner UX without pretending