GalleryFRAYActivityLeaderboardStudio
GalleryArtistsFRAYActivityLeaderboardCode modulesHow it worksMy claimsStudio

Discover, collect and make digital art that lives onchain. Built on KEEL, so every work stays viewable without depending on any one website.

Creative toolsPreserveDocumentationHow we verifyCode modulesLook up a workYour profile
OnKeel Guide
⌕/
Browse documentation
Overview

Start here

One engine. A connected creative world.Your work, your choicesThe Shell & Harness

Create

Revisions, freezes & preservationKEEL collections & mintingThe launchpad: from work to releaseThe marketplace: after the mintYour artist page & creative identityCosts, reads & interrupted uploads

System

The Hold: storing a workThe Crucible: checks & permissionsParts, modules & shared codeInline, Hybrid & direct mediaEthereum, Tezos & AnchorsKEEL on Ethereum / EVMKEEL on Tezos / TEZThe Index & discoveryThe Rites: contract map

Tools

Images, code & worldsThe SDK: KEEL from codeChain data: let the work respondMCP: working with an assistantThe editor: bring it all together

Projects

FRAY: KEEL’s auction systemOnchaininator: preserving existing work

Reference

The design language: one word, one jobKEEL’s words, explainedWhen something does not open
Overview

Start here

One engine. A connected creative world.Your work, your choicesThe Shell & Harness

Create

Revisions, freezes & preservationKEEL collections & mintingThe launchpad: from work to releaseThe marketplace: after the mintYour artist page & creative identityCosts, reads & interrupted uploads

System

The Hold: storing a workThe Crucible: checks & permissionsParts, modules & shared codeInline, Hybrid & direct mediaEthereum, Tezos & AnchorsKEEL on Ethereum / EVMKEEL on Tezos / TEZThe Index & discoveryThe Rites: contract map

Tools

Images, code & worldsThe SDK: KEEL from codeChain data: let the work respondMCP: working with an assistantThe editor: bring it all together

Projects

FRAY: KEEL’s auction systemOnchaininator: preserving existing work

Reference

The design language: one word, one jobKEEL’s words, explainedWhen something does not open

Guide/System·3 min read

Inline, Hybrid & direct media

Choose how the files reach the browser, separately from where the files are stored.

Select an underlined word to see what it means.

In this guide
One delivery or several reads?Shared Parts stay shared.Do not wrap the same content repeatedly.Measure the whole package.

“It works on my laptop. What reaches a collector?”

Choose how the browser receives the files, then test the complete result.
Same work. Different delivery paths.SYSTEM MAP
  1. 01Inline

    The complete presentation arrives when the token is read

    →
  2. 02Hybrid

    The browser retrieves and checks the stored pieces

    →
  3. 03IPFS access

    A chosen gateway reaches files stored on IPFS

    →
  4. 04Raw artifact

    Open the original media directly, without a Shell

Storage and presentation are separate choices. Hybrid can retrieve the work entirely from its chosen chain.

One delivery or several reads?

With Inline, the token’s prepared presentation already contains what the work needs to open. With Hybrid, the browser first opens a small shell and then asks chain readers for the exact remaining objects.

An RPC is simply a service used to read a chain. Hybrid needs those reads to be available and permitted by the host. An explicit IPFS route uses a different file-delivery network.

PresentationDelivery after the token readStorage meaning
InlineThe complete document already carries its resourcesMay reuse native KEEL objects during assembly
HybridThe browser reads exact objects through RPCCan still be entirely native onchain storage
IPFSA gateway/provider supplies the selected document or graphAn explicit external dependency
Raw artifactA compatible reader opens the artifact descriptor directlyNo shell; still independently releasable and readable
FOR EXAMPLE

Two ways to open Tidal Study

The sketch and library are both stored in 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 →.

Inline assembles them into the returned presentation. Hybrid lets the browser retrieve the same declared objects after opening.

What this means for you: Several browser reads do not mean the artwork was moved offchain.

Shared Parts stay shared.

The builder can assemble a complete presentation from stored shell fragments, shared PartsReusable components included in a work, with their own identities and permissions.For exampleSeveral artworks can share the same verified drawing library.Full glossary entry →, and your creator file. A complete returned document does not require storing a new copy of every library for each SlabThe collectible token recorded in your wallet. It identifies an owned item and points to its work.For exampleYou collect Tidal Study #7. That token is your Slab; the artwork files have their own storage records.Full glossary entry →.

For a standalone image, video, or self-contained 3D model, the direct-media route uses the original file and the registered display Part. You do not need to invent a new HTML wrapper just to show a picture.

Do not wrap the same content repeatedly.

Sometimes the page that opens your work has to travel inside the token’s own description. OnKeel stores it in a compact form, so it is not wrapped again and again. That keeps it smaller and cheaper to store.

Images, sound, and other media files still travel in their own format.

Technical detail: envelopes and builders

A presentation sometimes carries HTML inside a larger metadata document. The compact saver keeps that inner content close to its original form and escapes only the characters its envelope requires, which avoids extra layers of encoding. Binary files still need their declared packing, and the outer metadata document has its own encoding rules. Raw-percent Inline assembly uses a registered builder and matching fragments on the chosen chain. Earlier Base64 and percent builders use different formats. Prepared bytes must match the format expected by the selected builder.

Measure the whole package.

A small sketch can produce a much larger response once the player, preview, and metadata are included. Check the complete token response and the work needed for the chain reader to return it.

The SDK can recommend a delivery mode from measured size, but a selected mode remains an explicit choice. A recommendation should explain its reason.

Technical detail: current SDK read limits

KEEL defaults automatic presentation to Inline at up to 1,750,000 compressed asset bytes. The complete tokenURI compatibility ceiling is 2,000,000 bytes. Read gas is bounded by the smaller of 60,000,000 and the selected chain’s latest block gas limit; the actual provider can be stricter. These are KEEL reader budgets, not token-standard file-size rules or prices. Measure the complete token response against the selected network and provider.

KEEP EXPLORING

The Hold: storing a work→The Shell & Harness→The SDK: KEEL from code→
← PreviousParts, modules & shared codeNext →Ethereum, Tezos & Anchors

ON THIS PAGE

One delivery or several reads?Shared Parts stay shared.Do not wrap the same content repeatedly.Measure the whole package.