Skip to main content

Storage Programs Examples

Each recipe below uses the real v4.0.3 SDK surface:
  • StorageProgram.* static helpers to build typed payloads.
  • demos.storagePrograms.sign(payload) to produce a signed transaction.
  • demos.confirm + demos.broadcast (or broadcastAndWait) to submit it.
  • demos.storagePrograms.read(address) to query state via RPC (free, no transaction).
For deeper background on operations, ACL modes, and resource limits, see the Operations and Access Control guides.

Boilerplate

Every example below assumes this setup:
A small helper to broadcast a signed storage-program transaction with deterministic confirmation:
StorageProgram.createStorageProgram takes a nonce (the sender’s current account nonce) so that the derived storage address is unique per transaction from the same deployer. Fetch the nonce from demos.getAddressNonce(ownerAddress) before each create.

Example 1 — Public user profile

A read-only-for-the-world profile: anyone can fetch it, only the deployer can write.
writeStorage replaces the entire data field — it does not merge. Keys you don’t pass are dropped. Use the granular helpers (setField, appendItem, etc.) for partial updates.

Example 2 — Restricted team workspace

Two ACL groups: editors (read + write) and viewers (read-only). Other addresses cannot read or write.
To rotate membership later, push a new ACL via updateAccessControl:
Only the program’s owner can call updateAccessControl.

Example 3 — Binary attachment with metadata

For non-JSON payloads (PDFs, images, archives), encode the bytes as base64 and use encoding: "binary". Storage Programs are capped at 1 MB (MAX_SIZE_BYTES = 1,048,576 bytes) per program — splitting larger blobs across multiple programs is the standard pattern.
metadata is opaque to consensus but is returned alongside the data on read, so it’s a good place to stash filename, MIME type, encoded size, or content hash.

Where to go next