Access policy example patterns
This page summarizes common Seal patterns from the Move patterns repository. It is not exhaustive. For additional patterns and the latest updates, see the repository directly.
Private data
Use this pattern when a single owner should control encrypted content. You store the ciphertext as an owned object. Only the current owner can decrypt, and ownership transfer moves custody without exposing the data. This pattern is a good fit for personal key storage, private NFTs, or user-held credentials that must remain private yet portable.
Allowlist
Use this pattern to share encrypted content with a defined group or list of approved users. You manage access by adding or removing members on the list, and those changes apply to future decryptions without touching the encrypted data. This pattern works well for subscriptions, partner-only data rooms, or early-access drops, and can optionally switch to public access after a set time.
Subscription
Use this pattern to offer time-limited access to encrypted content or services. You define a service with a price and duration. When someone subscribes, their identity gets a pass that lets them decrypt the service's content until it expires. There is no need to re-encrypt or move data. This pattern is ideal for premium media, data feeds, or paid API and AI model access.
Time-lock encryption
Use this pattern to publish encrypted content that unlocks automatically at a specific time. You encrypt once with an unlock timestamp. Before that moment, no one can open it, and after it passes, anyone (or your intended audience) can. No re-encryption or per-user distribution is needed. This pattern is ideal for coordinated reveals (drops, auctions), MEV-resilient trading, and secure voting. An optional variant lets an authorized party extend the unlock time before it expires.
Variation - pre-signed URLs
Apply the same time-based logic to gate a specific Walrus blob behind a time-limited link that expires. Encrypt once (optionally bind the blob ID in the key ID), include an expiry parameter, and let the policy authorize decrypts only before the deadline, not after. To emulate cloud "signed URLs" more closely, combine the time check with an access rule (for example, an allowlist or subscription check).
This section covers access control, not link generation. You can generate and distribute the URL off-chain, or add a helper function in the same access policy package to produce or validate link parameters if you prefer to keep it on-chain. This enables limited-time downloads without re-encrypting content or managing per-user copies.
Secure voting
Use this pattern to run a vote where ballots stay encrypted until completion. You define eligible voters and each submits an encrypted choice. When all votes are in, anyone can fetch the required threshold keys from Seal and use the on-chain decryption to produce a verifiable tally. Invalid or tampered ballots are ignored. This pattern is useful for governance, sealed-bid auctions, or time-locked voting.