Spark Program | Tiko Creator Commerce Expansion + Private Beta Validation

1. Project Name

Tiko Creator Commerce Expansion + Private Beta Validation

2. Team / Individual Profile

Project: Tiko
Type: Ticketing and creator commerce platform built on CKB
Lead: Indie Developer
Contact: Discord - @getigeti21

I have already built the live ticketing foundation of Tiko, including event
listing, checkout, CKB testnet payment confirmation, ticket issuance, QR-based
access, operator check-in, and Spore-backed ownership. The current product is
already testable and demonstrates the core event commerce flow working end to
end on CKB testnet.

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

Current test access

How to test the live product

  1. Open the live website.
  2. Sign in with the test credentials above.
  3. Browse the available event listing.
  4. Open the event details page and proceed to checkout.
  5. Complete the wallet-based payment flow on CKB testnet.
    Use the internal token faucet for test tokens.
  6. Submit the payment transaction hash.
  7. Verify ticket issuance, QR-based access, and post-purchase ownership flow.

I am applying for Spark support to build the next stage of Tiko: expanding it
from a working ticketing product into a broader creator commerce offering, and
then running a short private beta to validate that expanded product with real
users.

3. Project Description

Problem

Most event and creator platforms are fragmented.

A creator may use:

  • one tool for events
  • one tool for digital products
  • one tool for memberships
  • one tool for fan rewards
  • another tool for authenticity or collectible ownership

This creates a broken experience for both creators and fans. Ticketing is
disconnected from post-purchase engagement, digital commerce is disconnected
from community access, and blockchain ownership often exists separately from
usable product workflows.

Solution

Tiko combines ticketing and creator commerce into one product.

The existing product already handles event ticketing. For this Spark cycle,
the scope is intentionally narrowed to the first 3 creator-commerce
capabilities that are the best fit for a 1-2 month validation cycle:

  1. Digital drops
    Creator-led downloadable or unlockable products such as artwork, media,
    templates, and exclusive files.
  2. Memberships and passes
    Fan-club style access products, VIP passes, and community memberships.
  3. Limited editions and collectibles
    Editioned creator items and event collectibles with Spore-backed ownership
    and provenance.

Existing Product State

Already working:

  • event listing and publishing
  • ticket checkout flow
  • CKB testnet payment confirmation
  • order tracking
  • ticket issuance
  • QR access and operator check-in
  • Spore-backed ownership after purchase

What This Grant Will Build

This Spark cycle will implement 3 creator-commerce components:

A. Digital Drops

Creators can list and sell digital products that buyers unlock after payment
confirmation.

B. Memberships and Passes

Creators can issue access-based products such as VIP memberships, fan passes,
and community access products.

C. Limited Editions and Collectibles

Creators can issue limited digital collectibles tied to products, campaigns,
or attendance, with Spore-backed ownership and provenance.

This scope is intentionally limited to validate the strongest creator-commerce
expansion paths first before moving to broader categories such as bundles, fan
rewards, and physical merch authenticity.

4. Spark Scope Clarification: Business Design, Delivery Boundaries, and Validation Plan

This section clarifies exactly what I plan to build during Spark, what counts as done, what business hypotheses will be validated, and how I
will publish evidence from the private beta.

1. Core Goal for This Spark Cycle

The goal is to validate whether Tiko’s existing ticketing foundation can expand into three concrete creator-commerce product types:

  1. Digital drops
  2. Memberships / passes
  3. Limited editions / collectibles

The core question is:

Can creators use Tiko to sell simple non-ticket products, and can buyers understand, purchase, and receive those products through the same
CKB-powered commerce flow already used for tickets?

2. Business Hypotheses to Validate

A. Digital Drops

User value:
Creators can sell downloadable or unlockable digital products directly to their audience.

Purchase motivation:
Buyers want useful or exclusive creator content they can access after purchase.

Use cases to test:

  • event replay access
  • creator templates
  • digital artwork
  • workshop materials
  • exclusive media files

Hypothesis:
If creators can package a simple digital item and sell it through Tiko, buyers will understand the value without needing the product to be an
event ticket.

B. Memberships / Passes

User value:
Creators can sell access-based products such as VIP passes, fan memberships, or community access.

Purchase motivation:
Buyers want ongoing or time-limited access to creator benefits, not just one-off tickets.

Use cases to test:

  • VIP creator pass
  • event season pass
  • member-only content access
  • early access membership

Hypothesis:
If Tiko supports simple membership entitlements, creators can use it to sell access relationships instead of only one-time attendance.

C. Limited Editions / Collectibles

User value:
Creators can sell scarce digital items with visible provenance and ownership.

Purchase motivation:
Buyers want proof of support, proof of attendance, or ownership of a limited creator item.

Use cases to test:

  • limited digital poster
  • proof-of-attendance collectible
  • supporter badge
  • editioned creator artwork

Hypothesis:
If a buyer receives a Spore-backed collectible after purchase, the ownership layer can add trust, scarcity, and emotional value beyond a normal
digital receipt.

3. Minimum Viable Delivery Boundaries

A. Digital Drops MVP

Will build:

  • creator/admin can create a digital drop product
  • product has title, description, price, image, and digital content/access link
  • buyer can view the product page
  • buyer can purchase through the existing checkout and tx-hash flow
  • after confirmation, buyer can access the purchased digital item from their order/library view

Done means:

  • a reviewer can create or inspect a digital drop
  • purchase it on the test environment
  • submit a CKB testnet payment tx hash
  • see the digital item unlocked after confirmation

B. Memberships / Passes MVP

Will build:

  • creator/admin can create a membership/pass product
  • product has title, description, price, validity period, and access description
  • buyer can purchase the membership/pass
  • after confirmation, buyer sees an active membership/pass in their account/library
  • app can show whether the pass is active or expired

Done means:

  • a reviewer can purchase a membership/pass
  • the buyer account shows active access after payment confirmation
  • the membership has a visible access status and validity window

C. Limited Editions / Collectibles MVP

Will build:

  • creator/admin can create a limited-edition collectible product
  • product has title, description, price, image, and edition supply
  • buyer can purchase the collectible
  • after payment confirmation, Tiko issues/mints the collectible using the existing Spore-backed ownership flow
  • buyer can see the ownership result, including transaction evidence where available

Done means:

  • a reviewer can purchase a limited-edition collectible
  • the edition supply is enforced at prototype level
  • Spore-backed issuance completes on CKB testnet
  • buyer can see the collectible result linked to the purchase

4. Cross-Feature Delivery Boundary

All three product types will share the existing Tiko commerce foundation:

  • product listing
  • product detail page
  • checkout
  • CKB testnet payment
  • tx-hash submission
  • payment confirmation
  • post-purchase entitlement
  • buyer library/order view

This keeps the work focused. I am extending the current working ticketing flow into three new product types instead of building unrelated
systems.

5. Pass / Fail Signals

Product Delivery Pass Signals

The Spark build passes if:

  • all 3 product types can be listed or demonstrated in the test environment
  • each product type can be purchased through the existing CKB testnet payment flow
  • each product type produces a visible post-purchase result
  • digital drops unlock content
  • memberships show active access
  • limited editions produce collectible ownership evidence
  • reviewers can reproduce the flows using the live website and GitHub repo

Product Delivery Fail Signals

The build is incomplete if:

  • products can only be mocked but not purchased
  • payment confirmation does not connect to fulfillment
  • buyer cannot see what they received after purchase
  • collectible issuance has no visible ownership evidence
  • reviewers cannot reproduce the stated verification steps

6. Private Beta Validation Plan

Participant Sources

I will recruit:

  • 3-5 creator/operator testers

  • 20-30 buyer testers

    Sources will include:

    • Nervos / CKB community members
    • early users from the current Tiko test environment
    • direct outreach through Discord and community channels

Beta Tasks

Creator/operator testers will be asked to:

  • review or create one digital drop concept
  • review or create one membership/pass concept
  • review or create one limited-edition collectible concept
  • give feedback on whether each product type is understandable and commercially useful

Buyer testers will be asked to:

  • browse the available products
  • claim test tokens through the faucet
  • purchase at least one product
  • submit the payment transaction hash
  • confirm whether they understand what they received
  • give feedback on the value and clarity of each product type

7. Metrics and Evidence

Quantitative Metrics

I will track:

  • number of testers onboarded
  • number of products tested per category
  • successful checkout completion rate
  • successful payment confirmation rate
  • successful fulfillment rate
  • number of failed or abandoned flows
  • number of support/manual intervention cases

Qualitative Metrics

I will collect feedback on:

  • whether creators understand what each product type is for
  • which product type creators are most likely to use first
  • whether buyers understand the purchase value
  • whether blockchain ownership improves perceived trust or value
  • where the flow feels confusing or too technical

8. Evidence to Publish

At completion, I will publish:

  • GitHub repo updates
  • live demo link
  • screenshots of the three product flows
  • screen recording of at least one end-to-end purchase flow
  • CKB testnet transaction hashes where relevant
  • short product documentation
  • private beta summary report
  • comparison of planned scope vs completed work
  • recommendations for the next stage

9. Learning Report Format

The final report will include:

  • what was built
  • what was tested
  • how many users participated
  • completion rates for listing, purchase, and fulfillment
  • key user feedback
  • what confused users
  • which of the three product types showed strongest demand
  • what should be improved next
  • whether the product is ready for a larger follow-on grant or broader beta

10. Budget and Work Mapping

Requested amount: $1,450

Development and Product Implementation — $1200

Mapped to:

  • digital drops MVP
  • memberships/passes MVP
  • limited editions/collectibles MVP
  • shared buyer purchase flow updates
  • shared fulfillment and buyer library updates

Beta Testing and User Validation — $200

Mapped to:

  • recruiting 3-5 creator/operator testers
  • recruiting 20-30 buyer testers
  • preparing test tasks
  • collecting feedback
  • summarizing results
  • preparing the final learning report

Infrastructure and Operations — $50

Mapped to:

  • hosted test environment maintenance
  • storage and service costs
  • small deployment and testing contingency

5. Why This Fits Spark

This project is a strong Spark fit because:

  • it extends a working prototype rather than starting from zero
  • it can produce a meaningful prototype expansion within 1-2 months
  • it combines technical development and early user validation
  • it clearly aligns with Web5 thinking: familiar Web2 UX with Web3 ownership
    where useful

6. Expected Deliverables

By the end of the grant period, I will provide:

Product Deliverables

  • creator-commerce expansion inside Tiko for:
    • digital drops
    • memberships / passes
    • limited editions / collectibles
  • updated creator-facing listing and management flows for those 3 product
    types
  • updated buyer-facing discovery and purchase flows for those 3 product types
  • beta-ready private test environment

Technical Deliverables

  • public open-source code repository updates
  • deployment instructions
  • concise product and technical documentation
  • live or recorded product demo
  • walkthrough of the 3 new creator-commerce flows

User Validation Deliverables

  • structured private beta with early users
  • user feedback summary
  • product learning report
  • recommendations for next-stage iteration

7. Estimated Completion Time

1.2 months
Planned execution window: 5 weeks

8. Clear To-Do List

Week 1

  • finalize narrowed creator-commerce scope
  • define delivery boundaries for:
    • digital drops
    • memberships / passes
    • limited editions / collectibles
  • prepare creator-facing product setup structure

Week 2

  • implement creator-facing listing flows for the 3 product types
  • implement buyer-facing discovery and purchase entry points
  • connect checkout and order handling to the 3 product types

Week 3

  • implement fulfillment logic for digital drops
  • implement access logic for memberships / passes
  • implement collectible issuance flow for limited editions

Week 4

  • connect the 3 product types into buyer library / ownership views
  • internal QA and end-to-end testing on CKB testnet
  • prepare private beta environment
  • onboard early testers and selected creators

Week 5

  • run private beta
  • collect structured feedback
  • summarize user insights, friction points, and adoption signals
  • publish completion report, demo, repo updates, and learnings

9. User Testing Plan

This project includes a real early-validation phase, not just feature
delivery.

Private Beta Goals

  • validate whether creators understand the combined ticketing + creator-
    commerce offering
  • validate whether buyers understand and adopt the first 3 creator-commerce
    product types
  • identify which of the 3 categories has the strongest practical demand
  • identify where blockchain-backed ownership improves perceived trust or value

Planned Beta Scope

  • 3-5 early creators / operators
  • 20-30 users
  • structured feedback collection through direct testing and product
    observation
  • track usage across listing, purchase, fulfillment, and post-purchase access

What I Want to Learn

  • which of the 3 categories is most commercially attractive
  • what creators want to sell alongside tickets first
  • whether buyers understand and value ownership-backed creator products
  • where the current product flow is too complex
  • what should become the next priority after Spark

10. Required Funding

Requested amount: $1,450

Suggested funding composition

  • 50% USDI
  • 50% CKB equivalent

11. Relevance to the CKB Ecosystem

This project is directly relevant to the CKB ecosystem because it uses CKB and
Spore in a product-shaped way that real users can understand.

Practical ecosystem relevance

  • demonstrates a real end-user ticketing and commerce flow on CKB
  • expands CKB usage beyond payments into ownership, authenticity, and creator
    product flows
  • shows how Web2-style UX and Web3 ownership can coexist
  • creates a practical reference product for creator commerce on Nervos

Why CKB matters here

CKB is not being used as decoration. It provides:

  • ownership-backed product fulfillment
  • Spore-based provenance for creator items
  • a foundation for collectible, access, and creator-commerce flows that make
    sense for creators and fans

This is aligned with the ecosystem goal of building practical Web5 products
that connect real user workflows with blockchain-backed value.

12. Alignment With Web5 Philosophy

This proposal strongly aligns with the Web5 direction described by Spark:

Organic combination of Web2 and Web3

Buyers browse and purchase through a familiar web flow, while blockchain is
used where it adds ownership and trust.

User-centric and human-oriented

The focus is not on protocol complexity but on creator products, audience
relationships, and useful buying experiences.

Small but real

The scope is intentionally sized for a 5-week cycle and tied to concrete
prototype and beta outcomes.

Prototype plus feedback loop

The proposal includes both implementation and real user validation.

13. Open Source Commitment

Yes.
All work delivered under this Spark proposal will remain open source and will
be published through the existing repository.

14. Completion Outputs

At completion I will provide:

  • updated open-source repository
  • product demo
  • short implementation summary
  • private beta report
  • key user feedback findings
  • comparison of planned scope vs actual completed scope
  • recommendations for next-stage iteration
  • verification evidence package:
    • demo links
    • screenshots
    • transaction links
    • screen recordings
    • test documentation

15. What Success Looks Like

This Spark project will be successful if, by the end of the cycle:

  • Tiko supports creator-commerce flows beyond tickets for the first 3
    categories
  • digital drops, memberships / passes, and limited editions / collectibles
    exist as usable prototype capabilities
  • creators can understand the narrower creator-commerce offering
  • buyers can successfully purchase and use at least one of the 3 new product
    categories
  • early beta feedback reveals which of the 3 categories has strongest market
    pull
  • the CKB ecosystem gains a concrete creator-commerce reference product beyond
    ticketing

16. Closing Summary

Tiko already proves that ticketing on CKB can work in a real, user-facing way.

This grant will help prove the next step: that ticketing can become the
foundation for a broader creator-commerce platform, beginning with a tightly
scoped first expansion into:

  • digital drops
  • memberships / passes
  • limited editions / collectibles

17. How to Verify

Test Environment Access

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

Current test access

Existing Ticketing Verification

Reviewers can already verify the current foundation by:

  1. Opening the live website
  2. Signing in with the credentials above
  3. Browsing an available event
  4. Proceeding to checkout
  5. Completing testnet payment
  6. Submitting the transaction hash
  7. Verifying ticket issuance, QR-based access, and ownership flow

This confirms the product foundation already exists before this Spark cycle
begins.

Verification Scope for This Spark Cycle

Reviewers will verify the 3 narrowed creator-commerce capabilities:

  1. Digital drops
  2. Memberships / passes
  3. Limited editions / collectibles

Verification Steps and Pass / Fail Criteria

A. Digital Drops

Verification steps

  1. Creator lists a digital drop
  2. Buyer opens the product page
  3. Buyer completes purchase
  4. Buyer receives access to the purchased digital item

Pass criteria

  • listing is visible in the storefront
  • checkout completes successfully
  • buyer can access the purchased digital drop after confirmation

B. Memberships / Passes

Verification steps

  1. Creator lists a membership or pass
  2. Buyer purchases the membership product
  3. Buyer receives the membership/pass access outcome
  4. Membership appears in buyer-facing account or library flow

Pass criteria

  • membership product can be listed and purchased
  • buyer receives access after successful confirmation
  • buyer can see the membership in the product experience

C. Limited Editions / Collectibles

Verification steps

  1. Creator lists a limited-edition collectible product
  2. Buyer completes purchase
  3. Product triggers collectible issuance
  4. Ownership-backed result is visible in the buyer flow

Pass criteria

  • collectible product can be purchased
  • collectible issuance flow completes
  • ownership result is visible and linked to the purchase

Evidence Publication

Evidence will be published through:

  • GitHub repository updates
  • product demo or walkthrough video
  • screenshots of creator and buyer flows
  • screen recordings for end-to-end verification
  • transaction links / hashes where relevant
  • completion documentation and summary report

Private Beta Verification Loop

Source of test participants

  • 3-5 early creators / operators
  • 20-30 test users

Task design

Testers will be asked to:

  • create or review product listings in the 3 new categories
  • complete purchases
  • verify access / ownership outcomes
  • report friction points and clarity issues

Key metrics

  • successful listing completion rate
  • successful purchase completion rate
  • successful fulfillment / access completion rate
  • qualitative clarity of the product offering
  • perceived usefulness of ownership-backed features

Feedback collection

Feedback will be collected through:

  • direct structured tester feedback
  • guided walkthrough sessions
  • short written summaries
  • product usage observation

Final report format

The completion report will include:

  • what was built
  • what was tested
  • what worked
  • what failed or caused confusion
  • which of the 3 categories showed strongest demand
  • recommended next-stage priorities
5 Likes

@DWSQUIRES 你好,感谢提交 TiKo 的提案。

委员会讨论后决定:该项目当前状态定为Pending。原因不是否定方向,而是现阶段提案存在两个关键问题,需要你补齐后才能进入正式评审:

  1. 范围过大
    你把 creator commerce 扩展拆成了 7 类能力,但以 Spark 的资助定位来看,这个范围会显著拉高交付与验收风险。
    委员会建议你将“商业功能”抽象为更清晰的开发交付边界,并优先收敛为 7 类中的前3类(即:Digital drops、Memberships/passes、Limited editions/collectibles)作为本期 Spark 支持范围。

  2. 提案细节不清晰(尤其是 How to Verify)
    在你缩范围后,请同步把 How to Verify 补充到可复现的验收级别,至少写清:

  • 评审者如何进入测试环境;
  • 每个里程碑/功能的验证步骤与通过/失败标准;
  • 证据发布位置(repo、demo、录屏、交易链接、截图、文档等);
  • private beta 的验证闭环(测试对象来源、任务设计、关键指标、反馈采集与最终报告形式)。

下一步要求:请你基于上述两点 缩小范围、补充验证细节,并相应重新调整预算需求

更新后在本帖@我,回复“已更新”,并说明修改了哪些章节/新增了哪些链接或附件,我们会在信息齐备后继续正式评审流程。

祝好
行天
代表 Spark Program 委员会

2 Likes

Updated.

I narrowed the supported scope from 7 categories to the first 3 categories:
Digital drops, Memberships/passes, and Limited editions/collectibles.
I also added a detailed How to Verify section, including:

  • access to the live test environment
  • verification steps and pass/fail criteria for each supported feature
  • evidence publication locations
  • the private beta verification loop, including participant source, task
    design, metrics, feedback collection, and final report format

Modified sections:

  • Section 3: Project Description
  • Section 5: Expected Deliverables
  • Section 7: Clear To-Do List
  • Section 8: User Testing Plan
  • Section 9: Required Funding
  • Section 10: Funding Breakdown
  • Section 14: Completion Outputs
  • Section 15: What Success Looks Like
  • Section 16: Closing Summary
  • Added Section 17: How to Verify

Links included:

3 Likes

Hi @DWSQUIRES

感谢你根据委员会之前的意见对提案进行了修改。我们认可你已经做出了一个可测试的 ticketing 基础产品,并且把 “creator commerce expansion + private beta validation” 作为下一阶段方向提出。

经委员会讨论,目前该项目保持 Pending 状态。

主要原因是:我们仍然无法从当前提案中清晰看出你在 Spark 期间“具体要做什么、做到什么程度算完成、以及委员会应如何有效协助你达成最终目的”。在该信息不充分的情况下,委员会无法给出负责任的评审与支持承诺。

因此我们希望你先把待办清单的 第 1 周计划(思考并明确具体业务内容的设计与目标)执行完毕,并将结果体现在主帖更新中,至少补齐:

更清晰的业务设计与目标:你要验证的核心假设是什么?三类能力(digital drops / memberships / collectibles)里,分别想验证什么“用户价值/购买动机/使用场景”?
可验收的交付边界:每个能力的最小可用版本是什么?做到什么程度算完成(通过/失败信号)?
验证与证据:private beta 的任务清单、样本来源、反馈收集方式、最终你将发布什么形式的“学习报告/数据摘要/结论”。
(如适用)预算与工作映射:把预算与上述交付边界一一对应,避免“看起来合理,但无法验收”。

你完成更新后请在本帖回复并 @ 我,委员会会在信息具备可评审性之后继续推进评审,并更具体地讨论我们能如何帮助你把 beta 跑顺。

祝好,
行天
代表 Spark Program 委员会

2 Likes

@xingtianchunyan Updated.

I added a new scope clarification section covering:

  • the core hypotheses for Digital drops, Memberships/passes, and Limited editions/collectibles
  • minimum viable delivery boundaries for each capability
  • pass/fail criteria
  • beta participant sources and task design
  • metrics and evidence to be published
  • learning report format
  • budget-to-work mapping

The proposal is now narrowed around three reviewable product capabilities and a reproducible beta validation plan.

3 Likes