Hmmm, I can easily move my fund to CKB without a bridge, but why should I move it?
Yeti
,
They’ve kept things rolling for the past 6-7 years, and it’s been seen that doing things that no one else has (joyid, nervape, .bit) is more successful than copying other ecosystems (yokaiwasap, forcebridge, godwoken, daruma, etc..)
Also and there is one main problem Nervos *has, which causes in my opinion the lack of successful products and the trust of a large community still.. and that is accountability of all income and expenses(I meant at the foundation level, not the community fund)
Just my 2c
In this case is it a single signature that’s required to move funds in the bridge?
TLDR: Nope.
Long answer: reading the full section, this phrase explains the meaning:
Key takeaways:
- Exists an already decentralized set of trusted Guards
- Sōnami is gearing up to join such Guard set
- This is to practice decentralization, not just preach it
- Joining Guard set requires to be invited and stake a huge amount of RSN
- At a second time more Guard slots will become available
Conversely, anyone from the Community can join the Watcher set and gain some in the process.
Phroi
The ability to quickly recover and rebuild the bridge, in my understanding, isn’t the core proof of a bridge’s decentralization. Moreover, code recovery doesn’t equate to fund security. A true measure of decentralization is the ability to maintain bridge functionality even with a significant proportion of malicious actors. Currently, unlike RGB++, where users can completely trust their own keys, they need to trust the operating team or other human-controlled entities within the Rosen bridge. This isn’t something that can be solved simply by open-sourcing. As I understand it, this is why so-called decentralized bridges aren’t significantly better than multi-signature bridges, hashlocks, or atomic swaps.
Regarding the UTXO alliance you mentioned, I looked up some information. While there are many visions, I didn’t see a concrete roadmap. Shared values are good, but I understand that Nervos’ current situation isn’t just about gaining recognition, but about needing crucial support. It’s difficult to judge what actual benefits this set of values will bring at present, and aside from the financial and resource investment, I think the waste of time and attention is even more alarming.
I strongly agree that infrastructure should precede applications, but we should at least know which applications require it, rather than concluding that all applications might potentially use it. From all the discussions above, I haven’t seen any ongoing application projects, only various guesses and assumptions. Making such assumptions incurs no cost or responsibility. My statement that Rosen Bridge has a low priority is in terms of application availability. In my earlier example, Yokai is clearly an existing idea, and Force Bridge implemented a cross-chain bridge to meet this need.
If there were specific applications, I think this project would have a high priority. Furthermore, I believe that any product or tool we develop should be based on meeting specific needs, whether for the end user or the developer. Working in isolation is not a good practice.
TLDR: Nope, ATM.
Long answer:
These links will likely break (sigh) after explorer upgrade, anyway here you go:
- Go to: https://explorer.nervos.org/rgbpp/transaction/list
- Pick one
- Cell Info of Nervos L1 Cell
- Lock Script
- Click on
rgb++ - Now you are on the page of the
rgb++Script - Notice it’s a Reference by Type (ouch)
- Click on Deployed Cells (
you can start from here) - Click on the Live Cell symbol
- Take note of how it’s a MultiSig (recently updated to App5)
Result: we are comparing (RosenBridge) MultiSig against (RGB++) MultiSig
Marketing didn’t completely fool us, RGB++ has still a clear path to becoming trustless:
App5 just need to upgrade RGB++ MultiSig to a Zero Lock (which Rosen can’t match).
Side Note 1: Zero Locks are those locks that can’t be opened (cause they don’t quite match to contract/keys), so the contract/l1-script-binary they holds in Cell Data becomes non-upgradable.That said, there still are ways to unlock these, with the usual Wrench Attack on the right persons (common to all block-chains & human-based entities). Here too Decentralization is the solution.
Let’s say RGB++ is now secured by a Zero Lock, that would also mean that in the unlikely event that something happens to the Bitcoin protocol that breaks RGB++ validation (for example, Bitcoin protocol taking measures against Quantum threats? IDK), we are unable to adapt to it.
Side Note 2: there are update paths even in a Zero Lock scenario, just they are usually not fully effective. For example, we could just ask users to upgrade to RGB++ v2 before the breaking event, but it’s tricky cause there will be always a small percentage of users who don’t quite update in time. See dCKB tale for example.
Hence, the current RGB++ design strikes the right balance.
I like the Rosen Bridge design and assumptions too, hence this proposal.
Phroi
Is it true that it can take a few hours for these rosen bridge transactions to complete? There is a post on the ergonauts Reddit about this the other day. That it can take several hours for the transactions to complete. https://www.reddit.com/r/ergonauts/s/ogaPmgGv77
Yes, that’s correct: when big transfers cannot be fulfilled by hot wallets, they need checking the transaction and manually unlocking cold wallets.
Something Force Bridge designers didn’t felt the need of, evidently.
Convenience vs security, Rosen strikes a good balance.
Phroi
Hey @zz_tovarishch, as Official Community DAO Transitional Period Coordinator can you scutinize the results of this first voting phase?
Always available for more technical questions,
Phroi
Hi Phroi,
We’re coordinating with Metaforo on the duplicate voting vulnerability. The potential solution is to disable unbind functionality during the voting period, then conduct manual onchain verification after voting closes.
I’m currently awaiting final confirmation from the DAO Funds Management Committee on this approach. Once confirmed, I’ll post a clear notice here.
Wish you and all your loved ones happy new year.
Hi Phroi,
The security approach for the transitional period has been confirmed by the DAO Funds Management Committee.
Timeline:
Metaforo will disable the unbind function within ~2 days after the holiday (around Jan 5-6). Once confirmed ready (I’ll update you), you can initiate the voting stage.
Verification process:
After the 7-day voting period, I will conduct on-chain verification by cross-referencing Nervos DAO deposit data with Metaforo voting records. For instance, I’ll verify that no voting address withdrew CKB from Nervos DAO during the voting period, transferred it to another address, and used that new address to vote again.
Verification results will be published in your proposal thread and submitted to the Committee for final confirmation. If any security issues are detected, the Committee will make the final ruling.
Important notice for voters:
- Unbind functionality will be temporarily disabled during the voting period
- Voters should adjust their CKB address bindings BEFORE voting starts if needed, as changes won’t be possible during the voting period.
DAO 资金管理委员会已确认过渡期的安全方案。
时间表:
Metaforo 将在假期后约 2 天内(大约 1 月 5 日至 6 日)禁用解绑功能。一旦确认准备就绪(我会通知您),您即可启动投票阶段。
验证流程:
7 天投票期结束后,我将通过交叉比对 Nervos DAO 的存款数据和 Metaforo 的投票记录来进行链上验证。例如,我会验证是否有任何投票地址在投票期间从 Nervos DAO 提取 CKB,将其转移到另一个地址,并使用该新地址再次投票。
验证结果将发布在您的提案帖中,并提交给委员会进行最终确认。如果检测到任何安全问题,委员会将做出最终裁决。
投票者重要通知:
-
投票期间,解除绑定功能将暂时禁用。
-
如有需要,投票者应在投票开始前调整其 CKB 地址绑定,因为投票期间将无法进行更改。
投票安全措施说明 / Voting Security Measures
I. Address Unbind Function Temporarily Disabled
The CKB address unbind function on Metaforo platform has been disabled.
Important Notice:
- If you attempt to unbind an address during voting, you will see “Failed to unbind this neuron”
- This is NOT a system error. It is a temporary measure to ensure voting security
II. Post-Voting Verification Process
After voting closes, as transitional coordinator, I will conduct the following on-chain verification:
- Extract voting data: Compile a list of all Metaforo accounts that voted and their bound CKB addresses
- Check fund movements during voting period: Verify whether any addresses unlock CKB from Nervos DAO during the voting period, transferred to other addresses, and re-deposited into Nervos DAO during the voting period
- Track duplicate voting during voting period: If both addresses voted, the following rules apply:
- Only the most recent vote will be counted
- Previous votes from earlier addresses will be deemed invalid
- The behavior of the associated accounts will be publicly disclosed
Note: Address changes and binding adjustments completed before voting starts are normal operations and are not subject to this verification.
III. Result Publication and Confirmation
Verification results will be:
- Published in the proposal thread
- Submitted to the DAO Funds Management Committee for final confirmation
- If security issues are found, the Committee will make the final ruling
IV. About This Measure
This is a temporary security measure for the transitional period.
Thank you for your understanding and cooperation.
一、地址解绑功能暂时关闭
Metaforo平台的CKB地址解绑功能已禁用。
重要提醒:
- 如果您在投票期间尝试解绑地址,系统会显示 “Failed to unbind this neuron” 的提示
- 这不是系统故障,而是为保障投票安全而实施的临时措施
二、投票后验证流程
投票结束后,作为过渡期协调人,我将进行以下链上验证:
- 提取投票数据:获取所有参与投票的Metaforo账户及其绑定的CKB地址清单
- 检查投票期间的资金流动:核查这些地址是否在投票期间从Nervos DAO解锁了CKB、转移至其他地址、并在投票期间重新存入Nervos DAO
- 追踪投票期间的重复投票:如发现两个地址都参与了投票,将按以下原则处理:
- 仅计算最后一次投票地址的投票权重
- 之前地址的投票将被视为无效
- 相关账户的行为将被公开披露
说明:投票开始前已完成的地址变更和绑定调整属于正常操作,不在此验证范围内。
三、结果公示与确认
验证结果将:
- 在提案帖子中公开发布
- 提交给DAO资金管理委员会进行最终确认
- 如发现安全问题,由委员会裁决最终结果
四、关于此措施的说明
这是过渡期的临时安全措施。感谢您的理解与配合。
如果这样的提案能够通过,我觉得我对ckb不会再抱有任何期待,我实在想不通连接了两个完全没有人的社区的一个桥梁,这个桥梁的建设能够值这么多ckb,“这真是一笔好生意”,也许应该建造,但绝对不是现在,如果通过后,我会抛售我持有的所有ckb,并且退出所有关于ckb的相关频道
如果这样的提案能够通过,我觉得我对ckb不会再抱有任何期待,我实在想不通连接了两个完全没有人的社区的一个桥梁,这个桥梁的建设能够值这么多ckb,“这真是一笔好生意”,也许应该建造,但绝对不是现在,如果通过后,我会抛售我持有的所有ckb,并且退出所有关于ckb的相关频道。
这么多年了,教主每年都要发几次“已经放弃ckb了”的声明,但其实一直不离不弃的。
@AIIA @Stone @matt.eth if you have any technical question about the Rosen Bridge, I’m always here! ![]()
Cheers, Phroi
sock puppet ?
The second phase voting is live ![]()
https://dao.ckb.community/thread/vot-ckb-integration-for-rosen-bridge-66568
过渡期协调人公告
投票已正式开始。作为过渡期协调人,确认以下信息:
投票参数核查(符合v1.0规则):
预算:27,356,903 CKB ($65,000 at $0.002376)
Quorum:82,070,709 CKB (预算的3倍)
通过阈值:51% (非元规则提案)
投票期:7天
安全措施提醒:
投票期间CKB地址解绑功能已在接口层面完全禁用
如您尝试解绑会显示"Failed to unbind this neuron",这不是系统故障
投票结束后将进行链上验证,详见安全措施公告
投票后流程: 投票结束后,将进行链上验证并在本帖公布结果,提交给DAO资金管理委员会最终确认。
期待所有社区成员参与投票和治理!
Transitional Coordinator Announcement
Voting has officially begun. As transitional coordinator, I confirm the following:
Voting Parameters Verified (compliant with v1.0 rules):
Budget: 27,356,903 CKB ($65,000 at $0.002376)
Quorum: 82,070,709 CKB (3x budget)
Approval threshold: 51% (non-meta-rule proposal)
Voting period: 7 days
Security Measures Reminder:
Unbind function disabled at API level during voting period
If you see “Failed to unbind this neuron,” this is NOT a bug
On-chain verification will be conducted after voting closes, see security notice
Post-Voting Process: After voting closes, will conduct on-chain verification and publish results in this thread for DAO Funds Management Committee’s final confirmation.
All community members are encouraged to participate in the voting and governance!
We did a Q/A session last night to go over some of the questions which have been circulating about the proposal. Video link below!
- Which specific projects or applications require Rosen Bridge to justify proceeding with this integration?
- Is a cross-chain bridge necessary for CKB at this stage of the ecosystem’s maturity?
- Does this proposal align with Nervos’ stated Web5 direction?
- Does this proposal align with a native-first design philosophy for CKB?
- Are we prioritizing infrastructure before demonstrated application demand?
- Should DAO funding prioritize infrastructure or product development at this time?
- Are we repeating strategic or execution mistakes made with Force Bridge?
- Why was continuing, upgrading, or decentralizing Force Bridge not pursued instead?
- Is the Q1–Q4 2026 delivery timeline appropriate given current ecosystem conditions?
- Is this the best use of Community Fund DAO capital relative to other options?
- Is the opportunity cost justified given limited experienced developer bandwidth?
- Does Rosen Bridge have meaningful real-world usage today, independent of CKB?
- What concrete benefits does Rosen Bridge currently provide to its existing ecosystems?
- How is this integration expected to benefit CKB specifically, rather than Rosen Bridge generally?
- Does bridging assets out of CKB risk reducing L1 usage or economic density?
- Is an external security audit required before mainnet deployment?
- What risks exist if the integration proceeds without an external audit?
- What is the expected cost range for a CKB-specific audit?
- What happens if an audit proposal fails after earlier milestones are funded?
- How secure is Rosen Bridge relative to prior bridge designs?
- What concrete attack vectors remain plausible under Rosen Bridge’s security model?
- Does the Watcher/Guard model introduce trust assumptions that conflict with CKB principles?
- Is Rosen Bridge decentralized in operation, or primarily federated in practice?
- Does Sonami operating an initial Guard create governance or concentration risk?
- How will Guard admission, rotation, and removal be governed over time?
- Should Rosen Bridge or partner ecosystems share the financial cost of this integration?
- Why is a bridge approach preferred over exclusively pursuing RGB++ or isomorphic bindings?
- Are bridges inherently a step backward compared to native cross-chain designs?
- Will a bridge still be necessary if Fiber channels mature as intended?
- How do Rosen Bridge and Fiber coexist without duplicating functionality?
- What is the long-term strategic role of this bridge beyond initial deployment?
- How will the DAO evaluate whether this integration is successful post-launch?
- Should infrastructure funding be contingent on measurable downstream usage?
- Can user activity and adoption be measured via public, ongoing metrics?
- Should milestone completion require public reporting to the community?

