tezos-checker / ctez

ctez contract and frontend

ctez

Ctez contract and frontend

IMPORTANT

The code within is currently unverified, unaudited, and untested. You are absolutely mad if you try to use it for anything serious.

Introduction

The following describes a simplified version of Checker in the special case of tez collateralized by tez. Since 99% of the complexity of Checker comes from handling potentially faulty oracles and liquidation auctions, the resulting system is quite simple. There is no governance involved, the system is completely mechanical and straightforward.

Target factor

The target factor represents the number of tez that a ctez should be pegged to. It starts out at 1.0, but changes over time. Typically given the current state of baking on the Tezos chain, this target factor might be around 1.05 or 1.06 after a year representing the accrual of more tez through baking. The target evolves over time based on its drift.

Drift

The drift is a system-wide parameter which varies over time. The relationship between the target and the drift is as follows:

target[t+dt] = target[t] exp[drift[t] * dt]

Note that given realistic values of drift and dt, in general target[t+dt] = target[t] * (1 + drift[t] * dt) is an excellent approximation and sufficient for our purposes.

Ovens

An oven is a smart contract following a certain pattern and controlled by a single user. It lets them place tez in it, pick any delegate they want, and mint ctez.

Liquidation

If a vault has less tez in collateral than the number of outstanding ctez outstanding times the target factor, times 1.0667 (16/15th, as a safety buffer), then anyone can grab the collateral in that vault (or a fraction thereof) by sending to it the outstanding ctez (or a fraction thereof) which is burned.

CFMM

A constant product market making contract (similar to uniswap) allows people to exchange tez for ctez. Once per block, it pushes the implicit rate of ctez in tez to the ctez contract. Ideally, this rate is the target factor, but this informs us of any deviation. There is no baker for that contract.

Each time the CFMM pushes its rate to the ctez contract, the drift, and the target factor for ctez, are adjusted.

If the price of ctez implied by the CFMM is below the target, the drift is raised by max(1024 * (target / price - 1)^2, 1) * 2^(-48) times the number of seconds since the last adjustment. If it is below, it is lowered by that amount. This corresponds roughly to a maximum adjustment of the annualized drift of one percentage point for every fractional day since the last adjustment. The adjustment saturates when the discrepancy exceeds one 32ndth. Note that, by a small miracle, ln(1.01) / year / day ~ 1.027 * 2^(-48) / second^2 which we use to simplify the computation in the implementation.

Rationale

If the price of ctez remains below its target, the drift will keep increasing and at some point, under a quadratically compounding rate vaults are forced into liquidation which may cause ctez to be bid up to claim the tez in the vaults.

If the price of ctez remains above its target, the drift will keep decreasing which might make it attractive to mint and sell ctez while collecting baking rewards.

The drift is a mechanism that automatically discovers a competitive rate at which one might delegate.

Why it's useful

ctez can be used directly in smart-contracts that would normally pool tez together without the thorny question of "who's baking".Given that there's almost no real movement in this pair, it doesn't need a whole lot of liquidity to function effectively, just a tad enough that the rate read from the contract isn't too noisy, hence the lack of baking shouldn't be a huge hindrance.

ctez's Issues

pairing with kukai should bring up kukai's edo2net wallet

which is at https://edonet.kukai.app/

Make node URL configurable

Maybe a settings screen accessible through the hamburger? Though if there's only a single setting it may be overkill.

"Modify depositors" component

"Modify depositors" should use the same component as the one used for oven creation

Enumerate ovens

In order to display a user's oven, assume that they were minted sequentially and probe the bigmap for (tz1...,0) (tz1..., 1) (tz1..., 2) etc.

However, this could miss some ovens. To deal with this, add a button "track oven" which lets a user enter the address of an oven and adds it as a card on the oven page. Visually distinguish it from the others if the key that's logged in isn't its owner, and disable actions except for deposit and liquidate.

Do not default mint to maximum value

Field for mint should default to 0, not the maximum value.

In fact, it wouldn't hurt if the UI prevented you from minting so much that you are less than a month away from liquidation at current drift levels.

not able to burn or swap ctez on https://ctez.app/ today with Temple wallet

Temple Beacon gives an error : Aborted
The action was aborted by the user.

If I swap on Quipuswap it works well

Also the liquidate button gives same error

Show lqt balance under the cat menu

total number of lqt and fraction of the pool it represents

[FE]: Edit Depositors Component

For modifiying depositors, the screen should give you either

• a list of who is currently allowed
• or a message saying it's anyone
  and then
• if it's everyone, you have a button to "use a whitelist" instead
• if it's a list or allowed people, you have a (+) button to add to the list, and a delete button next to each entry in the list, or a button that says "allow anyone to deposit"

in cfmm when error messages refer to cash, replace with "tez" when displaying the error

fields set at 0 require to delete the 0 to enter a value

A tester reports:

"When you go to deposit, withdraw etc there is already the number 0 in the field and you have to delete it before you type your input, it's a small thing but it can get annoying when you forget "

Invalid address value for "Modify Depositor(s)" causes unhandled JS error

Submitting a value like "fubar" for the Address field for the Modify Depositor(s) action causes an error reported only in the browser console. This is in Firefox on MacOS.

Warning: An unhandled error was caught from submitForm() TypeError: a.t0.data is undefined
    a EditDepositor.tsx:84
    l runtime.js:63
    _invoke runtime.js:293
    I runtime.js:118
    Babel 6
    o EditDepositor.tsx:68
    X Formik.tsx:851
    cr Formik.tsx:1202
    V Formik.tsx:758
    promise callback*rr/V< Formik.tsx:733
    cr Formik.tsx:1202
    J Formik.tsx:825
    cr Formik.tsx:1202
    React 11
    unstable_runWithPriority scheduler.production.min.js:18
    React 19
    787 index.tsx:10
    a (index):1
    t (index):1
    r (index):1
    <anonymous> main.09ac684b.chunk.js:1

Info display

On all pages, the following information should be displayed (not necessarily all in one place, the account specific information might make sense when clicking on the cat in the upper right, the rest might make sense as part of a header)

• current target: target / 2^48
• current price implied by the CFMM: cash_pool / token_pool
• premium over target in %: (price / target - 1)
• current annual drift in %: (1 + drift / 2^48)^(365.25 * 24 * 3600) - 1
• annual drift over the past week in %: (target_now / (target_7_days_ago))^52.1786 - 1
• tez in my account (the one linked through beacon)
• ctez in my account (the one linked through beacon)

On the oven page:

• total tez in ovens
• total ctez outstanding

On each oven:

• how many ctez can be minted in that oven
• warning sign when it is one month away from being liquidated: (assume the target grows at the current drift for a month, and if that would liquidate the account, mark the oven in red or something)

On the cfmm page

• total liquidity in the cfmm (expressed in tez, just double the cash_pool value)

When using the CFMM

• instead of displaying fields like min_bought_tokens etc, express as max_slippage. That means, compute the limits based on the current values of cash_pool and token_pool, then add max_slippage % to that to determine the parameter to pass to the contract
• when adding liquidity, instead of max_ctez, express it as slippage as well, instead of min_lqt express it
  as a min % of the pool that will be owned : min_lqt / (total_lqt + min_lqt)

---

Historical graphs for target, cfmm price, premium, drift (with smoothing) would all be very neat but they require a middleware and aren't as important as the above.