How are there no conflicts of interest if the TF literally owns part of the CO involved with tzBTC? That is the very definition of a conflict of interest.
1 Like
If TF participated in LB, they’d have to reduce their baking operation and move part of their btc to tzbtc. Isn’t that what everybody wants?
1 Like
Because TF has no material interest in tzBTC being used or not used? This would be on the order of maybe $10 for an organisation that owns on the order of $1B or $2B in assets.
No
2 Likes
That’s fair I don’t see a huge reason for TF to benefit but does the general public care about tzBTC?
I still think a stablecoin would be better suited for liquidity baking as it’s a de facto FIAT on-ramp.
tzBTC would be good too I just don’t see why stablecoins aren’t included.
I think the point has been made on both our sides. So you hear it from me:
**Oops, not enough enough people participated in the Tzip process, let’s inject a competing proposal and asset to poll bakers who may have missed this. **
Every proposal is opinionated, there’s no precedent here.
Sure. As stated above, I think achieving consensus on whether this is a good idea is useful, as opposed to springing to immediate action. I think yolo-injecting another proposal before reaching consensus is probably a net negative move that causes thrash and confusion.
I don’t think having monolithic tightly coupled proposals is a good idea - but that is a debate we as a community can have another day.
If you don’t like the proposal, make another one, you have more than enough technical know-how to do so.
I’ve asked some questions above about how to inject the proposal. My original post stated that I was happy to help put in the work to get this done.
You chose instead to present this as an ominous, power-consolidating, precedent-setting move by “the powers that be”.
I think my original post states this quite well and clearly lays out the concerns I have as well as a path to remediation. I think my posts here stand on their own and readers can reach their own conclusions - if your personal opinion is that I’m misrepresenting the situation, that is your right.
I do think the process around this proposal consolidates power away from bakers and sets a bad precedent. I’ve stated why extensively above so I won’t repeat here and I don’t think these are wrong opinions to have.
By creating this confrontational framing, you’ve engineered a no-win situation where the development teams involved in this either don’t inject new proposals and are thus insensitive to “the demands of the community” (even though comments on the choice of assets were requested for the past 5 months), or they do, in which case they give the appearance that they were up to something nefarious until you bravely called them up on it.
I don’t think that I’ve implied anyone is doing anything nefarious. I do think the easy win here is for additional protocols to get injected but I don’t think doing so admits any wrong doing or nefariousness on anyone’s part. Everyone here is human, humans sometimes make mistakes and sometimes people are working with different mental models / information.
8 Likes
One community member has produced a proposal that implements Granada, without liquidity baking:
I have read this code and I believe it to be correct and achieve the desired outcomes. I believe, to the best of my knowledge, that this is a legitimate proposal. I do not, however, know this person and I encourage the community to validate the code on their own, rather than blindly trusting my opinion.
It is now up to a baker if they would like to inject this protocol. It is my opinion that we should do this - but I’d like an implicit “second” by having another baker participate in injection.
I do still believe we should offer LB for an alternative asset. I’d be happy to help an interested party create this proposal (Otherwise, I may try to produce an asset). I’ve posted instructions for this above.
I am advocating options for this proposal, and decoupling of controversial features from common sense improvements. I am not advocating for a specific outcome by suggesting we inject these proposals - I’m only advocating that we give folks the choice.
If the two protocols described above are injected I think we’ve achieved the goal of decoupling and providing options and I feel that we are in a good place where the community of bakers can have a good faith discussion, debate and ultimately select the path forward.
7 Likes
It’s great to see the few opposing bakers finally understand LB and no longer have a knee jerk reaction. This feature is so powerful that I think will have a major positive impact on Tezos.
3 Likes
The point isn’t to bring liquidity to tzBTC, it’s tied to bitcoin so it already has deep liquidity. Its spread might be meh, but if you need volume you start tapping into the liquidity of the entire bitcoin market. Of course the same would be true of USDC for instance.
The point is to bring liquidity to tez, tzBTC is a tool to do that, and currently, there aren’t that many options. What do you think would work better and why?
5 Likes
Hi everyone.
I found the current topic quite interesting, and I believe many of the participants might lack some more core-dev-y point of view about what is going on. As such, I have written a little (~2000 words) about it. 
If you are interested in learning more about my point of view, or just want to improve the governance process of Tezos, you can come to this thread.
Cheers
13 Likes
Awesome points being raised by Keefer, particularly on not injecting tightly coupled proposals and allowing bakers more options to choose from when voting for proposals. However, I do not agree with changing the liquidity pair asset from tzBTC to an alternative pair at this last minute. This topic about liquidity baking with xtz/tzBTC has come up many times in different platforms that even only as a general user of Tezos, I have been aware about it for couple of months. If people had issues with tzBTC being used as the asset pair, this concern should have been raised and discussed a long time back when it was absolutely clear that tzBTC was the asset that was being worked on for liquidity baking.
I do not think it is on any xtz holders’ advantage to try and change the liquidity asset now after the proposal has already been injected. Why not let this experiment run for few months and perhaps try and change it to a different asset after six months if there is community consensus? Granada proposal was likely tested by many core dev teams and had gone through several reviews before it was injected. So, the suggestions that a third party inject a new proposal without liquidity baking (or with an alternative asset) after only reading or being aware about liquidity baking in the last few days seems like a hasty and an irrational move. Further, I would also worry about the security implications to Tezos from proposals being injected by people who are only now reviewing the code and trying to tweak it to make it more in line with the suggestions presented by Keefer. I sincerely hope that we as a community completely ignore this idea about moving to a different asset for liquidity baking at the moment, and continue with the Granada proposal as it is.
3 Likes
Thank you galfour for your insight. One of the brightest minds in the Tezos ecosystem.
7 Likes
Sounds like the subsidy, is going to propitiate some sort of crony capitalism, even if the minting fee is miniscule, it matters. I don’t like that.
1 Like
It seems Liquidity Baking will need to be set up 3 times. Once for tzBTC/XTZ, once for a stable-USD/XTZ, and once more for a stable-USD/tzBTC. That 3-point pyramid would allow for full arbitrage opportunities. The more channels for arbitrage the more volume and so the more fees will get burnt to offset this new temporary inflation.
3 Likes
I guess tzBTC is the best option at the moment.
What would it take to get USDT or USDC interested in using Tezos for issuance? They may be interested in Liquidity Baking on their stablecoins.
2 Likes
Time and use cases, so yes, it’s a thing that might make them integrate sooner.
6 Likes
I don’t think it’s a good idea to subsidize multiple pools. But what we could do is use a constant mean instead of constant product in order to have more than two assets in one pool.
5 Likes
It is my understanding that the alternative protocol presented earlier today was injected in hash oo1SPmMcEzhLK8q2tvzfyuXtGkBkqmqWWMkyNgWNQCiVgAFTB7b.
Importantly, at this time I do not have opinions on whether bakers should / should not vote for this proposal, though I am happy that options and alternatives are being presented.
I’ve written my understanding of the protocol and it’s implications here:
1 Like
As a small baker, I I’m concerned on this matter. These proposal is reducing Bakers rewards by 6%. It is a subsidy at baker’s expenses.
It makes sense to obtain back the whole 100% block rewards, the whole cake, to us bakers.
It may be difficult to subsidize a stable-USD/tzBTC pair so I like your idea better since triple MM are supposed to be more stable. However that type of smart contract does not yet exist on Tezos. Therefore it may take more time to develop your proposed smart contract, than it would to use the existing technology we have and point to another pool on the next protocol upgrade.
1 Like
This is false and has been addressed above. The subsidy is an additional component that doesn’t come from Bakers rewards.
