[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