Spark Program | Tiko Creator Commerce Validation Sprint

Project Name

Tiko Creator Commerce Validation Sprint

Team / Individual Bio and Contact

Project: Tiko
Type: CKB-based ticketing and creator commerce prototype
Lead: Indie Developer
Contact: Discord - @getigeti21
GitHub: GitHub - Tiko-T/Tiko · GitHub
Live demo: https://tiko-pied.vercel.app/

Tiko already has a working ticketing foundation on CKB testnet, including event listing, checkout, payment transaction-hash submission, payment confirmation, ticket issuance, QR access, operator check-in, public test-token faucet, and Spore-backed ownership.

This Spark proposal does not ask the committee to fund the ticketing foundation again. The goal is to validate whether that existing foundation can expand into creator commerce.

Previous proposal

Project Description

Problem

Tiko has already demonstrated that CKB can support a working ticketing flow. The next product question is different:

Can creators use the same CKB-powered commerce flow to sell non-ticket products to their audience?

Many creators sell experiences, access, digital goods, and collectibles across separate tools. This creates fragmented workflows, weak post-purchase relationships, and limited ownership/provenance for digital products.

Core Hypothesis

Creators who already run events, communities, or audience-based projects will be interested in using Tiko to sell simple creator-commerce products if:

  • the buying experience feels like normal web commerce
  • CKB handles payment verification
  • Spore adds visible ownership, provenance, or scarcity where useful
  • buyers can clearly understand what they bought after purchase

Existing Foundation Evidence

The existing Tiko prototype already proves that the base ticketing flow can work on CKB testnet.

Current live product supports:

  • event listing
  • checkout
  • internal token faucet for test users
  • CKB testnet payment submission through transaction hash
  • payment confirmation
  • ticket issuance
  • QR access/check-in
  • Spore-backed post-purchase ownership

Sample testnet evidence already produced during development includes:

  • hosted test faucet transfer: 0x8e4d81ef12fdd80bcba13bcf0c12eba64d9418b472d8b7f616e81294b00498ea
  • hosted checkout payment test: 0x9e4531dfe0bedf2a9b31b1227e4a0cd4312f5f05bf6cdfff32232696d90bd37f

This Spark cycle will build on that foundation and validate whether the same flow can support creator-commerce products.

What This Spark Cycle Will Validate

This project will validate three creator-commerce use cases.

1. Digital Drops

Hypothesis:
Creators will want to sell simple downloadable or unlockable digital products to their audience after an event or campaign.

User value:
Buyers receive useful or exclusive creator content after purchase.

Use cases:
Event replay, workshop material, creator template, digital artwork, exclusive media file.

Success criteria:
At least 3 of 5 creator/operator testers can define a digital drop they would realistically sell, and at least 70% of buyer testers can complete purchase and understand how to access the product.

2. Memberships / Passes

Hypothesis:
Creators will want to sell ongoing or time-limited access relationships, not only one-time tickets.

User value:
Buyers receive recognizable access status, such as VIP access, community access, early access, or a seasonal pass.

Use cases:
VIP creator pass, community access pass, early-access membership, event season pass.

Success criteria:
At least 3 creator/operator testers can define a membership/pass offer with a clear buyer benefit, and buyers can identify whether their purchased pass is active and what it gives them access to.

3. Limited Editions / Collectibles

Hypothesis:
Spore-backed ownership can add value for creator items where scarcity, proof of support, or provenance matters.

User value:
Buyers receive a limited item with visible ownership/provenance instead of only a normal digital receipt.

Use cases:
Limited digital poster, proof-of-attendance collectible, supporter badge, editioned creator artwork.

Success criteria:
At least 60% of buyer testers report that visible ownership/provenance makes the item feel more trustworthy, valuable, or meaningful than a normal digital receipt.

Expected Deliverables

Product Deliverables

  • minimal creator-commerce flow for digital drops
  • minimal creator-commerce flow for memberships/passes
  • minimal creator-commerce flow for limited editions/collectibles
  • buyer-facing post-purchase library/status view
  • testnet payment and fulfillment flow connected to each use case
  • Spore-backed issuance for collectible validation

Validation Deliverables

  • 5 creator/operator interviews or structured feedback records
  • 20-30 buyer tester task results
  • task completion data for purchase and fulfillment
  • summary of failed or confusing flows
  • comparison of the three use cases
  • recommendation: continue, adjust, or abandon each use case

Public Evidence

  • GitHub commits
  • live demo
  • screenshots
  • screen recording of at least one end-to-end flow
  • relevant CKB testnet transaction hashes
  • final learning report
  • brief deployment/testing documentation

Funding Requested

Requested amount: $1,450 USD equivalent

Funding can be provided in CKB or CKB + USDI.

This request is above the standard $1,000 Spark baseline because the project combines two workstreams within one short validation cycle:

  1. Minimal product implementation needed to test three creator-commerce use cases.
  2. Structured private beta validation with creator/operator testers and buyer testers.

The scope is still intentionally narrow. This is not a request to build a full creator-commerce platform. The funding supports a 6-week validation sprint focused on whether Tiko’s existing CKB ticketing foundation can expand into digital drops, memberships/passes, and limited editions/collectibles.

Funding Breakdown

Product implementation: $1100
Product changes needed to test digital drops, memberships/passes, and collectibles through the existing Tiko checkout, payment confirmation, and fulfillment flow.

User validation and beta coordination: $150
Recruiting and coordinating 5 creator/operator testers and 20-30 buyer testers, preparing test tasks, running feedback sessions, and summarizing results.

Infrastructure and test operations — $150
Hosted test environment, storage, CKB testnet operations, faucet support, deployment maintenance, and transaction/fulfillment monitoring.

Documentation and reporting — $50
Final learning report, screenshots, demo preparation, testing instructions, transaction evidence, and public evidence organization.

Estimated Completion Time

6 weeks

This fits Spark’s 1-2 month cycle and gives enough time for both minimal implementation and user validation.

Clear To-Do List

Week 1: Prepare Test Flows

Goal: Build what is needed to test the hypotheses.

Tasks:

  • add listing/support for the three product types
  • prepare buyer-facing product pages
  • connect each product type to the existing checkout flow

Deliverable:

  • test environment with three purchasable creator-commerce offers

Week 2: Validate Purchase and Fulfillment

Goal: Test whether buyers can complete the flow and understand what they receive.

Tasks:

  • run internal test purchases
  • verify payment confirmation
  • verify unlock/status/ownership result per product type
  • fix blocking UX or fulfillment issues

Deliverable:

  • reproducible end-to-end flows for all three use cases

Week 3-4: Run Buyer Beta

Goal: Collect real user feedback.

Tasks:

  • onboard 20-30 buyer testers
  • ask testers to claim faucet tokens
  • ask testers to purchase at least one product
  • collect task completion and feedback data

Deliverable:

  • buyer testing data
  • transaction and fulfillment evidence
  • issue log

Week 5: Compare Use Cases

Goal: Determine which creator-commerce use case has the strongest signal.

Tasks:

  • compare completion rates
  • compare buyer understanding
  • compare creator interest
  • identify top friction points

Deliverable:

  • use-case comparison table
  • continue / adjust / abandon recommendation for each use case

Week 6: Publish Report and Evidence

Goal: Make results reviewable by the committee and community.

Tasks:

  • publish final learning report
  • publish demo screenshots/video
  • publish transaction evidence
  • update documentation

Deliverable:

  • public completion report
  • GitHub updates
  • demo/evidence package

Relevance to the CKB Ecosystem

This project is relevant to CKB because it tests a practical Web5 use case: familiar web commerce backed by blockchain ownership and verification.

Tiko already shows that CKB can support ticketing. This Spark cycle tests whether the same foundation can support creator-commerce use cases where Spore’s ownership and provenance model may create additional value.

The project contributes:

  • a working reference product for CKB-based commerce
  • a real user validation report
  • practical feedback on Spore usage in digital goods, memberships, and collectibles
  • open-source code and documentation for the community
  • evidence for whether a larger creator-commerce product on CKB is worth pursuing

Success / Failure Criteria

Success

The Spark cycle succeeds if:

  • 5 creator/operator testers provide structured feedback
  • 20-30 buyer testers participate
  • all three product types can be tested through the live environment
  • purchase and fulfillment can be completed for each product type
  • at least one product type shows strong enough demand to justify deeper development
  • the final report clearly explains what should continue, change, or stop

Failure

The cycle will be considered unsuccessful if:

  • creators cannot define realistic offers for these product types
  • buyers cannot understand what they are purchasing
  • checkout or fulfillment cannot be completed reliably
  • Spore-backed ownership does not improve perceived trust, value, or clarity for collectibles
  • no product type shows enough signal for continued development

Completion Outputs

At completion, I will publish:

  • updated open-source repository
  • product demo
  • testing instructions
  • screen recording
  • screenshots
  • transaction hashes where relevant
  • user validation summary
  • final learning report
  • transparent funding usage summary
  • recommendation for whether Tiko should pursue a larger follow-on grant

Live Testing Instructions

Reviewers can test the current Tiko foundation here:

Live demo: https://tiko-pied.vercel.app/
GitHub: GitHub - Tiko-T/Tiko · GitHub

Test account:

Testing flow:

  1. Open the live website.
  2. Sign in with the test account.
  3. Browse the available event listing.
  4. Claim test tokens from the faucet if needed.
  5. Open an event/product page and proceed to checkout.
  6. Complete the CKB testnet payment flow.
  7. Submit the payment transaction hash.
  8. Verify ticket issuance, QR access, and post-purchase ownership.

Summary

Tiko has already validated a working ticketing foundation on CKB testnet.

This Spark proposal is a focused validation sprint to answer the next question:

Can that ticketing foundation become a creator-commerce product?

The work is intentionally limited to three testable use cases: digital drops, memberships/passes, and limited editions/collectibles. The outcome will not just be code. It will be a public learning report showing which creator-commerce direction has real user signal and whether Tiko should continue toward a larger CKB creator-commerce product.

2 Likes

Hi @DWSQUIRES,

Thank you for resubmitting the proposal based on the feedback and restructuring it toward a validation sprint. After a full review, however, the committee has regretfully decided to mark this proposal as rejected.

The primary reason is as follows:

The committee cannot determine whether the final deliverables will meet expectations.

The core deliverables of the second proposal are a “final learning report” and a “user validation summary,” intended to answer “which creator-commerce direction is worth continuing.” However, the committee could not confirm the following key issues from the proposal:

  • What specific content will the learning report include? Format, structure, depth — none of these were specified in the proposal.
  • How will user validation data be collected? Will feedback from 20–30 buyers be gathered via surveys, interviews, or behavioral data? The collection method was not specified.
  • What is the criterion for judging “strong enough demand”? On what quantitative basis will the report’s conclusions (“continue/adjust/stop a given direction”) be made? Thresholds were not defined.
  • Are three product tracks being pursued in sufficient depth? Allocating two weeks to implement each of digital drops, memberships, and collectibles plus one week for comparison likely yields insufficient sample size and validation depth for each direction.

Because of the issues above, the committee cannot determine at the end of Spark whether the submitted learning report provides enough data and methodological support to answer the core hypotheses. Quality standards for the deliverables were not established in the proposal.

Your existing ticketing work on the CKB testnet has provided valuable reference for the community — thank you for your time and interest in the CKB ecosystem. But out of responsibility to funds and the community, we have made this difficult decision.

We hope you will review the Tiko proposal evaluation process, deeply reflect on the real bottlenecks and breakthrough strategies between product development and business promotion, and find a clearer path for future development.

Best regards,
Xingtian
On behalf of the Spark Program Committee

cc: @zz_tovarishch , @yixiu.ckbfans.bit , @Hanssen

1 Like