GuideSystem3 min read
The Hold: storing a work
The HoldKEEL's native onchain storage for the file bytes and the instructions for joining them back together.For exampleYour sketch and its shared drawing library are stored as separate objects in the Hold.Full glossary entry → stores the files. SlugOne small piece cut from a larger file so it can be stored and recovered in manageable amounts.For exampleA large image needs several Slugs. Their order matters when rebuilding the image.Full glossary entry → make them manageable; WeldAn ordered join that makes Slugs or smaller objects into a larger object.For exampleA Weld records that the first, second, and third pieces must be read in that order.Full glossary entry → put the pieces back in order.
Select an underlined word to see what it means.
In this guide
A large file becomes manageable pieces.
The tooling splits the prepared file into Slugs for the selected storage route. You keep thinking about the work; the storage planner handles the pieces.
Watch the 16-second storage film
Cut the prepared file into Slugs. Cast them into the EVM Hold. Weld the references in order. Recover the files, check their Marks, and open the accepted work.
Keep every needed file in the inventory.
Tidal Study needs its sketch and a drawing library. A game may also need music, models, and textures. KEEL records these as separate resources so a reader knows exactly what to recover.
Large files can be cut into SlugOne small piece cut from a larger file so it can be stored and recovered in manageable amounts.For exampleA large image needs several Slugs. Their order matters when rebuilding the image.Full glossary entry →. A WeldAn ordered join that makes Slugs or smaller objects into a larger object.For exampleA Weld records that the first, second, and third pieces must be read in that order.Full glossary entry → records how those pieces or smaller objects join together. These connections form the object graph: the work’s assembly plan.
Pack smaller, then check what comes back.
Compression packs a file into fewer bytes. Decompression restores it. KEEL can check both the packed file and the restored file by their sizes and MarkA file's computed fingerprint, also called a digest or hash. A reader recomputes it to check the bytes.For exampleChanging the sketch's background color changes its Mark. A filename alone would not reveal that change.Full glossary entry →.
Think of checking a sealed parcel, then checking its contents. The browser needs the declared decoder (the program that unpacks it) before the art can use those restored bytes.
Current codec boundaries
Compression options include none, gzip, deflate, and Brotli. The small p5 path uses the registered gzip profile. Brotli requires a matching decoder as a declared Part. Choose a compression format whose decoder is available alongside the work on your selected chain.
Know what recovery depends on.
Native storage means file bytes are kept in the selected chain’s HoldKEEL's native onchain storage for the file bytes and the instructions for joining them back together.For exampleYour sketch and its shared drawing library are stored as separate objects in the Hold.Full glossary entry →. Other carriers may use a file network or a declared mirror. Each has its own availability and retrieval path.
The IndexThe sealed inventory and presentation records that identify the work's pieces and their Marks. This protocol layer is different from the site's search indexer.For exampleThe inventory says this revision uses this sketch and this exact library version.Full glossary entry → records what the reader expects. The CrucibleThe verification layer. Its browser checks compare recovered files with the fingerprints and sizes the work declared.For exampleA changed script fails its check before the default shell opens it.Full glossary entry → checks what actually arrives. A matching MarkA file's computed fingerprint, also called a digest or hash. A reader recomputes it to check the bytes.For exampleChanging the sketch's background color changes its Mark. A filename alone would not reveal that change.Full glossary entry → proves the recovered content; it does not keep an unavailable server online.
| Path | What the reader depends on |
|---|---|
| Native KEEL objects | The selected chain’s committed objects and a compatible reader |
| IPFS / declared mirror | A provider that can return bytes matching the commitment |
| HTTPS cache | Availability of the cache, with independent byte checks |
| Wake · experimental | Ethereum history or verified archives, transaction evidence, and the Wake reader |
Wake recovers from transaction history.
Wake is an experimental route that places payloads in Ethereum transaction history and records commitments to them. A suitable reader recovers that history and checks the bytes.
This differs from asking the HoldKEEL's native onchain storage for the file bytes and the instructions for joining them back together.For exampleYour sketch and its shared drawing library are stored as separate objects in the Hold.Full glossary entry → contract for its stored content. A contract cannot read an old transaction’s payload just because it knows the hash. Historical data and a compatible recovery path must be available.
Storage and opening are two decisions.
Inline delivers the complete prepared presentation with the token read. Hybrid starts the presentation and retrieves the declared objects through a chain reader.
Both can use native onchain files. Hybrid describes how they are delivered, and does not silently select IPFS.
- 01Inline
The complete presentation arrives when the token is read
- 02Hybrid
The browser retrieves and checks the stored pieces
- 03IPFS access
A chosen gateway reaches files stored on IPFS
- 04Raw artifact
Open the original media directly, without a Shell
Technical detail: EVM and Tezos carriers
On EVM, IngotOn Ethereum, each Slug is saved inside its own small contract, called an Ingot.For exampleThe EVM Hold reads bytes from Ingots. Tezos stores Slugs in native maps instead.Full glossary entry → contracts carry bytes and KeelHold uses ordered descriptors and bounded WeldAn ordered join that makes Slugs or smaller objects into a larger object.For exampleA Weld records that the first, second, and third pieces must be read in that order.Full glossary entry →. On Tezos, native SlugOne small piece cut from a larger file so it can be stored and recovered in manageable amounts.For exampleA large image needs several Slugs. Their order matters when rebuilding the image.Full glossary entry → are held in big_maps; KeelHoldOnchFS additionally speaks the published OnchFS interface. The native Tezos carrier recovers files through its own object format.