[DIS] CKB Integration for Rosen Bridge

[phroi]

Hey @david-fi5box, thank you for the questions!! Also, sorry for the delay, just finished replying in the other thread: On-Chain Tally: DAO v1.1 Limits and a Deposit-Paired Voting Proposal - #13 by phroi

@david-fi5box

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.

Yesss, we are well aware. May ask what’s your point?

• Multisig v1 could be classified both as a System Script and/or User Script and it would not make a difference due to Nervos L1 architecture.
• Multisig v2 can be more easily considered a User Script.
• Nervos DAO is the only real System Script cause it needs special permissions to mint new CKB.

We initially wanted to integrate via Multisig v2 until we discovered that TSS was the better integration for similar security assumptions. Feel free to check out the commit history of the Tecnical Analisys and let us know: Commits · sonami-tech/rosen-bridge-ckb-integration · GitHub

@david-fi5box

Token Support — xUDT is the chosen standard. — Some xUDT assets use independently deployed xUDT contracts (e.g., USDI, RUSD etc). Can these be supported?

As explained previously, it depends on the Rosen Bridge token policy:

@phroi

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.

For example, while USDI could be technically bridged, Rosen Bridge could never accept to bridge a bridged USDC, cause it has not one, but two centralization points: issuer of USDI and issuer of USDC.

On RUSD, passing the fact that it could easily become the next TAI, it would need to be carefully examined for centralization issues. Its closed source nature actively hinders its inclusion.

For example just looking at its deployment, I can already see that is deployed by type and its upgradable by the owner: https://explorer.nervos.org/en/transaction/0x8ec1081bd03e5417bb4467e96f4cec841acdd35924538a35e7547fe320118977

Since creator of RUSD could hypothetically freeze RUSD bridge reserves by updating the RUSD script (not just the Owner script as in xUDT), this means RUSD does not currently qualify.

@david-fi5box

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.

@david-fi5box

Why do users manually select an ACP cell in the UI instead of the system auto-assigning an available one?

Nope, idea is that UI chose randomly one (being it either in the tx pool or not) to avoid as much as possible state contention.

Where did we give the impression that user would have to manually pick one?

@david-fi5box

How many ACP cells are there—fixed or scalable?

One at listing time, then dynamically Scalable: deployed manually under elevated on-chain activity or user feedback. Once an additional cell is created, it will keep being deployed.

Manual deployment of a new ACP cell is easy: just send 0 xUDT of that specific token type to Rosen Bridge ACP lock.

Love & Peace, Phroi

[phroi]

@david-fi5box

xUDT is the chosen standard

PS: let me be more specific, cause this statement conflates two different meanings:

1. Assets bridged to CKB (like BTC, ETH, DOGE …)

xUDT is the chosen standard for assets who are gonna be bridged to Nervos L1

Let’s say that Core Team was to deliver betterUDT before Rosen Bridge mainnet deployment, I would personally be very happy to switch to betterUDT in Rosen Bridge. See: Pre-RFC Discussion: Activating the Nervos DAO Treasury - #12 by phroi

2. CKB Native Assets (like CKB, iCKB, SEAL …)

We don’t need to support only xUDT here, we could easily bridge from Nervos L1 to other chains future betterUDTassets or even sUDT ones.

For example, notice how sUDT is a references by type, but non-upgradable, cause the lock locking the sUDT binary is a zero lock: https://explorer.nervos.org/transaction/0xc7813f6a415144643970c2e88e0bb6ca6a8edc5dd7c1022746f628284a9936d5

By default sUDT assets are as much decentralized as xUDT ones

[david-fi5box]

@phroi

esss, we are well aware. May ask what’s your point?

• Multisig v1 could be classified both as a System Script and/or User Script and it would not make a difference due to Nervos L1 architecture.
• Multisig v2 can be more easily considered a User Script.
• Nervos DAO is the only real System Script cause it needs special permissions to mint new CKB.

The multisig part is fine. I previously thought your project was using the multisig from the genesis block rather than multisig v2, so I wanted to give you a heads-up. Now it’s clear—you ultimately chose TSS and did not use CKB’s multisig.

@phroi

CKB Native Assets (like CKB, iCKB, SEAL …)

It looks like only xUDT assets with type code hash 50bd8d66 be supported?

@phroi

For example, while USDI could be technically bridged, Rosen Bridge could never accept to bridge a bridged USDC, cause it has not one, but two centralization points: issuer of USDI and issuer of USDC.

I fully understand that handling assets with centralized points can be very tricky for cross-chain bridges.

However, USDI did this for compliance reasons.

Additionally, USDI only updated to PUDT on testnet, while on mainnet it is still xUDT, just deployed separately (you can verify its data hash). What I actually wanted to ask from the beginning is whether this scenario can be supported?

Beyond that, I also want to point out that many xUDT assets on CKB deploy their own xUDT contracts for various reasons—not necessarily to introduce centralization.

Because the strictly decentralized way of using xUDT that you mentioned is only suitable for assets with a fixed cap like SEAL.

Will you screen these assets, either technically or manually? Or will you simply not support them? I hope to have a very clear table.

@phroi

Nope, idea is that UI chose randomly one (being it either in the tx pool or not) to avoid as much as possible state contention.

Where did we give the impression that user would have to manually pick one?

So essentially this is just a random selection.

The UI mentioned in the documentation stands for user interface, right? This makes me feel that user action is required here.

So this just means the relevant information about the selection will be displayed on the UI?

[BuildUnion]

You may have misunderstood. goal was not to use RGB++ as bridge I was asking if it could be used as decentralized custody. I have gotten the clarification on it.

[phroi]

Hey @david-fi5box, I’d like to remind that my role is:

@Sonami

Phroi will lead the development effort, tasked with making all critical development decisions, contributing all necessary code, and ensuring that the integration code base is up-to-date at all times.

Proposal voted upon says development decisions, not policy making. @jm9k feel free to correct me in any way or provide more info.

Allow me to reply in more detail:

@david-fi5box

Will you screen these assets, either technically or manually? Or will you simply not support them? I hope to have a very clear table.

Proposal team cannot make the final decision on assets inclusion: not our role, nor authority.

Once the integration is done and Bridge is running, it’s ultimately up to the Rosen Bridge Guards and Team to decide which assets can be included. The only way to get some authority in the matter by buying up a bunch of RSN and becoming a Guard.

Conversely, we can pre-screen assets for known issues, possibly suggest some assets for inclusion, but remember CKB is a the only real decentralized asset here, everything else needs a formal evaluation by Rosen Bridge Guards and Team.

Known assets class not included: USDC-alike assets are very often requested in the Rosen Bridge by users, but since the Rosen inception USDC inclusion has always been firmly blocked. Please, don’t trust my word, verify it publicly with @Armeanio in Telegram: View @rosenbridge_erg

@david-fi5box

USDI only updated to PUDT on testnet, while on mainnet it is still xUDT, just deployed separately (you can verify its data hash). What I actually wanted to ask from the beginning is whether this scenario can be supported?

There are issues at multiple levels with USDI:

• The contract can be updated at any time to Pausable UDT, cause it’s referenced by type and someone own the lock on that binary: https://explorer.nervos.org/en/transaction/0xf6a5eef65101899db9709c8de1cc28f23c1bee90d857ebe176f6647ef109e20d
• @IPN reading the terms and conditions for USDC, under Restricted Activities: 8. use the USDC Services on behalf of any third party or otherwise act as an intermediary between Circle and any third parties. Conversely, the previous Matrixport agreement was protected by law.

Those assets can be frozen at multiple levels for multiple reasons. Not something we want on a decentralized bridge.

@david-fi5box

It looks like only xUDT assets with type code hash 50bd8d66 are supported?

Which other assets would you like to advise for inclusion? Can you provide a list of names with relative documentation, open-source code and trustless deployment?

@david-fi5box

The UI mentioned in the documentation stands for user interface, right? This makes me feel that user action is required here.

So this just means the relevant information about the selection will be displayed on the UI?

Nope, it will be handled internally by the UI code, so on the client side.

@BuildUnion

You may have misunderstood. The goal was not to use RGB++ as a bridge; I was asking if it could be used as decentralized custody. I have gotten the clarification on it.

Sorry for the misunderstanding: it seemed like you were asking for a bridge, while asking if RGB++ could do it

Phroi

[BuildUnion]

No worries. I can see how it came across that way. I did explicitly state it, but that wasn’t what I meant.

[fgh]

@BuildUnion

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.

Your overall understanding is correct. To provide a bit more technical context:

The RGB++ asset remains under the owner’s control in their source-chain wallet, secured by a Bitcoin UTXO acting as a ‘single-use seal.’ The asset’s state is stored within CKB Cell data, which is isomorphically bound to that specific UTXO.

Any asset transfer is governed by both the source chain’s consensus and the RGB++ lock script on CKB, ensuring decentralized security without third-party custodians.

[BuildUnion]

Thanks. I’ve been made to understand that this only applies to native CKB assets, so it can’t be used for the Zcash integration. If you have different information, feel free to reply here: https://talk.nervos.org/t/verifying-zcash-equihash-on-ckb/10180/7”

[zz_tovarishch]

M1 Payout

https://explorer.nervos.org/transaction/0x0c59bdaedb9be76e4682c75a254dafc35713cbe136d158a444d18dfa5b96c3dc

8,777,063 CKB (representing the 23% of full grants)

[phroi]

Hey @zz_tovarishch & Commission, thank you for the payment

Just there seems to be a misunderstanding:

x / 27,356,903 CKB = 15k USD / 65k USD
~ x = 27356903 CKB * 15 / 65
~ x = 6,313,131 CKB

Please, could you double check this?

If you can confirm, could you give us guidance on what should be done about these additional 8,777,063 - 6,313,131 = 2,463,932 CKB ?

Sending them back should be doable, allocating them towards the next Milestone is doable too, no trouble on our side

Phroi

[zz_tovarishch]

Hi Phroi，CKB数量的差异是因为自25年10月以来，在实际执行中，打款都是按照CKB新的价格进行，一定程度上缓解价格波动对开发者的影响

[phroi]

@zz_tovarishch

the difference in CKB amount is because since October '25, in actual execution, payments have been made according to the new CKB price

Linked CKBoost payment was a special case:

@terrytai

V. Special Cases: Approved Proposals with Unfinished Milestones

There is one particularly important and complex issue that requires clarification:

Whether already approved proposals can adopt stablecoin-based pricing.

At present, this situation mainly involves two projects: CKBoost and DAO v1.1.

This issue has been discussed internally at length and presents a genuine dilemma:

• Allowing stablecoin-based pricing would clearly violate Principle 1 (rule integrity)
• Taking no action at all could result in insufficient funding for these projects, potentially preventing completion, which would violate Principle 3

---

VI. Temporary Off-Rule Solution (Personal Action Statement)

As this issue cannot be resolved within the existing rules, we can only seek a temporary solution outside the rule framework.

On a personal basis, I will:

• Donate a portion of CKB
• Reach out to a small number of other donors to help alleviate the funding pressure faced by the above projects during the transitional period

It must be clearly stated that:

• This is my personal action and does not form part of DAO rules
• This action is limited in scope and responsibility
  • There is no guarantee it will be expanded
  • There is no guarantee it will fully offset the impact of price fluctuations
• If the funds raised are insufficient, that outcome will have to be accepted
• Any surplus funds will be fully donated back to the DAO treasury

Additional clarifications:

• This personal subsidy applies only to proposals that have passed final voting (Voting Stage) but have not yet been paid
• It does not apply to new proposals submitted during the transitional period
• Projects with a strong requirement for stablecoin-based pricing are advised to wait until v1.1 officially goes live

[zz_tovarishch]

Transitional Policy Statement (Community Fund DAO v1.1) 发布在2025年12月

但CKBoost在2025年7月的申请中提出：

@Alive24

Amount requested: $20,000 USD (around 4635652.81 CKB at current price. Should use the latest price at the time of issuance)

通过投票后，其两笔发生在2025年8月和2025年10月的打款，实际是采用的the latest price 计算CKB进行打款

此后，多个项目在申请时均提出使用the latest price计算打款时的CKB数量，如Pocket Node 2026年2月

Invisibook 2026年4月

且都通过了投票
所以目前在实际操作中，各个项目的打款都进行了重新计算

[phroi]

Additionally, payment target is CKBoost is not last price, it was: Fixed Milestone Percentage in CKB + reimbursement of any loss inccurred to CKB price

[phroi]

Now the issue is this:

@Sonami

Grant Amount: $65,000 USD (CKB price: $0.002376; CKB requested: 27,356,903)

Note how we did not specify equivalent value in CKB at the time of disbursement

[phroi]

@zz_tovarishch

Therefore, in current practice, the disbursements for each project have been recalculated accordingly.

Nope nope, that’s a MetaRule change in itself: [DIS] Use USD amounts for DAO payments, calculated on the date of payment

All this said:

• If it’s opt-in, I don’t mind and it could indeed be beneficial.
• If it’s forced upon DAO projects, I need to raise the question.

Phroi

[zz_tovarishch]

谢谢你的指正。后续会按照通过投票的项目的实际情况通知委员会打款。

具体到CKB integration for Rosen Bridge, 这次多打的CKB数量，我会在下次需要打款时告知委员会减掉相应数额。

[phroi]

If anybody has any question about the Rosen Bridge and its integration progress, we are always available here

Love & Peace, Phroi

[matt_ckb]

many people would like to understand the integration progress, please share what you can

[phroi]

Implementation is actively on-going! Nowadays coding is fast, but making sure that everything works as it should is a bit trickier. So ultimately it’s a slow and methodic process.

I feel lucky that I can compare my solutions with other integrations, just CKB flexibility & state rent are definitely NOT helping out!!

For example, I just dug out something interesting. Given the following assumptions:

• Rosen Bridge attach on transfers meta-data such as fromAddress and toAddress
• CKB to OUT transfers are done by storing this data in a cell owned by the bridge (ACP)
• OUT to CKB transfers are done by storing the usual xUDT data in a cell owned by user (normal user cell)
• User addresses length can be up to max block size: ~500KB or more if tx is mined by private miner

Then a CKB user with a long enough address can:

1. CKB to OUT: occupy all CKB of the ACP by effectively abusing fromAddress
2. OUT to CKB: drain out of CKB an ACP cell or generally any exchange supporting naive CKB tokens withdrawals

Remedies being investigated:

1. Not really an attack per se, cause this is not limiting Bridge actions, that metadata information can be lost at the next tx without trouble. That said, if we wanted, we could use fromAddress to store an outpoint representing user, instead of address. Most of the other UTXO chains integrated in Rosen Bridge adopt this approach.
2. Bridge Network fee could would pay for a fixed amount of CKB, so user UDT cells get a fixed amount of CKB.

All in all everything is proceeding,
Phroi