A year ago, we told the stories of people who were finding their feet in the CKB ecosystem, learning how it worked, and figuring out what they could build with it. Since then, the journey has continued. Some ideas have grown into working projects, some builders have taken on more difficult technical challenges, and others have learned just how much can change when you share your work and let people give you feedback. Getting started is one thing. Staying with a project long enough to improve it, working through problems, listening to other developers, and finding ways for people to actually use what you have built is another. That is where much of the real work happens, and it is what this second volume is about.

Rick returns from Volume 1, giving us a chance to see how his journey has developed since we last featured him. Alongside him are Truth, Cecilia, Ngoc, Oluwaseun, and Ebube, whose work shows what can happen when curiosity turns into a deeper commitment to building. Their experiences are different, but they share a common thread, learning does not stop when you understand the technology or get your first project working. In many ways, that is when the more interesting part begins.

Different Roads into CKB

There is no single route into CKB. Some of the builders arrived with years of experience in software or blockchain development, while others were still learning how the technology worked. What brought them together was the chance to explore something new, find problems worth solving, and discover where their own skills could make a difference.

For Truth, whose name is Wasiu Ajao, the journey began with mathematics and grew through software engineering, blockchain development, and cryptography. His background shaped the way he approached CKB: he wanted to understand how the system worked beneath the surface, not just what could be built on top of it. Before joining the CKBuilder programme in March 2026, he had already worked with several blockchain ecosystems and explored smart contracts, zero-knowledge proofs, and privacy-focused applications.

The CKBuilder programme gave him a more direct way to put that experience to work. He began studying CKB’s cell model and writing scripts, then moved quickly from learning the basics to building projects of his own. His early work included Learn CKB in 45 Minutes and Grid3, a Tic Tac Toe game built on CKB Testnet. Since then, his work has expanded into identity and reputation infrastructure, cryptography, and tools for developers. You can explore more of his work through his GitHub profile and portfolio.

For Rick, the route into CKB started with Bitcoin and an interest in how blockchain systems work. Before discovering CKB, he had already built a decentralised exchange on Alephium, including swaps and liquidity pools. So he was familiar with smart contracts, but CKB gave him a different design to think about. A friend introduced him to the ecosystem and its cell model, and joining the CKBuilder programme in August 2025 gave him the structure and encouragement to get more involved.

What caught Rick’s attention was how the cell model could be used to solve a practical problem. As he explained in his interview, each crowdfunding pledge could be held in a cell governed by rules that determine whether the funds go to the project creator or return to the backer. That idea became CrowdCell, his all-or-nothing crowdfunding project. For Rick, CKB was not simply another chain to learn; it was a chance to apply his existing skills to a problem in a different way.

Ngoc Vo, also known in the community as Nghiadang, came from a very different background. He works as an embedded software engineer at Renesas in Vietnam and had little experience with blockchain before a friend introduced him to CKB. What made him pay attention was something he already knew: RISC-V. He had worked on a RISC-V-related project in the past, so learning that CKB used a RISC-V-based virtual machine immediately caught his interest. His reasons for staying began to change. He said that earning money while learning was his initial motivation, but that the more he understood CKB, the more he appreciated how it was designed. He also liked that he could work with familiar languages such as C/C++, JavaScript, and TypeScript, while receiving guidance and reviews from other community members. That support helped him move from curiosity to building his own projects, including ToyTrade, a platform designed to let people trade toys using CKB and Fiber. His experience is a reminder that a person does not need to come from a traditional blockchain background to find a place in the ecosystem.

Cecilia Mulandi’s path began in Computer Science, although it was not her first choice. She initially had other plans, but a university lesson on distributed systems introduced her to blockchain, and that sparked an interest she continued to explore after graduating. She began learning about zero-knowledge proofs and cryptography, studying the mathematics behind them while also learning Rust so she could put those ideas into practice.

She discovered CKB through a Web3 community WhatsApp group, where she came across a post about the CKBuilder programme. What convinced her to take a closer look was the connection between CKB’s architecture and the kind of work she wanted to do. As she put it, CKB’s role as a verification layer was her “ooh moment”: she saw a close connection between how CKB verifies transactions and how zero-knowledge systems use proofs to establish that something is valid. The architecture made technical sense to her, but the people mattered too. She singled out the developer support and feedback she received as reasons she felt encouraged to keep building. That combination led her to develop a Groth16 verifier for CKB, infrastructure that other developers have since used as a starting point for their own work. Cecilia is based in Nairobi, Kenya, and her journey shows how a personal interest in cryptography can grow into a contribution that helps other builders move forward. You can follow her work and updates on X.

Oluwaseun’s entry point was more conventional, he started with general software development before moving into blockchain. He discovered CKB through TechyJaunt, joining one of its cohorts in late 2024, and began learning how to develop on the network. Coming from outside the blockchain space, he had to get to grips with CKB’s cell model and understand a different way of representing assets and application logic. The important shift came when learning turned into making things. Building and deploying his first contract gave him a foundation to work on larger ideas, including PactAgent and Klaveroq. Rather than treating blockchain as something to study from a distance, he wanted to build practical products around problems involving payments, trust, and coordination. His story is a reminder that experience in conventional software development can be a useful starting point, even when the underlying technology is unfamiliar.

Ebube Chukwuma, known in the CKB community as Smilez, came into the ecosystem with more than five years of experience as a software engineer. A friend introduced him to CKB, and he was drawn to the Cell Model, the RISC-V virtual machine, and Fiber. As he explored the technology and started building projects, he began noticing gaps where he could contribute. Looking back, he explained that the change happened naturally: “I didn't even realize when that turning point happened. I was simply exploring the tech and building projects, and before I knew it, the drive to contribute naturally took over.” His journey reflects how exploring new technology can gradually grow into a deeper commitment to building and contributing to the ecosystem.

When Curiosity Becomes Something People Can Use

Learning a new blockchain is one thing. Building something that other people can test, use, review, or build on is another. For the builders featured here, that shift has meant tackling practical problems: how to make crowdfunding trustless, how to make privacy tools reusable, how to simplify payments, and how to turn an early idea into infrastructure that can support real applications.

Their projects are at different stages. Some are testnet experiments, others are tools already being used by fellow developers, and a few are moving from prototypes towards products. What connects them is the decision to take what they were learning about CKB and put it to work.

Rick: Making Crowdfunding Work Without Trusting a Middleman

For Rick, the challenge with crowdfunding was straightforward, what happens when a campaign fails, or when the people involved cannot agree on what should happen to the money? Traditional platforms manage the funds and determine when they are released. His project, CrowdCell, takes a different approach by using CKB scripts to enforce the rules.

CrowdCell is an all-or-nothing crowdfunding application. If a campaign reaches its target before the deadline, the creator can receive the pledged funds. If it fails, backers can reclaim their money. The intention is to make those outcomes depend on the rules encoded in the application rather than on a platform's discretion.

Rick built the project across several layers, including Rust scripts, a TypeScript transaction builder, an indexer, a keeper bot, and a web interface. But one of the most important lessons came when he realised that his first version still depended on backers cooperating to release or refund funds. He had to redesign the pledge mechanism so that the rules were enforced on-chain.

The milestone that mattered most was seeing the system work as intended. As Rick explained, he was proud of “watching the keeper bot finalize a campaign and pay the creator on testnet without anyone touching it, then do the same for a refund on a failed one.”

That was more than a successful demonstration. It showed the central idea behind CrowdCell working in practice: the scripts, rather than a person, determine where the money goes.

CrowdCell is currently live on testnet and remains under active development. Its progress has also involved external review, security fixes, and improvements to how pledges are handled. You can explore the CrowdCell codebase and follow its development updates.

Truth: Building Infrastructure Other Developers Can Reuse

Truth's work reflects a different kind of challenge. Rather than focusing on one application, he has increasingly been interested in the underlying tools and protocols that allow other developers to build applications of their own.

One example is Vellum, a reputation and identity-related project built around CKB's did:ckb identity system. Its goal is to provide reusable infrastructure for verifiable claims and reputation, allowing applications to issue, verify, and use claims without every project having to develop its own system from scratch.

The project has progressed beyond an initial demonstration. Truth's Vellum repository contains the implementation, while its first milestone delivered testnet contracts, a TypeScript SDK, verification flows, schemas, and a dashboard that shows the evidence behind reputation scores. The milestone has been delivered and was awaiting formal reviewer sign-off at the time of his interview.

Getting there required more than writing code. Truth had to refine the protocol's boundaries, respond to community feedback, and rethink parts of the design after review. That experience changed how he evaluates his own work: a working demo is useful, but reusable infrastructure must also be understandable, testable, and maintainable by others.

His work on Fiber takes a more focused approach to developer experience. Through fiber-forge, Truth created an open-source tool intended to make Fiber development and testing easier. The tool was released on npm and won first place in its category at the Gone in 60ms Fiber Network Infrastructure Hackathon. The official hackathon results document that milestone.

Cecilia Mulandi: From Cryptographic Theory to Privacy Tools

Cecilia Mulandi's work grew out of a long-standing interest in cryptography and zero-knowledge proofs. After studying the underlying mathematics, she wanted to move beyond understanding how the techniques worked in theory and see what they could make possible on CKB.

Her first major contribution was groth16-ckb, a Groth16 verifier over BN254 that runs as a script in CKB-VM. The project addressed a practical gap: developers needed a way to verify zero-knowledge proofs on-chain if they wanted to build privacy-preserving applications on CKB.

For Cecilia, implementing the verifier brought together months of study and the challenge of translating that knowledge into working software. The important milestone was not simply getting the mathematics to work. Other developers began using the verifier in their own projects. Arthur integrated it into CellScript, Xiaomao worked with it in a Noir-to-CKB toolchain, and Truth used it in a two-player zero-knowledge word game.

That adoption encouraged Cecilia to ask a further question: once the verifier existed, how could developers use it without having to assemble all the surrounding components themselves?

Her answer was zk-Lock. Rather than requiring a cell to be unlocked through a conventional key-based authorisation, zk-Lock allows access to depend on a valid cryptographic proof. This could support applications where someone needs to prove that they meet a condition without disclosing the underlying private information.

Cecilia described the progression clearly: “The groth16-ckb verifier was me proving to myself that I could take the math I’d been studying and turn it into working code on CKB. zk-Lock is the next question: okay, I have a verifier, so what can people actually do with it?”

At the time of her interview, zk-Lock was running on the Pudge testnet and included a command-line interface for deploying, locking, and unlocking cells. She had also added a proof-binding variant after a community review identified a security gap. That work matters because a privacy tool must do more than demonstrate an interesting cryptographic idea; it must also account for how proofs are used in real transactions.

Ebube Chukwuma (Smilez): Making Fiber Easier to Run and Use

For Ebube, a recurring challenge has been the technical effort required to use Fiber. Running a Fiber Network Node can involve command-line tools, node configuration, connectivity settings, and channel management. Those requirements can become a barrier for developers and users who simply want to experiment with the network or accept payments.

His Fiber Studio project approaches that problem through a desktop application. It is designed to let users run, monitor, and manage a local Fiber node through a graphical interface rather than relying entirely on command-line operations. Smilez has said that building Fiber Studio is one of the achievements he is most proud of, noting that people are already using it to run Fiber on their desktops.

The project is still under active development, with a version-one rebuild underway to improve performance, node stability, and channel synchronisation. Its progress can be followed in the Fiber Desktop rebuild discussion on Nervos Talk.

Smilez has also been working on FiberFlow, which addresses a related but distinct problem: helping merchants accept payments through Fiber. The project combines a self-hosted payment backend with invoice and webhook APIs, a checkout page, and a merchant dashboard. The aim is to reduce the amount of custom infrastructure a store would otherwise need to accept payments through Fiber channels.

FiberFlow has a public testnet demo, including a customer demo store and a merchant dashboard. It remains in active development, so it is more accurate to describe it as a working testnet demonstration than a fully launched payment product.

The two projects complement each other. Fiber Studio focuses on making a node easier to run; FiberFlow focuses on making payment acceptance easier to integrate. Both reflect Smilez's interest in removing friction between the underlying technology and the people who might want to use it.

Oluwaseun: Turning a Hackathon Idea into Reusable Infrastructure

Oluwaseun's progress illustrates how a project can change significantly after its first success. His work on PactAgent began as a milestone-based agreement and escrow concept built on CKB. The idea was to support workflows in which funds, milestones, and agreements could be managed according to defined conditions rather than relying entirely on trust between the parties.

Winning the AI agent hackathon gave Oluwaseun a reason to continue, but he did not treat the hackathon version as the finished product.

Instead, PactAgent is being reworked into API-first infrastructure for agreements, milestones, escrow workflows, proofs, disputes, and webhooks. The intention is to make its capabilities reusable by other applications, rather than keeping them confined to a single demonstration.

Oluwaseun has described this transition as a major part of his development. Refactoring PactAgent has forced him to think beyond making a demo work and pay more attention to developer experience, reliability, APIs, testing, and long-term maintenance.

The next step is to validate its core workflows, complete integration work, and prepare the infrastructure for use by real applications. PactAgent has not yet been publicly launched. Neither has Klaveroq, the product Oluwaseun is developing to use PactAgent's infrastructure.

The distinction is important: PactAgent is evolving towards a reusable technical foundation, while Klaveroq is intended to demonstrate what can be built with it. For Oluwaseun, the hackathon win was a milestone, but the larger task is turning that early promise into something dependable enough for others to use. You can also read his PactAgent builder interview on Nervos Talk.

Ngoc: Making Toy Trading Familiar to Everyday Users

Ngoc approached CKB from a background in embedded software engineering. One of his projects, ToyTrade, grew from a simple observation: children can quickly lose interest in toys, even when those toys are still useful to another child.

ToyTrade is a marketplace intended to help children and parents trade used toys. Each item receives an identifier using Spore digital objects, allowing its ownership and history to be tracked. The aim is to make that process accessible to ordinary users, not just people who already understand blockchain technology. As Ngoc describes it, users should be able to scan a QR code to begin a transaction rather than having to navigate a complicated blockchain interface.

That emphasis on familiarity is important. ToyTrade is not designed simply to showcase digital assets; it applies CKB and Fiber to a recognisable, everyday activity. The blockchain components support the identification and history of traded items, while the user experience is intended to remain straightforward.

At the time of his interview, ToyTrade was running on testnet. Ngoc described building it as an opportunity to learn web application development and smart contract development, while also improving how he manages his time alongside his full-time role at Renesas.

The Community Behind the Code

Behind every project is a developer making decisions, working through problems, and trying to figure out what needs to improve. But these builders’ stories show that progress rarely happens through code alone. A review can reveal a weakness the original developer missed. A question from another builder can lead to a new feature. Sometimes, the most important contribution someone makes is not a new project, but helping another person make theirs stronger.

For Rick, that support made a direct difference to CrowdCell’s design. His original version still depended on backers cooperating to release or recover their pledges, which meant the crowdfunding process was not yet as trustless as he wanted it to be. Feedback from Neon helped him recognise the gap, while discussions with other developers informed his approach to pledge locks and receipts. He then submitted the project through the CKBuilder project review process, where Officeyutong reviewed the v1.1 contracts and identified six issues, including two serious ones.

Rick was clear about how much that review mattered. He described it as “the single most useful piece of feedback the project has had” because it exposed vulnerabilities before mainnet. He fixed the identified issues and continued working through a second round of review. For him, the lesson went beyond CrowdCell: a project can appear to work as intended and still contain weaknesses that only become visible when someone else examines the code carefully.

His experience also shows why sharing work before it feels completely finished can be valuable. Rick has published more than 30 weekly progress reports since August 2025 through his CKB builder progress repository. The reports document what he built, what broke, and what changed. As he explained, they kept him accountable even during slower weeks, when progress might otherwise have been easy to lose sight of.

Cecilia Mulandi has experienced that same feedback loop from another angle. Her zero-knowledge work began with the Groth16 verifier for CKB, but the contribution became more meaningful when other developers began using it. Arthur integrated the verifier into CellScript, Xiaomao explored related tooling, and Truth used it in a two-player zero-knowledge word game. Their projects and questions helped reveal what the verifier made possible and what additional tools developers still needed.

That kind of reuse changed Cecilia’s understanding of what a successful contribution looks like. As she put it, “With the verifier, my main question was ‘does this work?’ Now I start with ‘who uses this, and how easily can they?’” The shift is important: it moves the focus from getting a technical implementation to work towards making it understandable, accessible, and useful to people building on top of it.

The community’s role became even more tangible during the development of her zk-Lock project. After Cecilia had implemented the original lock script, Truth reviewed the tutorial and identified a security issue: a proof that was not properly bound to the transaction could potentially be copied and used in a different context to redirect funds. Cecilia responded by developing zk-lock-bound, which binds the proof to the transaction being spent. The updated implementation was merged through zk-Lock pull request #4 and deployed on the Pudge testnet alongside the original version.

Cecilia’s reflection on the experience captures what makes this process valuable:

“People actually read your code, question your design, and care enough to tell you when something is wrong.”

It is a striking example of community support that does not mean simply encouraging someone or praising their work. It means taking the time to examine an implementation, explain a problem, and help make the result safer. Cecilia could improve her project because another builder was willing to look closely at it; Truth, in turn, contributed something beyond his own projects by helping strengthen hers.

Truth’s own journey shows how this relationship can develop further. Through projects such as Vellum, he has experienced public feedback, technical review, and maintainer discussions that changed his implementation and clarified how its components should fit together. His contribution to the official CCC codebase through pull request #376 added identity-related functionality, tests, and examples after working through maintainer review. The result was not just code in a personal repository, but a contribution incorporated into shared developer infrastructure.

He has also started reviewing other builders’ work. His review of Cecilia’s zk-Lock tutorial is one example; his participation in public project discussions and the CKBuilders review channel is another. That is an important change in the relationship between a new builder and the wider ecosystem. Someone who once needed guidance can gradually become the person identifying a problem, answering a question, or helping another developer avoid a mistake.

Making the feedback loop visible

The CKBuilder project tracker on GitHub gives this process a practical structure. Builders can submit an issue describing their project, its current features, planned work, deployment status, repository, demo, and the specific feedback they want. Reviewers can then examine the project and offer technical advice, identify weaknesses, or suggest ways to improve it. The tracker also provides a public record of projects and their development stages, making it easier to see which ideas are still being explored and which have progressed further.

This matters because a project update becomes more useful when it includes enough information for someone else to respond. A repository shows the code; a testnet demo lets people try the application; a progress report explains what has changed; and a clearly stated request for review gives others a starting point. Together, these make it easier for feedback to become practical rather than remaining a general conversation about an idea.

The GitHub process also creates a record of how a project improves. Rick’s contract review is one example. Truth’s work on CCC shows how an individual contribution can pass through maintainer review and become part of a shared codebase. Cecilia’s zk-Lock changes show how an external review can lead to a concrete security improvement. In each case, the value lies not in avoiding every mistake on the first attempt, but in making it possible for others to identify problems and for the developer to respond.

The wider CKBuilder programme supports this approach by connecting builders with experienced developers and giving projects a place to be presented, reviewed, and tracked. Nervos Community Catalyst’s own updates describe the tracker as a central record of work in progress and report that projects have been submitted for technical review by core CKB developers Nervos Community Catalyst: Quarterly Reports - General - Nervos Talk.

Of course, not every suggestion will be adopted, and not every project will reach production. Some will remain experiments; others will change direction after feedback. But a public process makes those stages easier to understand and gives projects a better chance of benefiting from knowledge beyond the person who started them.

From Community Support to Funding and Recognition

A working prototype can show that an idea is possible, but taking it further often requires something more: time to develop it properly, feedback from people who understand the problem, and a clear plan for what comes next. For some CKB builders, community support has opened the door to funding. For others, a hackathon has provided recognition, while the process of preparing a grant proposal has taught them how to communicate their work more effectively.

These experiences show that funding is not simply a reward for writing code. It involves explaining why a project matters, setting realistic goals, responding to questions, and showing that the work can progress beyond an initial demonstration.

Truth: Turning a Rejected Proposal into Funded Infrastructure

Truth’s experience with Vellum illustrates how a funding setback can become an opportunity to rethink a project and present it more clearly. His first Community Fund DAO proposal did not pass. Rather than abandoning the idea, he revisited the proposal, clarified Vellum’s technical foundation and independence, adjusted the scope and payment structure, and responded to concerns raised during community discussions.

The revised proposal passed with 64.37% approval, and the kickoff funding arrived the following day.

Looking back, Truth described the achievement as more than securing a grant. He said he was most proud of “turning Vellum from a rejected proposal into funded, working infrastructure and then delivering its first milestone publicly.”

That distinction matters because the funding was followed by tangible development. The first milestone delivered Claim Type and DID Lock contracts on CKB Testnet, the @usevellum/sdk package, account-verification flows, a versioned reputation policy, seven published schemas, and a dashboard showing the evidence behind reputation scores. The delivery report also recorded 326 TypeScript tests, 21 Rust and CKB-VM tests, and six public Testnet checks.

Truth’s journey demonstrates why a proposal that initially fails does not necessarily mark the end of an idea. Clearer communication, a more concrete scope, community engagement, and evidence of delivery can help a project earn renewed support.

Cecilia Mulandi: Funding with Clear Milestones

For Cecilia Mulandi, funding helped address a practical obstacle to using her zero-knowledge work. Her Groth16 verifier for CKB already existed, but developers wanting to use it still had to connect several separate pieces themselves, including the verifier, lock-script scaffolding, witness encoding, and transaction construction.

Her proposal for zk-Lock aimed to bring those components together. Instead of requiring each developer to repeat the integration work, zk-Lock provides a more reusable path for creating a Circom circuit, committing to its verifying key, locking a cell behind the proof, and unlocking it when the proof is valid.

She delivered all three Spark grant related milestones:

• Milestone 1: The core zk-Lock lock script.
• Milestone 2: Deployment on the Pudge testnet, including a command-line interface and the first on-chain unlock.
• Milestone 3: A reproducible Circom circuit, TypeScript SDK, Rust encoding pipeline, end-to-end tutorial, and continuous integration.

The milestone structure gave the work a defined path from core implementation to a more complete developer experience. Cecilia noted that the weekly check-ins also helped keep her accountable.

The project received an additional benefit from community review. Truth examined the implementation and identified a security weakness involving proofs that were not sufficiently bound to the transaction being spent. Cecilia developed zk-lock-bound to address the issue, and the change was merged into the main project.

Cecilia’s Spark proposal for zk-Lock documents the project and its original funding request. Her experience shows that a small scope can still produce meaningful progress when the scope is adjusted, the milestones are clear, and feedback continues after approval. It also shows that completing the technical work is not always the final step: documentation, contribution guidance, and opportunities for other developers to participate help make a project more useful beyond its original author.

Smilez: Community Fund DAO Support for Fiber Studio

For Ebube, Community Fund DAO support helped him take Fiber Studio through a substantial rebuild.

Fiber Studio, also described as Fiber Desktop, aims to make running a local Fiber node easier by replacing a complicated command-line setup with a desktop application. The goal is to lower the barrier for developers and users who want to work with Fiber but may find the initial setup difficult.

Smilez confirmed that his proposal was successful and that the funding accelerated development, enabling a ground-up rebuild of the v1 application. He described the result as a more robust, high-performance desktop application for the ecosystem.

Community feedback played a role in that decision. Smilez explained that problems with Fiber Node channel synchronisation during the initial build, alongside discussions on Nervos Talk, helped guide him towards rebuilding the application rather than simply making small changes to the existing version. The wider support also helped refine the architecture of Fiber Studio and related proposals.

The work can be explored through the Fiber Studio ground-up rebuild discussion on Nervos Talk and Smilez’s related UDT for Fiber Mainnet proposal.

Smilez’s experience also highlights an important part of building infrastructure: making a tool work is only one challenge. It must also be stable, accessible, and practical for the people expected to use it.

Oluwaseun: Recognition Through a Hackathon

Not all recognition comes through a grant proposal. For Oluwaseun, PactAgent finished first-place finish in the Claw & Order: CKB AI Agent Hackathon.

PactAgent was built around milestone-based agreements and escrow on CKB. The idea was to create a system for managing agreements and releasing funds according to defined conditions, rather than relying entirely on informal coordination between the parties involved.

Winning the hackathon recognised the work he had already put into the project, but it also became a starting point for a different phase of development. Oluwaseun has since been developing PactAgent into API-first infrastructure for agreements, milestones, escrow workflows, proofs, disputes, and webhooks. Klaveroq, a separate product under development, is intended to use that infrastructure.

He explained the shift in his approach:

“Initially, I focused on getting a working product built. I now pay more attention to architecture, API boundaries, security, tests, documentation, and deployment planning.”

That change is significant. A hackathon project often begins with a clear demonstration of what is possible, but building something that other applications can rely on requires attention to integration, reliability, and long-term maintenance.

The prize gave PactAgent recognition, but the next challenge remains the work of turning a promising project into dependable infrastructure. Oluwaseun’s account makes clear that winning is not the end of that process; it is one step in a longer development journey.

Rick: Learning How to Build Support Before Asking for Funding

Rick’s experience with CrowdCell offers a useful contrast. While Truth’s revised Vellum proposal secured funding and Cecilia’s zk-Lock received Spark support, Rick’s latest Community Fund DAO proposal had reached the voting stage but had not yet been awarded a grant at the time of his interview.

CrowdCell is an all-or-nothing crowdfunding application on CKB. Its scripts are designed to release pledged funds to a creator when a campaign succeeds or return them to backers when it fails. Rick’s first Community Fund DAO proposal stalled at 16 of the 30 likes needed to proceed to a vote.

He took the feedback seriously and resubmitted a smaller, testnet-focused proposal. The revised scope concentrated on developing the existing demonstration into a more complete product, with planned features including creator and backer dashboards, .cell name support and Vellum reputation, keeper incentives, categories and search, a Chinese-language interface, and optional early campaign finalisation.

This time, the proposal reached the 30-like threshold in three days. Reaching that stage was meaningful progress, but it has not yet completed the grant approval process. Rick’s own explanation of the first setback was direct:

“The main lesson: the process rewards engaging the community before you post, not just good code.”

He described how he spent more time participating in CKBuilders and forum discussions, speaking with people directly, and helping where he could before reposting the proposal. That changed the response: the revised proposal went from 16 likes in a week to 30 in three days.

Rick’s experience adds another lesson to the stories in this section: community engagement is not something to begin only when funding is needed. It is part of the ongoing work of building trust, making a project understandable, and helping people see why its next stage is worth supporting.

What Funding and Recognition Really Require

These five experiences show different ways community support can influence a builder’s progress. Truth revised a proposal that had failed and went on to deliver funded infrastructure. Cecilia adjusted her scope and milestones to secure Spark support, then delivered the work and improved its security through further review. Smilez received support for a major Fiber Studio rebuild. Oluwaseun’s hackathon win recognised PactAgent and gave him a platform from which to continue developing it. Rick, meanwhile, learned that a proposal needs community engagement and a clear scope before it can be successful.

There is no single route from prototype to a sustainable project. A grant, a hackathon prize, technical feedback, or sustained community participation can each help, but none removes the need to do the work. Builders still have to define what they intend to deliver, explain why it matters, respond to questions, and demonstrate progress. That is perhaps the strongest connection between these stories: support becomes most valuable when it is tied to a clear next step. Funding gives a builder room to work, but milestones make that work accountable. Recognition brings attention, but continued development gives people a reason to remain interested. And community discussion helps proposals become clearer before funds are committed.

A Growing Community, Beyond One Region

The stories in this volume come from different places, but they share a common thread: people discovering CKB through their existing interests, finding others willing to help, and gradually contributing work of their own. From Nigeria to Kenya and Vietnam, their experiences show how builders can find a place in the ecosystem without following the same path.

For Cecilia Mulandi in Kenya, that journey began with a post shared in a Web3 community WhatsApp group. Already interested in cryptography and zero-knowledge proofs, she recognised CKB’s potential as a verification layer and began contributing technical work, including a Groth16 verifier and zk-Lock. Support from other developers helped her refine those contributions and make them reusable. Her involvement has also extended beyond code: Cecilia has spoken with local developers about CKB and explained how its cell model works, sharing what she has learned with people exploring the technology for themselves.

Ngoc Vo’s experience in Vietnam offers a different perspective. Working as an embedded software engineer at Renesas, he already had experience with RISC-V-related technology before discovering CKB. That familiarity drew him towards the CKB-VM, but blockchain development introduced new concepts to learn. Through projects such as ToyTrade, he has been exploring how to apply what he knows while balancing development with his full-time job. His story reflects a gradual process of learning by building rather than an overnight transition into a new field.

Nigerian builders bring further perspectives. Truth has moved from learning the fundamentals to developing identity, reputation, and developer tools, while also reviewing other builders’ work. Oluwaseun’s hackathon experience shows another route into recognition, and Smilez’s work on Fiber Studio demonstrates the importance of making technical infrastructure easier for others to use. Their experiences also point to the value of sharing progress, asking questions, and helping fellow developers along the way.

These stories do not, by themselves, establish how quickly CKB is growing in any particular country. What they do show is how participation can develop in different settings: through a local Web3 group, an existing technical background, a learning programme, or a project that attracts the attention of other builders.

A community becomes more than a collection of individual contributors when knowledge begins to travel between them. Someone discovers the technology, receives guidance, builds something useful, and eventually becomes a source of support for someone else. Across these experiences, that cycle is already visible and it offers a practical picture of how the CKB community can extend beyond any single region.

The Next Stage/Conclusion

For these builders, reaching a first milestone is not the end of the journey. It is a starting point for making their work more useful, reliable, and accessible. Whether the focus is making privacy applications easier to use, strengthening Fiber infrastructure, improving existing products, or developing practical applications for everyday users, the next stage is about moving beyond what works in a demo towards what people can depend on.

That progress also depends on bringing more people into the ecosystem. Hackathons, Build on CKB weekly challenges, prizes, and other community initiatives offer different ways for aspiring builders to learn, experiment, receive feedback, and contribute. These opportunities do not guarantee an easy path, but they can give newcomers a place to start, a problem to solve, and a community to learn alongside.

The experiences in this volume show that building on CKB is rarely a solitary effort. Projects improve through reviews, conversations, shared tools, and the willingness to learn from mistakes. Some builders are still exploring ideas; others are refining products or taking on more demanding technical work. Each stage matters.

The strength of an ecosystem is not measured only by how many projects it produces. It is also measured by whether its builders help one another grow, make their work better over time, and remain willing to contribute. That is how individual projects can become the foundation for a stronger CKB community.

For anyone with a web development background interested in learning CKB or joining the CKBuilders, send an email to neon@nervos.community.