We never ask for a seed phrase
There is no field anywhere in Droppy that accepts a private key or recovery phrase. Any site or person asking for yours is trying to rob you.
Security
What we protect, and how
Droppy is non-custodial payment software. It never holds your funds and never sees a key. What it does hold is the record of what was paid — so the honest question is how that record is protected, and how it is proven.
First principles
Three things that are always true
We never hold your funds
Payments move directly from your customer's wallet to yours. Droppy is not a custodian and cannot move, freeze or reverse a payment.
We never trust the browser
Payment status comes from a server-side read of the chain. Nothing a page script claims can mark a payment paid.
Authentication
Sign-In With Ethereum, done strictly
- Challenge
- The server issues a single-use nonce with a ten-minute expiry, recorded in the database. Consuming it is an atomic update, so two requests can never spend the same nonce.
- Signature
- Your wallet signs an EIP-4361 message. It is plain text, not a transaction — it cannot transfer anything.
- Validation
- The server checks the domain, origin, statement, chain id, issue and expiry timestamps, and the nonce before it even looks at the signature. A signature harvested from another site will not pass.
- Contract wallets
- Verification runs through a public client, so ERC-1271 smart-contract wallet signatures validate as well as ordinary EOA ones.
- Session
- A signed JWT in an HttpOnly, SameSite=Lax, Secure cookie. Page scripts cannot read it, and it cannot be forged without the server key.
Authorization
Never trust the connected address
A connected wallet is a claim, not proof. Every merchant endpoint derives the acting address from the signed session and ignores whatever the request body says.
- Listing payments
- Returns only links whose merchant is the session address.
- Creating a link
- The receiving address is set from the session. A merchantAddress in the body is ignored, so nobody can point a link at another wallet or plant one on another dashboard.
- Merchant profile
- Reads and writes only the session address's own record, whatever address the body carries.
- Tested, not asserted
- The end-to-end suite signs in as a second wallet and proves it can neither see nor modify the first one's data.
Settlement integrity
Money-safety invariants
Idempotent verification
Verifying the same transaction repeatedly converges on one stored result. Re-checks update the confirmation count but never rewrite the original settlement time.
No duplicate settlement
A hash already recorded against a link is refused for any other, enforced by an application check, a row-locking transaction, and a unique index on the hash in PostgreSQL.
Exact amounts
Amounts are stored as exact base units, never floats. An amount too precise for the asset is rejected rather than silently rounded, so the figure shown always equals the figure demanded.
Recipient and chain bound
A payment only counts if it reached this link's address, in this link's asset, on this link's chain. Everything else is a failure with a reason.
Platform
Application and infrastructure hardening
- Rate limiting
- Fixed-window counters stored in the database, so limits hold across every server instance. Public endpoints return 429 with Retry-After when a caller is over budget.
- Input validation
- Every input is validated server-side regardless of client checks: addresses, amount format and precision, link lifetime, and the chain and asset against our own configuration. Text fields are stripped of control characters and length-capped.
- Secret handling
- RPC keys, the session signing key and the database URL are read only in server-only modules and never carry a public prefix, so they cannot reach the browser bundle. The test suite asserts they do not appear in served HTML.
- Transport and headers
- HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict Referrer-Policy and a restrictive Permissions-Policy on every response.
- Dependencies
- Deploys are blocked on known-vulnerable framework versions rather than waved through, and the block is fixed by upgrading, never bypassed.
Honest limits
What we do not claim
- Droppy has not had a third-party security audit. The protections above are real and tested, but they are our own tests.
- One merchant equals one wallet. There are no teams, roles or API keys yet, so anyone who controls your wallet controls your Droppy account.
- Blockchain payments are irreversible. If your customer sends on the wrong network or to the wrong address, no one — including us — can recover those funds.
- We depend on public RPC infrastructure to read the chain. If it is unavailable, verification is delayed; it never guesses.
Questions about the security model?
We would rather answer them before you take your first payment than after.