Coordinated disclosure. Signed receipts. No silent fixes.
Jelleo is a Solana-program audit platform. This page describes how to report security issues against the platform, how Jelleo handles findings against its audit targets, and how to verify a Jelleo cycle's signed attestation.
How to report
If you have found a security issue in the Jelleo platform — the audit pipeline, the hypothesis library, the CLI, the dashboard, the website, or the signing/attestation key handling — please report it directly to us.
A For sensitive or pre-disclosure reports, request our PGP key by emailing security@jelleo.com with subject "request PGP key".
For findings Jelleo has produced against a third-party Solana protocol, the protocol maintainer is the disclosure target — Jelleo's role is to coordinate that disclosure. Direct disclosures from external researchers about a Jelleo customer's protocol are routed via the same email above.
What is in scope, what is not.
In scope
- The audit-pipeline CLI (platform repo)
- The Jelleo website source (
website/deploy/) - The hypothesis library (
OUTREACH/*.yaml+ templates) - The findings database schema (
src/audit_pipeline/db.py) - The Ed25519 signing implementation (
src/audit_pipeline/commands/sign.py) - The shadow-audit logic (
src/audit_pipeline/commands/shadow.py) - The dashboard (
src/audit_pipeline/commands/dashboard.py) - Any signed Jelleo cycle receipts that are claimed but cryptographically invalid
Out of scope
- The Solana programs Jelleo audits (report those upstream — Jelleo will help coordinate)
- The Anthropic API, the Solana RPC providers, or other third-party services Jelleo depends on
- Self-XSS, missing security headers absent demonstrable impact, or other low-impact web findings without an exploit chain
- Issues requiring physical access to the maintainer's workstation
- Social engineering attacks against Jelleo personnel
Jelleo also maintains a public ruleset for Anthropic's Claude Code security-guidance plugin at jelleo.com/guidance (source: github.com/Copenhagen0x/solana-security-guidance). Issues in those rules — false positives, missed cases, regex DoS — are reported via the ruleset's own SECURITY.md rather than here. Same email (security@jelleo.com) reaches both queues.
For findings Jelleo produces
Jelleo follows a coordinated-disclosure model. The defaults below are floors; specific engagements may extend any of them by mutual agreement.
Timeline
| State | Action | Default duration |
|---|---|---|
confirmed | PoC reproduces. Disclosure email sent to the maintainer with a private GitHub issue or alternative. | Day 0 |
disclosed | Maintainer acknowledged. Embargo begins. | 30 days |
fixed (in window) | Maintainer ships patch within the 30-day window. Public disclosure proceeds coordinated. | within 30 days |
fixed (extension) | Maintainer requests extension — granted by default for active fix work, up to 90 days total. | 30–90 days |
| Public release | Writeup, PoC, fix bundle, attestation made public. | Day 30 or after fix |
| No-acknowledgement | If no acknowledgement after 14 days of repeated outreach, public disclosure proceeds. | Day 30 |
Embargo conditions
- Critical findings affecting deployed mainnet protocols receive maximum embargo flexibility — Jelleo will not publish until a fix is shipped or the protocol's funds are no longer at risk.
- High findings against active protocols default to 30 days, extensible to 90.
- Medium / Low / Info findings default to public disclosure on the next regular cadence (weekly or monthly rollup).
- Embargo duration is recorded in the signed cycle receipt (methodology §07).
Findings are sent to maintainers before any third party.
Customers, partners, and Jelleo employees do not receive in-embargo finding details until the embargo lifts.
Every finding eventually becomes public — either with a fix in place or with the maintainer's explicit acknowledgement that no fix will ship.
Jelleo does not sell findings. It does not sell early access to findings. Customers receive findings against their own protocol; nothing more.
External researchers who report platform vulnerabilities are credited in the disclosure unless they request anonymity.
How to verify a Jelleo signature.
Every Jelleo cycle produces an Ed25519-signed receipt. The current platform public key is published in three places — any one of them is authoritative.
keys/jelleo.ed25519.pubin the platform repo- jelleo.com/methodology.html#attestation
https://jelleo.com/keys/jelleo.ed25519.pubhttps://api.jelleo.com/keys/jelleo.ed25519.pub(mirror)
To verify a Jelleo signature:
$ audit-pipeline sign verify <file> <file>.sig --pubkey jelleo.ed25519.pub
✓ VALID signature on <file>
If a signature does not verify, do not trust the file. A failed verification means either the file has been altered since signing, or the file was not signed by the published Jelleo platform key. Either case warrants a direct report to security@jelleo.com.
Bug bounty
Jelleo does not currently operate a formal bug bounty program. We extend courtesy compensation for impactful findings on a case-by-case basis. The intent is to formalize a bounty within the Year-1 funded build.
Researcher honor roll
We thank every researcher who has improved Jelleo's security. As of the date below, no external researchers have reported platform vulnerabilities. This list will grow.
Last updated: 2026-05-07.