GuideReference6 min read
KEEL’s words, explained
Learn each KEEL name through its job and a concrete example. The same words apply on Ethereum and Tezos.
Select an underlined word to see what it means.
In this guide
What are you making?
Tidal Study is a drawing made by a small script. You keep the editable source. The sketch also needs a particular version of its drawing library.
A project with your files and the Parts it needs.The work, its rules, and ownership.
Start with the creative work. If it becomes a collectible release, these names explain the rules and the owned token.
- Slab
The collectible token recorded in your wallet. It identifies an owned item and points to its work.
For example: You collect Tidal Study #7. That token is your Slab; the artwork files have their own storage records.
- Rite
KEEL's name for a smart contract: published rules that the chain enforces when someone calls them.
For example: A Rite can enforce the supply limit even if a website offers a button to mint more.
- Die
The artist's token contract. It records the Slabs, their owners or balances, supply, and presentation bindings.
For example: A Die can issue a series of 100 individually identified works.
- FRAY
KEEL's auction contest between an individual bidder and a collective of patrons. The separate FRAY game project uses KEEL too.
For example: The published auction rules decide whether a unique-work or edition outcome is issued.
Keeping the files and their inventory.
Files become manageable pieces with a precise assembly record.
- Hold
KEEL's native onchain storage for the file bytes and the instructions for joining them back together.
For example: Your sketch and its shared drawing library are stored as separate objects in the Hold.
- Slug
One small piece cut from a larger file so it can be stored and recovered in manageable amounts.
For example: A large image needs several Slugs. Their order matters when rebuilding the image.
- Ingot
On Ethereum, each Slug is saved inside its own small contract, called an Ingot.
For example: The EVM Hold reads bytes from Ingots. Tezos stores Slugs in native maps instead.
- Weld
An ordered join that makes Slugs or smaller objects into a larger object.
For example: A Weld records that the first, second, and third pieces must be read in that order.
- Mark
A file's computed fingerprint, also called a digest or hash. A reader recomputes it to check the bytes.
For example: Changing the sketch's background color changes its Mark. A filename alone would not reveal that change.
- Index
The 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 example: The inventory says this revision uses this sketch and this exact library version.
Opening the work and checking it.
Verification and execution have distinct jobs. The default shell keeps their boundaries visible.
- Crucible
The verification layer. Its browser checks compare recovered files with the fingerprints and sizes the work declared.
For example: A changed script fails its check before the default shell opens it.
- Pour
One run through the Crucible's checks.
For example: Opening a work triggers a Pour for the resources that presentation needs.
- Haul
The resources recovered and accepted by those checks.
For example: The checked sketch, drawing library, and image become the Haul used to open the work.
- Harness
The composition that runs the work: its selected resources, runtime context, and isolated environment.
For example: The Harness connects your sketch to its drawing library and runs it inside the Cage.
- Shell
The opening program and interface around creator content. The canonical KEEL verification shell owns the protected checks and K controls.
For example: Open the K control to inspect the files and checks behind the displayed work.
- Cage
The isolated browser box where creator code runs. The default environment does not give it a wallet or unrestricted network access.
For example: An animated work can draw inside its box without receiving control of the gallery's wallet.
- Sleeve
Your work's name, image and details in the standard format wallets and marketplaces already know how to show.
For example: The Sleeve supplies a name and preview in the format the receiving tool expects. Full interaction still depends on that tool.
What the work can ask for.
These terms describe permission boundaries. The current default shell exposes bounded read-only information; richer requests need a supported host interface.
- Seam
The checked, limited interface across the Cage boundary.
For example: Information crossing the Seam must match the allowed shape and size.
- Knock
A request made by the work through the Seam. The request itself grants no permission.
For example: A future host capability could handle a Knock only if that action is explicitly supported and allowed.
- Guard
The declared limits on what the work may do.
For example: A Guard can limit the runtime to the declared files and read-only context.
- Accord
The permissions that all relevant parties allow together: artist, included parts, host, and chain. The most restrictive boundary still applies.
For example: A gallery that disallows network access does not acquire that permission because an artwork requests it.
Reusing and preserving the work.
Sharing a component or adding a checked copy should retain the exact resource identity and applicable rules.
- Parts
Reusable components included in a work, with their own identities and permissions.
For example: Several artworks can share the same verified drawing library.
- Inlays
Attached components that contribute to another work's composition under its rules.
For example: A game character can display an equipped item while keeping the item's own identity.
- Anchor
A record on another chain that points to one version of your work, so people can check a copy is kept there too.
For example: An Anchor may document a checked copy; an attested route additionally depends on the named parties vouching for its observation.
- Grip
How many chains are recorded as holding an Anchor. The count is meaningful alongside each record's evidence.
For example: Two listed chains do not by themselves prove that every dependency is retrievable from both.
Reading a verification verdict.
These are the lexicon’s verdicts. A particular interface should also name the checks and record it is describing. A raw artifact is a no-shell presentation choice, separate from the RawA verification verdict meaning this resource has not been tested. It makes no integrity claim.For exampleA file waiting to be checked is Raw. This differs from choosing a raw artifact with no shell.Full glossary entry → verdict.
- Raw
A verification verdict meaning this resource has not been tested. It makes no integrity claim.
For example: A file waiting to be checked is Raw. This differs from choosing a raw artifact with no shell.
- Clean
The declared resource checks passed. It is a statement about those checks, not a license, value judgment, or promise of perfect code.
For example: The received script matches the revision's Mark and length.
- Stale
A previously accepted revision has been superseded in the context being inspected.
For example: Revision 1 can still be the correct pinned version for an older Slab even when revision 2 is current.
- Slag
The resource failed verification and was rejected.
For example: A recovered image with different bytes is Slag; do not bypass the check to display it as verified.
- Burned
A record deliberately retired or destroyed through an authorized action, rather than rejected for bad bytes.
For example: Read the exact contract event: a deliberate burn is a different event from a failed verification check.
Other words you will meet.
These ordinary technical words appear alongside KEEL’s vocabulary.
| Word | Meaning |
|---|---|
| Byte | A small unit of digital data. File size is a count of bytes. |
| Artifact | An identified work, separate from the collectible token pointing to it. |
| Revision | One recorded version of a work or presentation. |
| Manifest | The structured inventory describing files, their 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 →, and relationships. |
| Module / runtime | A reusable code or data Part; a runtime runs a particular kind of work. |
| Carrier | The location and method used to recover stored bytes. |
| Metadata | Descriptive information and media references for a work or token. |
| RPC | A service through which an application reads a chain or sends an operation. |
| ABI | The machine-readable menu of an EVM contract’s methods and inputs. |
| Receipt / read-back | An inclusion record / retrieving and checking the result itself. |
| Seed | A recorded input used by a generative work or simulation. |
| Wake | Experimental recovery from Ethereum transaction history. |
Technical detail: old names and standard interfaces
Historical deployments may still use Stratus/OCA names. Existing ABIs, oca:// routes, STR3 descriptor magic, published manifest formats, and OnchFS standard entrypoints retain their exact bytes. Use KEEL’s names in explanation without renaming identifiers needed to read old data.