CashDrop moves value through a single-use shielded envelope. The claim link carries the secret that opens it. This page lists what each party can learn, what can go wrong, and what we do about it. It is written for users and reviewers, not as marketing.
| PARTY | CAN LEARN | CANNOT LEARN |
|---|---|---|
| Public chain | That shielded transactions occurred | Sender, recipient, envelope address, amount, note, that it was a CashDrop |
| Sender | Amount, note, secret, that the envelope was emptied, roughly when | The recipient’s destination address |
| Recipient | Amount, note, secret, their own wallet | The sender’s wallet or its history |
| CashDrop server | Requests for static files, basic network metadata | The link, keys, seed, amount, note, address, transaction material |
| Messaging app | Who talked, when, that a link was sent. The link itself if the chat isn’t end-to-end encrypted, or via previews and backups | Anything on-chain, if the chat is properly encrypted |
Anyone holding the secret can spend the funds.
Mitigation: native share sheet first, warnings on every share path, take-back until claimed.
Chat services may fetch or scan shared links.
Mitigation: secret lives in the # fragment, which isn’t sent in HTTP requests. Lowers risk; doesn’t remove it.
Other apps and clipboard history can read copied links.
Mitigation: never copy silently. Copy sits behind an explicit warning.
The sender can take funds back before a claim confirms.
Mitigation: stated plainly everywhere. CashDrop is not escrow. Confirmations shown to both sides.
A compromised device can steal the link or destination.
Mitigation: outside our control. We minimise retention and clear state after claim.
A malicious deployment could exfiltrate keys.
Mitigation: reproducible builds, pinned static assets, no third-party code, signed desktop releases.
CashDrop is a hackathon prototype. It has not been audited and should not hold amounts you can’t afford to lose.