Products built from modules
Integrate an application profile or FRAY release.
The contract manifests declare CoolS, Canvas, LINE, Onchaininator, and Vault Runner application profiles with uneven source, test, and deployment evidence. FRAY is a separate source-bound contest service and release classification integrated into Keel.
Shared data and state model
Applications bind product-specific state back to exact Keel identities.
Collection applications
Collection/token, permanent seed, artifact/viewer/presentation revisions, renderer/code identity, release/access policy, and conventional metadata form the collectible surface.
Composable applications
Source tokens, object revisions, graph edges, equipment/loadout, stake runtime, and visual context remain individually inspectable inside a composed result.
Service applications
FRAY binds source digest, chain/currency, unique/patron outcome, reserve, increment, timing, royalty, edition size, patron pricing, extension rules, participants, and settlement state.
Choose the application integration
Start with the product state your host must read or write. Each profile names its manifest, source/test boundary, deployment evidence, authority, and open constraints.
CoolS
The app manifest and generated ABI describe a generative KEEL721 collection with a mint hook, target table, novelty ledger, visual registry, metadata renderer, release resolver, equipment provisioning, and freeze closure.
- Source boundary
- The manifest declares keel-contracts/src/apps/cool-s, but that directory is absent in the inspected checkout.
- Manifest
- keel-contracts/apps/cool-s/keel.module.json
- Tests
- The manifest declares keel-contracts/test/apps/cool-s; that path is absent in the inspected checkout. SDK ABI/readiness checks exist in keel-sdk/tests/cool-s-abi-conformance.test.mjs and keel-site/apps/studio/tests/unit/cool-s-sdk.test.ts.
- Deployment
- No app deployment JSON is present in the inspected checkout.
- The declared mint model binds seed, target-family selection, visual revision, renderer/viewer closure, and backed equipment provisioning.
- The declared authority model keeps collection configuration, generator behavior, linked libraries, and freeze state separate.
- Studio blocks release when viewer compatibility is false, and G0 entropy remains explicitly unproven.
Source · Partial
keel-contracts/apps/cool-s/keel.module.json ↗Keel Canvas
The app manifest describes a shared canvas collection, renderer, splitter, composer, and mint controller for committed CoolS and LINE visual inputs.
- Source boundary
- The manifest declares keel-contracts/src/apps/keel-canvas, but that directory is absent in the inspected checkout.
- Manifest
- keel-contracts/apps/keel-canvas/keel.module.json
- Tests
- The manifest declares keel-contracts/test/apps/keel-canvas; that path is absent in the inspected checkout.
- Deployment
- No app deployment JSON is present in the inspected checkout.
- The declared read model includes source-token bindings, split/composition state, and rendered output.
- The declared authority model gives the token/controller only the named source-input and mint-policy transitions.
- Source, tests, and deployment proof are required before presenting these declared behaviors as implemented.
Source · Specified
keel-contracts/apps/keel-canvas/keel.module.json ↗LINE
The app manifest describes a KEEL721-derived line collection with an on-chain thumbnail object and renderer designed to compose through Canvas interfaces.
- Source boundary
- The manifest declares keel-contracts/src/apps/line, but that directory is absent in the inspected checkout.
- Manifest
- keel-contracts/apps/line/keel.module.json
- Tests
- The manifest declares keel-contracts/test/apps/line; that path is absent in the inspected checkout.
- Deployment
- No app deployment JSON is present in the inspected checkout.
- The declared read model includes token ownership, thumbnail source, and renderer result.
- The declared authority model keeps collection mint/renderer control separate from Canvas consumption.
- A thumbnail remains a rendition, but source and tests are required before claiming exact implementation behavior.
Source · Specified
keel-contracts/apps/line/keel.module.json ↗Onchaininator
The app manifest describes a preservation token, factory, and proof ledger for a source ERC-721. Its contract and deployable lists drift around PreservationBounty and OnchaininatorProofRenderer, so neither is treated as a current deployable fact.
- Source boundary
- The manifest declares keel-contracts/src/apps/onchaininator, but that directory is absent in the inspected checkout.
- Manifest
- keel-contracts/apps/onchaininator/keel.module.json
- Tests
- The manifest declares keel-contracts/test/apps/onchaininator; that path is absent in the inspected checkout.
- Deployment
- No app deployment JSON is present in the inspected checkout.
- The declared read model binds original collection/token identity, preserved artifact, and proof state.
- Publishing a preservation token and proof still requires exact source, tests, deployment, and receipt evidence.
- A wrapped token does not transfer authorship or IP rights, and URI/pixel evidence remains separately labelled.
Source · Specified
keel-contracts/apps/onchaininator/keel.module.json ↗Vault Runner
The EVM app manifest and generated ABI describe characters, mint seeds, sprite catalogs, packs, items, equipment, game cards, maps, achievements, auctions, deterministic runs, loot, leaderboards, and custody. The Tezos package contains the inspected native source and tests.
- EVM source boundary
- The manifest declares keel-contracts/src/apps/vault-runner and test/apps/vault-runner, but both paths are absent in the inspected checkout.
- EVM manifest
- keel-contracts/apps/vault-runner/keel.module.json
- EVM deployment
- keel-contracts/apps/vault-runner/deployments/11155111.json
- Tezos source/tests
- vault-of-the-fallen/packages/vault-tezos/contracts/vault.py; tests/test_vault.py; tests/test_vault_hardcore.py; tests/test_stake_object.py
- The declared EVM model and implemented Tezos model bind character seed, catalog revisions, loadout, map build/root, run commitments, score policy, and custody outcome.
- The Tezos implementation separates player authorization, collection/map/game authority, and signature-reporting scopes.
- The leaderboard and hardcore result remain signer-trusted, commit-reveal is not VRF, and Tezos positive browser evidence is Octez mockup replay rather than accepted Shadownet release proof.
Source · Recorded testnet deployment
keel-contracts/apps/vault-runner/keel.module.json; vault-of-the-fallen/packages/vault-tezos/README.md ↗FRAY is a service relationship, not a contract app
FRAY is a source-bound timed contest and release classification integrated through its own auction contracts and indexer. Keel prepares, displays, verifies, and hands off the full policy; it does not redefine FRAY as storage, OneMint, or KeelMarket.
- Policy source
- keel-sdk/packages/sdk/src/fray-auction-intent.ts
- Agent source
- keel-sdk/packages/mcp/src/fray-agent.ts; keel-sdk/skills/fray-keel-agent/SKILL.md
- Studio source
- keel-site/apps/studio/src/server/services/fray-contract-service.ts; apps/studio/src/app/fray/; apps/studio/src/app/studio/fray/new/
- Tests
- keel-sdk/tests/sdk-fray-auction-intent.test.mjs; mcp-fray-auction-intent.test.mjs; keel-site/apps/studio/tests/unit/fray-tabs-accessibility.test.ts
- A FRAY binds the exact source digest and full chain/currency/reserve/increment/timing/royalty/patron/edition/pricing/extension policy.
- Quick test is bidder-only; Standard and Collector add visible patron-edition economics. Preset labels are shorthand, never authority.
- The current EVM contract/indexer room does not prove a live Tezos contest; a prepared intent is not a published auction; the agent never signs or spends.
Source · Partial
keel-sdk/packages/sdk/src/fray-auction-intent.ts ↗Reads, writes, and authority
Product actions stay within the module that owns their state.
Collection actions
Mint, transfer, freeze, presentation revision, and equipment configuration use collection/factory/mint/presentation/equipment authority rather than application-server flags.
Game actions
Stake, enter, authorize session, report result, resolve custody, extract loot, and update leaderboard each have separate exact state and role requirements.
FRAY actions
Prepare source and full policy, inspect live contest state, choose bidder or patron side, simulate the exact contract call, approve in the wallet, and confirm the receipt. Preparation alone performs no spend.
const intent = materializeFrayAuctionIntent({
source,
family: "ethereum",
network: "sepolia",
chainId: 11155111,
presetId: 2,
});Failure and security boundaries
Applications inherit every proof boundary of their dependencies.
No release by appearance
A rendered preview, local collection, prepared FRAY, or deployment JSON is not a live independently verified release.
No silent source substitution
A thumbnail, preview, generated placeholder, indexer record, or stale carrier must not replace the exact committed work.
No authority blending
Artist profile, collection admin, game reporter, module reviewer, marketplace operator, FRAY indexer, and Studio operator remain separate actors.
Ethereum and Tezos realizations
Vault is the deepest dual-family application; the other app manifests are currently EVM-centered.
Ethereum
All five app profiles have EVM manifests, but the manifests' declared src/apps and test/apps paths are absent in the inspected checkout. Vault Runner alone has a tracked Sepolia deployment JSON. The other four have no checked app deployment record here.
Tezos
Vault has a native FA2/SmartPy game lane and local browser package. FRAY policy supports Tezos terms, but accepted live Tezos contest execution is not established here.
SDK and Studio surfaces
Apps reuse the same manifests, viewer, receipts, catalogs, and wallet boundaries.
SDK
Generated app ABIs, CoolS readiness checks, Sprite Codex, stake-object model, FRAY intent policy, wallet requests, and viewer adapters expose app-specific behavior without baking it into the core protocol.
Studio
Public app/gallery/collection/FRAY/market/leaderboard pages and creator preparation routes project exact product state while keeping unavailable sources and partial feeds visible.
Exact evidence boundary
Application status is intentionally uneven.
Vault Runner
A tracked EVM Sepolia deployment manifest plus Tezos source, SmartPy scenarios, and local/mockup browser evidence. The EVM app source/test paths are absent, and this does not establish accepted cross-chain release parity.
CoolS
Manifest, generated ABI/readiness tests, and an explicit Studio release blocker. The declared app source/test paths are absent; entropy/fairness and public deployment remain separate proof gates.
Canvas, LINE, Onchaininator
Manifests describe these apps, but their declared source/test directories and deployment records are absent in the inspected contract checkout. Onchaininator's contract/deployable lists also drift around bounty and proof-renderer names.
FRAY
Policy and MCP tests plus EVM contract/indexer product integration. A prepared/test room is not an independently published contest, and Tezos execution remains separate.

