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

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?

1 Like

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.

1 Like

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.

1 Like