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!