Timing of this proposal I think could have waited until after Christmas, I think more people would be voting.
I’ve always seen this bridge as a bridge to communities, outreach and expanding eyes on CKB. Making friends from other ecosystems are what gets more attention. Hopefully it could bring other developers or people that want to experiment.
The team are trusted, work already within the ecosystem so the money will be in trustworthy hands. It seems more credible than an NFT project or meme token project which I’m sure most communities are sick of, that always result in value extraction from a small community to survive.
It’s a vote from me. Build bridges and move forward westerly. I mean this amount of money is negligible in comparison to large marketing campaigns that are just based on words and not technical architecture and often bring little exposure. I’m glad to see there are teams forming to push things forward.
I have a negative view of this project. Do we really need to build more roads that no one will drive on? I think Nervos is very similar to the economic situation in China: an oversupply of infrastructure and various industrial parks, but a lack of actual demand. Even from the perspective that “infrastructure is necessary to some extent,” how well does this align with the Web5 direction that Nervos is currently pursuing? Is it necessary to divert funds and energy to efforts in DeFi (currently, various blockchain projects are competing fiercely in DeFi; what advantages does CKB have to compete with them)? And this is a niche project developed on a relatively obscure chain like Rosen Bridge. As the user above said, how different is this from the Force Bridge, the EVM cross-chain bridge that we spent time and money on before? What’s the point of reinventing the wheel at this point? Last year, we finally discovered the unique advantages of isomorphic binding, and now we’re going back to copying others’ bridge designs?
Roads must exist before there can be any expectation of growth in projects that require them. You seem to have forgotten that Force Bridge had plenty of traffic early on when DeFi was active. Our ecosystem’s DeFi offerings are currently unable to compete with the incumbents, and discouraging necessary infrastructure from being built ensures the situation remains unchanged.
Force Bridge is an example of a project that failed to reach its goals. It supported a very limited number of chains and never reached decentralization or self-sufficiency. Rosen Bridge has already gone beyond this to the decentralization phase and has extended its reach to more chains, and the list is steadily growing. The project continues to show innovation and direction that was never reached in Force Bridge.
This is not “reinventing the wheel” in any sense of the phrase. This is not an attempt to invent anything. We do not have proper wheels, and we’re just trying to attach some that we know work.
Isomorphic bindings have unique advantages and unique disadvantages. The inability to leap certain types of assets, paired with the low number of supported chains and lack of integration with existing tooling, limits practical usage for the foreseeable future.
I would love to see isomorphic bindings become a prominent standard within the industry, but this is a high-risk angle with a tremendous opportunity cost. These two technologies are not mutually exclusive. In fact, I consider them to be complementary. I do not want to risk the future of the ecosystem on an experimental approach when we can adopt a practical bridge approach with the lowest proposal cost that has ever been offered to this ecosystem.
I strongly agree with this statement in many ways. However, we must ensure we have the right infrastructure to facilitate effective experimentation on the product side. If we do not have proper channels, it sharply increases the likelihood of failure for any experimental project because even a good product is subject to the effects of liquidity friction. If value cannot flow to CKB at a time when a new project is trying to gain traction then the project will dwindle and die.
Releasing without an audit is not the preferred route, but it is absolutely an option. It is worth mentioning that Rosenbridge itself has already undergone a full audit. The audit that we would be seeking would be purely for the Nervos portions of the project. The audit costs would be much lower since the full project does not need to be audited.
In talking to the Rosen Bridge team, it sounds like the current integration teams are opting not to audit the chain-specific code. I still would opt for an audit, but this is a decision that should be made after we receive estimates.
If isomorphic bindings served an identical role, then I would suggest that we should use that exclusively and forego the bridge entirely. However, the reality is that isomorphic bindings have both advantages and disadvantages today. They are unable to leap certain types of assets, such as BTC itself. I’m told this also includes the newly announced USDT stablecoins, which are being issued on the RGB protocol on Bitcoin. Paired with the low number of supported chains, inability to connect with account model chains, and lack of integration with existing tooling, this limits practical usage for the foreseeable future.
I believe we should continue to invest in technological innovation, like isomorphic bindings, but I also see that we need to continue making progress in other areas using a practical bridge approach. These technologies are ultimately complementary, especially if we can use multiple routes to grow the ecosystem in parallel.
Force Bridge already supports a form of bidirectionality…
The terminology here is confusing, so allow me to clarify. Allowing assets issued on other chains to go to Nervos and then be brought from Nervos back to the originating chain, we refer to as “two-way bridging”. We are referring to Nervos-issued assets being transferred to a connected chain as being “bi-directional”.
Force Bridge’s development is largely complete…
No, it is not complete. It never reached decentralization, nor does it have the same level of features or a modern bridge design that Rosen Bridge has. The costs to continue development on Force Bridge to reach parity with Rosen Bridge are much, much higher.
You are comparing the market cap of a blockchain to a bridge? These two are not really comparible directly like this. A bridge offers value transfer pathways between multiple blockchains, but it is not a blockchain itself.
I don’t believe that working on this bridge is the first choice for any of us. What you are witnessing is three community members recognizing a problem and stepping up to provide the solution. I wish that there was a pre-existing solution already in place so that we could spend our time on products instead of infrastructure, but there is not. We need to get this out of the way, and this is the solution with the lowest opportunity cost.
We did not want to delay any longer, and we had hoped that people would be home for the holidays and would be more likely to read the proposal. In retrospect, I believe you are correct and that it had the exact opposite effect that we hoped it would. Thank you kindy for your support.
Why not? We’re discussing a bridge in the middle that could benefit three parties: the bridge itself, the other end, and CKB. I believe all parties are equal and should invest equally. We need to assess each party’s contributions and rewards, and question why the CKB community should bear the costs while all parties share the benefits.
What potential projects or possibilities do you envision with the existence of a Rosen bridge?
Suppose Fiber channels are launched in the future and channels are established between CKB and the other chain. What different roles do you see Rosen Bridge and these channels playing at that point? Do you think bridges will still be necessary in that context, and why?
With all due respect to the people of Sonami, I do not support this proposal. I do not like bridges, I think the effort is not worth it and should be directed towards more innovative applications and solutions that CKB can provide(or not? )..
On one hand, I fully understand the concern about spending time and resources on infrastructure before clear demand exists, especially given the history and risks of bridges in this industry…
Focusing on native primitives like isomorphic bindings, RGB++, Fiber, and Web5 is clearly where CKB’s long-term differentiation lies.
On the other hand, without some practical liquidity pathways today, even strong products struggle to gain traction. From that perspective, Rosen Bridge feels less like a “vision replacement” and more like a transitional tool to reduce friction while the native stack matures.
To me, the key question isn’t bridge vs no bridge, but how to ensure this remains complementary, limited in scope, and doesn’t divert focus away from CKB’s core strengths.
If handled carefully, both approaches can coexist without compromising the broader direction.
Correct assumption, not so much the conclusion. Allow me to go into detail:
1. The Bridge Itself
You are conflating at least three parties into this one, so let’s break it down!
a. The Rosen Team
These are the OC, we would not be here discussing this integration without their hard work.
Costs
Develop & maintain the protocol
Develop & maintain the Rosen Bridge Kit
Coordinate the Community of Watchers/Guards
…
Gains
We are paying nothing to them, not for using the Kit, not for using the Bridge (fee goes to Watchers and Guards)
They were Granted by the Cardano Catalyst Fund: Dan Friedman and Alexander Chepurnoy were listed on the original grant proposal (Big names in the space)
b. The Guards
These are the ones who holds the funds in MultiSigs.
Costs
Staking HUGE amount of RSN, slashed in case of bad behavior
Running nodes of target chains and making sure they run smoothly
Running the Guard itself and making sure it runs smoothly
Manually authorizing transfers from Cold Wallets (transfers too big for Hot Wallets)
Gains
Percentage of bridge transfer fee (WIP)
c. The Watchers
These are the ones who watch for transfer events in the target chain and notify Guards via trigger box.
Costs
Staking some amount of RSN to get permits, slashed in case of bad behavior
Running nodes of target chains and making sure they run smoothly
Running the Watcher itself and making sure it runs smoothly
Gains
Percentage of bridge transfer fee
2. The Other End
Currently the Rosen Bridge already integrates:
Doge
Bitcoin + BTC Runes
Binance
Ethereum
Cardano
Ergo
Side Note: once connections are made via watchers and guards, all these are interoperable between each other, so you can bridge between any two pair, like Cardano to Ergo, Doge to Ethereum …
WIP:
Firo is in progress (their team leading integration)
HNS is pending (HNS community bounty)
CKB is voting, as you may be aware
Costs
Developing their own side of the bridge
Transaction fees paid to Watchers and Guards
Gains
3. CKB
Same same as the 2. The Other End section. It doesn’t really make sense to single out us as a separate chain:
We CKB Community are discussing if it makes sense to join a chain community (Doge, Bitcoin, Binance, Ethereum, Cardano, Ergo) and making an integration on our side is the only way to go about it.
Did Rosen Bridge Team ask us money for developing & maintaining the Protocol, Rosen Bridge Kit and Community of Watchers/Guards? (Nope, not even one cent)
Did Guards / Watchers ask us some monetary help for staking RSN, running nodes and the service? (Nope ATM, we pay them the usual fees when bridging)
Did Doge / Bitcoin / Binance / Ethereum / Cardano / Ergo / Firo / HNS ask us money for their Rosen Bridge integration? (Nope, additionally I would take it as a joke if they ever did )
Why, why do we need to ask other chains for money to develop our own Rosen Bridge integration?
Thanks Jordan, I agree that an audit of the CKB specific side of the integration would of course be best, but I also think that some audits aren’t worth the paper they’re written on, so there’s definitely a risk vs reward aspect we need to think about depending on the cost.
But the DAO can decide that at the time, if it gets to that point, I just really wanted to know if the audit was a make or break issue for the team to continue work.
Which is a very reasonable assumption BTW, being one of the original UTXO Stack targets
Good question!! For example, as you may know Rosen Bridge integrates BTC & BTC Runes (native tokens), but at the same time Bitcoin doesn’t support smart contract capabilities, right?
Well, with channels linking to Nervos L1 we could:
Have Runes on Bitcoin
Send to Nervos L1 via channel (super-fast & reasonably-cheap)
Stake/Swap/Use it in a Nervos L1 protocol (reasonably-fast & cheap)
Eventually send back to Bitcoin via channel the Runes and/or BTC
Example on a CKB xUDTs (a standard token issued on Nervos L1)
Let’s say that you:
Have xUDT on CKB
Stake/Swap/Use it in a Nervos L1 protocol (reasonably-fast & cheap)
Eventually send it to Bitcoin:
3.a Via Rosen Bridge the Rosen-bridged-xUDT and/or BTC (usually fast)
3.b Via channel the Rosen-bridged-xUDT and/or BTC (super-fast & reasonably-cheap)
3.c Via RGB++ leap to Bitcoin via RGB++ the xUDTs (slow & cost depends on Bitcoin tx fees)
Channels are really fast and they could avoid bridging fees, so they are pretty convenient.
For example, there is no way to bring BTC to Nervos L1 in a trust-less way with RGB++, nor Fiber. Let’s take RGB++, the JoyID leap function under the hood takes your BTC and returns ccBTC, that’s a leap only in marketing. Conversely, with Rosen Bridge you can get a trustless Rosen-BTC on Nervos L1.
Let’s consider channels between Bitcoin and Nervos L1:
If you want to send BTC and receive CKB, then you need to use oracles under the hood and they are a big source of troubles too.
If you want to send BTC and receive Rosen-BTC on Nervos L1, then you don’t need any oracle exchange is 1:1, pretty cool if you ask me.
In my dev opinion, Channels and Bridges will coexist and complement each other.
Thank you @phroi@jm9k for answering the majority of my questions. Lastly some additional quantitative information I would like to see are–
Rosen Bridge TVL is ~ $3.2 mil per Defilama it would be nice if we could get transaction volume and user count trends
Has any chains of similiar size to CKB integrated with Rosen and can we get any information on their metrics
Do we have any projections models (game theory or regression-based.) or rough estimate of expected bridge volume post integration, for judging wether 65k is a reasonable ROI
Any additional data or precedent you can provide
I know your guys time is valuable so I apreciate you taking the time to answer my questions!