Skip to content

Documentation

Storage adapters

IPFS · ArweaveIPFS tested live

Where encrypted artifacts live, and how integrity and availability are checked.

Adapters

AdapterLocatorStatus
IpfsStorageAdapteripfs://<cid>Tested live: checkpoints pinned on Filebase and restored from its gateway (testnet); also against a mock Kubo API
ArweaveStorageAdapterar://<id>Tested against a mock gateway; a live test is planned. The upload signer is supplied by you
LocalStorageAdapterepoch-local://<digest>Development only; marked developmentOnly
storage.ts
import { ReplicatedStorage, IpfsStorageAdapter, ArweaveStorageAdapter } from "./sdk/src/index.ts";

const storage = new ReplicatedStorage([
  new IpfsStorageAdapter({                                            // Kubo RPC, server-side only
    apiUrl: "https://rpc.filebase.io",                                  // e.g. Filebase; any Kubo-compatible pinning API
    authorization: "Bearer " + IPFS_TOKEN,
    gatewayUrl: "https://ipfs.filebase.io",
  }),
  new ArweaveStorageAdapter({ gatewayUrl: "https://arweave.net", uploader }),
], 2);                                                                  // both copies must succeed

A content ID alone does not make data private or permanent. Artifacts are encrypted before upload, and availability is checked, not assumed.

Write sequence

  1. Serialize the state; compute its hash and the context hash.
  2. Encrypt, bound to agent, chain, contract, workflow, execution and sequence.
  3. Upload; read the object back and check its digest.
  4. Build and upload the canonical manifest.
  5. Submit the commitment; wait for the configured confirmations; check the stored values.
  6. Retrieve independently and verify; only then is it a verified recovery point.

Reads

Every read is checked against its committed digest. A missing object is PAYLOAD_UNAVAILABLE; bytes that do not match are PAYLOAD_INTEGRITY_FAILED. The SDK never falls back to a different payload. Uploads retry with bounded exponential backoff.

Encryption

LocalAesGcmProvider uses AES-256-GCM with the binding as associated data, so an artifact cannot be decrypted under another agent, execution or checkpoint. An access policy decides which principals may decrypt (by default only the agent named in the binding). Lit Protocol is planned behind the same interface.