Loading ForensicBlock
Preparing your blockchain forensics platform...
Preparing your blockchain forensics platform...
Every credibility signal on this site maps to a verifiable rail. This page is the index — security posture, methodology, sealed-record contract, sub-processors, and the disclaimers we will not bury.
Active version: v1.7.6. Every sealed report cites its methodology version + SHA-256 content hash. Older reports stay reproducible against the version they were sealed under.
Methodology pageEvery report carries an evidence packet SHA-256 plus the certificate of authenticity hash. Both anchor the report against tampering.
Verify a sealed reportAnyone can verify a sealed report in a browser with no account, no platform login, no payment — opposing counsel, a court clerk, a regulator, a journalist.
Open the verifierTLS on every public surface (Vercel-managed certificates), HSTS enforced. No mixed content; no third-party trackers on authenticated pages.
Encrypted at rest at the database layer (Supabase-managed AES-256). Customer API keys are hashed before storage; we cannot read them back.
Supabase Auth with row-level security on every tenant boundary. Two-factor authentication (TOTP) with in-app enrollment. Service-role keys are segregated and never reach the browser.
Primary database in AWS us-east-1 (Supabase); hosting and CDN via Vercel. EU residency is on the enterprise roadmap — we do not state a residency guarantee we have not built.
Every status change, every finalize, every export anchored to fb_audit_log with hash-chained entry_hash. Tamper-evident across the matter lifecycle.
We hold no SOC 2, ISO 27001, or HITRUST certification today. We do not pretend otherwise. The methodology page + verifier + audit log are our receipts in the meantime.
We do not hide the vendor stack. Compliance officers should be able to map every sub-processor to a DPA.
| Sub-processor | Role | Data scope |
|---|---|---|
| Supabase (AWS us-east-1) | Database, Auth, Storage | Customer accounts, investigation rows, sealed evidence, audit log |
| Vercel | Hosting, edge runtime, CDN | Static assets, SSR responses, edge function execution |
| Vercel Blob | Object storage | Generated report PDFs, evidence bundle exports |
| Stripe | Payments + subscription billing | Email, payment tokens, billing metadata |
| Inngest | Job orchestration | Background investigation pipeline state |
| Anthropic (Claude API) | Agent reasoning + narrative drafting | Investigation context sent as prompts: addresses, transactions, catalog labels, and evidence text an examiner has loaded. Every number that reaches an exhibit is produced by a deterministic engine, not by the model. |
| Upstash Redis (Vercel KV) | Cache + job queues | Job state, rate-limit counters, short-lived cached lookups |
| Resend | Transactional email | Recipient address and message body: alerts, invitations, run-completion notices |
| Sentry | Error + performance telemetry | Stack traces and request metadata. Authorization headers, cookies and API keys are stripped before send. |
| Chain RPCs + block explorers (Alchemy, Etherscan-v2 family, Routescan, TronGrid, mempool.space and equivalents) | Read-only chain data | Public on-chain data. No account or matter content is sent — but the query itself discloses which address is being examined, which is why an engagement that requires that not to be observable needs a self-hosted node. |
| Attribution and sanctions feeds (MetaSleuth, Arkham, Chainalysis, TRM — each enabled only when its key is configured) | Third-party address attribution | The address being looked up. No account, matter or evidence content is sent. A feed with no key configured is absent, not stubbed. |
| U.S. Treasury (OFAC SDN) | Sanctions data feed | Public sanctions list; no PII |
Honest status per question. Where we're ready today; where we're building; what we won't pretend.
On the 2026 roadmap
We have not been audited yet. We will not claim SOC 2 we have not earned. In the interim: cryptographic audit chain, RLS isolation, public methodology, sealed reports.
Roadmap (post-SOC 2)
Will follow SOC 2. Same honest stance — we will not market a certification we do not hold.
Available — in-app SSO flow
SAML 2.0 single sign-on via the login page's SSO flow (Okta, Azure AD, Google Workspace, or any SAML 2.0 IdP). SCIM provisioning is in development — member sync is manual today. Contact us to enable on your workspace.
Available in-app today
TOTP two-factor authentication with in-app enrollment, available to every account. Org-wide enforcement policy is on the roadmap.
US (AWS us-east-1) today; EU on the roadmap
Primary database in AWS us-east-1 via Supabase. EU residency is being scoped for Enterprise customers — we will not state a residency guarantee we have not built.
Row-level (RLS) on every table
Every read goes through Postgres RLS scoped to the active org. Service-role keys are segregated and never reach the browser. No silent cross-tenant fetches possible.
Live and hash-chained; every historical break disclosed
fb_audit_log is hash-chained per entry and verified on two independent properties: each row must hash to itself, and its prev_hash must equal the prior row's entry_hash. The verifier reads every row and never stops at the first mismatch. It reports 210 historical breaks — 27 caused by a foreign key that rewrote org_id in place on 2026-08-05, since removed, and 183 in the ledger's first week in April 2026, none since. Each one is enumerated, dated and hash-pinned in an append-only incident record, so an already-broken row cannot be altered again without returning to the unacknowledged count. That count is zero. No row has been rewritten to make the verifier pass, and none ever will be: an append-only evidence ledger that is edited to produce a green result is not evidence. Immutability is enforced by the database, not by application code: a service-role delete of a sealed, attested exhibit is refused by named triggers, so an admin console, a support script or a compromised service account cannot route around it.
Managed backups; formal DR targets in progress
Encrypted database backups managed at the database layer (Supabase). We have not published audited RPO/RTO numbers and will not quote targets we cannot evidence; a formal DR runbook is on the 2026 roadmap.
Sub-processors published; DPA on request
The named sub-processor list (above) reflects current vendors, and we notify of changes in advance. Standard DPA available on request.
Scheduled — 2026 security roadmap
An independent third-party penetration test has not been completed yet. We will not cite a report that does not exist. The first engagement is on the 2026 roadmap; its summary will be available under NDA once complete.
DPA, security posture overview, compliance roadmap letter, sub-processor list, SSO/SAML configuration sheet, data-residency statement (US primary). One email, two business days.
For DPAs, security questionnaires, vulnerability disclosures, or sub-processor inquiries, reach out and we'll respond within two business days.