Summary: Blocklock is worth cataloging not as just another Solidity helper or timelock-encryption demo, but as a distinct application-facing threshold-encryption control plane inside the broader dcipher network. Its primary materials split the system into offchain ciphertext creation, condition encoding, onchain request registration through BlocklockSender contracts, pricing and funding policy, committee-side condition monitoring, threshold BLS-signature release, and callback-based decryption delivery to application contracts. That makes Blocklock a useful comparison point for Shutter, drand timelock encryption, TACo, sealed-bid auction infrastructure, and encrypted-mempool systems because the real control surfaces are not only the cryptography, but also who defines conditions, who watches for fulfillment, which contracts and chains are supported, how delivery happens, and whether the practical operator set is as open as the network rhetoric suggests.
What it does:
Lets users encrypt data against a future block height or other supported condition so the plaintext cannot be recovered until the condition is satisfied
Uses dcipher committees to watch the relevant condition and collectively produce a threshold signature that doubles as the decryption key
Exposes Solidity and TypeScript libraries so applications can register ciphertexts, pay request fees, and receive decryption callbacks directly in smart-contract flows
Supports both direct funding and shared subscription funding models for repeated conditional-encryption requests
Deploys chain-specific BlocklockSender proxy contracts across multiple production and test networks, giving applications a standard onchain ingress point
Positions the primitive for sealed-bid auctions, delayed reveals, conditional access control, and MEV-resistant transaction or payload release
Key claims:
Blocklock clears the bar because it turns conditional access into a comparison-ready middleware stack: condition expression, ciphertext creation, committee attestation, onchain request/funding, and callback delivery are all explicit layers.
The most important mechanism is the signature-as-decryption-key path. The docs describe a committee that does not store a preexisting release key; instead, it produces the threshold signature only after verifying the condition, and that artifact unlocks the ciphertext.
Blocklock is analytically useful because it exposes operational choke points that generic threshold encryption language often hides: supported-chain contract deployments, callback gas pricing, availability assumptions, and the trust boundary around the committee that monitors conditions.
The reviewed materials also show a valuable tension between protocol framing and deployment reality. dcipher presents itself as a permissionless threshold-signing network, but the Blocklock docs and repos make clear that today’s application path relies on predeployed sender contracts and dcipher-operated fulfillment infrastructure on supported chains.
Unlike Shutter’s ordering-focused framing or drand’s public-beacon framing, Blocklock is a narrower delivery rail for condition-triggered decryption. That lower-middle position makes it a strong comparison baseline for auctions, delayed reveals, and encrypted-mempool experiments.
Blocklock belongs in the active corpus because it preserves a distinct conditional-encryption layer that would be flattened if kept only under dcipher broadly or only as a developer library.
Whitepaper: Blocklock itself is documented mainly through dcipher docs and repos rather than a standalone blocklock paper. The broader dcipher lightpaper was saved at ../whitepapers/dcipher-lightpaper-v1.1.pdf, and the strongest Blocklock-specific materials are collected in ../whitepapers/blocklock-primary-sources-2026-05-13.md.