Add a Toggle vote wether to add/change the Liquidity Baking asset or not

Philosophy and Economics
1

We have the Liquidity baking toggle vote
grafik

Now that USDT is on Tezos and a discussion about adding USDT to liquidity baking happens here or in other social media chats - what about giving this power to the bakers directly? And not via proposal.

A baker can inject a proposal to change/add USDT to liquidity baking simply like the escape hatch toggle vote is working. Other bakers can vote yes/no on that and if the treshold is met for example 2/3 then the asset gets added/replaced etc. I say 2/3 so there does not happen a change every month, for that we need a big majority.

You can add a timeout for such votes that if it does not meet the treshold in a timespan of 30 days it gets declined and votes reset. Then a baker could inject the same vote again if he would like. The timeout idea because to not have a ton of votes that are “pending” after some months.

I see this as a really nice solution to decide about liquidity baking pairs or even the sunset etc.
What do you guys think about that?

2 Likes
2

Now that USDT is on Tezos and a discussion about adding USDT to liquidity baking happens here or in other social media chats - what about giving this power to the bakers directly? And not via proposal.

Note that implementing this mechanism, would entail indeed implementing it in a protocol proposal… but I see your point.

From an implementation perspective, a first concern is that the way in which liquidity baking and its toggle signaling mechanism are currently implemented in the protocol was not intended to be generalized like this, and it is mostly a stand-alone feature. Having multiple such toggle votes will hinder maintenance and make harder to pay technical debt in the protocol implementation.

Maybe this sort of ballots could better be implemented as a new “voting” operations. After all, they are intended to be issued by delegates (bakers). But in that case, more careful thought can be given to, as you mentioned, setting timeouts or other intricacies of the semantics.

For example: in a more general setting, you don’t want to be spammed with, say, 20 simultaneous toggle proposals, all or most of them unlikely to reach the threshold, and which take (free) time to process, making block production (even if marginally) slower.

Then, should it be required to lock bonds as a requisite to propose such changes? Should they be returned only if they pass a minimal quorum?

Also, what should be the semantics regarding two competing toggle switches? Is it allowed? can they have different thresholds?

Anyway, I went through a rabbit hole :slight_smile:

My point would be that implementing, reviewing, and testing such a signaling mechanism might be worth the time and effort if (i) there is significant interest in changing the LBT pair and (ii) there is an interest in changing that pair relatively often.

As a first step to gauge such interest, having a protocol upgrade proposal which changes the LBT pair (as it has been done before) is in my opinion a significantly leaner choice.

2 Likes
3

From an implementation perspective, a first concern is that the way in which liquidity baking and its toggle signaling mechanism are currently implemented in the protocol was not intended to be generalized like this, and it is mostly a stand-alone feature. Having multiple such toggle votes will hinder maintenance and make harder to pay technical debt in the protocol implementation.

Yes definitely valid points and I lack the technical knowledge to make a correct assesment.

Maybe this sort of ballots could better be implemented as a new “voting” operations. After all, they are intended to be issued by delegates (bakers). But in that case, more careful thought can be given to, as you mentioned, setting timeouts or other intricacies of the semantics.

This sounds even a better solution. Of course more consideration is needed, I just gave some quick examples to that idea. To prevent spamming a requirement to lock tez for example. Kolibiri DAO as example requires the Escrow Amount and that is the amount of kDAO that one must offer to lock before submitting a proposal. If the vote does not hit a minimum threshold (minYayVotesPercentForEscrowReturn), the kDAO is given to the community fund and not returned.

The current escrowAmount is 1000 kDAO.

Maybe @keefertaylor can add some thoughts to this as he is behind Kolibri.

As a first step to gauge such interest, having a protocol upgrade proposal which changes the LBT pair (as it has been done before ) is in my opinion a significantly leaner choice.

Yes but the thing is someone needs to make a proposal and inject it and until now only @KevinMehrabi did that for usdtz. People were actively discussing in all socials and still do. The thing is noone wants to compete with Nomadic Labs protocol upgrade proposals as they are very valuable and the time until activation we dont want to waste too. Also demanding that NL does propose more options as protocol upgrade is not right and fair. So overall leaving this “issue” at the “mercy” of someone in the community that wants to create and inject such a proposal is not great. This could be mitigated with sucha voting operation I think.

3 Likes
4

Some months passed since we got USDT on Tezos and I think its worth to explore the option to change the LB asset whether its via Protocol Upgrade or such a toggle vote. Does really noone see the benefits? There is such a huge brrier entry to get tzBTC besides getting pocketchange on tezos dexes.

1 Like
5

Is there really noone in favor of adding such a mechanic? A well thought process and implementation could be a benefit for Tezos in my opinion

6

I was thinking about this again about the last few days. In my opinion and from talks with others I will say that there is significant interest in changing the LBT pair. Maybe even not only in changing but adding a second pool to the existing one (and rewards get split between both or one gets more/less depending on the liquidity/volume). Agora is unfortunately not a great reflection of that, we all know that. But this does not mean to leave it as it is.

I am even willing to commit and add some funds to a pool to pay a developer or team as noone else is willing to, to implement this feature or first create the proposal for a LB change. Its not much but maybe others would also send in some funds.

But I see one major interest of conflict here:
We all have seen the announced Mumbai proposal, its so awesome and I have no doubt that the N proposal after that will be packed with awesome stuff too! So when it comes to the decision which proposal to support… be it either Mumbai/N etc with awesome features or proposal only “change LB to USDT”/“add voting mechanism” the latter will of course lose every time :frowning:

A separation into a single proposal is not viable and would of course not win. If there are two same proposals packed with all the updates and one with the LB change (or voting mechanism) and the another one without then its a “fair” voting process.