Scaling Cardano, Hydra Updates, CIP-110 & New SundaeSwap v3

Episode by Peter Bui on February 1st, 2024

In this insightful episode of the Learn Cardano podcast, we had the pleasure of hosting Pi from Sunday Labs. The conversation covered a range of topics including the development and scaling of Hydra, the latest updates on Sunday Swap V3, Pai’s new Cardano improvement proposal, and several exciting catalyst proposals from the Sunday Labs team.

Hydra and Scaling on Cardano:

  • Hydra’s Current Status: Hydra is now live on the mainnet and has been in version 1 for a few months. It is particularly suited for peer-to-peer, long-running connections.
  • Adaptation to Hydra: Existing dApps on Cardano need time to adapt and build for Hydra, as it offers a different model from layer one.
  • DApp Development: Future projects will find better market fit with Hydra, enabling unique applications like peer-to-peer settlements or streaming platforms.
  • Custody and Permission Model Changes: Hydra’s model changes the dynamics of custody and permissions, requiring careful consideration for applications like decentralized exchanges.

Sunday Swap V3 Updates:

  • Complete Rewrite: Sunday Swap V3 represents a complete overhaul of the existing smart contracts.
  • Scalability Improvements: Significant focus on scalability, increasing maximum batch size for orders, and resolving transaction sorting issues.
  • New Features: Enhanced features for seamless operation and integration, including features for DAOs and advanced transaction routing.
  • Launch Date: White paper and potentially the source code to be released on Valentine’s Day.

Catalyst Proposals by Sunday Labs:

  1. UPLC Debugger with Aiken Integration: A tool for developers to debug smart contracts efficiently.
  2. Gummiworm Protocol Specification: Developing an official specification for the Gummiworm protocol, which enhances Hydra’s model.
  3. Margin Pool Development: Introduction of margin trading in liquidity pools, enabling leverage trading.
  4. Permissioned DeFi Collaboration with Kora Labs: Developing permissioned DeFi ecosystems using Ada handles for personalization and identity.

Pi’s insights provided a comprehensive understanding of the current and future landscape of Cardano and the DeFi ecosystem. The developments around Hydra, Sunday Swap V3, and the catalyst proposals point to an exciting future for Cardano’s scalability and utility.

Text Transcript

This is going to be a really interesting conversation. I have Pi joining me on this episode from Sunday Labs. We’re going to go through a whole bunch of things, answering some of the questions from the community that I’ve had on my YouTube channel as well around Hydra, scaling, what’s going on there, but then also go into some of these brilliant new features and upgrades for Sunday Swap V3, and also go into Pi’s new Cardano improvement proposal.

that is going to do a lot of things for V1 contracts, and also a few of the catalyst proposals that the Sunday Labs team have as well this round. So, Pai, welcome back to the podcast. Yeah, thanks for having me on. I really enjoy your channel, so it’s always a delight to be able to come on and talk to you. Yeah, and I always learn so much when you’re on. So this knowledge sharing is really good for the community. But first off, probably the biggest thing.

that people have been asking me on the channel is like, where’s Hydra? Why aren’t we seeing 10,000 transactions per second? Can you give us some insights there around Hydra, and then also what you guys have been working on? Sure. So I’ll start this off with a disclaimer. I’ve been working really hard. So if I feel a little bit less eloquent than I usually am, that’s why. But Hydra is live and is on mainnet.

has been in v1 for a little while now, I think a couple of months. I think the biggest adjustment that people have to understand is that there’s kind of a little bit of a survivorship bias here, where the kinds of dApps we see on Cardano right now are those that are really well suited for the layer one transaction model, right? And the kinds of dApps that are really well suited for Hydra…

haven’t been built for Cardano because they weren’t the right fit on Cardano layer one. And so it’s going to take, I think, some time for projects to find that market fit and find what works well on Hydra and build adapt specifically engineered for that. Hydra is really good for peer-to-peer, long-running connections. So I can picture a really cool Venmo built on Hydra where

you and your friend are kind of settling lunch balances every day, and you don’t need that transaction history to be on chain. Or you’re tipping your barber. Or I could see a really cool streaming platform that used Hydra to do bits and tips like you see on Twitch. But those things don’t really make sense to build on the layer one, where it’s really expensive to get data on chain. But they make perfect sense for something like Hydra. And so you’re not.

While one of the great benefits is a lot of the tooling and infrastructure that works for the Cardano layer one, ports really easily. You’re not necessarily gonna see DAPs just flip a switch and switch over to Hydra because it really changes the custody and permission model, right? So I’ve talked about this a lot in other podcasts where the reason Sunday, even though we had a working version of Sunday on Hydra really early back in 2022,

it would mean that whoever is running the Hydra heads has custody, effectively, collectively, of millions of dollars. So it’s not really the best fit. And so to sum it all up, the key takeaways are Hydra is at a version 1 and is launched on Mainnet. And the team is recommending, I believe, apologies to the Hydra team if I’m not quite right on this. But they’re suggesting, hey, this is ready for people to use.

stand out stars in terms of open source development and being transparent about what’s progressing and things like that. And now it’s just on the businesses to come along and say, hey, we’re building a business that wants to do X. Does it fit with Hydra? And as you see things like, just to throw another example in there, an ad payment network where you’re

When you visit a site, you’re auctioning off the ad space to kind of a network of ad providers. That would also be really cool and really well suited for Hydra. And so you’ll see companies come in and kind of find the right tool for the job. I’m in talks with a lot of people, obviously I’ve talked a lot about Hydra publicly, so people reach out to me and say, hey, can you help us think through this and things like that? And so I know that they’re coming. Development is slow. And so that’s kind of where I would say have a little bit of understanding and

likely you’ll end up using something and not even realize it’s using Hydra. Yeah, I think that’s one of the biggest misconceptions that the community has. And especially my YouTube followers, they believe that Hydra will be on the L1 and dApps can just use it straight away. And I think the narrative that they understood was that it would be that way. But no, it’s a completely different solution that dApps need to adapt to and build.

different solutions for. So hopefully, we do see something come out of it soon and really utilize what Hydra can do. Just to comment on that real quick, I think where that comes from is a very well-intentioned communication on IOG’s part, where they’re talking about the technical details. They’re being really transparent about how it’s going to work. And maybe a misstep on their part of not understanding one of my maxims, which is the broader the audience, the less capacity for nuance. And so there’s

They’ve, in my opinion, been really honest about how Hydra is going to work and what the trade-offs are going to be. But by not focusing on some of the things that a non-technical user might miss, they’ve accidentally created this perception that Hydra will provide. Because if you look at their claims, it is going to provide 1,000 transactions per second per Hydra head. And if you look at their claims that

It’s isomorphic to the Cardano layer one, meaning you can run all the same contracts and all the same infrastructure against a Hydra node. All of that is true. What it misses out on is the subtleties in the design around custody of user funds and things like that. That makes it so that we don’t have to go and learn a whole new Plutus to build on Hydra, but we do have to maybe learn some new patterns for building and designing around Hydra.

And so that’s kind of where that comes from. And, you know, IOG is largely a technical company. I don’t want to throw them under the bus, but they often make missteps like this, where they underestimate how people are going to perceive what they’re talking about. Yeah, humans, right? We jump on the little bits that we’re hearing and get all excited about it and then just start talking about it. So.

With this, does that also mean like developers are building on Aiken at the moment or other smart contract languages, DSLs, can adapt what they’re doing there and their learnings there and implement things on Hydra as well? Yeah, absolutely. So the Hydra runs all of the same kind of, we call it the ledger rules. So all of the same calculations for how you account for UTXO,

spending scripts versus minting scripts, all of the same VM under the hood. So anything written in Aiken can compile down and run on Hydra. With some subtle nuances, I don’t think Hydra provides delegation and staking primitives. So they don’t implement the things like withdrawals and things like that. But for the most part, all of the same tools that we’re building now.

for the layer one work really well on Hydra. And that’s probably a good segue. I know the next thing you wanted to talk about was Gummy Worm. And so as we, like I said, we had a working version of Sunday Swap at Rare Bloom in 2021, 2022. And it was around that time that we were starting to realize this dichotomy, this like, oh, this would actually not be a good product to deliver to our users. It would be an unsafe product to deliver.

And so we started looking at like, hey, a lot of engineering effort has gone into Hydra and it has a lot of really good aspects to it. Can we design a protocol that doesn’t throw that out, right? We don’t want to throw the baby out with the bathwater. Can we leverage what Hydra has built and extend it and make it safer for things like a DEX or a pooled lending protocol and things like that? And so that effort is called Gummy Worm.

It’s something that we’ve been working on on and off. So sometimes we have to put it down for a couple of months while we work on our V3 launch, for example. So we haven’t done a whole ton of gummy worm work in the last couple of months outside of our funded catalyst proposals that are contributions to Hydra that will make gummy worm easier. But the goal here, right? Really what the gummy worm protocol is, is can we keep Hydra for execution for deciding what happens?

and get that fast finality so that if you submit a transaction, you know instantly that it will be included in the stream of transactions and you have high confidence and you can execute at thousands of transactions per second. But just split the custody of user funds separately. And that’s really intended to be a pluggable mechanism so that you can choose how the custody of funds from users is managed.

zero will probably be something simple like a multi-sig, but that can be upgraded with a layer one smart contract or even like a zero knowledge proof system, similar to what Orbis was trying to achieve back in the day. So that’s kind of the long roadmap for Gummy Worm where we want to leverage all of that really great work that’s gone into Hydra for that execution and settlement, but just make it a bit safer for user funds. And we have to make trade-offs there. So like…

things like withdrawing your funds out of a gummy worm head will be slower than closing a Hydra head. And there will be a small, you know, still a slight amount of risk that the, some of the economic activity that happens in the gummy worm head gets rolled back. Whereas on Hydra, you have really strong confidence in that, those guarantees. So like really engineering is all about making trade-offs and saying, hey, what’s slightly less important to us?

so that we can get back these properties that are important to us. And that’s, you know, since that demo that we gave, I’ve been describing Hydra as a family of protocols, like a kind of region in the design space where the version of Hydra that the IOG team is implementing is one point in that space, and then we’re kind of building out an adjacent point, and I’m sure there will be others. I’ve seen Hydra Zoa by George.

and I can’t pronounce his last name, but Florovsky, I think. And Hydralize, I think, is a catalyst proposal that I saw that looks really interesting. I know Trim or Term. I don’t know. I just read people’s names. I never say them out loud. He had a really great proposal. So there’s going to be lots of options. And I think that diversity will help the space. And Gummy Worm is just another point in that. And we’re excited to be building that out.

I will cautious everyone, it’s a very long term effort. This isn’t the kind of thing that you rush. And we’ve got to focus on the things that are out there, like delivering the V3 contracts and some of our other business operations. So it’s really this background burn thing that we think will make a very positive long term impact. But I wouldn’t expect it in the next couple of months or anything like that. Cool. Thank you for those updates around Hydra and scaling on that site.

put a lot of the questions to bed that people have had. So thank you so much for that pie. What about other terms, other ways of scaling? I know that you put out this Kadana improvement proposal. It’s got a number now, which is quite a little bit of a confirmation milestone for the proposal. Can you talk about this one here giving backwards compatibility for V1 contracts to have reference scripts and reference inputs?

Plutus V1 versus Plutus V2 matters to the broader Cardano ecosystem is this notion of reference scripts. Obviously there are a bunch of benefits that you can get from designing for Plutus V2, like reference inputs, where you can make a reference to some other global state without actually having to spend it. So you can have less contention over UTXOs. And…

the difference between a Plutus V1 and a Plutus V2 protocol from those features is going to be great. So there’s still incentive for Sunday swap to upgrade from Plutus V1 to Plutus V2, and in fact, to Aiken. And we can talk about that in a little bit. And for min swap to upgrade. And so there’s benefits to individual protocols from the upgrade. But the reason that we care as a broader Cardano community really just boils down to this reference

scripts feature, which is the feature that says if you publish your script once, you can reuse that publishing many times. Whereas with Plutus V1 or pre-reference scripts, you have to include it in the transaction. So if you look at a Sunday swap V1 transaction, each transaction is something like 14 kilobytes and 10 kilobytes of that is just…

the same scripts repeated over and over and over in every single transaction. The thousands of transactions of scoops that have happened through Sunday swap all just contain repeated data. And so reference scripts allow you to say, OK, I’m going to publish this once. And then in future transactions, I’m just going to point to that and say, oh, go use that transaction. And that cuts out that 10 kilobytes. I think the analysis that we did is something like,

90% of the transactions that use Plutus V1 scripts on average are dedicated to repeating those script bytes. And if you look at the blockchain as a whole, 40% of the chain is just redundant data at this point. And so that’s pretty frustrating. And the reason we care about that at a broader, ignoring any individual protocol, is because that’s taking up space that could go to other protocols.

And so we, you know, a lot of people call for like, oh, these projects should upgrade to Plutus V2, which is true. You know, Sunday is going to get a lot of benefit by upgrading to Plutus V2, as are all other protocols. But one, Sunday V1 is not going away, right? Like, that’s the thing about building on blockchain is these protocols are forever. And in particular, there’s a bunch of projects that, you know, like meme coins and stuff that took 100,000 ADA and their token.

locked it and then to show their community they weren’t going to kind of dump on them, they burned the LP tokens. And so that’s liquidity that’s never going to leave Sunday V1, right? Which means that as that token trades on the Sunday V2, V3 protocol, there’s going to become an arbitrage opportunity, right? If the price changes, somebody’s going to say, well, I can get it cheaper over here. I’m going to buy against the Sunday V1 protocol. So these Plutus V1 protocols

commitments we’ve made as blockchain, right? We want that kind of longevity. We want people to have confidence in what’s there. And so back when we, when IOG was introducing Plutus V2, I made a very strong argument. I fought really hard and, you know, this was back when John Woods was still at IOG and he was on my side and he was advocating for me that we should allow a, you know, Plutus V1 scripts.

We can’t give them all of the new features because that’s going to be a breaking change. And it could change the behavior of the V1 contract, which could introduce bugs in the protocol that they weren’t designed to account for. So we can’t give them all of the features. But I made the argument that this one feature of providing reference scripts, the script doesn’t care where it got its script from, whether it was a pointer to somewhere else.

or whether it was included in the transaction. And so I made the argument that at least for that one feature, we should allow Plutus V1 scripts to be satisfied by this reference script feature. And at the time, the ledger team disagreed. They thought it was too risky. It might introduce a bug. And I think they were very optimistic about people upgrading to Plutus V2 quickly. Fast forward a year and a half, and that hasn’t happened for a number of reasons. I think every protocol is working

upgrading, but we’ve been in a bear market, so the impetus has been less and things like that. But it’s also clear that it’s not going away anytime soon. Maybe Plutus V1 protocols will become less used over time, but they’ll still always be there. And it just takes one or two transactions to really fill up a ton of space. And so I think they’ve now come around to this way of thinking of.

OK, just for this one feature, we can enable backwards compatibility without too much risk to the scripts breaking. And that solves, at least for the broader Cardano community, the Plutus V1 versus Plutus V2 debacle. And basically, we stopped dumping sewage into the river for those Plutus V1 contracts. And there’s still an impetus to upgrade,

it’s less of a public health hazard, so to speak. And so I proposed it. Initially, I was thinking that this was going to be another big fight with the ledger team, and I’d have to do a lot of convincing. So I tweeted about it. I said, hey, your support would be helpful. And they were way more open and receptive to it. They said, actually, here’s an even simpler way that I was originally going to propose, but I thought that it would be too controversial. So I went with a one-step removed proposal.

And they’re like, well, why don’t we just do it this way? I was like, great. That’s even better. That’s fantastic. And they did their own analysis to kind of confirm smog-onized numbers and came to the same conclusion. And it got assigned a CIP 110, if you’re curious to go read it. And it’s now officially been included in the Conway backlog. So it’ll be the next hard fork, the one that introduces Voltaire and Plutus V3 and things like that. It’ll be included in that. And so that’ll be great.

From a practical standpoint, what this means is all it requires is a small code change on behalf of all of the Plutus V1 dApps, where they say, okay, I’m going to publish our Plutus V1 scripts and then reference them to free up basically 40% block space. So it’s like we are increasing the block size parameter and the transaction size parameter by 40% without actually having to increase it, which is great.

because increasing it is really risky from a block propagation and security standpoint. So I think it’ll be, you know, it’s such a simple thing, but it’ll be super, super impactful. So I’m really excited that they were that receptive. That is so good to hear. I did see the community get behind it. I saw Smorg working with you and publishing things online. So, you know, it was just really interesting to watch that process unfold over Twitter and see it being received so well.

And it sounds like what you just mentioned there, it’s not much work for these V1 dApps to integrate through and upgrade their V1 scripts. So I’m excited about that as well, because it will just extend the life of these protocols so they have more time to do the V2 upgrades or even V3 upgrades of their Plutus scripts. And that kind of leads me on to my next question here. Other ways and other methods that…

adapts out there could possibly scale, how Kadana could scale. And I’ve also seen a lot of mentions from you about skipping v2 and going straight to v3 scripts. Can we talk about this? Yeah, so I’ll address that last one first. That may be a bit confusing. So Sunday v3 will be on Plutus v2. The reason we are skipping a version is because

We did a whole rewrite of our UI, and we marketed that as the Sunday V2 UI. And then when we started talking about V2 contracts, people got confused. They were like, didn’t you just do a V2? And so we just made the decision, OK, the next thing that we release is going to be Sunday V3, where we upgrade the contracts. But that’s also confusing. Numbering is hard. Just ask Microsoft. And there’s not.

There’s not any major differences between Plutus V2 and Plutus V3. It’s not the step function increase like it was from Plutus V1 to Plutus V2. So I’m not too worried about, you know, we’re not going to delay our launch to wait for Plutus V3. We’re totally comfortable and really happy with what we’ve got from Plutus V2. All it does is it introduces some new cryptographic primitives that will be helpful for some types of protocols and all of the Voltaire primitives.

the ability to have a script, D-Rep, and things like that. So in terms of other ways to scale Cardano, on the horizon, we’ve got Mythril, we’ve got input endorsers. And if you let me talk, this will be a six-hour podcast. So I’ll just mention them and say, this is a great thing to Google and find more about. And maybe we can have me on again in the future to talk about any of these more in depth. But yeah, there’s Mythril, there’s input endorsers.

I’ve been hearing rumblings of a new Ouroboros version that has really cool features, though they haven’t published the research paper on it yet. So nobody really knows what’s in it. And so I think there’s a really rich long-term roadmap for Cardano, as there always has been. And software, especially high assurance software, is really hard. And so I think that is oftentimes at odds with the very.

chase the hype mentality of DeFi and Web3 because it’s so new and because people are really excited about it. It’s like when a new game launches, right? Everybody wants to, you know, win, win, win, and they get critical of the companies like Steam who delay a release, but you know, if you look at Cyberpunk 77, everybody wishes they had spent more time to release it compared to like Baldur’s Gate 3 where they took an incredible amount of time to build it and it came out as one of the best games.

I’ve been playing a lot of Baldur’s Gate 3 lately. But so yeah, I think there’s a long roadmap for Cardano that is really exciting. And things like Aiken, and we’ll talk about this in a second, but those are really unlocking the short-term gains we need now. I’ve also proposed bumping the memory limits, which I think we can do without impacting the block propagation time significantly, which allows us to fit even more

useful work in a single transaction. And so I think there are ways for us to scale while we wait for these even bigger long-term improvements as well. All right, super exciting. Yes, I will get you on the podcast to talk about Mithril and import endorses. I have been doing a bit of research behind them to get a better understanding of it, but always coming from you, just to get really good explanations. So I will tap you on the shoulder for that interview in the future.

updates from you around Sunday swap v3. You keep mentioning it. I’ve been playing around with it. It is quite nice and each time I come back to it, I see different updates as well. So it’s good to always check back. So if anyone is playing around with it, come back and have a look again because the team keep on rolling out more updates. Now, what can people expect from this particular update? Is it new features being added as well? What can we see?

and what can we play around with once you guys launch? Sure. So the Sunday Swap v3 represents a complete rewrite of the Sunday smart contracts. In effect, it’s a new protocol. It’s a new DAP that’s going to compete for liquidity with Sunday v1 for a little while, much like Uniswap v2 competed with Uniswap v3. That being said, it represents seven months of really intense effort on our part, eight months at this point of really intense effort

strike the right balance between scalability, new features, and getting it out and actually releasing it. So there’s still a whole list, maybe a three or four page document of just bullet points of other ideas we could have included that at some point we had to draw the line and say, if we just toil away on this and try to perfect it forever, we’re never going to release anything. And so we tried to say…

what is the most impactful to release now so that like in the next two years of Sunday Swap, so we just passed our two year anniversary of our launch, in the next two years, the DeFi ecosystem can grow and really integrate with the Sunday Swap protocol while we maybe look at what is the even longer term vision for that next version. The big thing that we’ve been talking about publicly is the scalability improvements. So right now,

the Sunday V1 protocol can, in theory, fit eight orders per batch. And then it hits its execution unit limits. Unfortunately, because of a personally what I consider to be a bug in Cardano, but who the ledger team disagrees, but the inputs to your transaction get sorted by their transaction ID when you run a transaction. And we didn’t realize that until after we launched.

Neither did a lot of other protocols, and then we launched and we discovered that. And what it means is that in order to execute things in the correct order, you need to break it down into small chunks. You need to say, OK, I can include the next three orders because their transaction IDs are increasing, but then the next one that should be processed would get sorted before these. So I need to submit that as a scoop and then build a different transaction with just this one.

you end up breaking it down into these small pieces. And if you do the math, 99% of the time, you’ll have three transactions that you can execute in a batch before you have to make this break. Most of the time, it’s even less. It’s one or two. And so in practice, the Sunday Swap Protocol does an average of two to three orders per batch. And that’s really frustrating. And so we’ve focused a lot on the Sunday V3.

contracts in one, solving that so that we can actually just include as many as we can include, and the contracts will process them in the right order. And that’s really hard to do efficiently. Probably 60% of the effort that went into writing the contracts was figuring out how to do that really efficiently. And I’m happy to say that brings us up to a maximum batch size of 25 orders per batch. So it’s like a 10x improvement over Sunday v1.

But just because we’re focusing on that doesn’t mean that’s the only thing that the new contracts bring to the table. We’ve also really focused on a bunch of features that will make the operation of the Sunday protocol by people like the scoopers and by the DAO a lot more seamless, puts the DAO in a lot more control of things, and builds features that are either

addressing what we saw as a market need or making it easier to integrate with the Sunday protocol. And so Butane, once we launched our V3 preview, moved really fast on this. And they showed an example of minting one of their synthetic assets and selling it all in the same transaction. And that’s technically possible on V1, but it was a lot more awkward to do. And it’s just a lot.

easier to do now on v3. We’ve got a full SDK that you can use to do that. And we’ve got a lot of features in the contracts that allow you to route the results of your swap to different places. Or the swap itself to be owned by a smart contract. So for example, the one thing that was technically possible but really awkward in v1 that’s now really easy to do is you can have a DAO.

that execute swaps, right? And the swap itself, both the incoming assets and the result are owned by the DAO and don’t have to be like first paid out to like a trusted trader to execute the order and then pay it back to the treasury. And so you’ll, we’re really reaching out to protocols to like make them aware of this and like plant a bunch of seeds to say, hey, if you wanna build really advanced features, like

Just to pull an example out of my hat, maybe, oh, I want to sell this JPEG token for ADA and have that ADA go and buy an NFT on JPEG store all in one seamless flow. That’s something that JPEG store could now implement. Or if you want to, I’m trying to think about.

An example I can give that won’t give away one of the kind of secret features that we’re still holding in our bag, but basically just all of these ways that other protocols could integrate with and build a really rich ecosystem that rely on the ability to exchange one token for another. We wanted to make that as delightful as possible. And so you’ll see a lot of that. I maybe I’ll give you an exclusive for for your podcast or your channel. Sure. Sounds good.

The plan right now is to release the white paper and potentially the source code on Valentine’s Day. And so that’ll be our Valentine’s Day gift to the community. And all of the features that we’ve built, barring any last minute adjustments from the audit, will be described in there. And we’ve been sharing the RV3 white paper around with a bunch of builders in the community to get their input. And I think they’ve been tweeting that they really enjoyed the white paper. They found it.

clear and well thought out and they really like the features that we’ve brought. So I’m really excited to share it with the broader community. And maybe I can come back on your channel once it’s all open and talk about all those features. All right. Yes, I’d love to dig into that. So I have to wait a little bit longer to get my hands on it and get a better understanding of it. But that’s OK. I did see that Butane.

post where they integrated in that direct sell of their synthetic asset over to Sunday. And I thought that was absolutely brilliant. I could see a bunch of really cool use cases for that in the future. Hopefully they can also set the price of it when they want to sell it, maybe in their limit order or something like that. So that, you know, you could mint a synthetic BTC and then set a sell price straight away. And, you know, that just makes sense. Like you’re trying to ride the wave and.

make some profits. So if you can get those profits, sell it in one simple transaction order, it just streamlines traders experience. So that stuff is really, really cool. And I hope to see a lot more of that from other dApps as well, integrating in whatever you guys building or what other dApps are doing too. So that’s super exciting. Yeah, we’re excited about it too. Now with

All this work, you also have a few catalyst proposals, or four of them, in fact. If you go to the website, you can check out the current catalyst proposals that are up and running. I’ll put the links down below so anyone else that’s interested can help support you guys. Can we talk through some of these? They seem pretty interesting. I have to say, I don’t understand all of this stuff, but hopefully you can explain them all so that the users here can get a better understanding and hopefully vote for you guys. Yeah, absolutely. So.

We have six proposals that we got funded for in the previous Catalyst round that we’re making really good progress on. And several of them are close to being finished. So for example, the Sunday contracts and the Sunday audit are very, we launched the public test set. And so they’re very close to being finished there. Also, one of our Hydra ones is finished. And the second one is kind of well underway. So we’re making good progress there.

link that you mentioned that’s probably going to be in the description of this video is slash catalyst. We want to make it really transparent about what’s the status of our different proposals and which ones are in the upcoming round and things like that. But with us making really good progress on those, we thought, hey, it would be great to have something lined up to work on after that. And so we made four catalyst proposals this round. So the first one is a UPLC debugger with

kind of Aiken integration. So a vast majority of a smart contract developer’s time is spent trying to figure out why their scripts are failing as they’re writing them, right? Because there’s not really great tools to like understand, what is happening when you execute the contract, it just tells you it failed. Or if you’re lucky, it tells you like, oh, here’s the trace lines that we found.

But they often give really inscrutable errors, or it’s really hard to inspect the state, like what different variables contained which values, partway through your script. And so that can be a real big pain. And people are really used to, programmers are really used to, what’s called a step-through debugger, which lets you go line by line through the code, pause, look at, OK, this variable is 10. This one is.

the string hello and understand the state of your program before you advance to the next step. And so what we’re proposing is that we at least start building that for UPLC, for the underlying programming language that Cardano uses. And so we’ve put some thought. We have a mock-up that I think we linked in the chat that shows what that interface might look like. We’re planning.

This will involve some upstream improvements to the UPC virtual machine that initially Aiken built, but now is maintained by TX Pipe in their, like among all of their Cardano Rust primitives. So there will be some upstream open source contributions there. We’ve already talked to them to make sure that they’re, you know, this isn’t an Aiken feature, it’s its own standalone thing, but we wanted to make sure that it would fit really nicely with the roadmap that the Aiken team had.

It’ll also be, you know, it can, our plan is for it to be used for any UPLC contract. So it’ll help if you’re using Helios Lang or Plutix or, you know, any of these other languages. But because we use Aiken a lot, it’ll have some extra features that kind of tie it in where, you know, maybe there’s a line of UPLC and you want to see the Aiken code that it came from. We plan on implementing that. So that’s one proposal.

The next proposal we have is, you know, we talked a lot about gummy worms. So we really want to sit down and write like a full official specification and white paper for everything from how the protocol works, how contestation works, what the wire format for different parts of the protocol look like, provide reference implementations for that wire format. And we want to do this in the open because what that would allow

other projects building to do is learn from our process, right? Learn, see, oh, they’re putting a lot of thought into this, and they’re discussing this. And maybe we can learn, hey, let’s lift this technique and apply it to our own protocol, or make it far more of an open design discussion here. Right now, because it’s kind of this Skunk Works project internal to Sunday, and it doesn’t have any external funding,

that’s a really risky thing to do as a business because it could turn into a lot of work that a competitor could just take and run away with and us not get any value of it and maybe even get to market with a different protocol that cuts corners, but just by learning from kind of some of the stuff that we did. So it’s not something that we can do without external funding. We’d have to kind of develop the spec and get to a V1 and be confident that like we’re gonna be the first to market with some of these ideas.

so that we can build a business around that knowledge. Eventually it would be open source, but it would be way down the line. And so we wanna do that earlier with a bit of catalyst funding, right? So that’s kind of the idea behind asking for funding there. And then the next two are basically the next steps for the Sunday V3 protocol. So one of the big things that we’ve focused on with this is making sure that

in a lot of ways, the protocol is extensible, right? In Sunday V1 or in other protocols, there is the contracts. They’re all decided at the time that you launch it. And if you want to do something new, it’s a whole new set of contracts. It’s a whole new version. It’s a big upgrade. And so there are some really clever ways where we’ve designed the Sunday V3 protocol and all of our off-chain code to be able to support extensions to the protocol.

And this might come in the form of new types of pools. And so we will probably follow up with a stable swap pool or an 80-20 pool from Balancer. Or we have a bunch of really cool ideas there. The two that we’re asking for catalyst funding for, because we think they’d be really cool, one is a margin pool.

which allows you to trade on margin or on leverage. So if you have 100 ADA and you see a market opportunity and you’re like, wow, I could make a lot of money, but the amount that I’m gonna make on 100 ADA is really tiny, but if I had 1000 ADA, I could make a lot more, allows you to make that bet and kind of borrow the extra money. That’s not quite the right term because you know,

It’s pretty nuanced and subtle how it works, but in a sense, you are trading on leverage, trading as if you had 1,000 ADA instead of 100 ADA. And the result of that, instead of being paid to your wallet, where you could just run away with the extra money that you swapped, is held in a smart contract. And then if the price does move in the direction that you anticipated, you can swap it backwards and keep the difference.

And if it doesn’t, then you can get liquidated. And then that’s just extra income for the liquidity providers in the pool. And so this is really cool for the Sunday Protocol because it allows these pools that allow really efficient price discovery. So if you expect a really volatile asset where market conditions are going to make the price swing really rapidly, then this can be a faster way for it to find what that price is than a normal AMM pool. And it really opens up the broader DeFi ecosystem

the benefits that leverage provides. And so that’s our third catalyst proposal. We’d like to build that out. And then our fourth one is in collaboration with Cora Labs, who’s behind Ada Handle. And the idea there is we want to build a form of permission to DeFi. So we’re in Web3 because, first and foremost, we believe that access to these financial products should be ubiquitous and universal.

And we believe in a permissionless first. And so that’s why we spent the last three years building a permissionless DeFi protocol. But we also think that there’s no point in not enabling, once you have that really solid foundation, enabling other types of permission to DeFi. So things like pools that have deeper liquidity, but you can only interact with them

by having KYC, or even pools that are like, offer a lower fee for loyal community members, right? So you can imagine maybe the snake pool is a 1% or a 3% trading fee pool, but if you’ve held snake for six months, then you get access to the 0.05% pool, right? And so allowing these, this as a primitive that people can choose how they build permissioned DeFi on top of,

would be really cool. And we’re partnering with Core Labs to extend Ada handles to be a key part of this, so that you could have the permissioning tied to Ada handles and tied to the dids that you attach to your Ada handle. And so it’s also, on their end, fleshing out the Ada handle personalization specification so that it can support. Right now, it’s really cool. It supports personalization of your profile picture and your background on your Ada handle.

But that’s just a tech demo, a proof of concept. Really, the Core Labs team wants to use that to attach much richer data. And this is one path of that, of, OK, you can attach your DID to your AIDA handle. And then that’s your one-stop shop for, if I need to provide or prove my DID, it goes through that AIDA handle ecosystem. So.

Those are kind of our four catalyst proposals. As with last time, we’d be happy if a subset of them got funded. So don’t feel like you are obligated to vote for any. We’re kind of asking the Cardano community to help us do things that we wouldn’t otherwise be able to do. But I’m not going to guilt anybody into voting for us. I think it’s totally fair if you vote for other proposals instead or whatever. Right? So.

Yeah, there’s some very interesting proposals there. And like I said, I’ll put all the links and references down below. So anyone that’s interested can read a little bit more about all of them. And if these proposals do get through, I think I’ll get you on again to talk about them as well. I find that permissioned DeFi really interesting, different concept there. KYC and all that stuff. So I would love to dig into that one with you and Core Labs to find out a bit more too. But bye.

Thank you so much for joining me on the episode and talking through all this. It’s been really educational, as always, to talk through all this scaling side of things and learn a little bit more about Sunday Swap V3. Good luck with the launch. I’m looking forward to it. Thank you. And thanks for having me on. Awesome, bye. Thank you. Yeah, yeah, gotta do it like that. You’ve been listening to the Learn Cardano podcast. Gotta get it hype.

crypto is what we like but this is not investment or financial advice gotta do your research cuz it’s risky we know it is this show is educational and it’s informative cryptos the future really it ain’t no debate



Leave a Reply

[learndash_login login_label=" You must be logged in to post a comment."]