How it works

Architecture

Three Sui technologies do real work together: Sui holds ownership and access policy, Seal handles encryption, and Walrus stores the bytes. This is what lets Kraterion make a promise a normal cloud can't — that it cannot read your files once you say so.

Ownership model

Each bucket is a Sui shared object, KraterionBucket. It records an owner (your account), a visibility mode, and a list of addresses allowed to decrypt — its api_decryption_addresses. Creating a bucket sets the owner to whoever signs, which is why bucket creation needs your zkLogin signature and can't happen over the anonymous S3 path.

Seal encryption

When you upload, the gateway encrypts the file with a fresh key and then seals that key with Seal — an identity-based scheme whose decryption keys are split across independent key servers. The identity an object is sealed to is derived from its bucket and object id, so a sealed key is bound to exactly one object in exactly one bucket. The ciphertext is what goes to Walrus.

The approval policy

To decrypt, a caller has to satisfy an on-chain policy — a Move function, seal_approve. The Seal key servers run it before releasing their shares. Its logic is small and the whole point of the system:

// Simplified. The key servers evaluate this before
// handing over any decryption shares.
public fun seal_approve(id, bucket, ctx) {
    assert!(identity_belongs_to(id, bucket));
    if (bucket.is_public()) return;          // anyone may decrypt
    let caller = ctx.sender();
    assert!(
        caller == bucket.owner
        || bucket.api_decryption_addresses.contains(caller)
    );
}

For a private bucket, only the owner or an address on the decryption list passes. If the caller isn't on the list, the policy aborts and no shares are released — there's nothing to decrypt with.

Walrus storage

The encrypted bytes are stored on Walrus and identified by a content address (the blob id). Because storage is content-addressed, the same blob id always refers to the same bytes — which is what makes the content hashes in citations meaningful. The gateway pays for storage from a platform reserve, so you don't handle tokens to upload a file.

Pools & renewal

Walrus storage is paid for in epochs and would otherwise expire. Kraterion groups a project's blobs into a storage pool and renews the pool ahead of expiry, so your files stay alive without per-file babysitting. Renewal runs continuously in the background.

The revocation guarantee

Revoking API access calls revoke_all_api_access on your bucket, which empties the decryption list on-chain. After that, the gateway's address no longer passes seal_approve, so the key servers refuse to release shares and the gateway genuinely cannot decrypt your files — not by policy, but by cryptography. The gateway also keeps a fast database flag mirroring this, so revocation takes effect instantly while the on-chain state is the durable, independently-verifiable source of truth. Your own browser session keeps working, because you are still on the list.

Cancellation persistence

The same ownership model means cancelling Kraterion doesn't delete your data. The buckets are objects at your address and the blobs are stored under your account on Walrus; they exist independently of your subscription. The platform can stop serving the API, but it was never holding your files hostage to begin with — they remain yours, on-chain.