1. Project Overview
Project Name: VibeQuest
One-Sentence Summary:
VibeQuest turns AI-assisted coding into structured learning by making users study, verify, and defend generated CKB/Fiber code before completing a quest.
Project Type: AI Learning Platform / Gamified CKB Onboarding Product / CKB-Fiber Education DApp
Live Product and Repositories:
Frontend Demo: https://vibequest-web-seven.vercel.app
Frontend Repository: https://github.com/buidlLabs3/vibequest-web
Backend Repository: https://github.com/buidlLabs3/vibequest-core
Product Architecture: https://github.com/buidlLabs3/vibequest-web/blob/main/docs/product-architecture.md
Recorded Walkthrough: https://github.com/buidlLabs3/vibequest-web/blob/main/demo.webm
2. Builder Profile
VibeQuest is being built by xbeach. I handle product direction, frontend, backend, AI learning flow, CKB/Fiber integration direction, deployment, and demo preparation.
Contact email: [email protected]
Telegram: @OXbeach
GitHub organization: https://github.com/buidlLabs3
The current product already has a deployed Next.js frontend, Rust backend, OpenAI-powered learning and quest generation, MongoDB persistence, wallet-based identity flow, a dashboard, code workbench, and ship-gate structure. The Spark request is to turn this working prototype into a sharper, reviewable MVP.
3. Product Background
AI-assisted coding is now part of how people build. Many new builders ask AI to generate code, run it, modify it, and continue. That workflow is not going away, but it creates a serious gap: people often ship code they cannot explain.
That gap is especially risky in CKB and Fiber. CKB uses cells, lock scripts, type scripts, witnesses, transaction structure, and asset logic. Fiber introduces payment channels, invoices, payment proofs, and off-chain state assumptions. A learner can ask AI to generate a paywall, payout split, receipt verifier, or cell proof flow, but still fail to understand what the code trusts, what can be replayed, and what must be verified.
VibeQuest makes AI-assisted building safer by turning it into a learning loop: generate, inspect, test, explain, and record progress.
4. Focused MVP Scope
The current VibeQuest MVP is focused on two narrowed learning areas: CKB Cell Model and Fiber Payment Models.
The CKB Cell Model path teaches how cells, OutPoints, lock/type scripts, witnesses, transaction evidence, wallet proof, and verifier logic connect to generated code. The goal is to help learners understand what a CKB-based app is actually trusting before they accept or modify AI-generated code.
The Fiber Payment Models path teaches how invoices, payment proof, channel state, receipt binding, replay risk, and paid-access logic connect to practical application flows. The goal is to help learners understand how payment-related evidence should be scoped to the right user, content, run, cell, amount, and state.
These two areas form the core MVP because they cover the most important learning problem VibeQuest is solving: helping users move from AI-generated output to real understanding of proof boundaries.
The current product loop is:
AI lesson → checkpoint → lesson-based code quest → generated verifier/test files → workbench verification → boss challenge → completion record
5. Product Solution
VibeQuest is a gamified learning workbench where users learn by doing. A learner selects a path, generates a structured lesson module, studies the concept, answers a checkpoint, asks the AI tutor questions, writes notes, unlocks a practical quest, inspects generated code, runs verification checks, solves a boss challenge, and records progress.
The product’s main idea is simple: AI is the execution layer, but understanding is the progression layer.
A user can use AI to generate code, but VibeQuest only rewards progress when the user proves they understand the generated code. The boss challenge is tied to the generated verifier and denial tests, not generic trivia.
For the first MVP path, learners should answer questions like: What does this verifier trust? Is the trusted value coming from CKB transaction evidence, wallet proof, or frontend JSON? Which field would an attacker mutate first? Does the denial test prove replay prevention?
6. User Experience and Architecture
A user opens VibeQuest, chooses the CKB Cell Model learning path, and selects their background, such as vibecoder, backend developer, frontend developer, security auditor, or product/community learner. VibeQuest generates a five-module learning path.
Each lesson includes an explanation, code lens, checkpoint question, tutor support, reference trail, and quest bridge. The learner must pass the checkpoint before generating the related practice quest.
Once unlocked, the quest generates implementation files and denial tests. In the Workbench, the learner inspects the generated files, runs file checks, asks questions about the code, and answers a boss challenge tied to the generated verifier. After completion, the dashboard records the lesson, quest, tutor questions, notebook reflections, and progress state.
The frontend is built with Next.js and TypeScript. It owns the learning interface, dashboard, workbench, wallet flow, and ship gate. The backend is built with Rust and Axum. It owns AI generation, output validation, wallet proof validation, persistence, quest state, and reward-claim preparation. MongoDB stores users, learning sessions, quest runs, tutor messages, notebook records, completion states, and reward claims.
Product architecture: https://github.com/buidlLabs3/vibequest-web/blob/main/docs/product-architecture.md
7. Technical Approach and Current Progress
VibeQuest is built as a working AI learning product with a Next.js frontend and Rust backend. The product currently supports AI-generated learning paths, interactive checkpoints, tutor questions, lesson-based code quests, a code Workbench, generated file verification, boss challenges, MongoDB activity records, wallet-based identity, and a recorded demo walkthrough.
The core technical flow is designed around one principle: learners should not only receive AI-generated code, they should prove they understand the trust boundary behind it. A completed quest must include generated implementation files, denial-oriented tests, code explanation, and a challenge that checks whether the learner can explain what the code trusts and what attack it rejects.
This progress gives the Spark MVP a concrete base: the grant work is not starting from zero, but refining the current product into a clearer, deeper, reviewable learning loop for CKB Cell Model and Fiber Payment Model education.
8. Funding Request and Budget
Total requested: $1,000
-
Product and development work: $600
Frontend refinement, backend hardening, learning flow improvements, AI quest generation improvements, dashboard organization, workbench verification, and end-to-end testing. -
OpenAI/API usage: $150
Lesson generation, quest generation, tutor interaction, repeated testing, and demo preparation. -
Hosting and infrastructure: $100
Vercel hosting, backend deployment, MongoDB usage, and operational testing during the grant period. -
CKB/Fiber polish and QA: $100
CKB/Fiber reference integration, wallet flow polish, ship-gate clarity, and ecosystem-specific testing. -
Documentation and demo material: $50
README verification guide, walkthrough preparation, proposal revision, and demo recording.
After the Spark grant, ongoing operational costs will be managed by keeping generation efficient, using free or low-cost hosting tiers where possible, and adding rate limits if usage grows.
9. Milestones and Deliverables
Milestone 1: CKB Cell Learning Path and Dashboard
Funding requested: $300
This milestone focuses on one learning path: Understanding CKB Cells and Proof Boundaries.
Deliverables:
Five AI-generated lessons for the CKB Cell path. Each lesson includes explanation, code lens, checkpoint, correct answer, wrong answers, feedback, tutor context, and quest bridge. Dashboard shows completed lessons, incomplete lessons, tutor questions, notebook reflections, and related quests. Learners can resume a saved learning path.
Acceptance criteria:
A reviewer can generate the CKB Cell path, see at least five modules, complete a checkpoint, ask a tutor question, write a note, and confirm the dashboard records the activity.
Milestone 2: Lesson-Based Quest Workbench and Verification
Funding requested: $350
This milestone turns completed lessons into practical code quests generated from the lesson’s concept, checkpoint, misconception, and practice bridge.
Deliverables:
Lesson-to-quest generation from completed lessons. AI-authored implementation file and test file. At least one valid test case and at least two denial-path test cases. Workbench display for generated files. Generated file verification checks. Code explainer tied to active generated files. Boss challenge tied to the generated verifier and denial test.
Acceptance criteria:
A reviewer can complete a lesson, generate a related quest, open generated code in Workbench, run file checks, answer a boss challenge, and see the quest completion state update. The boss challenge must test understanding of the generated code, not generic CKB trivia.
Milestone 3: CKB/Fiber Polish, Verification Guide, and Public Demo
Funding requested: $350
This milestone makes the MVP easy for reviewers and the CKB community to test.
Deliverables:
Clear public demo flow for one complete CKB Cell learning path. Recorded walkthrough showing lesson generation, checkpoint, quest generation, workbench verification, boss challenge, and completion. README verification instructions. Product architecture documentation. Clear CKB/Fiber reference links in the product. Ship gate state that explains what is complete, pending, and reward-claim ready. Frontend and backend checks passing.
Acceptance criteria:
A reviewer can follow the public demo or recorded walkthrough and verify the complete learning loop without private instructions.
10. Verification Plan
A reviewer can verify the product through this flow:
Open the frontend demo, connect wallet, choose the CKB Cell learning path, generate the five-module learning path, open a lesson, answer the checkpoint, generate the lesson-based quest, inspect generated files in Workbench, run generated file checks, answer the boss challenge, confirm completion state, and open the dashboard to confirm progress was recorded.
For technical verification:
Frontend: npm run lint and npm run build
Backend: cargo test
Repositories: public GitHub repos
Walkthrough: https://github.com/buidlLabs3/vibequest-web/blob/main/demo.webm
Expected output: the learning path appears with five modules, the quest is generated from a completed lesson, generated code and tests appear in Workbench, verification checks run, the boss challenge is tied to the generated code, and completion is recorded in the dashboard.
11. Current State vs. Funded Work
The current state is a working prototype with deployed frontend, deployed backend, AI generation, MongoDB persistence, wallet identity flow, learning modules, quest generation, workbench checks, dashboard records, and ship gate structure.
The funded work is the product-quality layer. It narrows the MVP, improves clarity, improves learning depth, strengthens generated quests, improves verification, and makes the demo easy for reviewers to test.
The main difference after this revision is focus. Instead of claiming broad ecosystem coverage immediately, VibeQuest will prove one complete CKB learning path first, then expand.
12. CKB Ecosystem Alignment and Final Summary
VibeQuest supports CKB onboarding by helping learners understand the concepts that matter when building real applications: cells, OutPoints, lock scripts, type scripts, witness data, transaction evidence, wallet proof, replay risk, Fiber invoice context, and proof-bound reward claims.
Many future builders will enter ecosystems through AI-assisted workflows. If CKB wants more builders, it also needs learning tools that meet users where they are. VibeQuest turns AI-assisted coding into a structured path toward understanding, safer development, and better ecosystem onboarding.
The requested $1,000 supports three clear milestones: learning path and dashboard, quest workbench and verification, and CKB/Fiber polish with public demo material.