Ctez: a synthetic tez backed by tez for better composability as an alternative to the virtual baker

This proposal 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.


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.


A vault 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.


If a vault has less tez in collateral than the number of outstanding ctez outstanding times the target factor, times 1.01 (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.


A constant product market making contract (similar to uniswap) allows people to exchange tez for ctez. It can also be queried to learn the implicit rate of ctez in tez. Ideally, this rate is the target factor, but this informs us of any deviation. There is no baker for that contract.

Each time the CPMM is called the drift, and the target factor for ctez, are adjusted.

If the price of ctez implied by the CPMM is below the target by over 1%, the drift is raised by one percentage point per fractional years per fractional days since the last adjustment. If the price of ctez is more than 1% above the target, the drift is lowered by one percentage point per fractional years per fractional day since the time of last adjustment.

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.

Why does it work?

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 causes 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 making it profitable 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”.


This is not very hard to build. If you’re interested in writing this smart-contract, hit me up and I’m happy to provide some guidance.


This is something which would be very cool. I am interested in writing the contract.


Cool, you can dm me here or ask in this thread directly if you want any help

There are three parts to this:

  1. the main contract, based on a FA2 or FA1.2 template
  2. a CPMM (which you can write or port from Dexter or Quipuswap)
  3. the vaults contract

The main contract is a factory for the vault contracts.

The CPMM calls the main contract at most once per block, upon the first transaction it receives in this block, and using the implied rate it had as of the last transaction before this block. You do this by storing a flag telling you whether or not you’ve been called in this block and the last rate for the current block.

All interaction with vaults happens through the main contract which keeps track of the state of every vault. You may be able to make some interactions happen directly between the owner and their vaults (e.g. changing the delegate) but start by routing everything through the main contract, and once you’re there, it’ll be easier to see what can be made into a direct interaction instead.

You’ll want to keep the math for the target in fixed point arithmetic.

In a liquidation scenario, you basically let anyone burn ctez any amount of ctez for 1.01 times the target factor times the amount of ctez in tez, up to the full balalance of the vault. You don’t let vaults issue ctez if they don’t have enough tez, etc.


Great. I will reach out.

So I ended up with this. Still untested, unaudited, unverified, and no frontend but, in principle, feature complete.


excellent! even though it may not be the intended purpose, i believe this will also function as a way for a vault holder to decide when delegation payments are distributed rather than being decided by when the baker pays out

I think the point is that there won’t really be delegation payments. The natural issuer of ctez is a baker.

1 Like