How diovault works, explained for everyone involved. A disclose.io project.
diovault is an open-source system that makes vulnerability disclosure deadlines cryptographically enforceable. When a security researcher submits a vulnerability report through the vault, the system guarantees that the report will become public at the agreed deadline — regardless of whether the vendor cooperates, ignores the report, or tries to suppress it.
It does this using timelock encryption: data is encrypted such that it can only be decrypted after a specific point in the future. No one — not the researcher, not the vendor, not a court — can prevent the decryption from happening. The deadline is enforced by mathematics, not trust.
Report encrypted with a symmetric key, then wrapped per-recipient using X25519 key exchange.
Content timelocked to the hard deadline. Content key separately timelocked to the recommended deadline for the auto-publish worker.
Encrypted packet stored immutably across distributed and permanent storage networks.
Content hash and participant identities recorded on-chain. Creates a tamper-proof audit trail.
Embargo period. Authorized parties decrypt with private keys. The drand beacon counts down.
Worker publishes at recommended deadline. If worker is down, hard-deadline backstop on IPFS fires automatically.
You've found a vulnerability. You want to disclose it responsibly, but you also want a guarantee that if the vendor stalls, goes silent, or sends legal threats, disclosure happens anyway.
Install and initialize. Generate your keypair — this is your identity in the system.
vault initYour public key is what you share with vendors. Your secret key stays local.
Write up the vulnerability as you normally would — a markdown file with description, steps to reproduce, impact, and proof of concept.
Submit to the vault. This encrypts your report, timelocks it, and stores it immutably. Set both a recommended deadline (when you intend to publish) and a hard deadline (the absolute backstop).
vault submit \
--file vulnerability.md \
--deadline 90d \
--hard-deadline 180d \
--recipient vendor-security:<their_pubkey>The hard deadline is the point of no return. Extensions can delay publication up to the hard deadline, but never beyond it.
Contact the vendor. Share your public key. Work with them normally during the embargo period. Both of you can decrypt the report anytime using your private keys.
Arm the dead man's switch (optional but recommended). This registers your disclosure with the auto-publish service at vault.disclose.io.
vault watch <id> --worker-url https://vault.disclose.io --api-key <API_KEY>Now even if you're offline, unreachable, or silenced at the deadline — disclosure happens automatically.
Check status anytime. See the state of all your disclosures, days remaining, and on-chain activity.
vault status
vault status <id>At the recommended deadline, the worker auto-publishes at vault.disclose.io/disclosure/<id>. If the worker is offline, the hard-deadline backstop on IPFS fires automatically — disclosure is guaranteed either way.
Vendor goes silent? The timelock decrypts at the deadline regardless. Their silence is the audit record.
Vendor sends legal threat? The encrypted packet is already on IPFS and Arweave. No action is required from you. The system is autonomous.
You're arrested or silenced? The dead man's switch at vault.disclose.io auto-publishes with zero human intervention.
Vendor needs more time? You can grant up to 3 extensions of 30 days each. In v2 mode, extensions are cryptographically real — the content stays encrypted until the new deadline (capped at the hard deadline). Details in FAQ.
Set the recommended deadline to when you intend to publish assuming normal coordination. Set the hard deadline to the latest date you’d be comfortable with this going public automatically, even if you’re completely unreachable.
| Vulnerability Type | Recommended | Hard | Extension Window |
| Web app (XSS, SQLi) | 90d | 120d | 30d |
| Infrastructure / API | 90d | 150d | 60d |
| Medical device / safety-critical | 120d | 270d | 150d |
| Multi-vendor coordination | 90d | 180d | 90d |
| Abandoned / no-contact vendor | 45d | 90d | 45d |
If the vendor is unresponsive and you want to escalate to CERT/CC or another coordinator:
vault add-party <id> --pubkey <coordinator_pubkey>They can now decrypt and help coordinate. The timelock is unaffected.
A security researcher has reported a vulnerability in your product through diovault. Here's what that means and what you need to do.
The researcher has encrypted their vulnerability report and set a disclosure deadline (typically 90 days, or whatever your published VDP specifies). The report is timelocked — it will become publicly readable at the deadline automatically, regardless of any action or inaction by either party.
Generate your keypair (if you haven't already) and share your public key with the researcher.
vault initDecrypt the report using your private key to read the vulnerability details.
vault decrypt <disclosure_id>Acknowledge receipt on-chain to create a public record that you received the report.
vault ack <disclosure_id>Fix the vulnerability before the deadline. Coordinate with the researcher as needed. Request a CVE.
If you need more time, request an extension. The submitter has 7 days to approve.
# Vendor requests extension
vault extend <disclosure_id> --deadline 14d
# Submitter approves (v2: also updates the worker's key timelock)
vault extend <disclosure_id> --approve
vault extend <disclosure_id> --deadline 14d \
--worker-url https://vault.disclose.io --api-key <API_KEY>Maximum 3 extensions of 30 days each. In v2 mode, extensions cryptographically delay publication up to the hard deadline. See FAQ.
You've been added to a diovault disclosure as a coordinator. This means a researcher has escalated — typically because a vendor is unresponsive.
vault audit <id>.When a vulnerability affects multiple vendors, you can link disclosures to track dependencies:
# Mark that disclosure B depends on A being fixed first
vault link <id_B> --depends-on <id_A>
# Check existing relationships
vault link <id>Links are coordination signals, not cryptographic constraints. Each timelock still fires independently.
You cannot stop or delay the disclosure. The timelock is cryptographic and operates independently of all parties. Your role is to help coordinate a good outcome before the deadline arrives — not to control whether disclosure happens.
You're looking at a published vulnerability disclosure on vault.disclose.io. Here's what happened:
Every published disclosure includes:
You can decrypt and verify any disclosure independently after the deadline:
# Decrypt a published disclosure
vault disclose <disclosure_id>
# Verify packet integrity (content hash, timelock status)
vault verify <disclosure_id>
# View the full on-chain audit trail
vault audit <disclosure_id>The report was encrypted to a specific point in the future using the drand distributed randomness beacon. When that point arrived, the drand network (operated by Cloudflare, Protocol Labs, EPFL, and 15+ other organizations) produced a cryptographic signature that served as the decryption key. No single party controlled this process.
No. The encrypted packet is stored on IPFS (distributed) and Arweave (permanent). There is no single operator to serve a court order to.
The drand beacon that triggers decryption is a distributed network across multiple jurisdictions. The system was designed specifically so that no legal mechanism targeting a single party can prevent disclosure.
Yes. In v2 (dual-deadline) mode, extensions are cryptographically enforced. The content genuinely stays encrypted past the original recommended deadline when an extension is granted.
How it works: At submission, the researcher sets two deadlines. The recommended deadline is when they intend to publish. The hard deadline is the absolute backstop. Content is timelocked to the hard deadline on IPFS (immutable). A separate timelock of the content key is sent to the auto-publish worker at the recommended deadline.
When an extension is granted, the researcher creates a new content key timelock at the extended deadline and sends it to the worker. The old timelock is replaced. Since the old timelock was only in the worker’s private storage (never on IPFS), it’s gone — the content stays encrypted until the new recommended deadline.
The hard deadline is immutable. No extension can push past it. If the worker is compromised or offline, the hard-deadline tlock on IPFS fires regardless. The researcher chooses this gap at submission time based on the vulnerability’s risk profile.
Coercion resistance: An attacker who coerces extensions can only delay disclosure from the recommended deadline to the hard deadline — never beyond it. The hard deadline is set by the researcher at submission and cannot be changed.
The auto-publish worker at vault.disclose.io runs every 60 seconds. In v2 mode, it tries two paths: first, it attempts to decrypt the content key from the recommended-deadline timelock stored in its private KV. If that succeeds, it decrypts the content, verifies the hash, and publishes.
If the worker is offline or compromised, the hard-deadline timelock on IPFS fires independently — the full plaintext becomes decryptable by anyone. This two-layer approach means disclosure happens even if the researcher is offline, unreachable, or silenced, and even if the worker itself is taken down.