Spark Program | Spore Metadata Standard and Reference Validator
Applicant: Gabriel_Temsten. Program: CKB Eco Fund, Spark Program. Requested amount: $1,000. Duration: 3 to 4 weeks. Category: Developer Tools / Core Protocol Conventions.
- 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.
- Final deliverables, stated explicitly
There is one schema, not two. This project produces a single JSON metadata schema for non-generative Spores, refined once based on community feedback before being finalized. It does not involve converting existing Spore content into a schema, and it does not involve creating a second, separate schema later. The two milestones described in this proposal are two stages of building the same schema and the same tool, not two different outputs. At the end of the project, the community receives exactly three things, and nothing beyond these three: first, a single finalized JSON metadata schema, published as a GitHub RFC pull request, defining a required name field, a required image field, an optional description field, and an optional attributes array of trait_type and value pairs, along with a version identifier field. Second, a live, publicly deployed validator web tool where anyone can paste a Spore’s content JSON and immediately see whether it conforms to that schema, with specific errors for any missing or malformed fields, plus a rendered preview of how the content would display in a wallet that supports the schema. Third, two to three real Spores minted on CKB Testnet that conform to the finalized schema, linked from both the RFC and the validator tool as working reference cases anyone can inspect.
- How the two milestones connect to this one outcome
Milestone one produces a draft version of the same schema described above, published for public comment, alongside an early working build of the same validator tool checking content against that draft. Milestone two does not start a new schema or a new tool. It takes the exact same schema and revises it based on whatever feedback came in during milestone one, then finalizes it as the version that ships in the GitHub RFC. It takes the exact same validator and finishes deploying it against that finalized schema, and it produces the testnet examples using that same finalized schema. Nothing produced in milestone one is discarded or replaced in milestone two; milestone two is milestone one’s output, refined and completed. The reason this project is split into two milestones at all is so that community feedback on the schema, gathered publicly during milestone one, can actually shape the version that gets finalized, rather than the schema being decided in isolation and only shown to the community after the fact.
- 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 finalized 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 during milestone one and finalized as a GitHub RFC pull request in milestone two, 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.
- How verification will work
A reviewer can confirm this project’s outcome with three concrete actions. First, open the published GitHub RFC pull request and confirm a single, versioned JSON schema is defined with the fields listed in section two. Second, open the live validator tool, paste a sample content JSON that matches the schema, click validate, and see a pass result with a rendered preview; then paste a sample missing a required field and see a specific, named error rather than a generic failure. Third, open one of the linked testnet Spores, confirm its content matches the finalized schema, and confirm the validator tool returns a pass result for that exact content. Each of these three checks is independently reproducible by anyone, at any time after the project completes, without needing to trust this write-up.
- 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 steps in section five exist to make review easier for the committee, not as a substitute for the tool actually functioning end to end.
- Timeline and milestones, explained in detail
The grant runs four weeks total and is broken into two milestones, each producing progress toward the same three final deliverables listed in section two, not separate or parallel outputs.
Milestone one covers weeks one and two. In week one, the JSON schema draft version 0.1 is written, covering the name, image, description, and attributes fields described in section two, 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 draft schema up for public feedback, and the validator’s wallet-style preview renderer is built so that checked content can be visually previewed, not just marked 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 against that draft 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. In week three, feedback from the Nervos Talk post is reviewed and incorporated into the same schema draft, any unresolved questions are documented rather than left ambiguous, and the schema is finalized as version 1.0 and opened as a GitHub RFC pull request. In week four, the validator is updated to check against the finalized version 1.0 schema and 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. This milestone releases the remaining eighty percent of the budget, which is $800, paid once the public validator link is live, the RFC pull request is open, and the testnet examples are minted and linked.
- Budget, explained in detail
The total requested amount is $1,000, split three ways based on where the actual time goes. The first portion, $400, covers schema design and RFC writing, meaning the research and drafting time to define the schema described in section two, the writing time for the Nervos Talk post, and the time spent reading and incorporating community feedback into the finalized version 1.0 schema and RFC pull request. The second portion, $450, covers building the validator tool itself, meaning the logic that checks pasted content JSON against the schema, the wallet-style preview renderer, and deploying the finished tool to a public, working URL. The third portion, $150, covers the testnet example Spores, meaning 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. These three portions add up to the full $1,000 requested, and map onto the milestone split in section seven: the $200 first payment covers the early portion of schema drafting and the start of validator development, and the $800 second payment covers schema finalization, the remainder of validator development and deployment, and the testnet examples.
- Success criteria
Success looks like a published GitHub RFC with a single, finalized version 1.0 schema, matching exactly what is described in section two. It looks like a publicly deployed validator tool that correctly checks real Spore content against that schema and renders an accurate preview. It looks like two to three real testnet Spores that demonstrably use the finalized schema, serving as reference cases anyone can inspect.
- Risks and mitigations
The main risk is low community engagement on the Nervos Talk post during milestone one, 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 feedback during milestone one arriving too late or too divergent to incorporate cleanly into a single finalized schema by milestone two, which is mitigated by fixing the feedback window to milestone one only and documenting any unresolved suggestions as items for a future version 1.1 rather than reopening the schema after finalization.
- Relationship to future work
If this round succeeds and the finalized 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.