toCKB: An Asset Cross-Chain System


The toCKB is an asset cross-chain system, which consists of a bunch of protocols, CKB contracts and off-chain modules, to support decentralized, redeemable token on CKB supply-pegged to any asset on any blockchain.

As long as you can transfer an asset on a blockchain and construct a spv proof to verify the transaction, you can implement the spv verification logic in the toCKB contract. Then anyone can use the contract to mint a token on CKB pegged to the asset by locking the asset. They can transfer the token and burn it to redeem the asset on original blockchain as well. The peg is implemented using an approch mixed with bonding and spv proof verification, which involves a new role called signer. Signers act as a guard on the original blockchain to ensure the asset is locked when minting token and send the asset back to user when redeeming. Anyone can be signer by bonding an amount of CKB that ensures their behavior in the system remains honest, at risk of losing their bond in case of dishonesty or undercollateralization.

The CKB contracts mediates the cross-chain’s lifecycle, including request, bonding, redemption and failure-handle. The off-chain modules help users use the whole system painlessly, including constructing transactions, monitoring CKB as well as other blockchains to act automatically, generating spv proof and so on.

We will support BTC and ETH in this stage, and provide a guide document to support other assets.


A Note on Naming

The system, in its entirety, is called “toCKB”. The blockchain is refered as “XChain” and the asset as “XAsset”. The token on CKB pegged to XAsset is refered as “XToken”, sometimes it can be shorten as “XT”.

For BTC and ETH, the names mapping is like below:

XChain XAsset XToken(XT)
Bitcoin BTC cBTC
Ethereum ETH cETH

Prior Work

Prior work towards asset cross-chain includes centralized or multisig notary schemes and spv based bridge.

Centralized or Multisig Notary Schemes

A party or a group of parties act as notary. When they receive asset on one chain, they mint token on the counterparty chain and send it to users. When they receive mirror asset on one chain, they burn it and send back associated asset to user on the counterparty chain.

Projects using this schema includes:


  • It is simple and easy to implement.
  • It is not decentralized and insecure. Custodians need to be fully trusted. A malicious custodian can delay or block the withdraw, even steal your asset.

Spv Based Bridge

If the two chains are both capable of verifying the spv proof of the counterparty chain, we can implement a spv based bridge. We setup cross-chain contract on both chains, lock asset in the contract on one chain, construct the spv proof and relay the proof to the contract on counterparty chain, the contract mint the amount of mirror token on counterparty chain. It is similar when you burn the mirror token and get your original asset back.

Projects using this schema includes:


  • It is fully decentralized and secure. You don’t need to trust anyone or anything except the two chains you want to move assets between.
  • It depends on the programming capability of both chain to verify the spv proof, which is hard to satisfy in some cases. E.g. Bitcoin’s script system is too weak to verify the spv proof of Ethereum.
  • It is more complicated to implement. We have to develop contracts on both chains to maintain an on-chain light client of counterparty chain, verify the spv proof and handle the lock/unlock logic and off-chain modules to generate spv proof, relay the proof.

Core Concepts

The core concepts of toCKB are:

  • Because we want to support the chains lack of ability to verify CKB spv proof, we involve a new role called signer to replace the contract in spv based bridge. Users transfer their asset to signer’s address instead of the contract to lock.
  • Anyone can be signer by bonding an amount of CKB that ensures their behavior in the system remains honest. The exchange rate may changes over time, so the value of CKB have to be more than the locked asset for security. The collateral value percent is configurable, which is 150% in this stage.
  • With the help of signer, we can handle both mint and redeem logic on CKB by spv proof verification:
    • When user locked their XAsset on XChain(which means they transfered their XAsset to signer), toCKB contract can verify the proof and mint XToken on CKB, owned by user.
    • When user burns their XToken on CKB, signer has to send the XAsset to user on XChain and submit the proof to CKB. toCKB contract verifies the proof, and redeem the bond of signers.
  • There will be additional logics in toCKB contract to handle unexpected situations, e.g. signer incentive, signer fraud, undercollateralization caused by the exchange rate changes.


The normal process shows below:

  1. User makes a deposit request on CKB, along with some pledge. If someone bonds as signer but the user does not follw up, the user will lose the pledge to compensate the loss of signer’s CKB liquidity.
  2. Someone bonds CKB to become a signer, provide a XChain address for user to deposit XAsset.
  3. User transfers their XAsset to signer on XChain.
  4. User generates the transaction proof and relays it to CKB, mints 1-to-1 CKB token – XToken. Signer gets some percent of XToken as fee, e.g. 0.1%.
  5. User can deal with the XToken as he wishes.
  6. When user want to redeem XAsset on XChain, he can make a redeem request on CKB, burn his XToken on CKB via toCKB contract.
  7. Signer sends the XAsset back to user on XChain.
  8. Signer generates the transaction proof, relays it on CKB, and withdraws his collateral back.

Handle Failture

There are two kinds of failure: abort and faulty.


  1. After users make a deposit request, nobody bonds their CKB to become the signer(step 2). Users can withdraw there pledge then.
  2. After someone bonds CKB to become the signer, user does not send the XAsset to signer(step 3). Signer can withdraw his collateral and user’s pledge.
  3. During redeem process, signer does not send asset back to user within a limited time(step 7). Anyone can trigger liquidation.
  4. The exchange rate changes, causes the CKB value bonded lower than expected. Anyone can trigger liquidation.


  1. During the warranty period, signer spends the locked XAsset. Anyone can relay the proof to CKB to trigger liquidation.
  2. During redeem period, signer transfers the XAsset to wrong address. Anyone can relay the proof to CKB to trigger liquidation.

In liquidation period, anyone can start an auction. The auction price decreases over time. People pays XT to buy the CKB bonded in the contract. User gets the XT to redeem XAsset from other signers.

The rules for the distribution of the remaining collateral from the auction are as follows:

  1. If the auction is caused by abort, the user who triggers the liquidation shares the remaining collateral with the Signer.
  2. If the auction is caused by faulty, the user who triggers the liquidation gets all remaining collateral.



toCKB Contract

The toCKB contract mediates the lifecycle of the deposit, including:

  • Deposit Request
  • Bonding
  • Withdraw Pledge
  • Withdraw Pledge and Collateral
  • Pre-term Redeem
  • At-term Redeem
  • Withdraw Collateral
  • Liquidation:SignerTimeout
  • Redeem: Pre-Undercollateral
  • Liquidation:Undercollateral
  • Liquidation: FaultyWhenWarranty
  • Liquidation: FaultyWhenRedeeming
  • Auction: SignerTimeout
  • Auction: FaultyWhenWarranty
  • Auction: FaultyWhenRedeeming

Price Oracle

The toCKB system relies on a price oracle who provides the CKB/XAsset price to remain security.

We are still working on design and implementation on that. The possible solutions:

The X Specific SPV Verification

For different XChain, we have to implement the spv verification logic on CKB. Due to the flexible design of CKB-VM, it will be easy to reuse a lot of previous work.


In this stage, we will make some scripts or command line tools to help users and signers construct transactions, monitor the chain events and even trigger the follow up actions automatically.

There are 3 modules in plan right now:

  • A user client for users to deal with the deposit request, mint XT and other actions.
  • A signer client for signers to deal with bonding, redemption and other actions.
  • A guard service for users who want to get profits by watching frand behaviors on CKB and triggering the liquidation.

The original document is listed in the repo, you can check the code for more detail, though it’s still on active development.
Any discussion or suggestion for this are warmly welcome.


你这个机制有点像,交易所的法币出入机制。但我觉得这样存在问题,如果要恒定比如1cBTC=1BTC 价格体系,如果比特币的价格飙涨,或者CKB的价格剧跌。Signer就会出现放弃抵押ckb,直接提出BTC的情况

针对以太坊我建议还是实现 Spv Based Bridge 的机制。针对BTC,可否CKB的合约里面,利用CKB的签名建立一个公用的BTC地址,(同时建立一种发送方比特币地址到CKB地址的映射关系,即用户用比特币的私钥,也可以解开一个CKB的钱包,类似Portal Wallet白嫖以太坊的原理 :grinning: :grinning: :rofl:)。当用户发送比特币到公共地址的时候,CKB合约就将铸造的cBTC,发送到用户比特币地址私钥能解开的一个CKB的钱包地址内

如果按照文章指出的“ 1. 汇率变化,导致债券的CKB值低于预期。任何人都可以触发清算。”,针对用户来说他们首要的目的是保证资金安全,而不是清算。如果映射到CKB,资金安全无法保障,就没人愿意映射到CKB了。进而基于Nervos的去中心化交易所也无法发展,用户把映射放到基于Nervos的去中心化交易所,最后资金安全无法保障,这肯定是用户无法接受的。



BTC 的 scripts 因为不具备验证 CKB spv 的能力,所以只能采用这种做法。对于 ETH,以后会有 Spv Based Bridge 的实现。

你描述的本质上是见证人跨链。“公用的 BTC 地址”如果由人(一个或一组)来管理,需要信任管理者。如果由合约管理,即验证用户在 CKB 上销毁了 cBTC 才能从这个公共地址提币,那这个是 BTC 做不到的。

提前清算的目的就是为了维持质押的 CKB 资产的比例高于一定的阈值, 从而保证 cBTC 后面有足够的 BTC 支撑。

以太坊和火币公链支持智能合约,可以实现双向 spv 验证,可以使用也可以不使用这个方法。

Signer can deal with the XAsset as he wishes是不是好些呢


  1. 可以规避 Signer 被清算风险
  2. 同时降低 价格波动导致的抵押不足风险

协议有一个 Pre-Undercollateral-Rate(预清算比例),比如是 125% 。初始抵押比例是 150%,触发清算的比例是 115% 。

当价格波动,抵押比例 降到 <= 125%,这时候仅 Signer 有特权也有动力发起赎回交易,将资产跨回 XChain,从而提防价格进一步波动(导致抵押比例跌破 100%)。

Signer 有动力的原因是,这种情况下 Signer 可以提前取回自己的押金。


中间开发者的合约可以透过 EVM 的兼容层 Polyjuice 在 CKB 上实现,这样的情况下就是需要胡老师这个组件,让用户在没有感知的情况下,可以减少手续费的花用,并且让开发者避免了以太坊过度拥挤的性能问题。

有几个 idea 和问题

1.地址上 Xchain 和 CKB 可以共享同一个地址(如果在大 Lay2 的支持范围内),体验更加
2. step 3 的 failure 是怎么判定,区块高度吗?
3.预言机看起来同时需要有例如 ETH 上的价格,同时也需要有 CKB 价格
4.引发清算确实场景比较像是在借贷,不管是 Abort4 还是Abort3 ,看起来确实会像为了让系统继续运作而处罚无辜的当事人
5.如果 signer 抵押的是稳定币,是不是可以减少 3、4这两点的问题,因为价格波动不会太大,可能预言机比较好处理,另外就是不会容易因为价格波动而触发清算。同时,如果有其他链上大型的 DeFi 项目的资产要进入 CKB 时(如 yearn finance), Signer 比较可以负担抵押成本。
6.对 signer 的激励行为相当于在 Nervos 链上进行滴滴打车或美团的补贴,或者 suhsiswap 的 yield farming。

想了下,没什么理论障碍,但是要做到用户无感知的用 polyjuice,还需要做一些工作:

  • 跨链到 CKB 的 ETH/ERC20 映射到 polyjuice 中
  • polyjuice 兼容 web3.js API

是的,超过一定的高度还没有提交转钱给 signer 的证明,即认为是 failure。

需要的是 XAsset/CKB 的价格

波动性不太会降低。因为这里质押的目的是保证质押的资产超过 signer 在 XChain 上托管的资产。 以 BTC 和 SUDT 为例,换成稳定币,BTC/SUDT 的价格依然是波动的,且幅度不一定比 BTC/CKB 小。


  1. signer 作恶。这个场景下的清算是为了惩罚 signer。
  2. 价格波动导致 signer 的抵押不足,这个场景下的清算是为了保证 CKB 上发行的影子资产(cBTC)依然有足够的价值作为支撑。

对的,这个可能是 Xtoken 和 Xasset 的关系,但是不知道在 CKB 上和在 Polyjuice 中间会需要多少工作

对的 那时候要说的是 ETH 上的 XAsset 价格和 CKB 价格,那看起来是不是对于不依赖线下 API 的预言机方案,在采用上具有困难,例如 Nest

明白,你这样说有道理,那确实他会导致许多要进行资产跨链的大单 signer 吃不下把?

对的 情况1 惩罚我是认同的
只是在想情况2 其实对于 singer 来说有点衰啊

我认为是可行的。有个问题,signer 支付了很大代价,映射cBTC,但是回报显然不足以让人参与进来。是否该考虑创造出来的cBTC之后在链上交易的手续费分成给signer ,达到年化20%以上的收益,才会有足够多的大户愿意提供CKB的流动性,让ckb发展为一个成功的Defi公链



这个地方不是很理解可以怎么对 cBTC 收手续费。Defi 收取手续费是因为它本身是合约。如果不是合约配合的话(一般合约应该也不会主动增加分手续费给 signer 的逻辑),可能要在 cBTC 的 token 代码里嵌入相应的逻辑,在用户转账、进行合约操作时,自动产生一定的手续费分给 signer 或者某个池子。你想表达的是这个意思么?

是的,基于质押的方案都有这种问题,相比于中心化的质押,toCKB 这种去中心化的质押更明显。

恩,理想的状况是,质押只是保障,押金永远不会动,mirror token 始终和原来的 token 保持相同的价值,可以随时双向兑换。但是基于质押的方案,价格波动时,双方都有很强的作恶动机。这个地方还挺难处理的。



Great to see some work being done in this front!
I’ve noticed that the Prior Work section doesn’t list any of the projects that use a similar system to the one toCKB plans to go for, so I thought I’d chime in and mention a few of these, as, in case you aren’t already aware of them, I imagine that checking out what worked for others could be beneficial, especially in regard to the discussion on incentives that is being developed in this thread:

  • tBTC is a system very similar to this one with the difference that it uses ETH instead of Nervos as the base layer. They are going for an incentive system very similar to yours, where signers earn a small fixed fee each time they take part in a minting, which combined with the fact that ported tokens have their locking period limited to 6 months, results in a fixed APY. Note that signers will also be incentivized with tokens and these rewards will likely be superior to signing fees, so that will likely be the driving force behind collateral-locking.
  • XCLAIM is a research paper that explores the core idea of using collateralized assets to port assets from one chain to another, it avoids some of the practical parts of such system so no incentive system is proposed.
  • Incognito Chain’s Portal is incognito chain’s crosschain solution to port tokens over to their chain. Fees are fixed and charged on deposit and withdrawal but, not unlike some of the other systems described, the main incentive for custodians comes from native tokens which are distributed to them.
  • smartBNB is a project I worked on that enabled the porting of Binance Chain tokens to NEO. Collateral providers were incentivized through a mechanism that deflated the balance of all token holders on a per-block basis and transferred that surplus to the providers.
  • Polkadot’s BTC bridge is an implementation of XCLAIM for Polkadot.