How diovault works, explained for everyone involved. A disclose.io project.
diovault is an open-source experiment in holding vulnerability-disclosure deadlines with cryptography rather than goodwill. The hard deadline cannot be moved once a packet is committed, and a packet that remains retrievable becomes independently decryptable after its hard-deadline drand round.
It does this using timelock encryption: data is encrypted such that it can only be decrypted after a specific point in the future. Automatic publication additionally depends on packet availability and the publishing service.
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 always retained locally, and replicated to IPFS and Arweave when storage is configured.
Optional: content hash and participant identities can be recorded on-chain, creating a tamper-evident audit trail.
Embargo period. Authorized parties decrypt with private keys. The drand beacon counts down.
Worker attempts publication at the recommended deadline. After the hard deadline, a retrievable packet can be decrypted independently.
You've found a vulnerability and want a deadline mechanism that does not depend solely on continued cooperation. The current alpha is for synthetic evaluation, not real reports.
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 writes an encrypted copy to your local vault. If IPFS/Arweave credentials are configured it also replicates there — check the submit output, which reports each leg. 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: it cannot be moved once the packet is committed. Extension of the recommended deadline is a planned feature and is not available in the current release.
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>The Worker will attempt publication even if you are offline; this remains dependent on Worker and storage availability.
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 attempts to publish at vault.disclose.io/disclosure/<id>. After the hard deadline, anyone who can retrieve the packet can decrypt it independently.
Vendor goes silent? Key release still happens at the deadline round, and no party can revoke it. Their silence is the audit record.
Vendor sends legal threat? A legal threat cannot reach the timelock. What it can reach is packet availability — so confirm your packet actually replicated, and keep your own copy.
You're arrested or silenced? The Worker attempts publication without you. That is an operational service, not a guarantee: it depends on the Worker running and on at least one copy of the packet remaining retrievable.
Vendor needs more time? The alpha can record an extension request on-chain, but safe v2 Worker re-keying is disabled until the new contract and authorization protocol ship. 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 disclosure deadlines. The hard-deadline packet becomes decryptable after its drand round if the packet remains retrievable.
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 records approval on-chain
vault extend <disclosure_id> --approveThe alpha intentionally does not replace the Worker key timelock. Production extensions require the planned signed v2 protocol.
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 change the hard-deadline encryption of an already distributed packet. Packet availability and automatic publication are separate operational concerns. Your role is to help coordinate a good outcome before the deadline.
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 absolute claim is appropriate in the alpha. Resistance depends on successful packet replication, continued retrieval, drand availability, and possession of the packet location. The current CLI treats IPFS and Arweave uploads as optional.
Not safely in the alpha. Extension requests and approvals can be recorded on-chain, but replacement of the Worker’s recommended-deadline key timelock is disabled.
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 inside the packet, and that commitment cannot be altered afterwards. A separate timelock of the content key is sent to the auto-publish worker at the recommended deadline.
The future protocol will require defined participant signatures, an on-chain approval event over the replacement timelock hash and nonce, and strongly consistent per-disclosure state before accepting that replacement.
The hard-deadline encryption in a distributed packet is immutable. The production protocol must prove packet replication and authorize extensions without allowing a replacement of this hard commitment.
Target property: an authorized extension may move only the recommended deadline and can never exceed the packet’s hard deadline.
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 still releases on schedule — the beacon does not depend on the worker. At that point the full plaintext is decryptable by anyone who can obtain the packet. That last clause is the honest limit of the two-layer design: the timelock reliably yields a key, never a document. If no replica was confirmed at submission, the researcher's local copy is the only one, and a disclosure that nobody can retrieve does not become public no matter how correctly the beacon fires.