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(orbroadcastAndWait) to submit it.demos.storagePrograms.read(address)to query state via RPC (free, no transaction).
Boilerplate
Every example below assumes this setup: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.updateAccessControl:
updateAccessControl.
Example 3 — Binary attachment with metadata
For non-JSON payloads (PDFs, images, archives), encode the bytes as base64 and useencoding: "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
- Operations guide — when each operation is appropriate.
- Access Control guide — full ACL matrix and security checklist.
- RPC Queries — fast read paths for clients.
- API Reference — full method signatures and payload shapes.