v1rc #10
v1rc #10
Conversation
This required a complete rewrite of the contracts.
This will make it easier to add mainnet support in the future.
The default show implementation decodes from hexidecimal. For this CLI, the hexidecimal is preferred so a custom implementation was needed.
The endpoint was returning royalties instead of the desired addresses. A different endpoint needed to be used.
Extra helper scripts were removed since they were for things users should already know. An example is the delegation helper script.
|
I am keen to help you with this awesome project any way I can. Unfortunately I am not enough of a programming guru that can just be pointed at the code so I might need training wheels before I can be much help. If you are building searching software or a decentralised order book viewer then I might be able to help with writing user documentation or with building deb packages so it is easy for users to install. I have both ARM64 and AMD64 machines that I can build and test on. Please let me know if there is some way I can help and I will try. |
|
@TerminadaPool I actually don't think I need help with the code at this stage. To me, the beta does not need to be 100% bug free (although it would be nice 😄). Instead, it is meant to grow community interest and inspire people to get involved. My bigger concern is the CLI since it is currently the only way to try it out. But even with that, I am more concerned with the UX than the code. What would really help is for you to just follow the GettingStarted and try it out. Try to do a round trip: create a swap, update the price, maybe convert it to a new trading pair, swap with it (pretending to be another user), and finally close it. Currently, the most pressing questions for me are:
|
|
Yeah sorry, I wasn't really offering any coding help because I already know that I am not in the same league as you that I could provide any meaningful help. I might even have trouble just compiling / using your github code. However, I will get onto trying it out over the next week and doing some testing. I will also have another read and think about the readme.md file but after quickly reading it just now, it looks good. |
Thanks for writing this & giving me time to fully understand what you've written. I've finally been able to go back to cardano-foundation/CIPs#466 and read your draft & the comments you've made on top of my own & other reviewers' comments (cc @zhekson1). Therefore I'll make any further general comments about Beacon Tokens there, and will comment here in this repo about the particular applications... until the point when these apps are referred to as reference implementations in CIP and CPS documents. 🤓 cardano-foundation/CIPs#466 (review) |
* Ask assets must be allowed in UTxOs since updates will also check swapped UTxOs for extraneous assets. * This commit also contains an edit to a comment. * A `> 0` was changed to `== 1` since there should never be more than 1.
There was a problem hiding this comment.
I am reviewing my own README instead of directly editing it in case you guys do take the time to read it over again. Again, you guys have done enough so no pressure. I didn't want to be changing it while you guys were reading it since you won't see the changes and would effectively need to re-read it. I would find that very annoying...
These comments are some mistakes I found and some thoughts about certain parts.
| transaction fees which makes this impractical to do at scale. | ||
|
|
||
|
|
||
| ## FAQ |
There was a problem hiding this comment.
I was thinking about adding this question to the FAQ. @zhekson1 and I have talked extensively about this. If it gets added, I would want the arguments to be pretty airtight since UTxO concurrency issues are a hotly debated topic right now.
If there is one two-way swap UTxO with 1000 djed and there are 10 users trying to use 100 djed each, isn't this still a concurrency issue despite having enough liquidity?
Yes, this is a concurrency bottleneck but no, this is not an issue. This is the perfect niche for businesses to build on top of Cardano-Swaps. Historically, whenever there is a risk that users don't want to carry, a business can form to carry that risk instead, for a price. Insurance is one such example. The same scenario applies here.
Imagine a slightly simpler example: Alice has a 100 djed swap available while Mike and Charlie both want 50 djed from it. No liquidity problem here, just a concurrency problem. Sarah can see this scenario and decide to front the 50 djed to both Mike and Charlie (possibly for a fee) with the intention of settling up with Alice's swap later, ideally for a profit. At a high-level, this is how market making works.
The contemporary liquidity pools are perfectly positioned to pivot to this niche. Since the liquidity pot should (ideally) be growing, this can be a potential source of profit for them. These would still be risky endeavors and would be actively managed but at least the yield tokens could have real economic value (assuming they are a claim on the ever growing pot).
If we wind up using liquidity pools anyway, how does Cardano-Swaps change anything? There are a few ways:
- Most liquidity will be in one-way and two-way swaps simply because they are far less risky than being in an actively managed liquidity pool. Therefore, the arguments regarding delegation and voting control still hold.
- Currently, if a liquidity pool collapsed, it would bring down a sizable portion of DeFi. However, if the liquidity pool was a market making business a fraction of the size relative to the underlying liquidity, a failed business would not materially impact DeFi since the underlying swaps would still be available. The annoyance of concurrency for buyers would be back but that is still preferable to the economy itself grinding to a halt. And since there is still a demand for a market maker to remove the concurrency risk, there is a natural incentive for a new business to fill the void left by the failed one.
- The fact that users can always choose to accept the concurrency risk and interact with the underlying swaps directly prevents potential abuse by market makers since users always have the option not to use them.
Tiered pricing would make it even easier for users to interact with swaps directly, if necessary. This scenario is very similar to what would happen under liquid democracy: most users will still delegate their vote but the very option to vote directly acts as a check on misbehavior by representatives. In Cardano-Swaps case, most sellers would use one-way and two-way swaps while most buyers would likely prefer market makers but can always interact with sellers directly.
When it comes to creating a decentralized economy, not every feature needs to be directly enabled by the DApp. Some features can, and should, be left to the market to fill.
There was a problem hiding this comment.
I'd add that in the endgame, most users will not be "competing" for swaps - market makers / businesses will be. Most users will create orders via swap UTxOs that are then swept by larger players (MMs/arbitragers) - in this scenario there is zero concurrency problem (for the end user)
There was a problem hiding this comment.
I respectfully would recommend that you simplify the explanation somehow because it seems like the description is making things sound worse than they really are. The way I see things is that market makers are going to be searching for all opportunities to profit and therefore they will combine all the overlapping djed swaps that can be executed profitably. I think the market makers will end up competing for essentially the same "meshwork" of profitable swaps they want to combine. This is a slight irritation for the market makers who will see some transactions fail, particularly highly profitable ones that will get competed over. But, it is not a problem for ordinary users who will quickly get their swaps executed if "in the money".
There was a problem hiding this comment.
How about this wording?
If there is one two-way swap UTxO with 1000 djed and there are 10 users trying to use 100 djed each, isn't this still a concurrency issue despite having enough liquidity?
Yes, this is a concurrency bottleneck but no, this is not an issue. This is the perfect niche for businesses to build on top of Cardano-Swaps. Historically, whenever there is a risk that users don't want to carry, a business can form to carry that risk instead, for a price. Insurance is one such example. The same scenario applies here.
Imagine a slightly simpler example: Alice has a 100 djed swap available while Mike and Charlie both want 50 djed from it. No liquidity bottleneck here, just a concurrency bottleneck. Sarah can see this scenario and decide to front the 50 djed to both Mike and Charlie (possibly for a fee) with the intention of settling up with Alice's swap later, ideally for a profit. At a high-level, this is how market making works. Mike and Charlie will likely prefer going through Sarah, even if Sarah charged a fee, simply because it means they don't have the concurrency risk. The option to directly interact with Alice's swap will always be available to Mike and Charlie. Because this option is always available, Sarah is incentivized to give Mike and Charlie a fair deal. Tiered fees will make it even easier for Mike or Charlie to use Alice's swap directly, if needed.
Thanks to Cardano-Swaps being fully p2p and permissionless, anyone can build a business on it like Sarah. And since the day-to-day users will likely not want the concurrency risk, there is every incentive for people like Sarah to step in. In the endgame, most users will not be competing for swaps - market makers and other businesses will be. Most sellers will create orders via swap UTxOs that are then swept by larger players (MMs/arbitragers) while most buyers will go through businesses that carry the concurrency risk in their stead. In this scenario, there is zero concurrency problem for the end user.
When it comes to creating a decentralized economy, not every feature needs to be directly enabled by the DApp. Some features can, and should, be left to the market to fill.
There was a problem hiding this comment.
Both work equally well for me but I think the latter (shorter, more familiar) edit will be more approachable by general readers... even docs for technical audiences in crypto & other Internet apps still have the Alice & Bob stories 😄
There was a problem hiding this comment.
What do you think are the most important points this answer should convey?
To me, they are:
- Users can pay to have businesses compete for UTxOs on their behalf. Users can set their own prices for this.
- Users always have the option to interact with UTxOs directly if desired.
- Anybody can be a liquidity provider and anybody can get paid to compete for UTxOs. It is fully permissionless. This competition also means users don't need to pay that much to have their swaps executed.
Yes, I think so.
I also agree that you want to keep the answers as simple as possible. It is your document, I am really just trying to provide a different perspective to stimulate your thought if that can help paint it in the best light. All these other DEX designs are inferior and it seems that AXO will not be permissionless. At the end of the day, I just want to see Cardano-Swaps go for number one!
There was a problem hiding this comment.
I definitely appreciate the perspectives so don't hesitate to keep sharing!
Your example has a slight issue:
For example, Mike and Charlie could both create 49.8 ADA -> 50 DJED swaps.
If Alice's swap is 1:1, 49.8 ADA can only get you 49.8 DJED. Mike's and Charlie's swaps would actually have to be 50.2 ADA -> 50 DJED. So the arbitrager would have from the two swaps 100.4 ADA but only needs 100 ADA to get the 100 DJED to satisfy them. The extra 0.4 ADA is left for the arbitrager.
How's this wording using your example (I think your example makes it a little clearer):
If there is one two-way swap UTxO with 1000 DJED and there are 10 users trying to use 100 DJED each, isn't this still a concurrency issue despite having enough liquidity?
Yes, this is a concurrency bottleneck but no, this is not an issue. Cardano-Swaps addresses these bottlenecks by natively supporting a healthy fee market that is immune to MEV and front-running.
Imagine a slightly simpler example: Alice has a 100 DJED swap available for ADA at 1:1 and Mike and Charlie both want DJED from it. No liquidity bottleneck here, just a concurrency bottleneck. If Mike and Charlie do not want to deal with the concurrency bottleneck, they can pay arbitragers to execute the swaps for them. Here is how it would work:
- Both Mike and Charlie create one-way swaps for 50.2 ADA -> 50 DJED (a price of about 0.99 DJED per ADA). If executed against Alice's swap, Mike and Charlie would each get 50 DJED and whoever executes their swaps gets to keep the other 0.2 ADA per swap. These swaps are effectively saying: "I'll pay you 0.2 ADA to execute this swap for me."
- Sarah, an arbitrager, can see all three swaps and executes them, keeping the 0.4 ADA arbitrage (0.2 ADA from Mike's swap and 0.2 ADA from Charlie's swap). After the 0.2 ADA transaction fee, she pockets the remaining 0.2 ADA.
In other words, Mike and Charlie deliberately create an arbitrage opportunity so that arbitragers will want to execute their swaps. If Charlie really needs his swap executed ASAP, he can configure his swap so that he gets 50 DJED and the arbitrager gets 0.5 ADA for executing his swap. Basically, the more attractive the buyer makes the arbitrage opportunity, the more arbitragers will compete for it and the faster their swap will be converted.
From the perspective of the arbitragers, the only cost to them is the transaction fee which scales very slowly relative to the number of swaps in the transaction (14 swaps costs about 1.5 ADA). Combine this with the fact that these transactions are risk free for arbitragers (a failed transaction is no cost to the arbitrager) and you end up with very healthy incentives for arbitragers to want to do this and satisfy as many users as possible with each transaction. The risk free nature means arbitragers would even be willing to do this for small profits like 0.2 ADA. Being an arbitrager is fully permissionless so anyone can start generating income this way.
These incentives are how Cardano-Swaps natively creates a fee market. It is effectively no different than paying a larger transaction fee to ensure your transaction gets into the next block. Furthermore, since users must explicitly set their prices which are trustlessly enforced, MEV and front-running are simply not possible.
As this scenario shows, most users will likely not be competing for swaps - arbitragers and other businesses will be. Most users will create orders via swap UTxOs that are then swept by these businesses. This results in there being zero concurrency problem for the end user.
When it comes to creating a decentralized economy, not every feature needs to be directly enabled by
the DApp. Some features can, and should, be left to the market to fill.
I want the answer to be fairly short but still address the key points. To me the key take-away is that Cardano-Swaps has an endogenous fee market and that is how it solves the concurrency bottleneck. This fee market is immune to MEV and front-running (I think... I have not really thought this through yet.).
There was a problem hiding this comment.
Feel free to make up some more FAQs if you like. For example, you could add an FAQ about using Cardano-Swaps with Hydra.
There was a problem hiding this comment.
I definitely want to mention hydra at some point but right now, with hydra not really finalized, there is too much speculation for that. Once I'm done with the protocols, I do want to try playing around with hydra and see what I can do with it. For now, I want to keep the FAQ to the criticisms I see most often. Since I also want to release it this weekend, it is a bit late to add much more...
There was a problem hiding this comment.
@fallen-icarus : That re-write above is awesome, it really showcases the strengths. In the end, I think the arbitragers will be so actively looking for any profitable bundle of swaps that users will simply post swaps that are very minimally in the money if they need them quickly executed. And, in reality any tiny profit margin is still risk free profit. Even it is only a penny worth, as an arbitrager, you already have the software running so why not take that penny.
Of course, since that is how an order book works. It is only when the prices meet with a degree of overlap, more than the transaction fee, that the trade will be profitable to execute. Arbitragers will only execute trades that are risk free profit. Otherwise, if they were to provide liquidity to execute trades not independently profitable, then they would be taking on directional risk. Arbitragers will also have accounts with centralised exchanges and will be watching the prices in all locations. As soon as there is an arbitrage opportunity worthwhile they will execute the trade. I am not an expert, but I understand the role of a market maker in the TradFi world of a stock exchange broker, is expanded beyond being simply an arbitrager, to include a requirement to provide a level of liquidity. These market makers may take on directional risk for periods of time but they usually hedge this risk using options and other strategies. They pay for privileged access to the broker's order book which allows them to preferentially order their trades. They also get to set the price spread, manipulate prices through high frequency trading, and snipe all arbitrage opportunities for themselves. If we view cardano-swaps as an isolated market then there would be no incentive for a market maker to provide extra liquidity beyond executing arbitrage opportunities because he can't gain any privileged access to front run other people. This is good and means that the real cost of transacting is transparent. By contrast, platforms like Robinhood are not transparent. They say they have "free" transaction fees but really this is because they are selling privileged access to their order book so that market makers can front run, and high frequency trade against, the ordinary users. |
|
thank you @rphair and @TerminadaPool for your feedback! I will be combing through these documents as well as writing others in the future and your input is a great help in the process! |
|
Thanks again for the help @rphair and @TerminadaPool! Your perspectives helped me realized things about this protocol that I hadn't noticed before (like the fee market). I hope you will be willing to help us out again for the other protocols. Loans is almost there. I am hoping to release it by EOY. |
|
@fallen-icarus I messaged you privately on Matrix about my testing attempt with a copy of my steps undertaken. |
|
@fallen-icarus I can read your message on matrix OK. Perhaps you can't see the content posted before you joined the room. I have reposted what I previously wrote, so hopefully you can see it now. |
|
@fallen-icarus I can see your posts on Matrix. Could you try creating a matrix private chat yourself with my handle and then I will attempt to join your invite? I find Element on Linux seems to be a pretty functional Matrix client: https://element.io/download To create a private chat I just click the + sign under "people" and then enter the user handle. I could post the log of my testing problem here but I was worried it would pollute your GitHub repository. I agree that the number of disparate social media apps is overwhelming. Though at least Matrix is freedom preserving and doesn't require a govt registered mobile phone number linking everything. The AI algorithms in the future are going to love getting inside peoples heads. |
|
I just created a room. I'd prefer to use the web app if possible since it requires less privilege. If it doesn't work, I can try the desktop app. |
This PR supersedes the offer-branch PR (it includes the addition of the offer beacons). This PR is meant to be the official beta version.
One-Way Swaps
Adds offer and ask beacons for more expressive off-chain querying of swaps.
Two-Way Swaps - credit to N8iveToEarth on X/Twitter for the idea
Adds a new reversible swap type that can be used to provide liquidity in a profitable way. In essence, Alice can create a swap for ADA <-> ERGO and set two prices, one for ADA -> ERGO and one for ERGO -> ADA. By setting both of these prices at slightly above market rates, Alice can profit from Bob using her swap regardless of trade direction. This potential for pure profit naturally incentivizes users to provide liquidity. The main advantage of this over the one-way swap is that the swap UTxO does not need to be reset after each usage. For users that just want to swap assets, the one-way swap is still available.
Off-Chain
Docs