Timelock encryption via a distributed randomness network means an early decryption attempt does not fail a permission check — the key genuinely does not exist yet. That is a different guarantee from a server refusing to answer. The vault history is the practical companion: because every sealed item is recorded with its round number and its decryption time, you can audit what was locked and when it opened rather than trusting that it worked.
An MCP server for time-based operations, combining an interval manager with timelock encryption backed by a distributed randomness network, and timing-attack protection through fuzzed durations and jittered timestamps. Encrypted items are persisted in DuckDB so history and statistics survive the session.
- Interval management with a name and a duration, then progress checks, pausing and resuming — `start_interval`, `check_interval`, `pause_interval`, `resume_interval`
- Timelock encryption bound to an interval: a value encrypted against an interval id reports "not yet decryptable" until the interval ends, then returns the plaintext
- Persistent history and statistics over past vaults, filterable by interval and by whether they were decrypted — `list_vault_history`, `get_vault_stats`
- Timing-attack protection applied to operations: random fuzz on durations, jittered timestamps and constant-time comparisons
No account and no key. Node.js: point the client at the built `build/index.js` with `node` in your Claude Desktop config. Storage is DuckDB running as WebAssembly, with a defined schema over the encrypted items, their round numbers and their creation and decryption timestamps. MIT licensed.