Responsible disclosure
Contact
Section titled “Contact”Primary: GitHub Security Advisory — the preferred channel. Creates a private thread with the maintainers and tracks the fix through disclosure.
Fallback: security@alea.so. Cloudflare Email Routing forwards to a personal inbox. If you don’t get an acknowledgment within 72 hours, ping the GitHub Security tab — that’s the redundant channel.
No paid bug bounty currently. If you want acknowledgment for a finding, we will publish your name and the vulnerability description (with your permission) once the fix has been deployed and verified.
What to send
Section titled “What to send”A reproducible bug report. Ideal contents:
- The commit SHA or release tag you’re testing against
- A minimal reproduction: a Rust test, a TypeScript script, a transaction signature on devnet
- Your assessment of impact and severity — we will likely revise; your initial take helps prioritize
- Whether you’ve already disclosed elsewhere
Do not include exploit code that targets the live devnet program in public channels. The vulnerable behavior is enough; we’ll write our own test cases.
Disclosure timeline
Section titled “Disclosure timeline”Standard 90-day window from acknowledgment:
| Day | Action |
|---|---|
| 0 | You submit via GitHub Security Advisory or email |
| 1–3 | We acknowledge receipt and confirm we can reproduce |
| 4–14 | We propose a remediation approach and discuss with you |
| 15–60 | We implement, test, review, prepare release |
| 61–80 | We coordinate disclosure window with you; pre-announce to integrators if needed |
| 81–90 | Public disclosure: GitHub Security Advisory + commit + release notes |
Critical bugs (e.g., the on-chain program can be made to verify forged signatures) compress this timeline aggressively — hours, not weeks, between ack and remediation. Low-severity bugs can extend by mutual agreement.
Out of scope
Section titled “Out of scope”These are not vulnerabilities in Alea:
- Drand network compromise. Flaws in drand itself (e.g., the threshold-BLS group can be reduced below the t-of-n threshold) belong to drand, not Alea. Report to the drand security contact. We are downstream.
- Solana network issues. Validator censorship, RPC misbehavior, MEV on your transactions. Report to the relevant Solana actor. We can help coordinate if the issue intersects Alea’s behavior.
alt_bn128_pairingsyscall bugs. Solana protocol bugs. Report to the Solana Security team — and let us know so we can pause integrations while it’s patched.- Application-level bugs in programs that integrate Alea. If your lottery has a bug, file with the lottery’s team, not us. The exception: if the bug stems from an Alea API that makes misuse too easy to be accidental, send it to us — the API needs documentation or a guard-rail.
- DoS via legitimate transactions. Alea has no rate limit and accepts any valid
(round, signature)input. Submitting many verify calls is not a vulnerability; it’s the intended interface.
What IS in scope
Section titled “What IS in scope”Anything that:
- Makes the on-chain verifier accept a signature it should reject (forgery)
- Makes the on-chain verifier reject a signature it should accept (denial)
- Makes the SDK return wrong randomness, or randomness that doesn’t match what the on-chain program returned
- Lets an attacker bias randomness by manipulating Alea (not drand, not Solana)
- Crashes the program or pushes compute past the documented ~407K envelope
- Bypasses the on-chain
Config.authorityor upgrade-authority gates before the planned multisig transfer
If you’re unsure whether something is in scope, send it. We’d rather decline politely than miss something.
Acknowledgments
Section titled “Acknowledgments”Reporters with credit (opt-in) are listed in release notes and below. Currently empty — be the first.