Deriving the price of kit in tez

[gkaracha]

When touching the parameters (in Checker.touch_with_index) we need the price of kit in tez (units: tez/kit). This we can get by multiplying

1. the price of kit in ctez (units: ctez/kit), as provided by Cfmm.cfmm_kit_in_ctez_in_prev_block, and
2. the price of ctez in tez (units: tez/ctez), as provided by the ctez contract.

When we changed the cfmm to use ctez instead of tez and removed the delegation auction we refrained from further complicating matters and assumed that the price of ctez in tez was exactly 1 (i.e., ctez ~ tez). I reckon it's time we switched to a more accurate calculation. I can see three possible ways to deal with (2) above:

1. Assume tez/ctez = 1 (current approach). Simple, since no calls to the ctez contract are required, but probably inaccurate.
2. Assume tez/ctez = 1.05 - 1.06 (that is, the somewhat expected target factor of ctez). Simple, since no calls to the ctez contract are required. Hopefully rather accurate, but probably too firm.
3. Ask the ctez contract what the current tez/ctez price is. This is clearly the most complicated but at the same time the most accurate option.

[gkaracha]

A possibly non-exhaustive list of things I expect us to have to change, should we decide to go with option (3) above:

• touch_with_index needs to emit an operation to ctez's %get_target to get the current tez/ctez target.
• Additional field last_ctez_target : Ligo.nat option is needed in CheckerTypes.checker. Initially it can be None and we could use 1.0 or 1.06; after that we are just one value behind (same story as with the last_price field).
• Additional entrypoint receive_ctez_target entrypoint is needed, to be passed as a callback to ctez's %get_target.
• The checker cli tool and the corresponding configuration file ($HOME/.config/.checker) should also store the address of ctez. Currently the ctez in the configuration file is a misnomer; it is actually ctez's FA1.2 contract. I expect we'll actually have to keep track of both now so we should probably change the name as well.

[dorranh]

I think that option (3) would also be required for #213 since it isn't necessarily true that an arbitrary token will have a price of exactly 1 ctez/some_token, right? That is unless we are able to parameterize the cfmm and burrow collateral using the same token.

[gkaracha]

Ah, yes, quite possibly. I wrote the above assuming that the cfmm will keep using ctez though, independently of the choice of collateral, which makes the problems orthogonal to each other. If we use the same FA2 token for both the cfmm and as collateral then the problems are not so independent anymore.

[gkaracha]

Note to self: this is currently blocked on https://github.com/tezos-checker/ctez/pull/30.

[gkaracha]

Roadmap: once tezos-checker/ctez#30 is merged we need to at least do the following on the Checker side:

• [ ] Extend external_contracts with the address of the ctez cfmm (cfmm_tez_ctez.mligo). Why another ctez address? The price entrypoint comes from ctez's cfmm subcontract, not it's FA1.2 subcontract whose address we currently store.
  • [ ] Add a new entrypoint %getCtezPrice (or something like it), to be passed to %getMarginalPrice. A callback should be able to update the price in Checker's storage.
  • [ ] Change touch to use the most recent ctez price, and emit an additional operation for updating the ctez price for the next touch.

We could probably start working on the infrastructure already, but I'm not sure yet if we should do that.

[gkaracha]

Though #280 did most of the work on addressing this issue, we still ignore the fraction we receive from the cfmm of ctez (see https://github.com/tezos-checker/checker/pull/280#discussion_r739295216). Let's leave #239 open until that FIXME is finally addressed.