The Exploit Lab is the entry point for working with capsules — sealed, reproducible records of an exploit path run against a fork of the real chain. From here you open a capsule by its fingerprint, see what’s been sealed under your tenant, and review what the Lab is able to reproduce.
Why it exists
A finding is more convincing when it comes with a runnable proof. A capsule is that proof: an exploit path the Lab executed against forked state, sealed so it can be replayed and inspected. This page is where those capsules live — the place to open the one attached to a finding, or to see what has recently been sealed.
Who uses it
- Auditor — opens the capsule attached to a finding to reproduce an exploit.
- Researcher — reviews the tenant’s capsules and what the Lab can do.
How to open it
- Sidebar → Exploit Lab.
- Direct URL —
/exploit-lab.
What’s on the page
Open a capsule takes a fingerprint and opens that capsule’s detail view. Capsules in your tenant lists what’s been sealed under your account — the tenant is derived from your signed-in identity, not something you type — with a Refresh to re-fetch. Recently viewed in this browser keeps a local list of capsules you’ve opened, with a Clear to reset it. A Capabilities panel summarizes what the Lab can do — run an exploit, simulate a governance compromise, forge a ZK proof, model cross-runtime admin impact, suggest attack paths, and fetch a capsule.
Limits
- Requires a signed-in account for the tenant-scoped lists.
- Tenant scoping is enforced on the server: a capsule from another tenant simply doesn’t resolve.
- The recent list is per-browser and doesn’t sync across devices.
Related pages
- Exploit Capsule Detail — the step-by-step view of a sealed capsule.
- Historical Exploit Corpus — the library of past incidents.