[ SECURITY ]
Trust boundaries,
stated plainly.
This page exists to describe what Lockey protects and what it does not. It makes no audit, uptime or adoption claims, because there are none to make.
Trust boundaries
Each row states what is meant to stay inside the boundary and what leaves it.
Wallet and spending keys
Signing stays with the user’s wallet. Spending keys and Zcash spending keys never leave it.
No Lockey service, browser automation session or cloud browser is ever given a spending key.
Private state
Balances and transfer details are held in private state and proven rather than published.
Deposit and withdrawal events are public by construction, along with their amounts.
Proof generation
Proofs are intended to demonstrate a valid transition without revealing the private inputs.
Where proving runs — locally or delegated — determines who sees the witness. This is not settled.
Agent execution
Policy, redaction and settlement authority stay on the Lockey side of the boundary.
The external web adapter sees only what a policy allows it to see. It is treated as untrusted.
Network and transport
Request shaping: range fetches and local filtering, so a provider cannot tell from your requests what you hold.
IP address, device fingerprint and timing are all still visible. This is not anonymity.
Two different problems
A proof can hide an amount. It cannot hide that your laptop asked a server for something at 14:03.
Transaction privacy
Amounts, balances and internal counterparties.
Commitments, nullifiers and zero-knowledge proofs.
Implemented and tested against real proofs.
Network metadata privacy
Who is asking, from where, when, and how often.
Transport choice, request shaping, infrastructure.
Partially mitigated. Not solved, and not anonymity.
What request shaping buys: an RPC provider cannot tell from your request pattern how much you hold — the number and shape of requests follow chain length, which is public. What it does not buy: your IP address, your device fingerprint, and the timing of your first request are all still exposed. Lockey does not provide network anonymity and does not claim to.
[ KNOWN LIMITATIONS ]
What Lockey
does not do.
Limitations are published in the same place as the design, not buried in a disclosure page.
- No external audit has been performed. An internal adversarial review exists; it is not the same thing.
- Contracts and circuits exist but are dev-only: the proving keys come from a single-contributor setup whose entropy is published in the repository, so anyone can forge proofs against them. Nothing is deployed to any network.
- Onchain privacy is bounded by the anonymity set. A small set makes deposits and withdrawals linkable by amount and timing regardless of cryptography.
- Wrapped or bridged assets do not inherit the privacy properties of their origin chain. Wrapped ZEC on an EVM is not shielded ZEC.
- Lockey does not run Zcash consensus. It borrows design principles — shielded-by-default UX, separated viewing and spending authority, selective disclosure.
- Network metadata is only partially mitigated: request shaping hides what you hold from an RPC provider, but your IP address, device fingerprint and timing remain exposed.
- Compliance behaviour, if any, is undecided and is not implemented.
What blocks release
Three conditions, none of which more testing can resolve.
No trusted setup ceremony
The proving keys come from a single contributor whose entropy is published in the repository. Anyone can forge proofs against them. This cannot be fixed by testing.
No external review
Every test was written by the same process that wrote the code. Under-constrained circuits are the highest-likelihood catastrophic bug class here, and self-review is structurally weak against exactly that.
Single-address authority
The asset registry is owned by one address. A multisig behind the timelock is required before value is held.
An internal adversarial review was completed: contract access control, root history, double spend, circuit under-constraint, cross-asset conservation, view-key separation, disclosure scope, agent exfiltration and policy bypass. It found three issues, which were fixed, and the three blockers above, which cannot be. A green test suite is not a security result.
Reporting
There is no deployed system to report against yet, and no security contact has been published. When one exists it will be listed here and on the Status page — not announced as a capability before it is real.
Build status →