[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”