[DIS] CKB Integration for Rosen Bridge

[neon.bit]

Dear @Sonami

Firstly, thank you for this proposal. The Rosen bridge has been a topic of discussion in the community for a while and I’m glad to see a proposal surface that supports our community developers to make this happen. @phroi @Alive24 @jm9k are all highly competent and reliable developers with a strong track record in the community.

Regarding the budget, it wasn’t clear to me in the proposal but could you clarify regarding the amount of RSN stake needed to become a Guard. Does this cost factor into the overall request?

Some topics I would like to share my perspectives on:

Is this bridge actually necessary? Will it be used?

Based on DefiLlama, Rosen Bridge has a TVL of $3.2m, some of which is staked RSN and the majority of it is locked/bridged assets. This puts it roughly into the same bracket financially as Force Bridge which is soon to be decommissioned.

Realistically, we may not see a spike in financial activity from the get-go. Bridges, despite their issues, are still an important financial primitive to introduce assets to different chains, at least until a better design gains traction. Not having the ability to do this closes us off from many potential opportunities mentioned in OP, but primarily these:

• Introducing wrapped CKB to new chains. A tradeable CKB on Uniswap, or Ethereum L2s such as Base or Arbitrum, or a Cardano dex, could create access to new markets and new potential sources of demand for CKB.
• Introducing wrapped coins/tokens to CKB. This is more challenging as we need to improve the DeFi offerings on CKB as well as the number of useful applications.
• New connections and collaborations. This to me is a strong argument in favour of this proposal. Being connected to other chains opens the doors for many new conversations around BD, collaborations and integrations, as well as better exposure to users and developers in other communities. These would otherwise be virtually impossible without a bridge. We stand to gain by being connected over operating as an island.

Should DAO resources be allocated towards infrastructure?

Infrastructure could currently be funded a few different ways, but in the long term governance-based funding will be unavoidable. Existing infrastructure projects would eventually need to transition. It does make sense for new initiatives to subject themselves to governance from the beginning to build community trust, as well as ensure transparency and efficiency.

Overall, I view Rosen bridge as a productive and important step forwards. It is not a panacea, and it will form merely one of many different approaches, but there is much more to lose than gain by not having this option available.

[phroi]

@matt.eth

Shouldn’t ckb’s goal be to generate as many transactions as possible on its own main chain, thereby increasing its occupancy?

I’d like to point out that:

• More Transaction != More CKB used
• More State stored in CKB cells = More CKB used (DeFi cells such as xUDT use a fair amount of CKB )

Feel like we need to soul search for DApps for which Nervos L1 is uniquely positioned. DeFi could be such an avenue, especially when paired with Fiber.

Love & Peace, Phroi

[phroi]

@matt.eth

I’d like to ask if the project related to dckb will continue?

Thanks for the question, feel free to ask away in the dedicated page:

[DIS] iCKB & dCKB Rescuer Funding Proposal (Non-Coding Expenses)

iCKB & dCKB Rescuer Funding Proposal (Non-Coding Expenses) The vote for this proposal can be found here. Summary Activities funded: Funding of user/dev support and generally non-coding expenses, if any, for iCKB & dCKB Rescuer. Refund of iCKB L1 Scripts deployment & audit costs. Grant amount: 673,400 CKB (roughly 10,000 USD at the current 0.01485 CKB/USD exchange rate) CKB Address: ckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqfey5wjqn7f059napy0nl9llw4ss50mmsgfrjtqs Introduct…

[phroi]

Thank you for expressing your view @neon.bit and for addressing the concerns generally expressed by @aiia, @matt.eth, @yeti & @silenceport. I personally stay away from speculations and focus more on deliverables

@neon.bit

Regarding the budget, it wasn’t clear to me in the proposal but could you clarify regarding the amount of RSN stake needed to become a Guard. Does this cost factor into the overall request?

As you can see, this proposal covers:

• Development
• Internal Reviewing
• Maintenance (1 year)

Any excess of expenditure (if any) will be put to good use.

Phroi

[Yeti]

Ok, your original wording of that section just sounded like completion of the project hinged on an external audit.

So just to be clear, if the audit proposal doesn’t pass the DAO, the team will still complete the rest of the project as normal and mainnet launch will go ahead?

[NightLantern]

@phroi Hey phroi! so i have a few questions about rosen bridge

1. Was hoping you could paint us your long term vision for the bridge? I think i’m probably lacking some insight here that’s why i ask.

2. Is it possible you guys could produce a more detailed scope on the full labour to complete the project witht he same amount of information @zz_tovarishch did for Dao v1.1 with a rough time and hourly price estimation for each role in the project?

3. I realize this is a more secure bridge, then your standard bridge. But if it was to be hacked, what would a hacker need to acomplish to do so?

4. I’m on the fence about being opposed or for this project– reason being im not exactly sold on the overall direction. To start my own personal experience I found wrapping tokens for new users is not user friendly– Now I know there is limitations and rgb++ didn’t quite fully deliver on an intirely bridgeless ecosystem but when i used Joyid even with its limitations the user experience i thought was very good.. Now forgive my ignorance but if you could help clarify why this approach is better then us finding new solutions– or focusing the funds towards web 5 that would be much aprecciated.

also!

Thanks for this proposal– phroi, Mack and kyle ya’ll are CKB Legends

[jm9k]

Force Bridge was the first cross-chain bridge, but quite different in almost every other way.

Force Bridge is centralized. It was designed to be decentralized eventually, but it did not reach that stage.

Force Bridge is not bidirectional. It allows assets issued on other chains to be bridged to Nervos, but it does not allow Nervos-issued assets to be bridged to other chains.

Force Bridge uses a more classic bridge design, whereas Rosen Bridge uses a newer dual-layer security design.

Force Bridge was built from scratch, which has higher development and maintenance costs that would be paid for exclusively by the Nervos ecosystem. Rosen Bridge is an established decentralized project with a revenue stream being generated by bridge traffic from a growing number of connected chains. The development costs and maintenance costs will be a far lower burden to the Nervos ecosystem than Force Bridge.

[jm9k]

@Yeti

I’ll most likely support this proposal, but if the audit is a mandatory part of the project, then I think the cost (estimated cost) of the audit needs to be included here.

It’s not possible to get accurate estimates from audit companies until you have the codebase for them to look at. However, perhaps we can get a ballpark estimate based on existing integrations. I’ll ask about this.

[tianlitao]

From the perspective of the final outcome and user experience, the differences between the two are actually not that significant—both essentially enable cross-chain asset transfers.

Force Bridge already supports a form of bidirectionality: assets issued on other chains can be bridged to Nervos, and they can also be redeemed (bridged back). The only limitation is that assets natively issued on Nervos cannot be bridged out to other chains. However, I believe that building support for bridging Nervos-native assets outward on top of the existing Force Bridge would not be technically difficult and is entirely feasible.

Moreover, Force Bridge’s development is largely complete and has been running stably for a long time, with significant sunk costs already invested. Continuing from here would primarily involve maintenance costs, which should be far lower than the development and integration costs required to onboard Rosen Bridge from scratch.

Therefore, between the options of “continuing to build and improve on Force Bridge” versus “switching to integrate Rosen Bridge,” I personally lean toward the former. The most substantial difference between the two bridges is likely that Force Bridge remains centralized, while Rosen Bridge is decentralized.

[phroi]

Back in the day Force Bridge was our pride and joy as CKB community. That said, it never reached Rosen Bridge level of maturity and one might even argue that it got hacked as a result

Conversely, in my opinion Rosen Brodge focused on solving the hard parts first:

• Decentralization of key roles
• Multilayered security
• Strategical adoption of cold wallets
• Risk aversion by using standard tech
• M-to-M bridging
  …

Please, take some of your time to familiarize with the Rosen Bridge inner workings. Even just the video I linked earlier explains well the main concepts and, if you have any technical questions/doubts, we are here

Merry Christmas,
Phroi

[zz_tovarishch]

Community Discussion Summary: Rosen Bridge Proposal

To help community members stay informed, here’s a summary of the key points raised so far.

1. Cost & Timeline Some community members questioned whether $65k across Q1-Q4 2026 is justified. The team clarified the budget covers development, internal review, and 12 months of maintenance. Audit costs remain out of scope and will require a separate proposal.

2. Necessity & Strategic Fit This is the most contested point. Skeptics argue CKB already suffers from “infrastructure oversupply” with insufficient actual demand, and question whether building another bridge aligns with the Web5 direction. Supporters counter that connecting to UTXO-aligned chains (Ergo, Cardano) opens BD opportunities that would otherwise be impossible, and that some infrastructure must precede demand.

3. Force Bridge Comparison The team emphasized key differences: Force Bridge remained centralized and couldn’t bridge CKB-native assets outward. Rosen Bridge offers decentralized operation, dual-layer security, and bidirectional transfer. Some community members noted Force Bridge’s sunk costs and questioned whether upgrading it might be more efficient.

4. Audit Requirement The team clarified that external audit is “nice to have” but not mandatory for mainnet launch, as multiple internal reviews by knowledgeable parties will be conducted.

5. Security Model One member raised concerns about bridge security generally. The team pointed to Rosen’s Watcher/Guard architecture and linked to explainer materials.

舟舟
Transitional Period Coordinator

社区讨论摘要：Rosen Bridge提案

为方便社区成员快速了解讨论进展，现将主要观点整理如下。

1. 成本与时间线 有成员质疑$65k和Q1-Q4 2026的时间跨度。团队澄清预算涵盖开发、内部审查和12个月维护。审计费用不在此预算内，将单独申请。

2. 必要性与战略方向 争议最大的点。反对方认为CKB已经"基础设施过剩、需求不足"，质疑此时再建桥是否符合Web5方向。支持方认为连接UTXO同类链（Ergo、Cardano）能开启原本不可能的BD机会，且部分基础设施必须先于需求存在。

3. 与Force Bridge对比 团队强调关键差异：Force Bridge始终是中心化的，且无法将CKB原生资产桥接出去。Rosen Bridge提供去中心化运营、双层安全架构和真正的双向转移。部分成员指出Force Bridge已有沉没成本，质疑升级它是否更高效。

4. 审计要求 团队澄清外部审计是"锦上添花"而非主网上线的硬性条件，因为会有多轮内部审查。

5. 安全模型 有成员对桥的安全性表示担忧。团队指向Rosen的Watcher/Guard架构并提供了解释材料。

舟舟
Transitional Period Coordinator

[neon.bit]

Continuing with Force Bridge would much more costly considering:

• The R&D and technical work needed to move from centralised to decentralised. This would not be a straightforward undertaking.
• The R&D and technical work needed for every new chain to be added and maintained. Recall that integrating Cardano took 2 seperate professional teams to design, develop, and audit, over 2-3 years, and even after that it was deemed unsuitable. This came at significant time and financial cost that dwarfs the cost of Rosen (+ audits). Now apply the same cost for each new chain added that needs a bespoke solution.
• Enhanced security measures to regain confidence after the Force Bridge hack. Even if it wasn’t being decommissioned, it would be impossible for Force Bridge to continue as normal without substantial additional security guarantees.

[Raja]

I went through this proposal carefully, and here’s how I see it.

First, this is not a hype-driven or short-term play. It’s infrastructure work, plain and simple. The kind of work that strengthens Nervos for the next few years rather than instantly moves numbers or TVL. If you’re expecting fireworks, this isn’t it but if you’re thinking long-term, it starts to make sense.

Rosen Bridge is already live, audited, and operating across multiple chains. Its security model is designed differently from traditional bridges: instead of putting all the trust in smart contracts, it uses off-chain Proof of Event verification, layered with Watchers and Guards. That reduces the most common historical failure points bridges have suffered from. It’s not risk-free nothing ever is but it’s a serious step forward.

What really changes the game here is the Bridge Expansion Kit. Nervos developers won’t be stuck waiting for Rosen’s core team to prioritize updates. CKB-native developers can build, maintain, and operate the integration themselves. That’s better for decentralization, long-term maintenance, and it makes the $65k grant a reasonable ask for the scope of work.

The team itself is solid. @Phroi has proven experience within the Nervos ecosystem, @Alive24 provides review and backup coverage, and @jm9k brings senior oversight. Bridges aren’t “ship it and forget it” software; you need operators who stick around when things break. This team structure addresses that concern upfront.

The bidirectional flow aspect is huge. Nervos assets like CKB, iCKB, and SEAL won’t just come in they can also move outward to existing liquidity venues like Ethereum or Cardano using standard token wrappers. This bypasses expensive native listings and opens real-world market access, which is something not many people realize bridges can do effectively.

The proposal also handles the RGB++ question maturely. RGB++ is theoretically more elegant and secure, but it’s early and limited to UTXO chains. Rosen Bridge works across UTXO and account-based chains and plugs into existing DeFi infrastructure. They’re complementary, not competitors. Knowing this distinction helps avoid ideological debates that stall real progress.

That said, there are points to watch. The timeline is long late 2026, so strong milestone tracking and regular updates are critical. Audits are out of scope here, which makes sense now, but this is a future requirement that must be budgeted. And while @Sonami running an initial Guard is operationally reasonable, governance will need a clear path for broader participation to avoid concentration concerns.

Overall, I lean toward support. This isn’t flashy. It won’t create hype overnight. But it strengthens Nervos’ long-term connectivity, expands cross-chain optionality, and does so without compromising on decentralization or security principles. The key will be discipline and accountability during execution, not just approval at the DAO vote.

In short: it’s quiet, strategic work, exactly the kind of infrastructure that ecosystems regret not doing when they realize they’re isolated later.

[woodbury.bit]

如果一个系统的安全最终仍然依赖于“被信任的人”，而不是由链上规则强制约束，那么它只是一个可以运作的工程方案，而非去中心化的基础设施。
而 CKB 从诞生第一天起，就不是走这条路的。

另外，也希望相关质询的问题，能够尽量由资金申请方本人来直接回应。
过多来自无直接责任方的回复，虽然出于好意，但容易引入理解上的歧义，反而模糊了讨论的核心。

最后祝大家圣诞快乐。

If a system’s security ultimately depends on trusted people rather than being strictly enforced by on-chain rules, then it is merely an operational engineering solution, not decentralized infrastructure.
And CKB, from its very first day, was never meant to follow that path.

Additionally, to keep the discussion focused, it would be helpful if questions are answered directly by the funding applicants whenever possible.
Excessive responses from unrelated parties may unintentionally blur the core issues.

Merry Christmas to everyone.

[phroi]

My role is not one of the visionary here, I’m just the developer, so I’ll reply as such. I’m happy to develop this very integration as it’s strictly within my capabilities

@NightLantern

Was hoping you could paint us your long term vision for the bridge?

Let me give you my perspective on our current L1 assets:

• ccBTC is cool, but I can’t really trust it as a long term store of value cause it’s centralized.

• USDi while being naturally centralized, I consider it a worthy attempt, just its utility is currently limited, especially for people who don’t intend to KYC.

• RUSD, I tried multiple times to get iCKB integrated as backing asset, it didn’t go thru. They are closed source and in maintenance mode. Recently, I’ve seen enough people lose 95% of their CKB holdings.

• Memecoins, not a fan.

• CKB and iCKB are the only assets I currently trust on L1 as user and dev.

Rosen Bridge would radically expand the horizons of assets available on L1, bringing a whole lot of high-quality decentralized assets. This has implications for any DeFi application we build.

My vision as dev: any asset we have on L1 is a potential arrow for grass-root DeFi developers who chose Nervos L1, think of Fiber, RGB++, warranty contracts…

These Rosen Bridge assets would not be the next dCKB, cause they are backed by a solid cross-chain tech & community, so they’ll likely live much longer that most of our now dead-coins

[phroi]

@NightLantern

I realize this is a more secure bridge, then your standard bridge. But if it was to be hacked, what would a hacker need to acomplish to do so?

When I last reviewed the Rosen Bridge proposal, I said:

@phroi

At the moment I cannot really think of a good way of breaking the Rosen Bridge, even in the event that the RSN price was almost zero. This three level hierarchical division of roles seems really well thought.

Now that I have studied their integration kit and talked more deeply with the team, I can confirm my previous viewpoint.

For example, Force Bridge failed because of a Validator Takeover. That said, I suspect most of these losses could have been avoided if only they kept about 90% of funds in cold storage, with a mechanism blocking suspicious withdrawals. So, in a way, Force Bridge was a Soft Target.

By contrast, the Rosen team started by cataloging known attacks and designed the bridge precisely around these risks.

Here are a few slides from @Armeanio on the topic:

[Ophiuchus]

Reading through the thread, it feels like the real debate is less about Rosen itself and more about how we sequence infrastructure, security, and real-world usage on CKB.

Rosen doesn’t have to be the solution, but it may still be a useful piece alongside more native approaches like RGB++ and Fiber, rather than in opposition to them.

[fishell]

@Raja

What really changes the game here is the Bridge Expansion Kit. Nervos developers won’t be stuck waiting for Rosen’s core team to prioritize updates. CKB-native developers can build, maintain, and operate the integration themselves. That’s better for decentralization, long-term maintenance, and it makes the $65k grant a reasonable ask for the scope of work.

This rhetoric seems overly biased toward Rosen Bridge. The integration requests funding from the CKB community, uses CKB developer resources, and leaves all costs and maintenance to the CKB ecosystem—yet presents these as benefits.

If this were an integration with Uniswap or Hyperliquid, I’d be on board because the potential market and user exposure are clear. But Rosen Bridge? I don’t know anyone who uses it, and it’s obvious that CKB has a larger community and market cap in comparison.

I trust @phroi’s technical judgment and believe Rosen Bridge is technically solid. I have no doubt the proposal team—@phroi, @Alive24, and @jm9k—can deliver and maintain it, I truly appreciate your work! However, I don’t see how it benefits our ecosystem’s growth enough to justify the costs. For this I’m against this proposal.

[matt.eth]

I believe the greatest failure of Force Bridge lies not in its centralization or other technical issues, but in the fact that almost no one is using it. Perhaps we should be wary of “problem-solving mindset” or “engineer’s mindset.” I have no doubt the proponents could complete this project, but I question how much positive externalities it could generate beyond “we solved this problem.” Perhaps future project proposals should include more business feasibility analysis. My opposition to this project stems precisely from recognizing how vital these developers are to the Nervos community. I see this as a waste of the community’s talent, with an excessive opportunity cost. Perhaps we should first foster the growth of Nervos’s own ecosystem, such as RGB++. Only when the Nervos ecosystem demonstrates sufficient potential for spillover effects should we consider building bridges.

[matt.eth]

We build a bridge not because we can make it sturdy, but because there are indeed vehicles that need to cross it.