Access Control Options

All blobs stored on Walrus are public by default. Anyone who knows a blob ID can fetch its contents directly from a Walrus aggregator. This means that access control for Walrus Sites is not enforced at the storage layer. Instead, you apply it at the application layer, either through client-side encryption before upload, or through onchain policy enforcement using Seal.

Fully public content (default)

When you publish a Walrus Site using site-builder, all resources are stored as publicly readable blobs on Walrus. The portal serves them to any visitor without authentication. This is appropriate for most static sites, documentation, open-source project pages, and other content that has no confidentiality requirement.

For these use cases, site data authentication already provides integrity guarantees: the portal verifies each resource's SHA-256 hash against the value stored on Sui before serving it, ensuring the content has not been tampered with in transit.

info

Integrity verification and access control are separate concerns. Authentication confirms that content has not been modified. It does not restrict who can retrieve it.

Restricting access through Seal

For content that should only be readable by specific users, Seal is the recommended mechanism. Seal is a decentralized secrets management (DSM) service built on Sui. It combines client-side threshold encryption with onchain access policies defined in Move smart contracts, so that encrypted content can live permanently on Walrus while access rules remain independently updatable onchain.

What Seal does not cover

Seal protects content confidentiality at the application layer. It does not enforce access control at the Walrus storage layer. Anyone who retrieves a blob directly from a Walrus aggregator receives ciphertext, but the blob ID itself is not secret. Seal is also not designed for highly sensitive regulated data such as personal health information or government-classified material. Refer to the Seal documentation for the full security model and its assumptions.

Seal access policy patterns

Seal's access policies are Move functions (seal_approve), which means they are as flexible and composable as any other Move code. The following patterns cover the most common use cases for Walrus Sites. For implementation details and example code, see Using Seal.

Allowlist

An allowlist restricts decryption to a defined set of Sui addresses managed in a shared object onchain. This pattern suits controlled sharing: private documents, collaboration spaces, or invitational access.

Reference implementation: examples/move/sources/allowlist.move

Subscription and token gating

A subscription policy grants decryption access to users who hold a specific NFT or token. Because ownership is verified onchain at decryption time, access automatically follows token transfers — no manual policy updates are required when an NFT changes hands. This pattern suits premium content, creator monetization, and any scenario where access should track asset ownership.

Reference implementation: examples/move/sources/subscription.move

Time-lock encryption

A time-lock policy makes content decryptable only after a specific point in time, by comparing the current Sui onchain clock against a threshold timestamp. This pattern suits embargoed announcements, sealed auctions, scheduled content releases, and MEV-resistant trading flows.

Custom and composable policies

Because seal_approve is arbitrary Move code, you can combine multiple conditions. Any state observable on Sui can be incorporated into an access policy. Additional high-level patterns are available in move/patterns in the Seal repository.

caution

If your Move package is upgradeable, the access control policy can be modified at any time by the package owner. These changes are transparent and publicly visible onchain. For higher assurance, consider publishing an immutable package or using a versioned shared object pattern for your policy state.

Choosing an approach

The following table summarizes when to use each option:

Requirement	Approach
Public content with tamper-evidence	Default Walrus Sites (no encryption)
Content restricted to known addresses	Seal with allowlist policy
Content gated behind NFT or token ownership	Seal with token-gating policy
Content that becomes public after a fixed time	Seal with time-lock policy
Custom or multi-condition access rules	Seal with custom seal_approve logic