Preview: Event-Based Decryption for Shutter API

Shutter API is Getting Smarter

If you’ve been following our work, you already know what Shutter API is all about - bringing fairness, privacy, and trust-minimization to dApps through commit-reveal threshold encryption.

In simple terms, it lets dApps keep sensitive data - like votes, bids, or game moves - encrypted until the exact moment it’s meant to be revealed. That single shift removes one of the biggest problems in Web3 today: information asymmetry.

Which means that some people have more information than others, and they can gain an unfair advantage. And that’s not fair. This is a problem we’ve written extensively about. Some links for your reference: 1, 2, 3, 4, 5

That’s the gap Shutter API fills. It restores fairness by removing the need for any trusted third party to handle encryption within your dApp’s core logic. Instead, Shutter API provides a seamless, trust-minimized encryption service powered by a distributed network of Keypers. It automates the encryption process, eliminates manual coordination, and ensures that data stays sealed until the right trigger - preventing early leaks, collusion, and front-running.

Since Shutter API’s launch in March 2025, it’s been used for encrypting sealed-bid auctions, time-locked predictions, time-locked gifts, time-locked reveals such as the official Ethereum 10th anniversary Time Capsule. It’s also in development for use in Kleros 2.0 juror voting and for Snapshot DAO voting.

Together, these integrations show how Shutter API is becoming the fairness layer for dApps.

And today it’s getting even smarter, as we announce the next upgrade, event-based decryption - a new way to trigger decryption based on on-chain events rather than time.

This unlocks an entirely new field of use cases, more in the direction of privacy, access control, escrow and others. See below.

From “When” to “Why”

Until now, Shutter API only used time-based decryption - meaning data stayed encrypted until a certain timestamp, i.e., “reveal this at 5pm.” That worked well for predictable releases.

But not everything in Web3 runs on a clock. DAO proposals close early. Games finish when a contract says they’re done. Payments happen when an event fires on-chain.

This is where event-based decryption comes in. It is used to unlock encrypted data automatically when specific on-chain conditions are met, i.e., “reveal this only when a specific contract event happens.”

This opens up a new layer of programmable, condition-aware privacy for dApps everywhere.

What Event-based Decryption Makes Possible

Payments, Licenses & Subscriptions

Unlock paid content immediately after on-chain payment is confirmed.
Renew access keys once a subscription or membership payment is detected.
Deliver license or activation keys when the purchase or minting event occurs.

Secure file storage

Allow a smart account to hold and maintain private data.
Files are only revealed after multisig approval is executed.

Auctions, Crowdfunding & Fundraising

Run sealed-bid auctions where results appear only when the contract signals closure.
Publish campaign details the moment a crowdfunding contract emits a “goal reached” event.
Reveal shared secrets once a threshold of participants have deposited or signaled interest.

Gaming & NFTs

Design decentralized games where moves only reveal when the round ends.
Show game results the instant the round-ending event is emitted.
Reveal NFT traits or visuals right after an achievement or milestone is recorded.

Escrow, Insurance & Oracles

Disclose escrowed contracts or files only after settlement or deal completion.
Release insurance documents or payouts only after a claim oracle confirms verification.
Trigger decryption of forecasts or settlements when oracle data updates are finalized.

Rewards & Collective Events

Unlock rewards automatically when claim or staking events are verified on-chain.
Reveal shared secrets once a threshold of participants have deposited or signaled interest.

Those are just some of the use cases for event-based decryption. We’re sure you may have other ideas in mind. Here’s also the list of time-based decryption use cases.

How It All Works

Event-based decryption builds on the same commit-reveal threshold encryption model that powers Shutter’s time-based triggers. The distributed Keyper set observes the registry contract for matching Event Trigger Definition (ETDs), generates a decryption key collaboratively, and releases it once the trigger condition is met.

Developers simply register an identity with either:

A timestamp (for time-based triggers), or
An Event Trigger Definition (for event-based triggers).

Event Trigger Definitions can include:

The emitting contract address (for example, a DAO or auction contract).
The event signature (such as ProposalExecuted, AuctionClosed, or Transfer).
Optional filters for specific parameters like proposalId, auctionId, or wallet address.
A time-to-live (TTL), defining how long the system monitors for the event.

Everything else - event matching, key generation, and key release - is handled automatically by the Shutter API.

Want Shutter API for Your dApp? Let’s Chat

Event-based decryption isn’t live yet, and will roll out in the coming weeks.

However, this doesn’t mean you have to wait.

If you’re working on a dApps that could benefit from event-based on time-based decryption from Shutter API, contact us to set up a chat. We’ll walk you through how Shutter API can be integrated into your dApp.

In the meantime, explore time-based decryption https://www.shutter.network/shutter-api.

Preview: Event-Based Decryption for Shutter API

Shutter API is Getting Smarter

From “When” to “Why”