-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEX Market Makers (?) #2749
Comments
I definitely think this is an interesting proposal…. However, I see nowhere that this proposal is discussed at length before it is immediately added to the protocol and slated for being included in a version by Adam. Is this still a decentralized protocol that’s driven by community feedback or is it simply developer suggest a good idea and Adam says let’s put it in the next release? If there has been any public discussion on this proposal, I have not seen it on github or in the counterparty developer channel or the new counterparty 2.0 channel which was established a little while ago. If this is indeed a community driven project still where can the community participate in conversations about proposed features? And is there any guideline for how quickly things go from a GitHub proposal to being approved without discussions? Serious question… I would like a response, please… as this certainly seems to be a case of immediately approving something before community discussions happen🤷🏻♂️ UPDATEAdding my comments here since they were Censored by Adam and marked as off-topic to hide them from community review... Apparently bringing up that there is no official guideline for how one can propose an idea and get it moved from idea into a protocol change is considered "off-topic"So discussions happen here, in github, where most community members don’t have github accounts, no see this proposal advertised in a public way, and lack of discussion or objections will be seen as “community approved this change”…. No CIP process, no open forum discussions, no discussions in developer chats, as it has been for the 10+ years before you came back n changed everything. Thanks for clarifying your viewpoint👍🏻 Also curious why this was added to a future release before ANY discussions happened… is this how develipment works now? Can I propose a change and if no community members but yourself object, I can get it included in the protocol? Kinda confusing process without any guidelines… like the CIP process we had for many years.🤷🏻♂️ |
This is the discussion. I added a question mark to the title to make it clear it that the proposal has not yet been decided upon. Before any additional substantive protocol, there will be a formal protocol spec. written and published, also for community input. |
I had a thought recently and have been trying to think it through figured I would drop it here for discussion. Proper AMM's will require quite a bit of new logic, testing and new database tables.
There may be a way to get the vast majority of the functionality into the current dex without a lot of changes by making a discreet version. It would require a new api endpoint, a new column in the dex, and a few lines of code to create a new order on the opposite side when an order of this type is filled. The disadvantage is there will be alot of orders created in the dex... (if this gets popular there could be tens of thousands of filled dex orders per day, so that side of things needs to be considered? It would be a good thing, but the db would certainly increase in size quickly ). If this were to ever be implemented, it would require an xcp fee large enough to discourage people opening up tons of LPs for tens of dollars in assets. (or perhaps when X pools are open on a pair, new pools must have a value greater than the smallest X/Y pools? just an idea)
Anyway, the idea is pretty simple, a user would compose a transaction to create a "DEX Market Maker". They would specify the asset pair, the minimum price, the maximum price, spread, and the type (linear or logarithmic spacing). In this example lets say the user wants to list 250 MINTS in the range 1 XCP to 10 XCP per mint with a spread of 1% and a linear order type. This order is creating a group of DEX orders selling 25 MINTS each. The table below shows the values
The power behind this is not the group of DEX orders created in one tx, it's what happens next. Lets say the price of MINTS goes from 0.9 XCP to 1.01 XCP. Order 1 is filled. When the CP node fills the order, it takes the the 25 XCP (25 MINTS at 1XCP each) and creates an order on that users behalf to then buy 25 MINTS at (orderPrice*(1-spread)) and credits the user (orderPrice*(spread) + rounding error). So if the spread is 1%, the user then is credited 0.25 xcp and has a buy order for 25 MINTS at a price of 0.99XCP each. Then if the price down and that order is filled, the user now has the same amount of MINTS they started with, and an additional 0.25XCP.
EDIT: There should also be a flag to "invest profits" so that rather than distribute this profit, it is used in the buy. This would be useful when a user wants to be "all in", but it would be especially valuable when someone creates a P2WSH x of x multisig and uses that to create the position, then destroys the keys, permanently locking the liquidity and any profits it generates in the market maker.
When a user wants to close their position, all of these orders are closed.
As multiple users open up DMMs, the liquidity will overlap, filling in the gaps in price. The great part about this is it unifies the current DEX with automatic market makers allowing for the reuse of the current dex primitives.
The text was updated successfully, but these errors were encountered: