Thank you for sharing this.
From the perspective of Ecosystem and Business Development at the Foundation, my position is to support this proposal.
Let me be clear: without this basic key INFRA, developing the ecosystem, onboarding partners and users is really hard.
I encourage that anyone with doubts look at the video posted before this answer, and if still have doubts, I’d love to know the rationale behind it!
教主，保重！ 
Rosen Bridge 提案投票现已结束
初步结果：通过（赞成率：64.11%，总投票权重：515,967,370 CKB）
接下来，我将使用 CKB DAO Watchdog 进行投票后验证，将 Metaforo 记录的投票权重与链上 Nervos DAO 的存款权重进行交叉核对，并进行人工核查。我将把验证日志提交给委员会，以便最终确认结果是否符合流程要求。
Rosen Bridge Proposal Voting has now closed
Preliminary outcome: PASSED (Approval: 64.11%, Total voting weight: 515,967,370 CKB).
Next, I will run a post-close verification using CKB DAO Watchdog to cross-check Metaforo-recorded voting weights against on-chain Nervos DAO deposit weights, along with a manual check. I will share the verification logs with the committee for final confirmation of whether the result is valid per the process.
Congratulations @phroi @jm9k and @Alive24
A bridge was always going to be a hard one to get through, but I think it’s worthwhile and will be another piece to the puzzle that we need.
Rosen Bridge Voting Verification Announcement
Based on the Metaforo tally at close, the outcome is PASSED. Approval is 64.11% with total voting weight 515,967,370 CKB (Yes 330,802,578, No 185,164,792).
Post-close verification has been completed using CKB DAO Watchdog at 20260117_080427 (UTC+8), together with a manual sanity check. The verification cross-checks Metaforo-recorded voting weights against on-chain Nervos DAO deposit weights. In this run, all entries match except one flagged account on each side, and both are undercount cases where the on-chain weight is higher than the Metaforo-recorded weight, consistent with post-vote updates to bound addresses and/or DAO deposits. There is no indication of weight inflation or double-counting in this run. Even if the on-chain differences are included, the approval remains 64.08%, so the pass/fail outcome does not change.
Committee confirmation: for process consistency, the final tally is the Metaforo-recorded weights at the time the vote closed. Therefore, the Rosen Bridge proposal is confirmed as PASSED based on the Metaforo tally at close.
Verification logs: ckb-dao-watchdog/Verification Logs - Rosen Bridge Vote at main · kydchen/ckb-dao-watchdog · GitHub
Thanks to @yixiu.ckbfans.bit for building the Watchdog tool, and to @Hanssen for additional support.
Rosen Bridge 投票核验公告
根据 Metaforo 在投票截止时的统计结果，本次投票结果为通过。赞成率 64.11%，总投票权重 515,967,370 CKB（Yes 330,802,578，No 185,164,792）。
投票结束后，我们在 20260117_080427（UTC+8） 使用 CKB DAO Watchdog 完成了核验，并配合进行了人工交叉核验。核验内容为对照 Metaforo 记录的投票权重 与 链上 Nervos DAO 存款对应的权重。本次核验中，除正反两边各有 1 个账号被标记外，其余记录均一致。两处标记均属于 欠算情况，即链上权重高于 Metaforo 记录权重，符合投票后地址绑定更新及或 DAO 存款变化的现象。本次核验未发现权重膨胀或重复计权的迹象。即便将链上差值纳入计算，赞成率仍为 64.08%，不影响通过或不通过的结论。
委员会确认：为保持流程一致性，本次最终结果以投票截止时 Metaforo 记录的权重为准。因此，Rosen Bridge 提案确认通过。
核验日志：ckb-dao-watchdog/Verification Logs - Rosen Bridge Vote at main · kydchen/ckb-dao-watchdog · GitHub
感谢 @yixiu.ckbfans.bit 开发 Watchdog 工具，也感谢 @Hanssen 的协助支持。
Hooray!! Glad this stressful vote has come to an official end 
Back to coding,
Phroi
PS: for a meta discussion about this vote: Some questions about the recent proposal vote
随着这个桥的完成，当我们发现，桥建好了，什么都没有发生，没有什么有益的事情在ckb上面因为rosen bridge这个桥的建立而产生，唯一真实发生的就是，ckb的dao资金真实划拨给了那几位开发者，那么投赞成票里面哪一位应该对此负责？
我感受到一种害怕，多数立场者，利益是一致的，他们的投票可以很容易的决定投票的走向，比如对于这个提案，我恶意的猜测，国外友人他们都是认识的，并且熟悉的，他们不需要对于这个提案的失败负责，毕竟大家是一起投票的
规则就是这样，这个提案在规则下通过了，就应该生效。兄弟，如果你反对的话，也应该遵守规则。
教主你可以对规则提出更好的改进建议，让大家支持你，使得DAO更好，我个人认为这是我们大家现在应该做的。
而且现在有专业的DAO物业团队在负责，我想他们会更用心的守护每个DAO里面的CKB的。
尊重不同意见也是一种成长。
尊重事务发展的螺旋上升规律。
The technical assessment for CKB integration into Rosen Bridge is under internal review, but I wanted to share an early sneak peek. Some highlights:
Signing approach: the DIS proposed on-chain multisig, but we’re leaning toward ECDSA TSS: the same signing and key rotation setup already used for Bitcoin, Ethereum, Doge, and Binance. CKB’s default lock accepts the standard ECDSA signature that TSS produces, and security is the same: TSS still needs M-of-N guards to cooperate before a signature can be created. Both approaches are covered in the detailed comparison. Similarly, we postponed CKB’s Quantum Resistant Lock: no other Rosen chain uses quantum-resistant signing, so protecting only CKB would not make the bridge safer as a whole.
Token bridgeability: native CKB, sUDT, and xUDT (no active extensions). Tokens whose issuer can freeze or clawback funds are excluded. @Jnr6 asked why Rosen Bridge won’t support USDT, so here’s a concrete example. USDi’s issuer can freeze specific addresses. If they froze the bridge address (say, for regulatory reasons), the USDi held by the bridge on CKB would be stuck. Since rsUSDi on other chains is backed by that USDi, it would lose its backing, depeg, and become worthless. A user who bridged 1000 USDi from CKB to Cardano would be left holding 1000 rsUSDi worth nothing. That’s why Rosen Bridge excludes these tokens entirely.
Confirmation policy: 50 blocks, matching CCC’s default and double the RGB++ security analysis (building on Ren Zhang’s work) recommendation for extra safety:
assuming that the adversary’s Hash rate accounts for 30%, CKB would need to maintain a 2.5% orphan block rate and require 23.29 confirmations to match the security of 6 confirmations on Bitcoin with a 0% orphan rate
The full plan is at sonami-tech/rosen-bridge-ckb-integration 
For any questions, doubts, or feedback: we’re here!!
Phroi
PS: We have an upcoming Reddit AMA on March 11th, Feel free to drop your questions over there too!
We are submitting this comment to confirm that Milestone 1 has been completed and to request release of the corresponding milestone payment. Tagging @zz_tovarishch here as the transitional period coordinator.
The completed deliverable is published here:
Primary document:
Supporting analysis:
This deliverable completes the Milestone 1 requirement by documenting the technical decisions and implementation path for integrating CKB into Rosen Bridge, including:
feasibility against Rosen Bridge’s base requirements
the signing architecture for CKB and the rationale behind it, with additional detail in the comparison
the data encoding for bridge requests, with extractor details in the extractor section
token support and bridgeability constraints
state rent and ACP cell design for deposits and custody
confirmation policy, fee model, and CKB chain parameters
the implementation plan across Rosen Bridge repos and services
guard rotation and asset migration considerations, with additional analysis in the multisig analysis and migration tradeoffs
The proposal defined this milestone as a deeper technical assessment and a documented implementation plan. That deliverable is now complete and public.
The approved proposal budget was 27,356,903 CKB for $65,000 USD. Milestone 1 represents $15,000 / $65,000 = 3/13 of that amount.
Using the same fraction of the originally approved CKB amount:
27,356,903 * (15,000 / 65,000) = 6,313,131.4615... CKB
Rounded to the nearest whole CKB, we request release of 6,313,131 CKB for Milestone 1.
At a current market price of approximately $0.001446 per CKB, that tranche is worth about $9,128.79 USD, below the milestone’s nominal $15,000 USD value. We are noting this for the record while keeping the request aligned with the originally approved CKB-denominated budget and milestone fraction.
An early preview of this work was shared in the March 5 update.
We will continue posting public progress updates as work advances toward Milestone 2. If the DAO Stewards, Committee, or community reviewers would like any follow-up materials or a milestone verification checklist, we can provide them in this thread.
Two quick clarifications:
On-chain multisig: CKB has a multisig lock script deployed in the genesis block — though note that it had bugs, and the community has migrated to v2.
Token Support — xUDT is the chosen standard. — Some xUDT assets use independently deployed xUDT contracts (e.g., USDI, RUSD etc). Can these be supported?
Multiple ACP cells per token avoid state contention when users deposit concurrently. The UI selects an available ACP cell; when all are consumed by pending deposits, it chains off a pending transaction’s output.
Two quick questions on ACP cells:
Hi guys , I’m in discussions with someone who has submitted a proposal to the Zcash Foundation around bringing wrapped ZEC into Ethereum DeFi, about using RGB++ as their bridge.
The path we’re exploring is: Zcash → RGB++ (isomorphic binding to CKB) → Rosen Bridge → Ethereum as a wrapped ERC20.
A few questions:
1. Is Zcash compatible with RGB++ isomorphic bindings given it is a UTXO-based chain?
2. If so, could a wrapped ZEC token flow through to Rosen Bridge and out to Ethereum DeFi?
3. Is this something that they can work in parallel with in Q2 ?
Tagging @matt_ckb too for public discussion.
hi Emmanuel,
I think it depends on the memory requirements for verifying Equihash proof of work. I have spoken with the Ergo community, they also have a memory-hard proof of work function but felt confident it would be able to be verified on CKB. Someone from the ZCash community would be best to advise on this, CKB scripts can access 4mb of memory.
I believe Rosen is compatible with all UDT’s
The scope of adding another chain for RGB++ verification is the biggest question here, I don’t think Q2 would be viable for this. The other parts are pretty straightforward.
I’m wondering, what would be the advantage here compared to another ZEC<>Ethereum bridge?
Hi Matt, thanks for the detailed response!
On your question about the advantage over another ZEC<>Ethereum bridge, the key selling point for the Zcash community is decentralization. Most existing ZEC<>Ethereum bridges are centralized or custodial, which is a hard sell for a privacy-focused community that cares deeply about trust assumptions. Rosen Bridge being fully decentralized and audited is a significant differentiator.
On the technical points really helpful context. I’ll check with the team on the Equihash memory requirements and come back with more specifics. The 4mb CKB script memory limit is a useful data point to bring to that conversation.
On timeline I wasn’t suggesting this would fall within the Sōnami team’s scope. The idea would be that the Zcash side (RGB++ verification for Zcash) would be built in parallel by a separate team, running alongside the CKB integration as it progresses. Given this would a parallel effort be feasible?
Would it be better to target Zcash integration into Rosen?
Someone would need to examine level of effort required for Zcash RGB++, first we need to know if it’s possible. Overall I’d say it’s unlikely we can start to target this in the near future.
One question that I think is fundamental to this discussion.
As I understand it with RGB++, the locked funds stay in the user’s own wallet on the source chain and proof of their existence is verified cryptographically via the isomorphic binding. No custodian ever holds them.
For Rosen Bridge, where exactly do the locked funds sit on the source chain? Are they held in a smart contract, a Guard-controlled multisig, or somewhere else? And who controls the private keys? and how is the proof of reserve done?
Too much multi-tasking for me these days, I should have mentioned. RGB++ only allows for creation and movement of new user-generated assets. It won’t be able to lock $ZEC on ZCash.
I don’t know the exact terminology, but I think Guard-controlled multi-sig will be closest. Proof of reserve would be visible on-chain.
If RGB++ allowed that, we would not even have proposed this Rosen Bridge integration.
Not a thing: RGB++ is not a Bridge, it just allows to export CKB L1 cells such as tokens/NFT/Protocols/… to other chains or (expressed in better terms) RGB++ current implementation allows UTXO on other chains to control a cell/UTXO on our chain. That’s the same reason why we don’t have RGB++ BTC on Nervos L1.
Fell free to double check with @fgh in a separate thread such as Verifying ZCash Equihash on CKB
