How to partially withdraw from an iCKB Deposit?

[ashuralyk]

hi, Phroi bro, I have a major question, how can you allow iCKB depositors to extract their CKBytes from iCKB cell, because the deposited DAO cell cannot split into pieces.

is there any aggregator to collect and match all of the iCKB extraction demands and the deposited DAO cells?

[phroi]

Hey @ashuralyk, thank you for publicly expressing your interest in iCKB as part of the integration of iCKB in NervDAO, I personally appreciate a lot!! 🙏

As you noticed, it's not possible to partially withdraw from an iCKB deposit. This is the underlying issue that led me to design such an overly complicated protocol.

To address this issue two measures have been taken:

1. Standard Deposits of 100k iCKB, this incentivizes deposits fungibility.
2. Limit Orders to handle conversions that are too small or big to run directly on the core of the protocol.

is there any aggregator to collect and match all of the iCKB extraction demands and the deposited DAO cells?

Indeed, this is the function of Limit Orders and Fulfillment Bot.

The iCKB core protocol is independent on the DEX used to fulfill user conversion requests. So NervDAO could choose to switch out Limit Orders in favor of UTXO Swap AMM. That said, UTXO Swap:

1. Charges a 0.3% fee plus slippage, while LO charges 0.1%, worth around two weeks of NervosDAO interests.
2. Has no guarantee on the conversion price between CKB and iCKB, while LO has a guaranteed conversion ratio.
3. Requires a non trivial capital to bootstrap an AMM pool, while LO only requires the minimal Fulfillment Bot capital, ~135k CKB

Withdrawing with the DApp

The current DApp avoids the use of Limit Orders as much as possible due to the associated fee of 0.1% and the possibility that the bot may not be able to fulfill the orders for whatever reason.

Let's make a few examples to understand how the DApp currently works, but also feel free to test out the DApp on testnet :hugs: (Keep in mind the iCKB pool is still in seeding phase, a month has still to pass from its deployment, so Withdrawal Request times are longer than usual)

Withdrawing 50k iCKB with the DApp

Let's say a user wants to withdraw 50k iCKB, the interface will create a tx with:

1. A Limit Order for converting ~50k iCKB to CKB (0.1% fee)

Side Note: Let's say a deposit of 50k iCKB or less exists near maturity, the DApp will try to use it. That said, these smaller deposits should be uncommon due to the higher associated costs for depositors.

Withdrawing 150k iCKB with the DApp

Let's say a user wants to withdraw 150k iCKB, the interface will create a tx with:

1. A Withdrawal Request of ~100k iCKB from a deposit close to maturity (no fees)
2. A Limit Order for converting ~50k iCKB to CKB (0.1% fee)

Withdrawing 10M iCKB with the DApp

Let's say a user wants to withdraw right away 10M iCKB (so without splitting it into multiple ~3M txs), the interface will create a tx with:

1. A Withdrawal Request of 30 * ~100k iCKB = ~3M iCKB from deposits close to maturity (no fees)
2. A Limit Order for converting ~7M iCKB to CKB (0.1% fee)

Side Note: NervosDAO txs have a maximum of 64 output cells. Due to the necessity of having Limit Orders (2 cells), change cells (2 cells) and Owner cells (an additional cell per Withdrawal Request), the cap is (64 - 4)/2 = 30 Withdrawal Requests per tx.

@ashuralyk do you have any additional question?

Love & Peace, Phroi

[ashuralyk]

@phroi thanks for your explanation, it's a huge step helps me more close to the certainty, so the Limit Order is not a feature to match the Nervos DAO cell and the iCKB cell, it's used to push out the iCKB token to some potential outside iCKB buyers, is this a correct understanding?

and the Limit Order cell is really necessary binding in the withdrawal phase? for example, I have 150k iCKB, and only 100k of them close to the maturity, so I just withdraw part of them and leave 50k iCKB to withdraw next time, but for the insufficient maturity case, I can buy enough iCKB from the second market, like Limit Order, and then withdraw them out.

[phroi]

the Limit Order is not a feature to match the Nervos DAO cell and the iCKB cell

Not really, by all means it is a feature in that direction. Just I didn't find a better solution, by any chance could you propose a better one?

Underlying issue: The value of iCKB xUDT respectfully to CKB depends on current block header, which cannot be accessed in the current transaction, due to on-chain determinism. So core deposits and withdrawals must have at least two txs to be able to access the header of the first tx. Additionally, iCKB deposits are of fixed size.

For example also @xxuejie proposed simplified/alternative versions of iCKB to go around this issue, but they were not improvements over iCKB. Feel free to familiarize with iCKB journey into CoBuild.

it's used to push out the iCKB token to some potential outside iCKB buyers

I understand that some meaning may be lost in the translation, but I really dislike this phrase:

• Nothing is sold (the Fulfillment Bot is helping user in converting their CKB into iCKB xUDT and back, the exchange rate depends only on the header, no free market here)
• Nobody is pushing anything on anyone (The user create a conversion request and the bot fulfills it by converting his own capital as necessary and matching the conversion request)

❌❌❌ Please, refrain from using buy, sell and other market related terms. ❌❌❌

On the other side, you can express a similar meaning with the following:

There is no way to directly match iCKB Deposits and iCKB xUDT for all conversion sizes. Limit Orders are used as an alternative interface for conversions that are too small or big to be handled directly by the iCKB Script.

and the Limit Order cell is really necessary binding in the withdrawal phase?

Not really. Say you have 100k iCKB xUDT and there is a deposit of exactly 100k iCKB xUDT, then you can use your iCKB xUDT to withdraw directly from it, no LO needed.

Side Note: I've never seen a deposit of exactly 100k iCKB, always 99999.99999... iCKB due to the delay time between deposit tx creation and inclusion. Also they all are few satoshis different from each other.

for example, I have 150k iCKB, so I just withdraw part of them and leave 50k iCKB to withdraw next time, but [...] I can buy enough iCKB from [...] Limit Order, and then withdraw them out.

Yup yup, this 100% is correct!! :+1: If the missing deposit percentage is lower than 50%, the the user could pay less fees. In the past I also evaluated to integrate this in the DApp, then again I also considered that:

1. All deposits are slightly different from each other. (For example, let's say you convert an amount CKB to iCKB xUDT to be able to withdraw from a particular deposit, but in the meantime that deposit is already consumed by someone else, and all other deposits are slightly bigger or smaller)
2. Not all users have the excess of capital needed to be able to afford this trick.
3. It's not a solution in itself as you still have to convert those CKB to iCKB xUDT somewhere.
4. The bot has been created exactly to address this kind of needs.

only 100k [iCKB xUDT] of them close to the maturity

Not sure I'm interpreting this correctly, could you rephrase?

The maturity concept does not really apply directly to the iCKB xUDT. For example, let's say you have 100k iCKB xUDT, you can withdraw from a deposit whose maturity is in one hour, one day, one week... The Withdrawal Request can happen right away in any of these situations, so iCKB xUDT can be converted right away into a Withdrawal Request cell. On the other side, the wait time for the final Withdrawal is gonna be shorter or longer depending on the chosen deposit maturity date.

Love & Peace, Phroi

[ashuralyk]

@phroi giant reply, much effort in it, so much thank you.

I'm considering the necessity of Limit Order for helping match of iCKB token and deposits, because it acts like an Order Book exchange system but not really that way, it exists for the complete of iCKB protocol, but brings so much complexity.

in my immature opinion, if I'm the writer of iCKB protocol, maybe I'll prefer to guide users to commit their Withdrawal Request, which contains the quantity of the iCKB token, and then, I have an off-chain aggregator to collect all of these request cells and match them with iCKB deposits, besides, request cells are self-divisible for the partially match.

have you thought about this process while designing iCKB protocol?

[phroi]

I'll prefer to guide users to commit their Withdrawal Request, which contains the quantity of the iCKB token, and then, I have an off-chain aggregator to collect all of these request cells and match them with iCKB deposits, besides, request cells are self-divisible for the partially match.

have you thought about this process while designing iCKB protocol?

Indeed @xxuejie proposed this very idea and we discussed about it, please familiarize with iCKB journey into CoBuild.

This idea issues are:

• iCKB deposits and withdrawals are two step due to the need of accessing Block Header, this complicates quite a bit carrying on the user intention.
• Different deposits sizes have different conversion rates to iCKB (this prevents a form of attack, see standard deposit), aggregation of deposits is risky as the aggregator could choose to incur the 10% penalty on the exceeding size.
• The same deposit has different conversion rates to iCKB when made at different times.
• NervosDAO txs have a limit of 64 output cells.
• No commonly agreed OTX.
• Necessity to run an off-chain aggregator which receives the OTX (What happens if the aggregator is offline? Is it centralized? Who can run the aggregator?)
• Necessity to put guards into the OTX lock to make sure the aggregator does not misbehave, but also without being able to access the current block header, needed to check the validity of CKB / iCKB xUTD conversion rate...

As far as I can tell, Fulfillment Bot is easy and safe (banally once the LO implementation is safe the bot cannot misbehave as user intention is detailed 100% in the LO), Fulfillmet Bot takes the risk for creating sub-optimal txs.

Love & Peace, Phroi

[phroi]

@ashuralyk you may want to design an off-chain aggregator to avoid LO, let me know if you need help!! :hugs:

[ashuralyk]

@ashuralyk you may want to design an off-chain aggregator to avoid LO, let me know if you need help!! 🤗

no really, I just want to discuss different considerations for opening my mind, I guess you have put much thoughts in it, so LO might be a bit more reasonable for now.