IMHO the elephant in the room is that providing liquidity to a volatile pair on a AMM Dex is a risky activity.
I don’t see how subsidising this is in the interest of the Tezos network as a whole, in the end we would be giving free money to informed and already rich market movers.
right now xtz btc pair is at its lowest, it means providing liquidity equals being rekt by IL.
and we don’t have a decent stablecoin yet.
too early to take drastic measures
So what? There is a risk, but there is also a risk of holding to xtz. The risk means that the fraction of delegated tez going into the pool may be less than 10%, but probably not much less. Uniswap pools at Ethereum did fare well.
Can’t buy any serious amount of xtz without moving the market a lot, which means it’s not even on some people’s radar. Why do you think Litecoin has any value?
Impermanent loss goes straight back into the baker’s pocket anyway because they choose content of blocks.
No, you can have long term trend and short term oscillation. Also you have crystal ball for the market? I don’t.
Maybe better with a stablecoin, but btc is very liquid, and correlated to xtz so volatility of pair is lower. Easy to change to stablecoin later anyway if there is stablecoin.
- ~ 0 change to baking annual %
- ++$100M of liquidity
- simple patch
- IL goes back to bakers
Only thing drastic is wanting to quibble over this 
Mixing existing economics of the protocol with the economics of an app on tezos sets a precedent for every app to change it in their favor.
The point is not to help “Dexter, the application”. Dexter is just code used for this, it could be code in the protocol, it doesn’t matter.
every project wants to get users, gain liquidity etc.
There is a lot of focus in this thread on Dexter specifically. I believe this is taking space away from the actual proposition, which is to make Tezos much more attractive by using its governance to provide liquidity to XTZ. This would set Tezos apart from other blockchains by banking on one of its comparative advantages.
If we are afraid of looking like we favor a Dex in particular, or if we are worried about safety issues, we can just code one in OCaml. I personally prefer just funding an existing contract, which is simpler, but I could go either way.
Dexter’s XTZ/TZBTC is just A pair on A Dex. Many pairs and many dex’es are to come on tezos. How do we decide which one to incentivize?
At first, a simple Uniswap with a useful pair as a working proof of concept sounds good. If this works as well as expected, we might want to structure this with a DAO, or an intermediary governance layer.
1 Like
By subsidizing with inflation not governance. Governance only decides whether it’s a good idea or not
Actually by taking a part of the inflation from bakers
The idea of picking THE pair contract sounds weird to me,
why make another dex then, when your competitor has an advantage on a protocol level
Once again we don’t have a stablecoin yet
xtz btc is at its lowest, it means the worst time to provide liquidity due to IL.
There might be no problem at all, let’s wait and the market decide
Lastly we have TF with the biggest xtz and btc bags and as a non profit they should not care that much about their xtz btc ratio
P.S. Uniswap has liquidity without any subsidy on a protocol level
Goal of Tezos is not to have people build dex, dex is just a tool. Also, there are many other pairs people might like.
So what? BTC is very liquid.
No, depends on how market moves at small scale + IL goes back to bakers anyway.
Let governance decide, this is a public good.
You can stop subsidy if they start doing it. No indication they ever will.
Ethereum is much bigger market cap and liquidity than Tezos. Do you want to win or not?
1 Like
For what it’s worth I think it’s a really good idea.
A few thoughts.
On the cost
The assumption that somehow this would end up being born by binance / coinbase seems a bit too rose-colored. Ultimately the consequence is bakers needing a slightly larger bond for baking. As bakers adjust the rate at which they purchase delegation power from delegators, the cost ends up being born by all tez holders. Even then, it sounds like an obvious trade-off to make. To avoid bakers having to reprice their agreements, I would suggest adding a small extra reward to the block as opposed to splitting the existing one.
On IL
The argument that IL ends up captured by bakers anyway and so is internalized is essentially correct, but bakers do have to actually go out of their way to capture it. It doesn’t seem that they bother to do so on Ethereum yet (though they capture the large tx fees of bots trying to grab the entire blockspace for themselves). Open-source software allowing bakers to do capture it would go a very long way.
On implementation
This is really straighforward to implement. It’s worth taking a second and triple look at the dexter code given the amounts potentially at play, but overall this is an easy task. It’s also a rather awesome demonstration of what Tezos governance can do.
3 Likes
And what of QuipuSwap? What about a DEX that doesn’t exist yet?
After all the careful planning, building and navigation to arbitrarily choose winners and losers like this seems foolish. The base layer shouldn’t be funding this or that. It either funds everything or nothing to remain neutral.
This parlor trick doesn’t win us anything except discontent from half of the community. I don’t want to win anything by compromising the whole base layer.
By the way I find the block subsidy an interesting idea but not executed like this toward a single DEX pair.
What about them? It’s irrelevant.
No one is “winning”, the subsidy isn’t going to CamelCase or to Madfish. The proposal just needs a piece of code in Michelson that computes (A + da)(B - db) = AB, it doesn’t matter in the least which repo you grab that piece of code from so long as it works. This proposal has nothing to do with funding “dexes”.
Would you say: “No, but if we take that piece of code that computes 2 + 2 = 4 it’s not fair to that other piece of code that computes 2 + 2 = 4”. Pieces of code don’t have feelings and they are fungible when they compute the same thing.
I don’t think you understand the proposal if you refer to it as a parlor trick. And no, it certainly doesn’t “compromise the base layer”. Maybe you see this as being about subsidizing a dapp, it is not.
Why would you need more than one?
I think the criticism that the proposal would go toward liquidity on Dexter and not to another DEX such as Quipuswap is a bit misplaced. The main goal would be to create liquidity where there isn’t much currently, and it can be done via on-chain governance. It isn’t about picking a winner. I would say its more about improving the ecosystem as a whole for a net-gain for the entire ecosystem.
It doesn’t prevent new DEX contracts from coming online and out-competing Dexter in any way. For instance, if Quipuswap launched, and it launched with liquidity mining and a governance token, that’s a method with which they can compete against Dexter, even though the Dexter contract may get a liquidity boost through a proposal. The dynamics would change if Dexter launches some sort of liquidity mining token, but as per the most recent Tez Talk about Dexter, that doesn’t seem to be in the cards currently.
On Ethereum there are many different Dexes which compete: Uniswap, Balancer, 1Inch, Airswap, etcetera and they all compete in different ways.
All in all I think a proposal like this would be a win as it would provide liquidity as a public good for the ecosystem without any one person/beneficiary to pull the LP out. The liquidity just kind of stays there.
Also, in the eventual event that DEX aggregators appear on Tezos, users will simply use an aggregation tool to access DEXes without care as to where their price comes from. So even if Dexter is an early leader, it won’t matter in the long run as liquidity fills on-chain in various places thanks to different incentives.
2 Likes
It’s a really neat idea and a magnificent illustration of what can be achieved by our governance mechanism.
We could discuss a few points:
- Should bakers vote in each block about the quantity they wish to be subsidized by the network: 0, 1, 2, 4 or 8 tez? (This would adjust dynamically the corresponding inflation if we ever care)
- Should bakers vote in each block about the contract to subsidize? (by default we subsidize the “current one” and switch to a new contract with a super majority of the last 100 expressed votes)
- We obviously need to carefully audit the corresponding contract (for costs and security) but, otherwise, we don’t really care who gets the reward (as long as the non XTZ part of the pair is liquid).
2 Likes
-
Allowing bakers to decide how much (if anything) to mint for the benefit of the pool is a neat idea and not too hard to implement, not sure many people would make use of it though.
-
In general, I like lightweight votes made by advertising in block headers, but that one requires a bit more integration work and it can get political as it opens it up to other contracts etc. You could also easily end up in a game of tug-of-war with no majority at all. I think keeping it dead simple for a first iteration would be better.
-
Yes, whichever piece of code ends up being used (whether it’s a piece of Michelson or built in the protocol) needs to be heavily audited / formally verified.
1 Like
I’d be interested in hearing more about the virtual baker implementation you incorporated just out of pure curiosity. I find the idea fascinating, so I’m looking forward to your post.
Is the virtual baker something that you’re planning to push onto main-net? I could see it being pretty useful for dapp developers looking to include baking mechanics but not looking to play around with choosing different bakers.
[Yes I’m aware this isn’t necessarily relevant to the Dexter Liquidity Mining topic at hand, but I love the idea of a virtual baker lol]
I don’t understand exactly how IL could be captured by bakers. My understanding was that IL was experienced by individuals providing liquidity between a pair, and then price diverging greatly between the paired assets. I’m using Uniswap LP token redemption as my frame of reference. Would you mind elaborating a bit?
Also, I agree it would be easier to add a small additional bonus to the block reward that would be allocated to the contract, but determining exactly what the % change would be, I think, is where it becomes difficult. For example, 0.01% of yearly emission would be (I think) 420,000 additional XTZ minted annually.
In any case, there would be additional XTZ entering the market (separate from current protocol rules) which isn’t necessarily a popular proposition. Obviously someone would have to buy the XTZ from the contract (w/ BTC, ETH, Checker, etcetera) and the base pair would be locked up within the contract as well, but I still think it may have negative repercussions on XTZ price. So for now I’m in favor of allocating a portion of the current block reward.
I also want to throw my hat in the ring here and say that I would much rather have the pair be some sort of algorithmic and on-chain native stablecoin rather than something that is custodialized like tzBTC or USDtz, etcetera.
In fact, preferably, it would be nice if this wasn’t just for Dexter or any particular “dex” but a way for individuals to swap XTZ for native-XTZ-backed stable on-chain as a one-off sort of useful contract.
And if its a continuous per block allocation to the contract sort of thing, I definitely think that the contract shouldn’t bake.
The main reason for the existence of IL is that there are spot markets which move much faster than the chain. As a result, when a new block comes, the marginal price offered by a uniswap contract is generally going to be different from the spot price available on centralized exchanges. If the spot market on centralized exchanges imply a price that’s lower than the one offered on uniswap, an arbitrageur might buy on the centralized exchange and sell to the uniswap contract. This keeps the uniswap contract in line with the market but, of course, the arbitrageur’s profit has to come from somewhere. So basically, at every block, people have an opportunity to capture an arbitrage between centralized exchanges and a uniswap contract.
Who can capitalize on this opportunity? In theory, everyone. Everyone can send a transaction and try to capture it. But of course, only one transaction will be the first one in the block and succeed in capturing the opportunity. So people might start paying larger and larger transaction fees to try and convince the block producer to include them. This can lead to very large fees and when you see large fees paid on Ethereum, a big part of the story is actually people competing for these arbitrages and the money being spent on hash power. It’s a bit comical to hail this as a mark of success but that’s another story.
However, this is a transient phenomenon. The endstate of these arbitrage opportunities isn’t people competing with very large fees, it’s simply block producers exercising them directly. The producer of a block can choose to include whatever transaction they see fit, in the order they see fit. As a result, they are the best positioned to capture any arbitrage left open by a uniswap contract and it can be largely automated. So even if there’s IL, the value ends up being captured back by bakers, either in the form of fees or in the form of arbitrage opportunities.
Now, not all IL is driven by this type of arbitrage. If a large baker decides to purchase a bigger bond for their operation, or if they want to sell their bond, they may have an impact and drive some IL’s that wouldn’t be captured by bakers. But that’s not what people were alluding to in the thread, they were mentioning the possibility of a trend following process driving IL, but that kind of thing is exactly the kind of thing that can be internalized by bakers.
420,000 additional tez minted annually would only be 0.05% of the supply, and 0.05% is a tiny number. Just the fee of just one call to a typical uniswap contract is 5 times larger than this!
It’s a tradeoff. IMO, for this proposal, anything under 10% of the existing total block reward (be it a part of it or in addition to) is probably a good idea, anything under 5% of the block reward is basically a no-brainer. Bitcoin marketing has trained people to focus on supply and emission without any sense of proportions or orders of magnitude.
From an economic standpoint, it’s actually makes no difference, aside from menu costs. Taking it as part of the block reward may require baker to pay delegate a smaller part of the block reward whereas doing it as an additional means they don’t have to change the fraction they pay. Net net, one is not more inflationary than the other.
Not quite sure what you mean.
Well a checker-like robocoin would be a good fit, wouldn’t it 
But it’s not there yet and tzBTC is a great choice for this.
Well yeah, the whole idea would break down if it did.
To be sure, the point of the block reward allocated to the pool is not to serve directly as part of the uniswap pool (though it does), it’s to attract LP to the pool.
1 Like
Yeah, my bad. There’s now a draft TZIP and thread here for comments. Different thing, but the code is easily adaptable for this idea and I’d be happy to do that.
It’s irrelevant in one way but very relevant in another way. We are choosing the brand/name of the most popular Tezos DEX LP, the Uniswap of Tezos so to speak.
The monetary subsidy is not going to CamlCase of Madfish but the name brand and caché is, as are the eyeballs and mouse clicks. We’re choosing one name over all other names and making it harder for the other names to compete.
I really don’t think changing the semantics here changes the meaning of the action. I mean to say this action undermines competition of other pieces of code with new names and new possible functionality. Choosing this specific piece of code without enabling this piece of code to alternate LPs somehow is anti-competitive. Sure you’ll say other DEXes can get magically funded and loaded with lots of liquidity and fund an amazing marketing campaign and have a way better interface but how likely is this going to be once we adjust the block reward in favor of 2+2=Dexter?
The number doesn’t matter. The ability to swap out the LP chosen by this code, allow the baker to choose or run through a list all via governance signaling all matter a lot.
This is a very interesting idea if we dress it up a little bit by involving our awesome governance features not just in the decision to set this code loose but also to adjust the variables within based on how things develop on layer 0.
You call it pieces of code, I call it businesses, teams and products 
i’d love to see tezos as the chain people come and build products on and make money off it
I agree with Primate, we pick dexter here and no one uses quipuswap at least for this pair except for arbs
the idea itself is great though, esp with a tezos native stablecoin (hey kUSD), because we’ll automatically subsidize people using Kolibri
Can we make a dex agnostic pool with every dex arbing it?
