Reporting vulnerabilities
SealedIP is a hackathon prototype running on testnet. There is no formal bug bounty program. If you find an issue that would lose user funds, leak bid amounts before the deadline, or let a non-winner claim the license, please disclose privately rather than exploiting on testnet.
Where to report
Preferred: Open a security advisory on GitHub.
→ github.com/sneg55/SealedIP/security/advisories/new
GitHub's advisory system keeps the report private between you, us, and any collaborators we invite. It also has a built-in patch + CVE flow if the issue warrants it.
Alternative: Open a GitHub issue tagged security with high-level
details only. Do not include exploit code or specific reproducer steps in
a public issue. We will respond and move sensitive details to a private channel.
What to include
If you have it:
- A short description of the issue and its security impact
- Reproduction steps (private channel only)
- A suggested fix or mitigation (optional but appreciated)
- Your preferred attribution name (or "anonymous")
Response timeline
We aim to:
- Acknowledge within 7 days
- Triage within 14 days
- Patch and redeploy when feasible (depends on severity)
- Publish a disclosure after the patch is live (typically 30 to 60 days post-report)
The hackathon team is small and the protocol is in active development. Response times reflect that. If you do not hear back, ping again.
What counts as a vulnerability
Things we care about:
- Fund loss — any path where deposits are not refunded as documented
- License theft — any path where a non-winner can claim the license token
- Privacy break — any path where bid or reserve amounts are readable before the deadline by anyone (orchestrator, validators, observers)
- Atomicity break — any path where settlement partially succeeds (license mints but payment does not, etc.)
- Reserve bypass — any path where a bid below the sealed reserve can win
Things we would appreciate hearing about but consider lower priority:
- DoS via gas exhaustion — auctions with many bidders that cannot settle. Known and documented (see Limitations).
- UI bugs that mislead users — wrong USD references, broken status pills, etc. Open a regular GitHub issue for these.
What is NOT a vulnerability
- Validator collusion above threshold — known, documented, fundamental.
- Bidder side-channel leaks — your machine, your problem.
- PIL terms not matching off-chain enforcement — that is Story Protocol, not SealedIP.
- High gas costs on Aeneid — testnet, not in scope.
- CDR contract not verified on Storyscan — known limitation, not a security issue.
Safe harbor
For good-faith security research:
- Do not exploit production funds. Testnet only. A mainnet deployment does not exist yet and will not until after a real audit.
- Do not withhold for ransom. Disclosures should be voluntary, not coerced.
- Do not publish exploits publicly before patches land. Coordinate disclosure timing with us.
If you follow these, we will not pursue legal action. We may also credit you in the published advisory.
Past disclosures
None yet. This page exists to make the path clear so there is never a "they had nowhere to report" situation.
Related
- Audit status — what is tested
- Known limitations — what is known or out of scope
- Threat model — what we claim to defend against