Virtual Baker TZIP

Request for comments on the virtual baker proposal. You can leave them below.


For the sake of completeness this post is related to Virtual Baker

Regarding the TZIP itself i think one should lift the ambiguity in the description whether the chosen model for this Virtual Baker is custodial or non-custodial with regard to the XTZ.

If non-custodial (as is the case for regular/real/physical bakers which are non-custodial) then we should refrain from adopting “deposit” in the naming of the api methods. It is quite ambiguous to speak of a “deposit” which usually implies physical transfer and counterparty risk if it is not what is happening under the hood. I am not good with names but i think things along the line of “delegate” or “lock” or “allocate” or w/e seem better instead.

If it is custodial then there’s a problem imho.

It is custodial. What do you see as the problem with that?

Non-custody of delegated funds is one of the core tenets of Tezos baking because it lifts the counterparty risk which exists in other protocols. Moving away from this model requires imho a specific discussion highlighting this AND explaining why it is necessary AND explaining why this is safe in this context.

In addition to this, physical transfers could have tax implications but that’s a separate “business” conversation. At any rate the document is at the very least incomplete in not discussing the custody aspect of the proposal i believe

I will update the draft clarifying this.

The tez is custodied by a contract that has no manager features so it’s not analogous to transferring funds to a baker and doesn’t have the same security or tax issues.

Maybe also worth pointing out that the intended users of the virtual baker are also autonomous custodians. If you want to use sapling transactions you have to transfer your tez to a contract and hold a sapling key corresponding to some theoretical “ztez” that only exists inside that contract.

I could see referring to virtual baker tickets as deposit slips having a negative connotation. If it issued tokens instead would you have the same reservations? Virtual baker tickets are basically just aggregated tokens.

So I read through the TZIP; thanks for putting ideas to paper. I’m just going to focus on the floating rate versus fixed rate decision.

With the Virtual Baker’s floating rate adding to overall XTZ inflation, the XTZ used within DeFi on Tezos would still be able to retain some of their ownership percentage of the network while being put to active use lending/borrowing etcetera. Block rewards for bakers and delegates may also get a boost as there are less XTZ actively being used for baking.

But, there will be increased inflation of XTZ, which could negatively effect the currency price. I lean conservative (Store of Value minimum necessary inflation) when it comes to any changes in monetary policy.

Is the Virtual Baker’s inflation set at the same rate of baking reward emission? By how much additional XTZ would the supply inflate yearly in a situation where say 25% of the total XTZ supply are utilizing the Virtual Baker?

Looking at the fixed-rate angle, this set-up retains the current predictable coin emission schedule. No real increase in inflation, and bakers may need to reduce fees in order to attract more XTZ delegations away from DeFi. Also, SoundMoney^TM.

However, decreasing baking rewards would make it harder for small bakers to remain competitive. Even though block rewards in Tezos are designed to be non-dilutive inflation, bakers still earn some XTZ over the 5% non-dilution threshold, and many people view XTZ block rewards as dividend earnings. There are also security and cloud computing related expenses. Bakers will have to “compete” against the virtual baker, reducing XTZ available for delegation, and reducing the amount of blocks they can bake (less block rewards). So there’s a possibility that bakers pack up and leave because there are better opportunities elsewhere. [Correct me if I’m wrong at any point here.]

Even though in my head I think reducing baking rewards and keeping the Virtual Baker’s minting equalized with current emission is the way to go to preserve the current monetary policy, adding the additional inflation may make it more economical for bakers to continue baking, while also not forcing XTZ used in DeFi to become diluted. It really all depends on just how much new XTZ will be minted on top of current baking rewards.

If you could provide some example estimates of how the bonding curve could work in practice to limit the additional inflation, that would be super helpful.

I think your description is accurate and touches on the key issues with this proposal.

This is where the bonding curve comes in. With 25% of supply in the virtual baker, inflation should increase by ~0.48%. However, at that point the virtual baking rewards might not be so attractive and we’d have to reconsider this solution. Having that much locked in DeFi is a problem we’d be happy to have.

You can expect the virtual baker balance to represent a certain percentage of stake just from arbitrage. So if delegation fees average 10% then with this curve one can expect 2.5% of supply to flow into the virtual baker even if there were no DeFi contracts using it. So as long as there’s at least that much locked in DeFi it’s not undercutting delegates.

Otoh, it’s hard to say at what point it’s no longer competitive. If you assume below 66% then it can handle 10% of the network and I think that’s a good target for Tezos DeFi over the next year.

So with between 2.5-10% of the network in the virtual baker you’d have total inflation increasing between ~0.14-0.40%. I don’t know how to estimate the increase in fees from the DeFi activity, but assume it’d be significant.

The current proposal uses a floating rate only because I think it’d be an easier sell at this point in time. I could easily see it switching to a fixed rate in the future.

I don’t know what you mean by this.

There would be less competition for blocks because the funds in the virtual baker are not actually baking. I’m not sure how to quantify this nor how it would affect delegation fees.

For comparison the examples above, with a fixed inflation rate of 6.1% baking rewards would be between 5.7-5.9% with 2.5-10% of total supply in the virtual baker. We could also use a fixed rate and raise it 0.4% to target baking rewards roughly equal to present with 10% supply in the virtual baker.

1 Like

Noob questions:

What hinders me to setup a smart-contract and use the Virtual Baker instead a “traditional delegation-service” ?

Or more radically, why shouldn’t we all use the virtual baker (100% reliable compared to delegation-services).

Isn’t this a threat to the network security?

I also become nervous at sentences like “a single “virtual baker” contract”.
I propose LeastAuthority for auditing this contract.

Nothing. People will probably do this initially, but the bonding curve means it will quickly pay less than delegation services. And if instead you put your tez in a DeFi contract that uses the virtual baker you’d capture virtual baking rewards plus liquidity fees.

The more people who use it, the less rewards it gets. If everyone uses it, no rewards. And again, if users are enticed to use it through DeFi contracts, that’s a good thing.

No. Stake remaining undelegated has no effect on network security. However, large contracts delegating to one baker is bad for security and the virtual baker provides an alternative to this.

It will be audited. It is also extremely short and simple in functionality so users familiar with Michelson can easily look it over to assure themselves.


Thx, the “bonding curve” was too complicated for me to understand but now i get it. Sounds like a reasonable and good idea; if 99.9999% secure :slight_smile:

Aside from potential (but important) tax considerations, non-dilutive inflation is neutral. If you print 10% more tokens and use that to increase everyone’s balance by 10%, no one is better off or worse off. Inflation in proof-of-work network is a direct cost, it is not comparable. You should give this a read.

(tax-wise, it might have a negative effect depending on treatment, although read this, psychologically-wise it may have a somewhat positive effect, see this.)

I’ve read your article about supply caps, and I largely agree with it. And I understand your positions in regards to convenience yield. And I agree that if everyone gets evenly inflated, everyone’s stake within the network remains the same relative to everyone else.

My main concern however is that each individual currency unit needs a buyer (or a long term committed holder) on the other end to maintain the strength of the currency. So, I agree that within a closed system that non-dilutive inflation is fine, but the system isn’t exactly closed when exposed to outside markets. And therefore I think that increases to inflation should be considered with caution.

Maybe you see it differently which is fine of course, just making conversation.

You’re mistaken, the existence of a market doesn’t invalidate the argument, it’s actually an integral part of the argument. Standard economic theory predicts that, all else equal, the propensity of people to sell what they receive from inflation should be balanced by the benefit of receiving it. This tells you that the “woohoo free money every three days” and “booohooo muh inflation” memes are, overall, equally mistaken in equal proportions :). They’re two side of the same coins which more of less cancel each other out.

I say more or less because of course reality is messier and there can be deviations from these models, which is what economists typically focus on because it’s a lot more interesting to study. These deviations can come from tax considerations, psychology, budget constraints under uncertainty, etc. There’s a whole field of study around this, but it focus on deviations from the baseline which is the neutrality of nominal effects.

If you don’t believe in the neutrality of nominal effects, you can easily design systems that exploit this belief and reach absurd conclusions so deviations, when they exist must be somewhat small.

1 Like

The “rationale” section is outstanding and super clear, well done.

I think the technical spec should be expanded and made a bit more precise. For example, it is said that x is the percentage of outstanding tez, but is that true? Or is it the percentage of outstanding rolls perhaps? A percentage implies fractions, how is (1-x)^4 computed exactly? In the rationals? With fixed-point precision? As a lookup table?

There should also be a spec as to whether the credits made to the contract will appear in the receipts, or be completely implicit like block rewards? This matters for block explorers which may make the assumption that a contract’s balance doesn’t change without transactions. Representing credits as dummy transactions from a dummy address might help.

I’ll update in a new version based on feedback.

Ah, yes. It’s outstanding rolls, or more precisely tez stored in rolls.

I also realized the language is a bit ambiguous about what y represents. At least what I think we want is for the virtual baker to be credited with a percentage of total rewards dependent on its stake. So if y is total rewards paid out between snapshot blocks then we want the virtual baker to be credited x^4 * y where x = virtual baker balance / (total rolls * tez in roll).

Currently the calculations are done in 16-bit fixed point.

It’s currently implicit. I didn’t realize this would be an issue for block explorers, but can easily change it to use transactions from a dummy address.

I’ve bumped the draft to version 2. Changes include:

  • Renamed @deposit entrypoint to @create. This is meant to reflect how, when used like this, tickets are no different from aggregated tokens.
  • More detailed calculations in the spec
  • It now inflates every block so we don’t have to account for rewards in storage.
  • Virtual baker rewards are now balance updates of type Misc in block metadata so they can be picked up by indexers.
  • Quorum is adjusted based on virtual baker share so it doesn’t affect voting.
1 Like