Currently we are using tickets to implement some of the token and token-like entities in checker. These are:
Kits
Liquidity tokens from CFMM
Liquidation auction bids
Delegation auction bids
Burrow permissions
We have decided to provide a FA2 interface instead. However, we can simplify some of the ones above so that they neither require tickets nor FA2. The end result should look like:
Kits: FA2
Liquidity tokens: FA2
Liquidation auction bids: Should have an address-based scheme.
Delegation auction bids: Will be removed with #82.
Burrow permissions: Should have an address-based scheme.
We should have a big_map from address to kit, the value being the amount they can claim back. Every time a new bid is made, the old bid moves to the
map. The given address can then withdraw their kit. So, only losing bids are stored in the map.
If they are the winner of an auction, they will need to pass us an avl_ptr, then we can check if that is: a) a completed auction. and b) won by the sender.
Burrow permissions:
There are two possible ways to implement this.
Instead of having a permission token, every burrow will contain a set of allowed addresses per permission type.
Alternatively, there can be a single "owner" address of the burrow, that can be changed. If the owner requires a finer grained permission scheme, they can create a contract to act as a proxy for permissions.
Suggested roadmap:
This can be easily split into three parts that can be done indepdendently:
Replacing the liquidation auction bids
Replacing the burrow permissions
Implementing the kit and liquidity tokens FA2 interface
Currently we are using tickets to implement some of the token and token-like entities in checker. These are:
We have decided to provide a FA2 interface instead. However, we can simplify some of the ones above so that they neither require tickets nor FA2. The end result should look like:
Here are the details:
Kits and liquidity tokens:
They will have a standard FA2 based interface: https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-12/implementing-fa2.md#multiple-fungible-tokens
Liquidation auction bids.
We should have a big_map from
address
tokit
, the value being the amount they can claim back. Every time a new bid is made, the old bid moves to the map. The given address can then withdraw their kit. So, only losing bids are stored in the map.If they are the winner of an auction, they will need to pass us an
avl_ptr
, then we can check if that is: a) a completed auction. and b) won by the sender.Burrow permissions:
There are two possible ways to implement this.
Suggested roadmap:
This can be easily split into three parts that can be done indepdendently: