Security
How Senddy keeps your funds and data safe.
Architecture#
Senddy is designed as a non-custodial system. Your funds are held in smart contracts, not in a company bank account. No one at Senddy can spend from or read your balance. The pool's owner can pause the whole pool in an emergency, which stops activity for everyone until it resumes; it can't single out an account.
Smart contract security#
- Reviewed in internal security audits; open findings are tracked and fixed before launch
- Upgradeable and access-controlled — admin functions are restricted to the contract owner. There is no on-chain timelock; hardening the owner key is an operational control we track as an open item.
- Spend authorization — spending a note requires the recipient's own spend key, not just knowledge of the note's secrets
- Source-verified — the pool contracts are verified on each chain's explorer, so anyone can read the code that runs
- On-chain Merkle tip checks — spends must cite a root the pool already knows (
isKnownRoot), so a poisoned off-chain tree alone cannot invent a payable note
Zero-knowledge proofs#
- Proofs are generated on your device — no server ever sees your transaction details
- The proving system (UltraHonk) is based on well-studied cryptographic primitives and uses a universal trusted setup
- Circuits are written in Noir and have been reviewed for correctness
Attestor security#
- Runs in a hardware-isolated trusted execution environment (TEE) — isolated from the host, no persistent storage, no shell access
- Signing key managed by a hardware security module (HSM) with an enclave-restricted key policy
- The attestor can only verify proofs — it cannot access funds or user data
- Enclave measurements are publicly verifiable
Key management#
- Your spend key is derived from an EIP-712 signature and never leaves your device
- Your view key allows read access but cannot spend funds
- No seed phrases — keys are deterministically derived from your wallet signature
What data does Senddy collect?#
| Data | Stored? | Details |
|---|---|---|
| Email address | Optional | Only if you sign in with email |
| Username | Yes | Public, chosen by you |
| Transaction history | No | Encrypted on-chain, only you can decrypt |
| Balance | No | Computed client-side from encrypted notes |
| IP address | Temporarily | Standard server logs, not linked to activity |
| On-chain activity | No | ZK proofs ensure transaction details are hidden |
What risks exist?#
Smart contract risk#
If a critical vulnerability is found in the pool contract, funds could potentially be at risk. This risk is mitigated by internal security reviews, responsible disclosure, and the upgrade mechanism.
Attestor compromise#
If the attestor signing key or enclave is compromised, invalid proofs could be attested and funds remain at risk. The pool still enforces nullifier uniqueness, share accounting, and isKnownRoot against tips advanced in prior leaf-producing transactions — which stops a gateway-only tree poison from creating a newly known fake root, but does not fully protect against a compromised attestor.
Regulatory risk#
Privacy-preserving financial technology operates in an evolving regulatory landscape. Senddy takes a proactive, layered approach to compliance:
- Onchain screening — Every deposit is checked against a sanctions oracle by the pool contract, blocking sanctioned addresses before funds are accepted
- Offchain screening — Activity is risk-checked against industry blockchain intelligence before it's attested or relayed
- View key sharing — Users can grant read-only access to auditors without giving up control of funds
See Compliance for full details.
Report a vulnerability#
If you discover a security issue, report it privately first to:
security@senddy.com
We take all reports seriously and will work with you to resolve issues promptly.