 This is on batch bonding curves. It's about creating the X front runners. My name is Billy. A little about me. I'm a global installation engineer at Cosmos Network. I'm the founder and creator of the Globalist Network. I've also done work previously with Paragon Black and NOSIS. I'm the author of EID 1643, the Refundable Token. I'm the creator of NS Nifty, which was a hackathon project that inspired NS to make the main names of the NFTs. And of course the founder of Beemords, the majestic curation market for memes. Today I'll be talking about market makers from running and going over mitigation techniques that are following batch bonding curves. There are three different versions. I'm curious if people have opinions about what it's like to make the most sense. Some links and then we can open up any questions in our name again in some time. So, body curves are automated market makers. You might be familiar with these concepts in the context of prediction markets. A mechanism invented by Robin Hansen that's used for basically gambling on future events. Bancor, which uses a technique called the Dirt Ratio, or Unislaw, which uses the product created by Furin and Helen Blue from NOSIS and invented by Kevin Adams. Or the slow formula version of body curves, which is kind of bearded by Simon Daler. But all these market makers provide liquidity, which is a very important concept in any sort of token-based or asset-based system. Whenever you have some asset that you're trying to sell or buy and there's not a lot of other people out there trying to buy or sell it, you're going to have a lot of problems agreeing on a price of these with low liquidity. And so there's many situations in which you have low liquidity. There's just not a lot of buyers, not a lot of sellers. It's a very niche topic or something like that. And so you have designated parties who are willing to buy or sell at some predefined formula or agreement or system, and those are market makers. In a prediction market, you have this situation because the tokens that you're dealing with are attached to outcome events. This is the sort of gambling on future events, and often these are very illiquid markets because there's not a lot of participants, but there's not a lot of token circulation. So if, say, the prediction market is about the future headquarters of Amazon, and I think it's in New York, and you think it's in Chicago, I maybe think it could be in Chicago, but you're like sure of it, so we don't really necessarily agree on what I should sell my Chicago tokens to you for. So it might be nice to have something like a market maker who's willing to buy those back. The logarithmic scoring rule is the market maker used in prediction markets usually, and it's really nice because it's calculated in a way so that at the end of all of these sort of events, the tokens that did not occur, the prediction that did not occur, and there's just enough money inside the contract to pay off all the people who had the tokens that did exist. Micro-economies in general, which could take place in app-specific tokens like token-curated registries or micro-object covers network in which there's just, you know, a very niche clientele for this token, but you don't want them to be sort of limited by that aspect. Probably you won't have access to exchanges. There's just not a lot of people buying and selling, and so there's very large spread and there's no agreement about the current prices. This is actually what got me into this topic again was making my project covers network. It's a game, and I didn't want my users to kind of be stuck with the ship coin and not be able to get rid of it, but there's no chance that some exchange was going to list me, so I wanted to be able to offer them the ability to offload the coin for Ether, and so I was able to deploy my own bonding curve in the contract so users can constantly buy and sell at a price that's changing. But the general concept for bonding curves which have indefinite token supplies are that the tokens themselves come from the contract, which is the market maker itself as well. So you could send some collateral token off to Ether into this contract, and it will mint some new tokens for you. The price that it mints is designated from a predefined formula or an adjustable formula. In this situation it would be basically total supply squared. Total supply is on the x-axis, so this sort of calculates how many tokens are currently in existence, and that determines the price, which is on the y-axis. But really, you can imagine when the total supply is at the very beginning and there's almost zero, the price is very low. As you purchase, the price gets moved up, so let's say the first 10 that you buy will be less expensive than the next 10 after that. If you wanted to get rid of those tokens, you can come back, send them to the contract, they will burn them, which will decrease by pushing the price back down. And a really convenient aspect of this visualization is that the area under the curve is actually the amount of collateral that's needed to populate that contract in order to generate those tokens. That collateral is always staying in that contract, which means that when you come back and try to cash out, that money's there waiting for you. So it's a bit like an ICO, except for the company doesn't have the money if the money's locked up and it's there for buybacks. Let's see an RRR. So at the top right, there's some kind of math, and this is the two ways that are often used for thinking about these and calculating these, which is the price formula, kind of a basic slope formula. I think this is really useful for visualizing and designing the start-up mechanisms. But when it actually comes to implementing, I kind of preferred the way bank works on it, which uses the concept of the reserve ratio, so that's what the RRR is. So they think about the price as the reserve, which is the amount of collateral, divided by the supply times some reserve ratio is going to be some number under one. Basically, what percentage of that supply is actually backed by collateral, which you can rearrange and see that the reserve ratio is actually the reserve divided by the market cap, so that's kind of like how much is actually backed. And the market cap, of course, is the price times the supply. So those are the two sort of ways that are thought about. You can actually program it in the original format, but there's some nice properties of the reserve ratio that lets you do some sort of adjustments while it's moving. I have some slides on that at the end. We can go over, but it's not quite tough, part of the talk. The example use case that this new batch bonnaker technique is being used in is in a continuous organization. And this is an idea where you basically have a DAO that has a bonnaker attached to it. And when that money goes into the contract, it actually can be used by the DAO for operational costs or something like that. So the shares are the tokens. The DAO sold this bonnaker. And that locked collateral in some portion might be used for this working capital. And the token holders might receive something like shareholder rights or receive dividends as being a participant inside of this, sort of more like a traditional company. It's been implemented with Aragon Black called the Fundraising App, which will be coming out soon. There's also some other organizations working around it. SeaOrc from Tiva Vabra. It's really interesting working to get this classified as Reg C in America so that you can participate then without having a credit investor status. SeaOrc is also building a similar mechanism using the DAO stack framework for Gnosis's DXDAO and give it then the common stack is working something similar. So this continuous organization instead of going through and hang out dividends, I mentioned this might be sort of a feature that you would want in a system like this. There's a really convenient workaround instead of sending out a bunch of transactions for all the several stakeholders to give them dividends. You can actually just put money back into the collateral pool and this is sort of will increase the value of all the tokens that already exist. So if you're a stakeholder and having these tokens by injecting collateral back into this contract, the value for token will increase for everybody. So it's sort of like paying everybody dividends with just one transaction instead of an individual wanting each person. Because if the collateral increases but the token supply stays the same you can imagine that the price will get boosted up in that previous graph. Similarly, when you remove collateral this is a way to basically decrease the value of the tokens because you've got to spend money to make money, but these are kind of the two actions that you would expect in a continuous organization using a money curve like this. So front running. As most people know Ethereum and a lot of public blockchains are kind of slow in their process of transactions at blocks and for a moment there's this mem pool of not-processed transactions and so in that moment you kind of have full sight of all of the activities that people are taking place on blockchain and if you can see that some of these transactions are buys or sells in one of these bonding curves you'll know that there's going to be a price movement in front running as possible. In the active front running imagine a buy order is coming in you as a front runner would be able to make another buy order and lose the gas price which might make the order get included first depending on how the miner works or you might be a miner yourself. You would make a buy order in front of them with the new gas they would make one after you and then you would make a sell one. So when you make your buy the price is pushed up further up you make your sell and you're back down here. So this is kind of bad because there's no risk in that buyer interacting with this market and so they're basically just scraping off some of your money in the buy order. Be like going into a store buying the object in front of somebody else turning around and selling to them in a markup when they could just buy from the store. Similarly in a sell order if you see a sell coming in you can make a sell in front of them push the price down. They can make a sell push the price further down and then you can buy back. So this is a way to increase your current position with no risk sort of scraping off their money and using it for yourself. In those two dividend and working capital situations you could similarly front run. So the transaction that might inject collateral into the pool this is similar to a buy because you know there's going to be a guarantee price flipping up so you might decide to buy right before that the injection happens and you sell right afterwards. Or if the working capital is about to be removed you wouldn't want to have the situation that you could just sell your tokens right before they withdraw that capital and then buy back afterwards in the same transaction. So front running in the wild is rather rampant. These are some statistics from last year's talk by Phil Dian about it. So they were doing most of the work on sort of publishing this in the wild and putting them in 2017 on Ether Delta alone which was not a very popular exchange. There was $4,500 in August. He and others recently released a paper called Flash Boys 2 which is a reference to Flash Boys the high-frequency traders who would sort of build their own line of internet across the New Jersey to the New York Stock Exchange in order to front run orders would have been meant to activity like that. And by their estimates there's 30% of all walks contain some kind of programmatic arbitration transaction which would be included in these sort of front running. If there's more data on that you can go to frontrun.me. There's a lot of really good work doing there. This is obviously rampant in the wild and it's only going to get worse. And so we do need to address this because we can't really ask anybody to use an on-chain exchange if we know that it's not going to be able to deliver quality service. So batch orders with common clearing prices is one proposed solution with three versions here. Calling them ordered batches and a common clearing price. And again, they each have their sort of benefits and drawbacks and I'd be curious what the general sort of feeling is what you thought the best version was. So the first one batched orders well, they all sort of follow a similar idea which is that you take some span of blocks and you collect all the buys and you collect all the cells in that span and in order to make things a little easier you just combine them into one big buy and you track of course all the individuals who actually put in those orders and then you clear them together with some price and then you redistribute it to those users based on that price and the percentage that they pay. So the first version of that has kind of a drawback in that one party gets ordered over the other although you can think of it as a feature and not a bug if you want to reward one of the parties more than the other for instance the buyers so in order to batch it kind of takes the most simplistic approach which is why we just execute all the buys using the bonnaker and then execute all the cells or the way around do all the cells and then execute all the buys but this does reward one or the other so imagine the execution buys first so let's say we're starting out in the blue line that's the current spot price we execute the buys first the price moves up to the red this is really good for the sellers because they want to sell at a high price and this is the price position of having a high sell price which then moves the price back down overall if you were to execute the same order as buy first and sell first the final price would be lower when you execute the buys first if you were to execute the cells first you can imagine starting in the blue line again it's going to push it down for the greenest which is great for buyers, they want to buy at low prices so now they're sort of the privileged party in this situation the final price is going to be higher than average or higher than the sell version which are the two sort of features if you want to reward buyers in your system you kind of think they're putting money into the system, they're, you know, contributing I want to make sure that they're rewarded for this capacity you might say this is a feature and you want to make sure it happens this way maybe you have an idea of rewarding sellers if you can do the other one so the second method is called match and fill and I think of a head tip for Tomarten Goldman from NOSIS for helping me with this and this idea is that you have that original spot price the current one and of course with the body curve you'll start moving it but in that moment you have an exact price, theoretical exact price so why don't you take that one and match orders as much as possible you've got this big group of buys, you've got this big group of sells at that spot price one half of them is going to get completely consumed by the other half you're going to have some leftover buys if there was actually more buy orders and some leftover sells if there were actually more sell orders so whatever is left over and executed is a normal bonding curve transaction so you have this entire side that gets taken care of just at the spot price disappears the other side gets a combination of that spot price plus whatever is left over as this bonding curve the third one is the bonding clearing price this is kind of the way you would imagine is the goal and this is where you can find some fair price for the entire group of buys and sells however it's a little bit too complicated to calculate on the EVM another head tip to NOSIS member Tom Walter for helping me with this but you can see the formula for getting this it's rather hard to find it ends up resulting in one solution that's zero one imaginary number solution and then one correct solution what is convenient is that even though it's hard to find you wouldn't be able to calculate it on the EVM it is easy to verify on the EVM so if you were to take that price which was the correct price in that formula provide it with the transaction execute the orders you'd be able to check did this mess up the slope at all did this change the market maker if there was an incorrect price it would have modified that so it's easy to verify so there is a solution for that this is inspired by the NOSIS diffusion exchange which does something similar very very complicated execution but it's easy to verify that they were done correctly off-chain in a similar topic Uniswap has been working with batching orders they're calling it netting trades so that's from Dan Robinson and Haydn Adams they just conduct it with us the other day they might be talking about it later today at 4.20 in room B7 you can see that when you're using the constant product it's batch order calculation Uniswap is a great product and it's used specifically for tokens that already have sort of fixed supplies or supplies that exist in the wild whereas I think that bonikers get much more interesting much more useful when there's a situation that the token is actually generated from the same place as the market maker where situations like prediction markets and curation markets but if you don't have that requirement then Uniswap is a definitely preferred calculation method and it has this convenient batching order system so there's a link to the github proof of concept there it also links to the art of black implementation and still undergoing final audits and there's also a link to a mini-particle that has a bit more details about all these topics if you want to check that out again later I'll wait till I see phones going down and if this is interesting to you come and say hello and talk to me you'll be holding me on Twitter, email, github yeah, that's it we have any questions for the next few minutes so the three approaches that you described, do you have a personal favorite and one? yeah, so for the most part while working on this I was really looking forward to this common clearing price this universal one for everybody but after sort of finishing it and finding it I kind of started favoring the second one and because I think that it's sort of the price is more reflective of the way the market is actually acting if there are more buyers than sellers that buyer should handle the price movement whereas the sellers are sort of the minority in that sort of situation so maybe they should actually just have the spot price which is an incredible one but I don't know, I mean the common clearing price also kind of feels good that's what I meant, I'm curious about your opinions if one of those feels better or worse for you I mean of course the first one also for the use case of rewarding the buyers, makes sense but I skew towards the middle a little bit the third, I don't know I'm going to show a hands first curve as the best one for general use case anybody? second version we got some hands, we got some hands and third version okay, we got a couple so I'd say general consensus is second kind of makes sense but yeah question in that second version you're talking about for the growth that's left over for the buyers and sellers like the price is evenly between that entire group or is it set of buyers to get screwed or set of sellers to get screwed evenly between that entire group good talk so did you look at all at jurisdictions or optimizations for the uniform clearing price or did you just implement so we found the formula that has all the necessary variables that you want to solve for but I ended up just using full from output to solve it I know there's some python libraries that are good for that symbolic subbing out but when you actually solve it for the variable you actually want it becomes this really nasty nasty formula that I don't know how to deal with so I'm sure there are ways to optimize that math but at the end of it that's all off-chain data so it doesn't necessarily need to be optimized all that really matters is that it's easy to verify on chain which is easy enough so you mentioned that on your last slide that because the new swap right doesn't have the same constraints that you were looking at what is the the kind of ways that we're there that provides for our running it's the same idea of batching for orders and they choose the common clearing price which is kind of the third version so after orders come in they get calculated next year so it's not like they're doing anything new it's just an easier plan exactly because the constant product formula is a lot easier to do are there any common patterns like the size of the orders that A you know tend to be the front runner orders versus the ones that tend to be front run like are there going to be small orders front running large orders like front running in the wild I'm not sure about that I would say check frontrun.me for that kind of data but I don't know I've talked to some people and it seems like it's easy pickings but there's actually just such little liquidity on chain that there's not it's maybe not worth putting in the effort to frontrun everybody I don't know so I've looked for frontrunners I mean I've had a lot of talks with different shops about it the short version is what you were saying there's just not enough money in $10,000 a day running a fairly complicated front running bot even though $10,000 a day sounds like a lot people I've talked to said it clearly wasn't worth it I mean we do actually give liquidity and people are using dexes of course that would probably be a different case well I would assume that at some point there would be a product differentiation between the dexes where you say no one's going to front run your fill so people would actually just fix the problem because it's an entirely fixable problem in the dex software itself that allows for the front running there's no you know well I think we're at time if you want to talk later, come back thanks a lot