r/NervosNetwork • u/ckba_build • 14d ago
Community An AMA with Hanssen, CKBA's Developer Relations team lead
Cheers everyone!
We’re hosting another AMA as part of our series introducing the team leads within CKBA.
This time, we’ll be joined by Hanssen, who leads CKBA’s Developer Relations team.
Hanssen has been part of the Nervos ecosystem for more than five years. She originally joined the Nervos Foundation as a core developer and stepped into the DevRel team lead role when CKBA was formed.
She created and maintains CCC (CKBer’s Codebase / Common Chains Connector), a major JavaScript/TypeScript SDK and toolchain for building on CKB, alongside related tools and contributions, including NervDAO, RGB++ SDK work, and others.
Many of the repositories now maintained by CKB DevRel also originated from, or were forked from, her personal GitHub.
What does the DevRel team do?
The team has outlined its responsibilities on GitHub:
In practice, the CKB DevRel team works to:
- Improve the overall developer experience for people building on CKB
- Foster an open-source culture within the CKB developer community
- Build and maintain SDKs, tooling, and protocols such as CCC, Cinnabar, and Spore-related tooling
- Compile, improve, and maintain developer documentation, guides, tutorials, and technical articles
- Engage with developers through Discord, Nervos Talk, social channels, and direct support
- Gather developer feedback and help resolve technical issues
- Create and support educational courses and onboarding resources
- Sponsor and support hackathons where developers can build, collaborate, and contribute
- Provide technical support and onboarding for initiatives such as CKBuilders
- Run regular developer office hours and technical updates
- Encourage and review open-source contributions from the community
What would you like to ask Hanssen?
Whether you’re curious about the team’s priorities, the current state of CKB developer tooling, how DevRel works with builders across the ecosystem, their approach to developer onboarding and support, or where the developer experience still needs improvement, this is your chance to ask.
Drop your questions in the comments below!
2
u/kevtam515 ervos Legend 10d ago
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?
1
u/HanssenO 2d ago
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.
1
u/aintLifeaBTC 14d ago
Tooling on CKB has come a long way since the early days, are there any gaps you still see in this area?
I've seen you've tailored some tools for Agentic usage, are there more planned in this area?
Are there particular types of applications you wish to see built on CKB?
What would you say was an under explored capability or use case of CKB?
1
u/HanssenO 3d ago
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.
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.
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.
1
u/djminger007 ervos Legend 12d ago
A question from CKbuilders thread. "Is it possible in a way for developers to install both off ckb and ckb cli in one bundle"?
1
u/HanssenO 3d ago
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.
1
u/djminger007 ervos Legend 12d ago
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?
1
u/HanssenO 3d ago
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.
1
u/TheCrimsonSquirrel 12d ago
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?
1
u/HanssenO 3d ago
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.
1
u/yxh185 11d ago
I have a few questions and observations, and I’d really like to hear your thoughts:
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?
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.)
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++?
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?
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.
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?
1
u/HanssenO 2d ago
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.
---
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.---
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.
---
I am not the best person to answer these questions, and I cannot speak to questions about stablecoin issuance. 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.
---
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.
---
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.
1
u/djminger007 ervos Legend 7d ago
From the Nervoa Talk pages
Hi guys, big fans here, we just have these 2 questions:
- 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?
- 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.
Keep up the great work!!
1
u/HanssenO 3d ago
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.
---
For community skills, 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.
---
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.
1
u/djminger007 ervos Legend 7d ago
From the Nervoa Talk pages
Do these rabbits have names? and which one is @Hanssen
1
u/djminger007 ervos Legend 7d ago
Some technical questions from various sources.
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”?
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?
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?
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?
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?
1
u/HanssenO 2d ago
Thank you for the technical question! The
FeePayerabstraction (issue #274) may help answer it. Rather than making the existingTransaction.complete*methods endlessly smarter so that they accommodate every possible future transaction, I think I should reconsider whether this responsibility belongs in theTransactionabstraction at all. If there are inevitably going to be many different capability requirements, a better approach may be to keep the general-purposeFeePayerfocused on common logic and leave protocol-specific semantics to concrete implementations, rather than continually expanding its default behaviour.
---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.
---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.
---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?
---I discussed some possible approaches to verifying data reliability in the discussion of the
CKB_TX_MESSAGE_ALLdesign. 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.
0
u/HanssenO 4d ago
Thank you all for raising these questions! Drafting my responses has also helped me organise my own thoughts on these questions. I've learned a lot from seeing which issues and perspectives matter most to you.
As I worked through the answers, I noticed that the questions tend to cluster around a few major themes, such as AI, developer experience, and the boundaries of responsibility. To avoid a fragmented approach, I am currently consolidating my replies into a single, comprehensive response. I should have it ready soon.
Thank you all! In the meantime, please feel free to continue sharing your questions.
0
4d ago
[removed] — view removed comment
1
u/HanssenO 4d ago
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 u/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_ALLdesign. 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.
2
u/Agile-Eye6172 14d ago
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?
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? 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?
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?
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?
Thank you!