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/Tools·4 min read

The SDK: KEEL from code

Use KEEL’s engine from your own code: prepare projects, reuse 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 →, read chain values, build previews, and plan releases.

Select an underlined word to see what it means.

In this guide
What is an SDK?Start with the decisions you already know.A plan becomes a build, then a review.Choose the right environment for the code.Let a chain value become part of the work.Build tools around the engine.

“I want the engine inside the tools I already build.”

Turn project choices into files, previews, reusable Parts, and a reviewable release plan.
CHAIN DATA / FROM A VALUE TO A VISUALTRY THE IDEA
01 / CHOOSE A VALUE02 / PREPARE BEFORE DRAWING
// Prepared data snapshot
// KEEL.data contains:
// { supply: 8 }

// Your drawing reads it
rings = KEEL.data.supply

In a real prepared layer, the values are frozen and include the source chain and block.

03 / THE WORK RESPONDS8 rings from one named value
Local interactive example. Moving the slider changes sample data, not a contract or a live chain read.

What is an SDK?

SDK means software development kit. KEEL’s SDK gives an application ready-made functions for describing a project, checking inputs, finding required 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 preparing contract review data.

You can use a creator interface without writing code. If you are building an interface yourself, the SDK lets you express the same decisions in a program.

ToolIts job in the workshop
SDKDescribe the work and prepare its choices and contract data.
BuilderInspect files and assemble the exact resources and outputs.
ProtocolDefine the shared records, fingerprints, and data rules.
ViewerRecover resources and reconstruct the presentation.
Studio CoreSupport the site’s preparation, delivery, and publication workflows.
MCPLet an assistant call a bounded set of these tools.
Technical detail: package entry points

Use the package whose job matches your integration. Some preparation packages require Node.js.

PackagePurpose
@keel/sdkPlanning, validation, presentation, and contract helpers
@keel/builderLocal builds, verification, cost models, and upload plans
@keel/protocolPortable types, canonical data, integrity
@keel/viewerResource recovery and presentation reconstruction
@keel/studio-coreShared Studio workflow primitives
@keel/mcpTool and resource server for assistants

Start with the decisions you already know.

Describe the work and ask for a plan. The planner keeps supplied choices and returns missing questions, required modules, and next tools. It can tell you what is needed before a full chain or sale decision is made.

In the example below, the result is a local plan for Tidal Study. It needs the drawing library and seed utility. A seed is an input used to make a generated result reproducible.

FOR EXAMPLE

Plan a generative drawing

You tell the planner: “Tidal Study, explore locally, using p5.”

It identifies p5 and KEEL’s seeded-random Part, and suggests analysis and library discovery. It does not upload files or mint a 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 →.

What this means for you: A useful plan tells you what to do next and which decisions remain yours.

Technical example: run a local SDK plan (no upload)
Technical example: run a local SDK plan (no upload)
import { planKeelProject } from "@keel/sdk/engine";

const plan = planKeelProject({
  title: "Tidal Study",
  outcome: "explore",
  runtime: "p5",
});

console.log(plan.nextQuestions);
console.log(plan.modules.required);
console.log(plan.nextTools);
// Inspect the questions and suggested tools before building.

A plan becomes a build, then a review.

Resolve the required 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 → to exact versions on the selected chain. Build the intended ShellThe opening program and interface around creator content. The canonical KEEL verification shell owns the protected checks and K controls.For exampleOpen the K control to inspect the files and checks behind the displayed work.Full glossary entry → and resource composition, preview it, and retain the identities of the source and output.

If the current publication path cannot find its registered shell or 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 →, it must explain what is missing. It must not create an unannounced replacement shell.

Choose the right environment for the code.

Some SDK helpers prepare local files and need Node.js, the program that runs JavaScript outside a browser. A webpage should import the browser-compatible entry point for its particular job.

The setup below is for a source checkout. After building it, run the local planning example from an application that links the SDK package.

Technical detail: source setup and browser imports

The source workspace specifies Node.js 22+ and pnpm 10.15.0. Install and build inside the keel-sdk checkout. The root SDK import includes Node-oriented code; browser consumers should use the documented /engine, /presentation, /contract-controls, or /abi entry point for their task. The /inline-viewer-graph build path is Node-side preparation.

Example
# Run inside your keel-sdk source checkout.
pnpm install
pnpm build

# Then run the planning example in a linked consumer package.
# No chain publication is performed by that example.

Let a chain value become part of the work.

A character’s health can set its glow. A collection’s supply can change a drawing. The SDK can read supported contract values and prepare them as named variables before the artwork starts.

The prepared data layer records the chain and block it came from. It is a snapshot for that build. A continuously updating work needs an explicitly designed refresh path.

Source detail: data before drawing

readOnchainData performs the reads. buildOnchainDataFragment emits a classic script in the data phase. assertOnchainDataRoundTrip checks what that script publishes. The sandbox reports the decoded data layer and variables without executing project source in its host process. See the Chain data guide for the supported types and build order.

Build tools around the engine.

Modules are 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 → used by the work, such as a runtime or data layer. Editor and SDK plugins are the planned way to extend the tools around that work: a custom inspector, workflow, or admin panel.

Keep those two extension points separate. A future editor plugin is not a requirement for a collector to open an artwork.

KEEP EXPLORING

Chain data: let the work respond→MCP: working with an assistant→Parts, modules & shared code→The editor: bring it all together→
← PreviousImages, code & worldsNext →Chain data: let the work respond

ON THIS PAGE

What is an SDK?Start with the decisions you already know.A plan becomes a build, then a review.Choose the right environment for the code.Let a chain value become part of the work.Build tools around the engine.