Why Permafrost

Who it’s for

For teams whose users, partners or auditors will one day ask “prove it”:

• Community and subscription apps. Private groups, member media, paid content, message history.
• Agentic apps. Drafts, approvals and outcomes, each with a stated home and a checkable record. → Agent workflows
• Records that must hold up. Submissions, evidence, anything whose version history matters.

Residency and a public record, together

Residency and a public record usually pull apart. Here they hold together:

• Your deployment runs in your region. Local files, backups and keys stay there. our statement
• Only fingerprints go public, never content. verifiable
• You decide per file what, if anything, leaves. → Data residency

Compared with S3

For plain storage, S3 is simpler and cheaper. Use it. Otherwise:

You need	With S3	With Permafrost
A record of what was stored, and when	The provider’s database row	A receipt on Sui anyone can check witnessed
Deletion you can show	A delete call and a promise	Key destroyed, certificate recorded our statement
Per-user isolation	IAM users, policies, keys	Users’ sign-in is the credential; each user is a tenant
A place for each file	One storage class per bucket	Per file: local, held, or decentralized
A way to leave	Export while your account works	Receipts on Sui point to Walrus
Residency with a public record	The provider’s own log	Residency plus public receipts

Same S3 API. Change the endpoint and the credential, not your code.

Compared with Walrus directly

Permafrost stores on Walrus. Going direct, you build the service around it:

You’d build	Permafrost gives you
SDK integration, wallets, tokens	An S3 endpoint; no tokens on your team
Privacy (Walrus content is public)	Encryption by default our statement, your own keys if you want, per-user access
Tracking when paid storage ends	Retention, watched and renewed
A record of content and ownership	A receipt with fingerprint and version history
Deletion on a network that can’t un-write	Key destruction with a certificate our statement
Access control, limits, read billing	Metered access: auth, rate limits, per-tenant limits, reads billed by agreement
Avoiding a network write per draft	Local and held placement

Compared with copying S3 to Walrus yourself

A copy job gives you two copies and none of this:

• Privacy. The Walrus copy is public unless you encrypted every object, under keys you now manage.
• Deletion. A blob stays readable until its span ends, unless each object had its own key, now destroyed.
• One answer. If the copy fails or the file changes first, the stores disagree. You pick the winner.
• Renewal. Every span tracked and extended, or it lapses.
• Proof. A blob ID isn’t a receipt with version history.
• A choice per file. A copy job sends everything; residency needs a per-file decision.

If two copies are all you need, build the job.

What we don’t claim

• An uptime figure. No acknowledged write is lost, but recovering from a failure is a short interruption, not a seamless switch. → How it recovers
• Bytes kept without end. Bytes last their stated span, which we renew. The receipt stays on Sui regardless.
• That the default keeps us out. By default the deployment holds the keys. To keep us out, use your own key service or encryption. With your own encryption we never see content, and you keep every receipt.