Kraterion: S3 Storage You Actually Own, Built on Walrus

We're working through the winners of the Walrus track at Sui Overflow one at a time – the teams that treated Walrus as a Verifiable Data Platform and not just a place to park bytes. After Deploy by Suize, this one is Kraterion, which takes object storage, and makes it something you can actually own.

Kraterion is a drop-in S3 API on storage that stays yours: every file becomes a Walrus blob in your own onchain pool, sealed so the platform can't read it, with access you can revoke in a single transaction. We talked to its builder, Razvan Statescu, about how you make storage that feels like AWS without inheriting the part everyone has to quietly accept – handing your data, and your leverage, to a company that can lock you out or read over your shoulder.

Where the cloud storage stops being a good deal

Renting storage from a big cloud is easy. Getting your data back out on your terms is the hard part. Cancel your subscription and your files can go with it. Get locked out of your account and they are simply gone. And the AI you point at that data reads every byte on trust: you assume the provider isn't looking, because you have no way to make sure it isn't.

Kraterion is built around the two moments a centralized provider can't match. Cancel, and your files aren't deleted – they live in an onchain pool owned by your address, and you, or anyone, can keep funding their storage directly. Revoke access, and the platform genuinely can no longer read your bytes: not a promise to stop, but threshold key servers that refuse to hand over the key. The cryptography stops working.

What Kraterion is, and who it's for

Kraterion is an S3-compatible storage platform built on Walrus, with a verifiable agent runtime on top. You point boto3, aws-cli, or rclone at it like any bucket – PUT, GET, LIST, presigned URLs, the usual – and under the hood every object becomes a Walrus blob in your own onchain storage pool, encrypted by default with Seal.

It is built for developers and startups building with AI, and it assumes no crypto knowledge. The whole thing is deliberately dressed as an ordinary dev tool: Google sign-in, credit-card billing, a drop-in S3 API.

The build challenge: mapping S3 habits onto Walrus

The main challenge was learning to think in Walrus's storage model instead of a cloud's. Kraterion's first cut gave every S3 object its own blob, prepaid for about two years in WAL. It worked, but it made small files look expensive, left deleted files paid-up, and meant renewing thousands of files one at a time.

That is less a flaw than a different set of primitives: Walrus prices storage per object, up front, by encoded size, where a cloud meters by the gigabyte. Once the team modeled around that rather than against it, the fix fell out naturally.

Inside the stack

Kraterion looks like a conventional web stack, which is the point – the interesting part is where the chain sits underneath. There is a Next.js front end, a set of Node services, and a Postgres database. What makes it Kraterion is that none of those hold the source of truth: the real record of what exists lives on Sui, the files live on Walrus, and Postgres is only a read model – a fast, queryable mirror of onchain state, not the system of record. It's one answer to a question more teams are hitting as agents start generating and depending on their own data: where AI agent data should actually live.

The services split by responsibility:

1. One owns the storage hot path: it speaks the S3 protocol, encrypts each object with Seal before it leaves the platform, and writes the ciphertext to Walrus.
2. Another owns the session side – accounts, projects, keys, billing, agents – and reads almost entirely from the mirror rather than the chain.
3. A third runs the opposite direction, following the stream of events off Sui and keeping Postgres in sync, so a write on the storage path surfaces as queryable metadata a moment later.

Tying all three together is a small Move program that defines the primitives everything else composes against: buckets, the storage pool, the access policy, and the shared balance that pays for it all.

Walrus is the storage layer in the literal sense – every file ends up as a blob there, reached through a thin ownership wrapper so the blob belongs to the user's project rather than to Kraterion. Reads and writes flow through Walrus's own relay and aggregator infrastructure, which keeps Kraterion a coordinator rather than a middleman holding your bytes.

Walrus Memory sits one level up, in the agent runtime: it is how an agent remembers across runs, exposed to the model as a simple remember-and-recall capability, with each agent's memory isolated from every other's. Because it is backed by Walrus, that memory stays owned by the user and portable across model providers – the same ownership principle Kraterion applies to files, extended to what an agent learns.

The decision worth copying: pool the storage, meter the pool

This is the fix to the economics problem above, and if you build on Walrus it is the one idea to take with you. Instead of one blob per file, Kraterion moved to Walrus's StoragePool and PooledBlob primitive: one KraterionPoolVault per project wraps a single Walrus StoragePool, funded from a shared onchain reserve. A PUT registers a blob into the pool and consumes some capacity; a DELETE frees it again, because every blob is registered deletable; and renewal is one transaction for the whole pool instead of one per file.

That single indirection is what turns Walrus's native, prepaid, per-object model into a metered resource that behaves like the pay-for-what-you-use storage people already understand – which is what lets Kraterion put a normal per-gigabyte bill in front of it.

The advice to another builder is exactly that: don't expose Walrus's raw economics to your users. Pool the storage, and meter the pool.

Why Walrus, and not their own storage

For Kraterion, ownership and verifiability are the product, not a feature bolted on afterwards – and running its own storage would have quietly reintroduced the lock-in and "trust us" privacy it sells against. Walrus gave three things Kraterion couldn't replicate itself:

• Blobs are genuinely owned by the user's address, so cancelling Kraterion doesn't delete anyone's data.
• Erasure coding makes it cost-efficient: RedStuff, Walrus's erasure-coding scheme, keeps the replication factor low, so storing at scale costs materially less than on networks that rely on full replication. You can check the numbers for your own workload with the Walrus cost calculator.
• Storage is programmable, tied to Sui objects, which is the part that lets Seal make revocation a cryptographic fact instead of a policy.

Walrus Memory extends the same idea to agents. Agent memory today is trapped in a vendor's database, tied to one model provider. Backed by Walrus, it becomes user-owned, portable across OpenAI, Anthropic, and the rest, and verifiable – the only version of agent memory that fits a platform whose whole pitch is that you own your data and your logs.

What Walrus made easy

Three things paid off – free reads, real revocation, and unexpectedly programmable storage.

Reads turned out to be basically free: a single aggregator GET per read, no fanout, so the gateway stays cheap on the hot path – the mirror image of the per-object cost that made writes hard.

Seal made "we can't read your data" true. The team expected access control to end up as a best-effort policy; instead seal_approve runs as an onchain check the key servers enforce, so revoking a key is a property of the cryptography, not a promise.

The storage turned out far more programmable than expected. Going in, the team pictured Walrus as any object store – somewhere to put bytes and get them back – and assumed the interesting logic would live in their own code. Instead they could wrap Walrus's storage primitive in their own Move type, fund it from a balance they control, and enforce their own write and access rules onchain. That is what let ownership and revocation be real properties of the system rather than lines in a privacy policy, and it is ultimately what made the product possible.

Rough edges & lessons learned

The rough edges were all economic, and they trace back to the same root: encoded bytes and billing quantity are not the same number, and it is easy to conflate them – the 92%-on-a-9%-pool gauge bug was exactly that mistake. Small files stay disproportionately expensive if you ever store them one-to-one, which is what the pool is there to absorb.

Two lessons came out of it. The first is tactical: model the encoded-size and epoch economics before you design billing and UX, not after. Storage on Walrus is closer to programmable money than to a disk you rent, and encoded capacity and WAL are first-class constraints. The second is architectural: design your product without compromising the primitives underneath it. The hard part isn't wiring up Walrus, Seal, or Sui – it is building something smooth and familiar on top without quietly giving the guarantees back. Holding the keys yourself because it's simpler, letting the off-chain mirror drift into becoming the real source of truth, adding a custodial shortcut "just for now" – each is a small UX win that hollows out the thing you're selling. If a feature can only exist by breaking the primitive, that's the signal to find a different design, not to break the primitive.

What's next for Kraterion

The roadmap is three phases, in order: Mainnet, then private access, then public. Mainnet is the big one – moving off Testnet onto production storage so the ownership Kraterion keeps demonstrating stops being a demo and starts being something you'd trust with files that matter. From there the doors open deliberately: an invite-only cohort of early builders who help harden the platform under real usage and shape what it becomes, then general availability once the rough edges are sanded down. It's a measured rollout on purpose – when your whole pitch is that people can trust you with their data, you earn that one careful step at a time.

Further out, is a deeper Walrus Memory build: verifiable, portable agent memory as a real product surface, with onchain session anchoring, so an entire agent run can be replayed against the exact Walrus-stored inputs it saw.

Build with Walrus

Walrus is the Verifiable Data Platform for AI builders: the foundation to store and manage your data, persistent, portable, and under your control across apps, providers, and agents. Start with the Walrus quickstart, or bring questions to the Discord.

About Walrus

Walrus is a Verifiable Data Platform for builders in AI and onchain finance. No more fragile foundations: Walrus finally makes it possible to verify where data came from, prove it hasn't been tampered with, and know it's always available, without compromising on speed. It is the foundation for applications where unverifiable data can cause irrecoverable losses. The more we trust AI and onchain finance with our money and decisions, the more mission-critical this becomes. Created by the ex-Meta engineers behind Sui.