My Reddit account was rate limited, so let me post in here first…
Thanks again to everyone for the questions! Writing the answers gave me plenty of food for thought as well. Please feel free to keep sharing your questions, and if anything else comes up, you are welcome to ask me directly on Nervos Talk.
Originally written in Chinese and translated into English by ChatGPT.
How Can We Use AI?
Q: CCC now ships Agent Skills for building with the SDK, and the maintenance notes say there is no eval suite for them yet. Where do you see DevRel’s AI resources going: will they cover on-chain scripts too, writing and reviewing them, and would you take community skills there? (asked by @LusoCryptoLabs on Nervos Talk; reposted to Reddit by u/djminger007)
Q: I’ve seen you’ve tailored some tools for Agentic usage, are there more planned in this area? (asked by u/aintLifeaBTC)
I think the AI Skills added to CCC are a good start. They capture some recurring problems AI may encounter and help shorten the development workflow. We are also exploring development paradigms for on-chain CKB contracts, but you should regard AI work on scripts as being at a very early, exploratory stage.
Completing CCC’s AI Skills does not mean we can simply replicate that experience and quickly make every other part of CKB development AI-friendly. At the off-chain application layer, I think there is still a lot we can let AI accelerate. We will therefore explore more things at this layer, such as MCP servers or the eval suite you mentioned, to get the most out of what we already have.
I do not want us to build AI tools simply because something is not yet “AI-enabled” enough and we feel compelled to do something urgently—even though we have not worked out what it could do, or whether anyone would need it. In my experience, that always ends up wasting people’s time.
On accepting community-contributed skills, I am assuming you mean whether they would be included in CCC or other shared repositories. I will discuss that later alongside the question of which protocols should become first-class maintained packages in CCC.
Q: CKB is typcally difficult to build on but has gotten easier. 1> How is Ai expanding the ability to develop on CKB? 2> Do you have any examples/links or any technical summaries to post on here? 3> What is the estimation in percentage on how useful it is, what you can do and can’t do? (asked by u/djminger007)
Q: How does the team feel about Ai hallucinations? Will it affect the industry as a whole? How is CKB aligned to safeguard the chain against future security issues? Can it even be a security issue to the core level? (asked by u/TheCrimsonSquirrel)
AI is a very capable coder, and over the past six months, hallucinations in frontier models have already been brought down to a fairly low level. I think developers who have used the latest models during that time should be familiar with this, so I do not need to belabour the point. The same holds for CKB: a few well-coordinated AI agents working in parallel can easily outpace the speed at which developers used to write code by hand. You should definitely try using AI to take over any task you find tedious and repetitive; in most cases, it can reduce your workload. AI can efficiently build frontend applications from existing protocol designs, generate large amounts of repetitive tests and glue code, or quickly read extensive source code to analyse problems. These are all useful applications on CKB.
Whether you are working with AI or other people to produce high-quality results, I think the key is to establish clear boundaries. Absolute security does not exist. That is why we do not entrust the survival of an entire system to one person, and the same applies to AI. If an AI-generated component has a problem, can the system’s architecture minimise the damage? That is what maintainers need to consider, and it is an essential part of preventing security problems. This is also why I do not think handing over critical boundaries such as protocol design to AI is a good idea.
That said, AI does allow irresponsible people to produce bad code faster, and this has certainly increased the review burden on maintainers. Interestingly, AI can also help maintainers review code and uncover hidden problems. System security is always a dynamic process, and I believe people will find a balance.
I have expressed this view many times: when the audience is another human being, you should not let AI do your thinking for you. For example, you would not want to see me paste a lengthy AI-generated essay here as my answer, and I would not want to decipher someone else’s intentions through AI either. An elegantly worded AI-generated article is no better than a simple expression of your own thoughts in rough language. This has nothing to do with AI’s capabilities or style. It is simply because I am a human being, and I do not want to become a slave to an efficiency machine.
Developer Experience and Infrastructure
Q: What do builders ask DevRel for most that the team has not had time to build yet? Some of us might be able to pick it up. (asked by @LusoCryptoLabs on Nervos Talk; reposted to Reddit by u/djminger007)
Q: Tooling on CKB has come a long way since the early days, are there any gaps you still see in this area? (asked by u/aintLifeaBTC)
Q: For developers coming from other blockchain ecosystems, how easy is it to start building on CKB today compared with 2024? What were the biggest barriers for newcomers back then, and which of those have been solved by 2026? Are there still any major challenges that make building on CKB more difficult than on other chains? (asked by u/Agile-Eye6172)
Q: CKB has long been criticized by the community for being difficult to build on. During the 2024 cycle in particular, CKB gained a lot of attention and attracted quite a few developers, but for various reasons, not many of them ended up staying. What do you think caused this? How much has the development environment improved since then? And what areas do you think the community should continue working on together? (asked by u/yxh185)
In 2024, developers had to solve many basic problems themselves, from the ground up: How do I connect a wallet? How do I assemble a transaction? Pay fees? Sign it? Interact with different protocols? These issues, which lie outside a developer’s core idea, can quickly drain their enthusiasm and make it difficult to keep building an application. I think this was one important reason developers struggled to stay. CCC aims to solve these everyday obstacles in advance so that developers can focus on their own ideas.
Among the unresolved issues, the first thing that comes to mind is data indexing on CKB. The community keeps working to make progress here—and if you have not tried CKBadger, you definitely should. Almost every application needs to query complex, aggregated data on CKB. I find it frustrating that we still do not have a sufficiently mature solution, but this genuinely requires an enormous amount of effort, time and supporting infrastructure.
Another difficult problem is on-chain behaviour that can still be adapted after signing. Consider two users trying to interact with the same piece of on-chain data at the same time—for example, both buying tokens. Two fixed transactions, neither taking the other into account, will inevitably cause one of them to fail. Approaches that allow transactions to change, such as Open Transaction, have been explored for many years, yet we have struggled to arrive at a solution people are satisfied with. Even so, I still believe it is worth implementing. Over the past two years, UTXO Swap’s intent-based, multi-step transaction approach has produced promising results, and we are also trying to generalise this idea in the CKB Cinnabar framework.
If you have new ideas for accomplishing these things, please give them a try! Running your own public CKBadger instance or providing feedback on CKB Cinnabar are also worthwhile ways to contribute.
Q: Indexer and light-client trust in the SDK. Most CCC flows assume a node plus indexer for live cell queries. What is the intended trust model for dApp builders today, and is light-client verification (or a pluggable proof-checked cell source) on the DevRel roadmap so apps can avoid treating a third-party indexer as the source of truth? (asked by an unnamed contributor; relayed by u/djminger007)
I discussed some possible approaches to verifying data reliability in the discussion of the CKB_TX_MESSAGE_ALL design. I would be interested to hear your thoughts on them. CCC currently trusts its indexer/node data sources completely, and for now I also recommend that dApps do the same. I am not in a hurry to add too many mechanisms to address this issue. The CKB blockchain already provides “trusted” validation of script logic; a malicious indexer cannot magically break that security model.
A malicious indexer can, however, distort the data a user sees and cause them to authorise a transaction they did not intend. But the misconception that “the dApp should verify the correctness of the data” largely stems from the absence of a trusted verification and presentation layer between today’s dApps and wallets from other chains. As a result, we can only hope that the dApp will take responsibility for security, when this should in fact be the wallet’s responsibility.
One solution I am exploring is to use the Khie protocol to connect to a wallet running in a separate, trusted environment, and to inspect the request shown by the wallet. However, the web-based intermediary still directly trusts the indexer’s data for now. Perhaps we can add independent verification in the future.
Q: On-chain script inner loop. OffCKB, Cinnabar deploy/migrate, and the debugger/Capsule path still feel separate. What is the biggest remaining gap between editing a RISC-V lock/type and a reliable local fail-fast cycle — especially for syscalls, dynamic loading, and spawned VMs — and is closing that gap owned by DevRel or by core? (asked by an unnamed contributor; relayed by u/djminger007)
As you point out, the CKB script development experience is still incomplete, and testability remains one of the biggest obstacles to development. The prevailing approach still ties business logic directly to syscalls, which means most tests depend on a simulated CKB VM environment and require developers to write the test logic from scratch. This is likely to be considerably inconvenient for developers accustomed to modern application development.
Providing the right abstractions for scripts and their supporting facilities, such as syscalls and dynamic scripts, should make testing substantially easier. Much of the development–testing feedback loop could be reduced to unit tests, greatly reducing coupling within the system. This is not something only one particular team can do, but expecting each developer to devise their own solution is certainly not an ideal developer experience. It is an issue DevRel wants to address actively, while the Core team focuses on the stability of the underlying infrastructure.
Q: Is it possible in a way for developers to install both off ckb and ckb cli in one bundle? (asked by a CKBuilders participant; relayed by u/djminger007)
Of course! Bundling them in a separate project should be relatively straightforward. But if you are asking whether OffCKB or ckb-cli will integrate the other, that depends on their maintainers. See my answer below about which packages can be included in CCC.
Application Directions on CKB
Q: Are there particular types of applications you wish to see built on CKB? (asked by u/aintLifeaBTC)
Q: What would you say was an under explored capability or use case of CKB? (asked by u/aintLifeaBTC)
Build something you feel passionate about, and keep that passion alive.
Since the beginning of CKB, the same questions have kept coming up: What kind of data do you want a decentralised network to keep recognising? How much are you willing to pay for that? Sometimes people misunderstand these questions, trying to persuade users to put data on-chain when it does not need to be there, or choosing to leave important data on a server to avoid the cost. Even if we set these questions aside for a while, we will eventually have to answer them.
I have always wanted to see more mature approaches to layered data storage on CKB. Spore has explored storing all data on-chain, combining metadata with a generative program, and using IPFS or server storage, but it is still largely at the stage of displaying simple images. I think connecting these ways of storing and transferring data to more practical use cases could help people better appreciate the value of CKB’s on-chain data storage. For example, I have recently been thinking about using a P2P network to enable a multisignature wallet to manage on-chain assets.
Q: Is CKB currently ready for real-world asset tokenization? If so, what tooling and infrastructure are already available for developers, and what is still missing? (asked by u/Agile-Eye6172)
Q: Are there any plans to launch or support a stablecoin on Fiber Network in the near future? If so, is this something the team is actively working toward? (asked by u/Agile-Eye6172)
Q: Stablecoins play a critical role in any blockchain ecosystem. Whether it’s DeFi or payments, both rely heavily on stablecoins as a fundamental piece of infrastructure. How do you think CKB should bring stablecoins into the ecosystem? Does the team have any plans in this area? (asked by u/yxh185)
I am not the best person to answer these questions, and I cannot speak to questions about stablecoin issuance. As things stand, CKB does lack trustworthy, usable links to real-world assets, but questions involving real-world assets usually depend more on markets, capital and the interests of the parties involved. I do not think these questions should be approached primarily as problems of technical design. From the beginning, CKB’s infrastructure has been heavily influenced by regulatory requirements for assets—to the point where I think it has gone somewhat too far—and Fiber has supported the movement of UDTs from the outset.
Q: What are the biggest technical or developer-experience barriers currently preventing wider adoption of RGB++, and which of them is DevRel actively working to solve? (asked by u/Agile-Eye6172)
Q: It seems that the project team and community developers are currently mainly focused on Fiber. Has development of the RGB++ protocol essentially stopped? What are your own thoughts on RGB++? (asked by u/yxh185)
As I see it, RGB++ has not changed much from when it first appeared two years ago: users submit transactions on Bitcoin to interact with an asset other than BTC. RGB++ continues to be maintained and developed, and developers can still build applications using the existing infrastructure.
I do not think any fundamental technical problem is blocking RGB++’s development. The problem is that the solutions we imagine around RGB++ are heavily constrained by its existing form, making it difficult to pursue bolder ideas on top of it. I would like to revisit the idea of “using CKB to extend Bitcoin’s capabilities without encroaching on Bitcoin’s value”, so that RGB++ can make fuller use of CKB’s capabilities, become a Turing-complete layer for Bitcoin, and move beyond simply piling up concepts.
Q: Do you see privacy becoming an optional, foundational capability of CKB, allowing developers and users to choose privacy when needed rather than making it mandatory? (asked by u/Agile-Eye6172)
I do not have a definitive answer, but I would absolutely encourage anyone who wants to explore privacy. All data on a blockchain is fully public to its participants, so finding ways not to disclose everything within such a deterministic system is a very interesting problem. And, as you say, CKB’s flexibility means a privacy layer can be an optional application-level capability rather than something enforced across the entire chain.
SDKs and CCC
Q: Cell selection and capacity completion in CCC. completeInputsByCapacity / completeFeeBy hide a lot of Cell Model mechanics. How does DevRel want those helpers to behave when type scripts have non-obvious occupied capacity, when inputs are constrained by lock/type pairs, or when a tx both consumes and creates cells under the same type? Where do you draw the line between “SDK finishes the tx” and “caller must supply an explicit cell-selection strategy”? (asked by an unnamed contributor; relayed by u/djminger007)
Thank you for the technical question! The FeePayer abstraction (issue #274) may help answer it. Rather than making the existing Transaction.complete* methods endlessly smarter so that they accommodate every possible future transaction, I think I should reconsider whether this responsibility belongs in the Transaction abstraction at all. If there are inevitably going to be many different capability requirements, a better approach may be to keep the general-purpose FeePayer focused on common logic and leave protocol-specific semantics to concrete implementations, rather than continually expanding its default behaviour.
Q: Language SDK divergence. CCC is the JS/TS flagship, while Rust and other clients still exist in the wider ecosystem. Is the plan a single protocol surface (known scripts, SSRI method sets, UDT/Spore layouts) that every language SDK is expected to track, or is JS intentionally the source of truth and other languages second-class? How do you stop script hashes, dep groups, and error codes from drifting across repos? (asked by an unnamed contributor; relayed by u/djminger007)
The only source of truth is the CKB chain itself. CCC is just one interpretation of it in the JS/TS ecosystem. SDKs that correctly implement the on-chain protocols should not diverge too far in their core design. Of course, I would like CKB SDKs across languages to offer consistent capabilities and developer experiences, but users of different languages have different habits, and maintenance teams have different amounts of time and resources. Most importantly, CCC is not the only correct answer to developer experience.
For that reason, I do not think divergence in developer experience is something we need to go to great lengths to prevent. It is a natural part of an ecosystem’s development: alongside its drawbacks, it also opens up more possibilities.
Q: First-class protocol packages vs. community scripts. CCC already ships pieces like Spore, UDT, and SSRI. What criteria decide that a protocol gets a maintained u/ckb-ccc/* package instead of living only in known-scripts or a third-party repo? How do you version those packages against Type ID migrations and script upgrades so dApps don’t pin a stale dep group? (asked by an unnamed contributor; relayed by u/djminger007)
I think this depends entirely on the repository maintainers’ judgement—in CCC’s case, that is me. If a problem arises in the protocol or skill in the future, are the maintainers willing and able to fix it? If not, can the contributor take on that responsibility and become the component’s long-term maintainer?
If we can answer those questions affirmatively, then of course the component can be included in a shared repository. Otherwise, it should not be. A poorly maintained component in a shared repository is no better than a well-maintained one in an independent developer’s repository, and anyone can try to build the latter. We are, of course, very happy to add a link to another project in CCC’s README to help people discover it.
In our experience with CCC so far, using a Type ID to discover the latest script version on-chain is a simple approach that works well. This does not mean every user has to use the script with hash_type: type. Developers can still choose to rely primarily on the data hash to pin a script version—although experience over time seems repeatedly to show that this often remains an ideal rather than a reality. The script’s code cell can simply carry a Type ID to help off-chain applications discover it. CCC also provides a Type ID-based dep group management tool to help with this.
You can probably see that this is not the most “elegant” solution. In theory, this coordination should be handled by an off-chain indexer. But if the current approach works simply and effectively, why not?
Ecosystem, Positioning and Responsibilities
Q: Is CKB’s current direction and positioning mainly focused on being a BTC L2? What other thoughts do you have about CKB’s future direction? (If possible, I’d really like to hear your own personal perspective.) (asked by u/yxh185)
No. Speaking personally, I think positioning CKB as a Bitcoin L2 is a bad idea. CKB is an L1 in the UTXO ecosystem. Nevertheless, Bitcoin’s importance to CKB, and the technical similarities between the two, are self-evident. We should actively encourage developers on CKB to embrace that relationship. Ideally, what we build and learn in the CKB ecosystem should feed back into the Bitcoin ecosystem, allowing CKB to realise its own value rather than making its existence dependent on Bitcoin’s value.
Q: Do you think the funding from the CKB Community Fund DAO and Spark Program will leave anything genuinely valuable behind for the ecosystem? Do you think these programs should be maintained long-term? Could their existence actually be misleading or create perverse incentives—for example, most projects on CKB wanting to apply for funding before they even start building, rather than contributing voluntarily and finding ways to create value and build sustainable businesses like in other ecosystems? I’m already starting to feel that this trend is emerging. (asked by u/yxh185)
Both the Fund DAO and the Spark Program have had projects demonstrate that they can leave something valuable behind for the community—for example, Omiga or Quantum Purse. A small amount of initial funding may not cover every cost, but it can help developers bring their ideas to life on CKB with their own passion behind them. I think this is a very efficient use of funds and is absolutely worth continuing.
But as you say, prioritising funding over the product is bound to happen, and there is no denying that this mindset has become increasingly prevalent in Nervos recently. On one side, applicants may lose sight of their goals, shifting from building out of passion to building for the reward. On the other, reviewers also need to reconsider what kinds of projects they want to encourage. We cannot focus only on the number of developers, the number of projects, or how compelling a project sounds. We need to care more about whether developers can keep moving their projects towards success, and whether they need something beyond money.
Q: We’ve seen a big uptick in people building on CKB through the hackathons, spark, and community DAO fund programs. Does the DevRel team audit all the code from these initiatives to make sure its safe before its published? (asked by u/kevtam515)
No. I used to read every line of code written by other people or AI during reviews, but I later realised that I had made myself the sole bottleneck and severely limited how efficiently things could move forward. The same applies to community projects: if we believe every project must pass a particular team’s review, we are effectively limiting the entire community’s pace to that team’s capacity.
This is an open-source community. Just as GitHub does not take responsibility for every project it hosts, funding programmes seek to help developers turn ideas into reality, not to endorse their projects. Development teams need to decide what commitments they make to users and take responsibility for those commitments. In Spark’s case, the committee’s technical review is primarily about assessing feasibility and the value of the final deliverables, rather than guaranteeing a project’s security. High-risk projects involving real assets can arrange a separate security audit, and can also seek assistance from the DevRel or Acceptance teams. That still does not mean those teams are endorsing the project’s security.
Q: Who is currently operating the Nervos.bit（@NervosNetwork） account on X? It was CKB’s original official account and has more than 118,000 followers—far more than any of the newer accounts. To be honest, I can barely tell which official accounts are which anymore; the current account structure is super confusing. I still see many people tagging u/NervosNetwork when reaching out to the CKB team, but the account has been left largely inactive for a long time, with regular updates stopping around March 2025. I understand that team structures change, but couldn’t the Foundation or CKB DevRel take over the account and keep it active? (asked by u/yxh185)
I am not the right person to answer this question; perhaps the Communications team could give you a better answer. I do not think DevRel will take over this account. Personally, I also think creating developer-focused content on X is a lot of effort for little return.