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.
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.
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).
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.
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.
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?
No, there’s no need to ever mention the word “Dexter” or “Quipuswap” or “Uniswap” or “Pangolin megashushi flip” or who knows. Just call it a constant product smart-contract and end this textbook bikeshedding.
Yes, and you’re wrong. In fact you’re making the (incorrect) argument that people who want to try and ban this type of technology are trying to make. An unbranded piece of code that computes (A + da)(B - db) = A B is just that, an unbranded piece of code, no matter how much the cryptospace wants to cosplay dapps as enterprises.
Don’t take offense but I really don’t think you understand how decentralized exchange with constant product smart-contract works. I think this conversation will be a lot more productive if you take some time to familiarize yourself with the concept.
Pretty sure you should say “I think differently” instead of “You’re wrong” when dapps on the network with the biggest network effect among developers and 50x mcap raise millions for these unbranded pieces of code
No offense taken, i’m sure I know how the concept but as I said earlier I see every dex as a separated product with a separated liquidity pool, different incentives to attract LP’s etc
“Can we make a dex agnostic pool with every dex arbing it?”
I wasn’t asking about the possibility.
You’re wrong. These teams raise money either because they take a cut, spread the cut over some token, or convince fools that somehow having a token that’s vaguely related to their project will create some economic link between the two.
Dexter is essentially a Uniswap clone, do you think somehow Dexter contracts helps the UNI token? Do you think it does anything for Hayden Adams? No. Well copying code from Dexter (Or Uniswap, or Quipuswap, or Penguin Megaswap 3.0 With Tempura Flakes™) and using it for its intended function doesn’t somehow magically translate into economic benefits for the developers of these contracts. This is magical thinking.
When you (or steve) first suggested the idea to use Dexter’s contract, I was under the impression you suggested to use the exact dexter’s tzbtc contract, not just a fork of their code which is unrelated to any dex. That’s it. And I stand corrected. Not about product/piece of code thing though
Saying something like dexter-like or fork would help
I would like to retract my arguments; I was under the impression this will be “on” Dexter as opposed to originating another contract using Dexter code to be used by anyone.
Only consideration now is security since this will be the first lucrative target for Tezos DeFi.
Thanks for the response. The big takeaway for me is that Bakers themselves could automate arbitrage and include their transaction as the first in every block they produce to capture that gain for themselves. Not sure how frequent this could happen for small bakers though as they don’t get many blocks. But if someone were to be active in a DeFi market on Tezos, it would be beneficial to them to be a baker so they can guarantee themselves inclusion in a block.
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!
Sorry, I don’t follow. How are the two metrics comparable?
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.
Personally, I think 10% of the existing block reward is much too large. An additional 4,200,000 XTZ per year just seems very drastic. 5% or 2,100,000 XTZ is more palatable, I guess, but whatever the case may be I’m more likely to lean conservatively on any sizable increase to coin emission if its coming on top of current block rewards. Obviously a 10% increase over current block rewards looks small relative to supply outstanding, but it adds up.
A supply and demand balance needs to be kept in regards to bid on XTZ otherwise the currency could depreciate. There needs to be a buyer, or holder, for each new unit of XTZ.
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.
Makes sense if you assume that the delegate will have this decrease in block rewards pushed onto them as a cost, which it may. So, good point.
Not quite sure what you mean.
That’s because it was an incomplete thought lol. I meant to say that even though there would be additional XTZ entering the market, the other half of the trading pair used to buy that XTZ would stay within the Tezos DeFi ecosystem, which I think is a good thing.
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.
Agreed that its what we have for the time being so it’ll do for now. Really looking forward to Checker’s release; hope its going well. Maybe the liquidity could be ported from the XTZ/tzBTC pair towards the “checker-like robocoin” pair when the time comes. The custodialized nature of wrapped coins feels like an attack surface if they’re not redeemable.
I definitely think it would be a plus to have a stable-ish token derived from the base currency as the protocol supported pair. Its censorship resistant that way.
It’s a point of reference. People who wouldn’t bat an eye at spending 0.25% twice by transacting their entire balance with a dex shouldn’t be more bothered by 0.5% dilution. Of course you can be bothered by both, but people sometimes treat the latter differently. The fact that you’re quoting absolute number of tez makes me think you might.
Another way to put it into context is that over the past two years or so, the average daily standard deviation of the purchasing power of tez has been roughly … 0.5%. You’re talking about a yearly rate that doesn’t even raise above the noise of a single day.
But for 10% of the block reward, 0.5% dilution is an upper bound. The real dilution is actually the cost born by the LP (the IL) minus the part which is recaptured by the bakers, which can be the bulk of it.
