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

There’s a demo on edo2net for anyone interested in playing with it. It’s a bit rough around the edges, the point being to have something simpler than the command line to try it out.


If you have suggestions Issues · murbard/ctez · GitHub


Where can I find more information on how this works? Can someone explain the drift formula in more detail?
target[t+dt] = target[t] exp[drift[t] * dt]

1 Like

Im trying to play around with this on Florencenet… I’m able to create an oven but failed to mint ctez. Note I dont know how it chose florencenet, but the oven is here KT19n2kg..phfhWC on florencenet.tzkt.io

What prevents me from capturing all staking rights?

Guys, I don’t know where to ask this question, but I created an oven a couple of days ago with 16k XTZ. I added another 12k XTZ. I delegated to my own personal baker. I minted around 99% of the XTZ as cTEZ and bought PLENTY and added to Farms, staked some xPLENTY, etc… Today I just opened ctez.app and around 21000XTZ are gone from my oven. Where did the XTZ go? What the fuck did just happen there?

This is the smart contract of the oven TzStats - Tezos Block Explorer by Blockwatch

Hi, your oven’s been liquidated Operation oo4H47..J29K on tzkt.io

1 Like

CTEZ = XTZ - vote rights

more precisely, ctez = xtz - delegation rights + expected delegation rewards, compounded

Although at the moment, and for probably no particularly good reason, there’s much more demand for minting ctez than for holding ctez, so ctez holders get about twice the delegation rewards

Could not the voting rights be returned ( in a way ) via some kind of DAO hosting the ctez oven. Where the DAO voted according to the wishes of a predefined quorum of it’s ctez holders.

The whole point of ctez is to avoid the governance mess associated with delegation of pooled tez. The voting rights don’t disappear, ctez ovens are delegated.


From : ctez

Q1 : It is said : “By adding liquidity you’ll earn 0.05% of all trades on this pair proportional to your share of the pool.”
How can I get this reward ?
Is it a global reward of the pool ? But when i convert back the LQ tokens to XTZ and CTez, is it including the reward too or not ? How can I see the formula of it to verify it ?

Q2 : When I get some LQ tokens from the Liquidity pool, what happens to my XTZ on it and its delegation ? Who get my delegation rewards out of it ? As XTZ are deflationist, it means that user is losing some inflation value here. But on the other way, Ctez are stable and the XTZ/CTEZ pair is growing on the opposite way, right ?

hi @murbard,

I was wondering, if there is the risk of short term, price/oracle manipulation. (not unlike the mangomarkets “hack”)

For example, is it possible to take advantage of the low liquidity in the tez/ctez pool in order to inflate the ctez value → mint ctez for free (or very very cheap) → drain different ctez AMM Pools.