Is it possible to have rebase token on Nervos CKB without the support of account model(e.g. Polyjuice)?

English
,
1

Hi all,
In recent,rebase token is so hot since this summer .So far ,Basis Cash（BAC、BAS) , Empty Set Dollar(ESD),Base Protocol (Base),Yam,Based ,Debase,RMPL,and the classic one AMPL.
Though such kind of topic makes lots of noise, even the price performances of some projects are very perky.
However, that’s not my interest to anticipate how such projects will be. Instead, I am into talking about that is it possible to have a rebase token to play some game on Nervos?

We know Nervos choose to adopt the UTXO model and cell have evolved from UTXO with powerful CKB-VM.

But,but but …
Rebase supply means that we could modify the amount of token from every holder’s hand automatically. For example,today Donald have 1000 $Rebase token,and tmr there may be only 500 or even possibly be 1500 $Rebase token.
It seems easy for Rebase token supplier to change the amount and supply on account model.
Anything lock script or type script could accomplish here?
And one more thing is that if we could take the right(or control,ownership) from cell owner(Seems that regulation cell could do obiviously), how to make the rebase supply mechanism more beautiful than sending tx from the cell of every token holder respectively?

will paste some link of rebase token case here
AMPL:https://www.ampleforth.org/
Debase :https://debaseonomics.io/
ESD: https://emptyset.finance/
Base : baseprotocol.org
Based :skull_and_crossbones:()
Basis cash : basis.cash
Yam( :skull_and_crossbones: may revive)

1 Like
2

Hint: design a token in terms of relative percentage instead of absolute amount.

2 Likes
3

Thanks for the hint.
What if the total supply change beyond the rebase supply?
E.g. Today we could earn token with the yield farming like YAM,BAC and at the same time rebase supply happen constantly. How to address it ? My percentage keep change when others get the token from mining.

1 Like
4

The trick is lazy evaluation. Consider the data held in your cell as “previous balance”. When events such as total supply update happens, the new total supply (and other necessary information) is stored in a separate cell, and your token cell is left untouched. When you want to spend the tokens, you construct a transaction with both your cell and the event cell as inputs/deps. In transaction verification, the “current balance” can be calculated on the fly by applying the adjustment formula to “previous balance” and latest total supply (along with other information), then the “current balance” can be used in subsequent evaluation. All these can be hidden from users, you will still see an “automatic adjusted balance” on application UI because it can calculate the “current balance” anytime locally.

Or you could just use polyjuice :slight_smile:

2 Likes
5

Perfect, thanks for your insight.
Help me to rethink a lot, especially about user experience.
It’s right my concern. All the workflow could be wrapped outside the user’s eyes.

In recent ,it seems that Basis.cash is really something.
The BAC stablecoin‘s price controlled elaborately by the BAS(like stock of a country ) & BAB (Bond).
Though still not sure whether it could be sustainable or not,it is remarkable when we want to make our stablecoin decentralized and raise the higher rate of capital circulation than collateral stablecoin like Dai.

6

I have a question, how to solve the problem of updating the state of global cell that stores the real-time total supply in Layer1 when multiple users initiate transactions at the same time?

7

There’re some common patterns for shared state problem, which one is best depends on your concrete situation. If it’s demo or small project I think some client side auto-retry mechanism might be enough. Otherwise a sequencer role can be introduced. Users send (open-)transactions to sequencer, and sequencer orders user requests and send the aggregated transaction on CKB. Godwoken would be the 3rd option (it’s actually a pre-built permissionless sequencer solution).

1 Like
8

Thx! It seems that this situation will be better solved only when we move up to layer 1.x-2. So will there be a problem the attacker keeps updating the shared state cell and it becomes unavailable to the users?Increasing the cost of updating the shared state seems to be one solution.

9

If the shared state cell can be updated by anyone, you can deploy some weak defenses which is enough in certain scenarios:

  1. The shared state cell could include some guarding conditions to prevent no-op updates initiated by adversaries.
  2. To monopolize the updates of the shared state, the attacker needs to continuously outbid all other rational/altruistic participants in such a permissionless system. It’s possible but there’s a cost.

If 1 & 2 is not enough, then you should consider using a more sophisticated entrance mechanism, e.g. a sequencer needs to stake before he/she can update the shared state, and he/she will be ousted by governance or challenge if found misconducting.

1 Like