Privacy Policy
What Fuga Labs processes, why, where it is held, how long it is kept, and the parts of the architecture that mean there is less of it than you might expect.
1. The short version
Fuga Labs is a security platform that mostly reads public blockchain data. Public chain data is not personal data in itself. The personal data we do process is small and administrative: who at your organisation has an account, who took which action in the console, and who to contact during an incident.
2. Our role
For account and console data, Fuga Labs is the controller. For subject data you configure us to monitor and for signed off-chain feeds you publish to us, Fuga Labs is a processor acting on your instructions. [Counsel: confirm controller/processor split per jurisdiction and attach the processing terms.]
3. What we process
Account and identity for the people you authorise, operational telemetry so the service can be run, the addresses and contracts you ask us to monitor, whatever signed off-chain events you choose to publish, and the audit record of every decision the platform made.
- account name and work email
- role and capability scopes
- OIDC subject where your IdP is the source of identity
- session token (HttpOnly cookie)
- IP and user agent in access logs
- monitored addresses and contracts
- signed off-chain events you publish
- every screening, verdict and action taken
4. What we do not process
No private keys, no seed phrases, no custody of funds, no wallet connection required to use the console, no advertising identifiers, no third-party trackers, and no cross-site tracking of any kind. The site sets exactly one cookie and it is a session cookie.
5. Cookies
One session cookie, set only after you sign in, marked HttpOnly and SameSite=Lax, and Secure in production. It holds an opaque session id and nothing else. There is no analytics, advertising or preference cookie, so there is no consent banner. That is not a dark pattern; there is simply nothing to consent to.
- HttpOnly
- SameSite=Lax
- Secure (production)
- opaque session id
6. Retention
Retention is a published posture rather than a promise, and it is queryable at /v1/retention. Operational caches serve the dashboard and the replay window; they are not the record of what happened. The response audit log is never purged, and that is expressed in the code as an explicit value rather than an omission, because an audit log with a quiet expiry is not an audit log.
- operational caches: 7 days
- delivered alerts: 30 days
- pending and dead-lettered alerts: kept until resolved
- response audit log: never purged
7. Where it is processed
Data residency is pinned per tenant and enforced at the API boundary on every authenticated request. If your tenant has no pin, onboarding tells you so out loud rather than leaving an unenforced residency commitment in a contract. [Counsel: list the regions offered and the transfer mechanism for each.]
8. Isolation between customers
Tenant data is never shared between tenants. The per-tenant view is constructed per request rather than filtered out of a global object, so a cross-tenant read is structurally impossible rather than policy-prevented. The shared market plane, meaning the contagion graph and the public labels, is identical for everyone and contains no customer data.
9. Sub-processors
We use infrastructure and RPC providers to run the service. [Counsel: publish the sub-processor list, the notification period for changes, and the objection mechanism.]
10. Security
Attestations are k-of-n threshold-signed over independent Ed25519 keypairs, and every attestation stamps the signer-set mode it was issued under. Signing keys are held in software, not in an HSM; the threshold defends against a forged or replayed signature rather than against compromise of the signing secret, and we state that rather than implying custody we do not have. The platform holds no customer keys or funds, so the blast radius of a total compromise of Fuga Labs is bounded to observation and to signed attestations that expire. An attacker would not inherit the ability to move anything you own. Access is capability-scoped, and the audit log names the principal, or the person where your IdP is the identity source.
11. Your rights
Access, rectification, erasure, restriction, portability and objection, as applicable in your jurisdiction. Note the interaction with clause 6 above: the response audit log is retained deliberately, and where an erasure request conflicts with a record we are required to keep, we will tell you which record and why rather than silently declining. [Counsel: rights framework per jurisdiction, response deadlines, and the supervisory authority for complaints.]
12. Breach notification
If we suffer a personal-data breach affecting you, we will notify you without undue delay with what we know, what we do not yet know, and what we are doing. [Counsel: statutory deadlines per jurisdiction.]
13. Changes and contact
Material changes are versioned and dated at the top of this page. Questions, requests and complaints go to the contact address below.
One thing this page cannot do.
Questions about any clause on this page?
Ask before you sign, not after. Every engagement is scoped by the team, and the terms are part of that conversation.