Spark Program | Spore Metadata Standard and Reference Validator

Spark Program | Spore Metadata Standard and Reference Validator

  1. Summary

Spore is CKB’s digital object protocol. When a creator mints a Spore, they can store arbitrary content, but the interesting use cases (DOBs, NFT collections, on-chain art) only work well across wallets and marketplaces if that content follows some shared convention. The Spore SDK defines the basic cell structure, but the metadata layer, meaning what fields to include for a name, description, image, and attributes, is left entirely to each creator today. This means every collection handles it slightly differently, wallets have to guess at the format, and new tools cannot reliably read data from older collections. This is the same problem ERC-721 metadata solved for Ethereum NFTs, and CKB has not solved it yet. This proposal delivers a minimal Spore Metadata Standard plus a reference validator tool that puts the standard into practice immediately, so adoption does not depend on trust alone.

  1. Team / Individual Profile and Contact Information

  2. Name: temsten

  3. Role: Sole developer and maintainer

  4. Background: Full-stack engineer with deep experience in TypeScript, React, Next.js, and the CKB ecosystem.

  5. Github: gabrieltemtsen (Gabriel Temtsen) · GitHub
    email : [email protected]

2. Deliverable clarity: what the tool actually is

The core deliverable is an open-source web tool where a creator pastes their Spore’s content JSON and receives an immediate check against the proposed standard, including which fields are missing or malformed, along with a preview of how that content would render in a wallet that follows the standard. Alongside the tool, the standard itself is published as a Nervos Talk post and a GitHub RFC, so the JSON schema is not just embedded in a tool but exists as a citable, versioned specification anyone can implement independently of this project.

On scope relative to DOB protocols specifically: this standard targets simple, non-generative Spores, meaning a single image, a written piece, or a small fixed collection, the same role ERC-721 metadata plays for a typical NFT. It is not a replacement for DOB/0’s DNA, Pattern, and Decoder mechanism, which already solves metadata for generative, trait-based collections, and it makes no claim about DOB/1 image-URI handling either. The relationship to both is stated explicitly in the RFC itself, so wallets and marketplace developers reading it know exactly when to use this standard versus when a DOB protocol is the more appropriate fit. This is deliberate scoping rather than an oversight: trying to cover generative DOB metadata inside a $1,000, one-month round would dilute the deliverable, so this round focuses on the gap that currently has no answer at all.

  1. How verification will work

Each time the validator checks a piece of content, it produces a small, self-contained verification bundle so the committee or any third party can confirm the result without needing to trust the tool’s UI. The bundle includes the exact content JSON that was checked, the specific schema version it was validated against, a plain list of which required and optional fields passed or failed, and a rendered preview snapshot showing what a compliant wallet would display. Because the schema itself is public and versioned in the RFC, anyone can take the same content JSON, run it against the published schema by hand or with their own script, and arrive at the same pass or fail result the tool produced. Reproducibility does not depend on the validator app staying online; it depends on the schema being public, which it is from the first milestone onward.

  1. Confirming this is a functional MVP

To state this plainly: the deliverable is a real, deployed, usable web tool, not a static demo or a write-up that can only be checked through its own output. Anyone will be able to open the validator, paste real Spore content, and get a working result during and after the grant period. The verification bundle described above exists to make review and reproducibility easier for the committee, not as a substitute for the tool actually functioning end to end. If the tool did not work as a live, usable application, no bundle would be able to compensate for that, and this proposal does not rely on that shortcut.

  1. Deliverables

The first deliverable is a draft JSON schema at version 0.1, covering a required name field, a required image field, an optional description field, and an optional attributes array of trait_type and value pairs, plus a standard identifier field so future versions are distinguishable. The second deliverable is the Nervos Talk post introducing the draft and explaining its relationship to DOB/0 and DOB/1. The third deliverable is a GitHub RFC pull request formatted for community discussion rather than an immediate final claim of standard status. The fourth deliverable is the validator web tool itself, open-sourced, accepting pasted content JSON, checking it against the schema, and rendering a wallet-style preview. The fifth deliverable is two to three example Spores minted on CKB Testnet that conform to the schema, referenced from both the RFC and the validator as working proof the shape holds up in practice.

  1. Timeline and milestones,

The grant runs four weeks total and is broken into two milestones, each tied to a specific, checkable set of outputs rather than a vague description of progress.

Milestone one covers weeks one and two and focuses on getting the standard itself into a reviewable state while building the validator’s core logic in parallel, since the validator needs a stable draft schema to check against. In week one, the JSON schema version 0.1 is drafted, covering the name, image, description, and attributes fields described in section five, and the validator’s checking logic is scaffolded against that draft. In week two, the Nervos Talk post is written and published to open the schema up for public feedback, and the validator’s wallet-style preview renderer is built so that a checked Spore can be visually previewed, not just pass or fail. By the end of week two, there is a public draft schema with an open feedback thread, and a working local version of the validator that can check content and render a preview. This milestone releases twenty percent of the total budget, which is $200, paid once the Nervos Talk post is live and the local validator build is shared with the committee for a quick sanity check.

Milestone two covers weeks three and four and focuses on turning early feedback into a stable release and proving the whole system works end to end on real content. In week three, feedback from the Nervos Talk post is reviewed and incorporated into the schema where it makes sense, any unresolved questions are documented rather than left ambiguous, and the GitHub RFC pull request is opened so the schema has a permanent, versioned home outside of a forum post. In week four, the validator is deployed publicly with a working link anyone can use, and two to three example Spores are minted on CKB Testnet using the finalized schema, with their content and transaction references linked from both the RFC and the validator itself as proof the schema and tool work together on real data. This milestone releases the remaining eighty percent of the budget, which is $800, paid once the public validator link is live and the testnet examples are minted and linked.

  1. Budget,

The total requested amount is $1,000, and it is split three ways based on where the actual time goes, not as an arbitrary round-number split.

The first portion, $400, covers schema design and RFC writing. This includes the research and drafting time to define the JSON schema itself, the writing time for the Nervos Talk post, and the time spent reading and incorporating community feedback into a revised draft before it becomes a GitHub RFC pull request. This is the largest single portion because getting the schema right, and getting the DOB/0 and DOB/1 relationship explained clearly enough that nobody misreads the scope, is the part of this project most likely to need revision.

The second portion, $450, covers building the validator tool itself. This includes writing the logic that checks a pasted content JSON against the schema and reports missing or malformed fields, building the wallet-style preview renderer so a creator can see how their content would actually display, and deploying the finished tool to a public, working URL. This is the largest technical line item because it is the one piece of this proposal that has to function correctly as software, not just as a document.

The third portion, $150, covers the testnet example Spores. This includes any minting or transaction fees needed to put two to three real, schema-conformant Spores on CKB Testnet, plus the time to build and format their content correctly so they serve as clean reference cases linked from both the RFC and the validator.

Adding these together, $400 plus $450 plus $150 equals the full $1,000 requested, matching the twenty and eighty percent milestone split described in section six: the $200 first payment covers the early portion of the schema and RFC work plus the start of validator development, and the $800 second payment covers the remainder of validator development, deployment, and the testnet examples.

  1. Success criteria

Success looks like a published RFC with a stable version 0.1 schema that has visible discussion from at least a few community members, whether creators, wallet maintainers, or marketplace developers. It also looks like a publicly deployed validator tool that correctly checks real Spore content and renders an accurate preview. Finally, it looks like two to three real testnet Spores that demonstrably use the schema, serving as reference cases anyone can inspect.

  1. Risks and mitigations

The main risk is low community engagement on the Nervos Talk post, which is mitigated by cross-posting to the Spark Program Discord channel and directly notifying known Spore SDK and DOB cookbook contributors for early feedback. A second risk is the standard being perceived as competing with DOB/0 or DOB/1, which is mitigated by addressing that relationship explicitly and early in the RFC rather than leaving it implied. A third risk is schema bikeshedding stalling progress, which is mitigated by shipping version 0.1 as an openly-labeled working draft with a fixed feedback window matching the grant’s four weeks, and documenting any unresolved questions as items for a version 0.2 rather than blocking this round on them.

  1. Relationship to future work

If this round succeeds and the schema sees real adoption or generates substantive feedback, a natural next step is extending the validator to accept a transaction hash directly, fetching and decoding on-chain content rather than requiring a pasted JSON blob, and pursuing tighter integration with wallets so compliant Spores render correctly without any manual checking at all. That work is a larger scope than fits a $1,000 Spark round and is proposed here only as a named next step, likely suited to a future Community Fund DAO application once this round has produced real usage to point to.

3 Likes