TXPipe Just Made Intent-Based Trading Possible on Cardano

So I want to talk to you guys about something called intent based trading or intent based swaps. And this is the idea and concept of being able to give an AI agent or a platform your desired outcome. So let’s say I want to stake my assets in strike finance and get a return on their native staking that they have. But I don’t have any access at all to any of those protocols or even use Cardano.

So the idea here is that I can go to a platform and just use Apple Pay or something. And that would allow the AI agent to take those assets and move it all the way through to the end goal and then set me up with a wallet and hey presto, there we go. So that is the idea of intent. And this is only possible if all of that infrastructure or the development infrastructure is there already.

Now for Cardano, this doesn’t exist yet, but I’ll talk about in a moment. Where it does exist is in other ecosystems such as Near. And if you just pull this up, it’s already pairing protocols such as Monad, Templar Protocol, Near Intents and Sweat Economy. So there’s a lot out there where this is actually happening.

And users are simply saying, this is my desired outcome, make it happen. And the whole process just works. Now this will only work if there is that underlying infrastructure or the APIs are out there for all the different protocols to make it happen. And the Near Intent guys have made this happen.

So there’s a full API layer that actually talks and communicates to everything within the Near ecosystem and beyond. So you can see here, you can use the Intents widget. So it’s like an online widget builder, go through the process of what you want, select the various networks and mash something together. And that is really, really powerful.

So you don’t need to know about all of these protocols. You don’t need to go Avalanche Polygon or BNB Chain, whatever it is. You just need to tell the AI agent, the platform what you want, and it will make it happen. Now for this to happen on Cardano, there are a couple of things that need to be put in place.

And the guys from TXPipe have put this together. This is called TX3. And this is that underlying protocol, that baseline that we need that will give all the dApps in the Cardano ecosystem, that level playing field, or not a level playing field, but a consistent language that other developers can talk to. So essentially when you’re trying to interface with a dApp smart contract, let’s say it’s Minswap for example, and we want to do a swap.

At the moment, you would probably go to the Minswap dApp and do your swap there. Or you could use a wallet that has integrated in and do a swap there, or use DexHunter. And that would interface with Minswap and do a swap there. So all these various interfaces are talking to Minswap, but actually they’re talking to Minswap’s smart contracts.

And if you make that layer available in a software development kit, an SDK, in a standardized way, it makes being able to talk to all these protocols really, really easy. And Minswap do have an SDK, all these protocols do have an SDK, but they’re all different. It’s not like a unified format, a unified language of standardized formatting that developers can just jump in and start using. It’s all a little bit different, there’s nuances, and it makes things a little bit, not difficult, but you have to adapt and learn for each one of those protocols.

And what TX3 here does is allows for a standardized protocol. So me as a developer coming in for the first time to the Kedano ecosystem, I just look at their structure, how things are done, pick it up, and then I can talk to all the different protocols in the same way. And I think that’s really powerful because then you can do some of these things such as intent-based trading, intent-based swaps, intent-based whatever, DeFi. And this is really, really cool stuff.

So I’ve got this interview here with Soundtea from TXpipe, and he talks through everything that they’ve been building in the Kedano ecosystem, but more importantly, what this TX3 protocol is and how it all works. So I’ve been starting to play around with it as well. And some of you may know, I’m building up a bounty platform and a leaderboard platform that uses smart contracts, really basic ones, escrow and tracking. I’m going to use this protocol here to try and integrate in some other third-party dApps.

So if you’re using the bounty program and you want to take a loan to fund some of your escrows, you can. You can take that loan and fund it out, and if successful, then you get something really cool out of it. So I thought that was really cool. And using some of this tech and using what other developers are using out there, I thought was a really good idea.

So check out this interview, guys. Santi goes through quite a few things in regards to what they’re building and how TX3 works. Just to note, it is all open source and it is free as well. So this is a really good way to onboard more developers to the Kedano ecosystem and get them using all the protocols out there.

All right, let’s get into this interview. I’m joined by Santi from TXpipe, and if you’ve ever built anything on Kedano before, you’ve probably touched on some of their infrastructure or some of the things that they’ve built within the Kedano ecosystem. So they’re very in-tuned and they’ve built a lot of really cool things in the Kedano ecosystem. And we’re going to go through a couple of things that they’re doing at the moment, get an overview about what you can experience if you’re a new developer coming in, but then also some proposals that they’ve got in the upcoming voting process as well.

So Santi, welcome back to the podcast. Thank you, Pete. Thanks for having me. All right, so let’s start off at a good place for beginners that are coming in and only hearing about TXpipe for the very first time.

Can we get an overview of what TXpipe is and what you guys have actually delivered for the Kedano ecosystem? Yeah, sure. So TXpipe builds open source tooling for blockchain developers, and we are really focused on Kedano. We started about five years ago and the journey was the typical one for a developer.

You kind of want to get into some new technology, in this case, Kedano, and you start hitting some roadblocks, some pain points. And as if you have a developer mindset, you will probably see, okay, is there a way that I can build something to overcome this blocker? And that’s how we started building our first open source tool, which was called Aura, which is just a chain follower. Since then, we’ve been kind of trying to understand from the perspective of a developer, integrating things in Kedano, what these pain points are, what the ideal developer experience would look like, and trying to reach that goal little by little.

For the past two years, we’ve kind of been aligning everything we’ve done so far into a cohesive approach for building on Kedano, which is called TX3, and hopefully we can get a little bit into that afterwards. Over the last couple of years, what is the proudest product that you’ve built? What are you most excited about that you’ve built over the last couple of years? Well, that will be TX3, but I will leave that for afterwards.

Because I’m kind of excited, I’m really excited about TX3, because I think it’s kind of like the end goal of everything that we’ve been kind of building isolated so far. But one that is already out there, and people are using it quite a bit, it’s called DOLOS, which is a data node, meaning that it’s kind of like a Kedano node, but instead of being part of a consensus, it is meant to serve data for developers that are trying to build the app, integrating some sort of use case and explore a wallet. And the value proposition there is that, first of all, you have a very rich API surface. Instead of having to deal with low-level or borrowed node-to-client protocols, which are kind of cumbersome, DOLOS offers APIs that developers are already used to working with.

For example, if you turn on DOLOS, you will see that you have a block for example. So you have not a full-blown block for us, but a mini block for us. That’s how we call it. So by installing DOLOS, you get a block for API.

You can also get a CUPO API. So the same shape that you will get if you integrate with CUPO, you will have it out of the box already on DOLOS. And last but not least, we have the UTXO RPC interface, which is a new take on how to integrate the apps, which is based out of a Google technology called gRPC, which is like a more performant, more compact, more efficient way of integrating web APIs. So one binary or one process with a very small resource footprint.

I’m talking about two gigs of RAM and less than one core of usage. And you get all of these things out of the box. So DOLOS, it’s probably the one that I’m most proud about because it took a lot of effort. A lot of sweat went into getting all of the ledger internals of the Cardano protocol, which it’s quite complex, working like they should.

But now we have something that lowers your infrastructure costs because you can run DOLOS with much less resources than a full-blown Cardano node. And the experience for a developer trying to query the data is much, much friendlier. It’s really cool. I’ve heard from other developers needing to run something like DBSync, and that’s quite a beast in regards to the resources that you need.

So you’ve got all these mini PCs or whatever running at home or big PCs, whatever, to actually run DBSync so you can actually query the node and all that. So this really brings that cost hardware down and makes it a lot easier to develop on a local network before scaling up and going to production environments. Yeah, exactly. Many people put it in the same category as the Cardano node, and actually I did it when I was explaining how it works.

But a more honest comparison would be against DBSync. So this is kind of like the lightweight version of DBSync where you have query requirements, but you can’t pay or don’t have enough resources to run DBSync, which is a beast. Then you have DOLOS. It’s a good alternative.

Very cool indeed. Do you want to touch on some of your other products that you guys have built over the last couple of years as well? Because the list is big. So these ones here, like DOLOS, the UTXO RPC, which I saw you guys announced just recently as well, they’re absolutely awesome.

But the list goes on and on. You have a lot of things that you’ve built for developers out there. Yeah, we kind of went a little bit crazy. Yeah, you did.

You certainly did. But that shows a little bit that we are passionate about what we do. Some of those projects have modest audiences because they’re very niche and very specific, but they all form kind of like a cohesive picture that hopefully we can discuss afterwards, which is the TX3 umbrella. But some of those other projects, which I think are really interesting, I mentioned Aura.

Aura is a stream processing pipeline for Carvana events. So instead of having to query things like you would do with DVSync or DOLOS, maybe you’re more interested in getting pushed, kind of like a push notification, when something happens on chain. Maybe when an address gets a new UTXO, or maybe when a specific policy of a token gets minted, or maybe when you see a specific label in the metadata of a transaction. Any of these triggers, if you use Aura, you can configure them as subscriptions, and then Aura will notify you whenever this happens.

So in that way, you kind of change the semantics of how developers approach things. Instead of having to pull continuously the chain to see what has changed, you just express, you declare what your interests are in a configuration file, and then you put Aura on top of that, and it will connect to the relay network out there and start listening to everything that happens. Whenever Aura sees that a transaction or a fragment of the transaction matches your interest, it will send an event, and you can push that to either a database, or maybe to a US Lambda, or any of the cloud providers’ serverless offerings, or even a Kafka topic. The list goes on.

It’s a very pluggable system and allows you to connect those two things, Carvana with whatever other message queue you need from the developer perspective. So I think that’s another take on how to integrate things. Yeah, I think I’ve seen some other products and services use it as well to get notifications of simple things like when Ada hits a particular wallet, so you know that you’ve been paid for something, you know, really, really simple services like that. So absolutely brilliant stuff that you guys have put together there for sure.

Now, you keep on alluding to TX3. We might as well dive into it and learn about what this is. I had a quick little look over the website just a moment ago, but talk me through it. What is TX3?

So let’s start with a problem statement, because I think that’s the main hook. Let’s say that you’re a developer and you’re building an e-commerce website, or a mobile app, doesn’t matter, and you want to sell t-shirts. And you get to the point where you have to implement the checkout page, and you have to ship the product to whatever the address of the customer is. You have two choices as a developer.

Would you build a shipping company? Are you a truck driver? Purchase trucks? Put the operations in place?

Or would you just go to an API of an existing shipping company and hit that API and say, OK, I will pay this fee and I will get this delivered? The option is, the spectrum is extreme. But it goes to show that every time a developer is faced with this kind of dynamics where they have to implement a feature, they will probably go for abstracting away the complexity of everything that is not core to their system. If it’s not about selling t-shirts, then you probably should have loaded somewhere.

And that’s the Web2 API experience for developers. They will probably go to the shipping company, go to the documentation site, see that they have an API. an API with one endpoint, one method that says ship package, for example, and they express where they have to pick up the thing and where they have to deliver it, and that’s it. All of the complexity around that was kind of hidden, abstracted away in this little endpoint that said ship package.

Okay, that’s the North Star for developer experience. That’s what we should aim for in blockchain, and we don’t have that, especially in UTXO blockchains, especially in Cardano. Because in Cardano, let’s say that you want to interact with one of the taxes in Cardano, or one of the lending protocols, or with prediction market. In any of these instances, if you want to submit a transaction without having to go through the front end of the actual Dapp, if you’re a developer that wants to integrate some of these features, let’s say that you want to integrate asking for a loan whenever you’re showing real estate options in a website, I don’t know.

If you want to integrate one of these things, not go to the website of the protocol, you’re faced with this same dilemma. How do I integrate that intent that I have with the protocol? How do I call Strike, or how do I call SunnySwap, or how do I call Bodega Market, and just interact with the protocol without having to go through the front end? That means, to do that, developers have to have a very deep understanding of how the protocol works.

It’s not like the shipping example where you have the ship package, and you just put the address and that’s it. No, in Cardano, if you want to integrate something like this, you need to understand how to compose the transaction, what the inputs are, what the outputs are, what the policy IDs are, when do I have to put this hash, how does this validator work, what is the shape of the datum, what is the version of Bluetooth that I have to use, how do I compute the fees, and the list goes on. I could just spit out 50 different things that you have to understand specific about each of the protocols. I’m not talking about learning Cardano, I’m talking about if you want to interact with Bodega Market, you need to understand all of these things.

If you need to interact with DEX, you need to understand all of those specific nuances for DEX. So this is not how we will gain developers. This is not how we get adoption for the ecosystem. We need to be more like the Web API experience.

Enter TX3. The idea here is that TX3 is a way to describe these UTXO protocols in a way that integrating things looks a lot like just calling an API. So let’s say that you want to integrate with some DEX. TX3 is not that it replaces anything on the side of the protocol, it’s a layer on top that declares, that describes, think of it as machine readable documentation that describes how to interact with a protocol at the intent level, at the same abstraction level that you would have with a shipping API.

Instead of having to understand how to put a bet on a prediction market, you just have the method that says put this amount in the yes category, if you want to make a swap in a DEX, you just have an entry on the TX3 interface definition that says make a swap, and you pass token A, token B, and the amount, and that’s it. It’s the same level of abstraction that we were discussing with the other example, which is describing the intents, describing what you want to do with the protocol from the user perspective, and hiding away of the complexity. By providing this interface language, this TX3 file for each of the protocols, what you get is automatic SDKs, so a developer that uses Rust already has, out of the box, without having to do anything, a typed SDK for talking with this test DEX, this other DEX, this lending protocol, the same for TypeScript, the same for Go, the same for Python, this is all automatic, nobody had to do anything, the author of the protocol didn’t have to do anything, they just had to express how the protocol works in a single file, .tx3 file, that describes this interface.

And then suddenly you get all of these SDKs in each of the languages auto-generated from that definition. So a developer that wants to integrate something just comes in, sees the definition, and knows what the intents they have for each of the protocol, and boom, they are integrating that into their own use cases. This is super useful. So, so much easier.

I’m, for the first time, for whatever reason, I’m developing my own DAP at the moment, and I’m learning to construct the transactions, put these validator on chain, and then hitting all of these roadblocks and going, why isn’t this working? What am I doing wrong now? And I’m learning all this. So I know the pain, and to have a simple API, because I do come from the web 2 space, so just have a simple API that I can just crawl through and just submit something to, and just have it done.

That sounds amazing. That sounds a lot better than the hell I’m going through right now. So this is really good. Now, you mentioned having this API, so we can do the lending, doing a swap and all that, and the protocols need to express the way that it works in the .tx3 file.

So what protocols are actually hooked into this at the moment? Yeah. So it’s kind of like an egg and chicken problem because the idea is that we want everybody, all of the protocol authors, to be describing the protocols using this .tx3 language. But until developers are actually using .tx3 to consume things, they don’t have a real incentive.

So it’s the marketplace problem. We need to somehow bootstrap this. So for that, what we’re doing from TXPipe is reverse engineering many of these protocols on our side. We have back and forth with the authors of each of the protocols, so that they get a final sign off and they say, okay, this is how our protocol works.

But we are putting the work to provide this first batch of protocols into a public registry where everybody can just go and see which protocols are already there and just start interacting with that. We have so far worked with Bodega Market, with Strike, with Indigo, with Fluid Tokens. We have a lot of the interesting names in the ecosystem. And hopefully, we just keep going.

And that’s one of our main proposals in this intersite budget season, which is about pushing this TXP registry to the next phase, because we have this vision. We have a vision where Cardano, instead of being just UTXOs and a complex, robust, and very strong consensus protocol, but not only that, on top of that, a rich, diverse layer of APIs where everybody, any developer that just wants to integrate Cardano is one API request away from that. Really exciting stuff. And I think once you do put in some of the work to get the first few protocols up and running and make it a really easy developer experience, others will see the benefit and hopefully contribute to their side of things as well.

So hopefully we see the snowballing effect of that happen. Now, what about AI agents here? I can see AI agents just picking this up and integrating this into things like OpenCLR and making the intent type of transaction, the intent base of a user much, much easier. I’m just envisaging something like using my OpenCLR, having this integrated in at some layer, maybe a skill, MCP, whatever you need to do.

And I can just say, that wallet that I gave you access to, please swap that for some Stripe tokens right now. I want this amount. If you don’t have enough, get a loan and make it happen. Could we see that actually happen with this?

Yeah, you should have said spoiler alert because that was the goal. Sorry, I ruined it. No, on the contrary, yeah. That’s exactly what we’re going for because AI agents feed from semantic context.

If you don’t have, if you provide them with an explanation of what the intents are, what each of the parameters to execute these intents are, LLMs can do amazing things. Right now, if you put an LLM to try to integrate some on-chain protocol directly on-chain without going through this semantic TX3 definition, they will have a hard time. And at the end of the day, I personally wouldn’t trust them because they are just hallucinating things and maybe they put a hash that doesn’t match or maybe they put an input that they didn’t take into account that only computes if the collateral is this or that. So letting LLMs loose directly with on-chain interactions, it’s risky to say the least.

So TX3 being in the middle and providing the right level of abstracting for LLMs because they just present intents, as you explained, I want to swap this for that. They present this as an API method so the coding agents or even LLMs for end users that have some sort of wallet integration could directly interact with the protocol without having to go through a specific front-end. So I mentioned things like, okay, I need to swap this token, this native token in Cardano for USDM. So for that, and then I want to blend it in some liquidity pool and you ask that in plain English to the LLM and they will know how to connect, how to compose these calls to different intents in different protocols to fulfill the whole thing, which is yet another big value proposition because you can now start composing things easily.

We have this tendency in Cardano that each protocol has its own front-end. So if you want to interact with two, you kind of have to go through a website, do something, and then go to the other website and do that other thing. If we express this as API intents that a LLM can safely and easily interact with, suddenly you can start composing things and you connect one to the other automatically and from the user perspective, it’s just a seamless workflow. That’s also an interesting value proposition in all of this.

Yeah, there has been a lot of talk online about composability of smart contracts and being able to tie multiple different protocols together to get the best gains. And I see so much potential out of this. You could literally tell your AI to go and look for the best yields, work it out mathematically, and then just do it. And I don’t know what protocol you’re using, I’m assuming it’s all okay, I wouldn’t have a clue, but we’ll just route everything through the right process and you just sit back and wait and we’ll tell it to do the calculations and voila.

So I’m really excited about this because I’m deep in the AI agent space at the moment. So it took me a while to get there, but I can see the value in this for sure. Yeah, the game has changed for developers and for end users. And I think that this is the right approach.

We actually started TX3 before this Asian revolution, but it just clicks. It just clicks because it’s trying to solve the same problem, which is hiding complexity, making that risky part deterministic and robust, but letting the interface be known by a higher level of abstraction, letting agents and users consume it safely. Very cool indeed. Okay, so this is a treasury proposal within the Intersect budget at the moment.

How much are you guys asking for? How long is the delivery? If we vote for this one as a yes, what will we get out of it? What should we see?

Yeah, so this is one of the biggest proposals that we have. We have a few, as you mentioned. And the idea is that we already have the base for TX3. We have a very robust beta already out there and the developers can start using it.

Actually, a lot of these teams that I mentioned have already tried it out and are providing feedback. In fact, I think, don’t quote me on this, but I think that Eclash itself is using TX3 under the hood. So we already have a very robust version that is production ready. And we have this set of initial protocols that we want to use to get the ball rolling.

The next phase is about finalizing all of the tooling because it’s a lot. We’re talking about integration with coding agents, integration with IDEs, the documentation, the tooling around the registry and all of the security around that and the infrastructure to maintain all of those things. So the proposal is about making TX3 a scale-up to start bringing developers and external users to the protocols directly. Plus, keep going and subsidize the reverse engineering of at least 12 more protocols in the current ecosystem so that they are available in the registry.

So that’s the TX3 one. That’s deliverables. Right, gotcha. Now, before we move on to the other proposals, we’ll talk about them briefly because I know we’re running out of time here.

But for me as a developer right now, to use TX3, what’s my cost? No, right now it’s zero. Everything is open source. There’s nothing, there’s no hidden costs.

Even the registry, it’s publicly available. You just publish the thing that you want and it will be there. So there is no business model behind TX3. And I should say that that goes for a lot of the open source tooling out there from TXpipe and from third parties.

Whenever we are dealing with governance and treasury asks, when you’re analysing one of these open source projects, my ask for the directs is that you analyse it from the perspective of a team that is offering a service and it’s charging for the service, but they are building something that doesn’t have a business model behind it. And the end goal is to make it easier for the developers and operators in the ecosystem to be able to build their own business models. So that’s my little comment in terms of how we see this open source and infrastructure proposals. So no, there’s no price tag attached to TX3.

In fact, please go to tx3.land and you will see how it works. You will get access to the protocol registry. You will also get access to the documentation. And please join our TXpipe Discord.

The link is in the same page. questions, any feedback, anything that you want to add, anything that doesn’t work as you expected, please reach out and we are working full throttle on this, so we would be more than happy to discuss anything that you have in mind. I think I’ll just go off after this and have a bit of a play with it and see what I can break. Yeah.

But it sounds really, really exciting and if some of these ideas are popping to my head, if I can execute them through TX3, then this is going to be a really easy onboarding experience for a lot of developers, so really, really good stuff. Now let’s touch on some of these other proposals, you’ve got quite a few here, so let’s just hit them off as quickly as possible so people know what all these other things you’re actually doing in the ecosystem as well. I wanted to focus on TX3 because it’s the more interesting one, the other ones, sadly they are boring, but boring in a good way. What we are asking is maintenance budget for some of these tools that we already mentioned before, which are already being used by the community and that they are already working ready, some of them have a few features that we want to build, but mainly it’s about keeping them compatible and up to date with the changes at the protocol level and being able to keep up with bug fixes and feedback from the users.

So we have this small maintenance proposals for Aura, the stream processing pipeline, one for UTXO-RPC, which is this new specification for interacting using gRPC against the Carvano protocol, which is, I have to say, not specific to Dolos, this is being used by Amaru, it’s being used by Dingo, and it’s also being integrated into the Haskell node, so UTXO-RPC is becoming slowly but steady, a very common way of interacting with the protocol itself, so there is a small proposal there for the maintenance of the specification. And then one for Dolos, which we already touched upon, which is again, a data node with a low resource footprint for those developers that need to query data from the protocol.

And last but not least, there is Pallas, Pallas is a Rust library, these are the primitives of the Carvano protocol, expressing components that you can integrate in anything that is within the Rust ecosystem, it is currently used by Amaru, it’s been used by Mithril, it’s been used by Blockfrost, it’s been used by a lot of teams out there, so it has become also kind of like a foundational component. And sadly, or not sadly, but it’s part of the deal, every time we have a hard fork, every time we have a new change on the ledger or on the network protocols, we need to keep up with that so that we maintain compatibility. So that’s the last of that set of different maintenance proposals, which are just half a developer, a part-time developer, keeping up with maintenance, patch fixing and so forth.

Okay, and you’ve got one more that I thought was worth pointing out, and that’s gov.exe. And this is a bit of a pilot that you have going in Argentina, I thought you just might want to touch on this one as well. Yeah, yeah, sure. This is the one where we get a little bit outside of our comfort zone, because we are an infrastructure company, so we really know how to do our tools and all of that stuff.

But we feel that we agree a lot with the sentiment of, okay, we’ve had a lot of infrastructure, but now we need some sort of push on the use case side of things. So we partnered with another team, Chief Consulting, which has a long standing experience working with the public sector in the region, meaning Latin, Argentina, being one of those sectors and places. And what we want to do is create a procurement system for the public sector, which is something that they were already working on here in Argentina, in a very big state, which is called Entre Rios, where we have already signed a memorandum of understanding where we are going to be working one way or the other, implementing a procurement system that uses both Asians and Catalano as a traceability layer to improve the efficiency of the procurement within the district.

Again, this is outside of our comfort zone, but the combination of Chief Consulting, which has this long standing experience building this kind of experiences and applying these changes in the public sector with our knowledge of the tech and Catalano, for us, it’s a very interesting opportunity to put in place in a high profile scenario, Catalano, with a clear and very useful use case. This is, of course, all very new, and there’s a lot of things that we don’t know. So the Tresurast is about putting in place a pilot study there where we will be not only trying to achieve an understanding of implementation, but also building a framework so that we can expand that same procurement system to other jurisdictions and make it an open source so that if this works well, and let’s say that the state of Entre Rios in Argentina suddenly improves its purchase efficiency in the state by using the system, then copy pasting this in other places would be zero price tag, zero cost, just an open framework and the handbook of how to do it in the same way as we implemented it in Entre Rios.

So it has a high risk endeavor. There’s a lot of things that could go wrong, but I think that it’s aligned in the right way of trying to build high profile implementations that actually use Catalano and in that way try to expand and scale up. I agree, and I think this is a good direction to go as well, especially when you’re trying to save money and costs through procurement processes that government agencies may go through. I do remember this MOU with Entre Rios a couple of years ago.

I can’t remember what year it was. They all blend. I don’t know what year it is now, but yeah, I do remember that MOU being signed. Yeah, we piggybacked on that and we signed a new MOU specific for this pilot study, but the relationships were there.

So I think that’s an interesting, curious thing. We need to start pushing on these relationships that were already built at the current ecosystem level, and I think that we need more teams exploring these avenues. So we’re really thankful that we have this communication line with the Entre Rios province, and hopefully this is just one more example of how teams in the ecosystem can piggyback on those efforts being made at the foundational entity level. Very cool indeed.

I feel like our ecosystem is maturing. We’ve got some awesome products like TX3 and now we’re looking into implementations in real world as well and hopefully onboarding more and more users and use cases onto the chain. But Santi, I’ll put all of the links and references for all this stuff that we’ve spoken about in the show notes down below for everyone. If you haven’t looked at these proposals, if you are a DREP, I highly encourage you to look into these ones.

The Hydra voting process is open at the moment. It’s open for about another week and a half or so. So please take your time. Don’t take your time.

We’re running out of time. Jump on there, talk to your DREP and get voting as soon as possible. I think TX3 for one is a very exciting project to look into. So Santi, thank you so much for talking through what you guys have been doing, what TX3 has to offer.

I’m pretty excited to go play with it myself now. So yeah, sounds good. Thank you, Ben. So I hope you guys are excited as I am about what TX3 could offer and the other things that the TX pipe team have been doing is pretty cool as well.

Now, like always, guys, if you got something out of this podcast interview, make sure you hit that thumbs up, like, subscribe, hit that notification bell as well, and it will keep you up to date with everything that’s happening in the Kedano ecosystem. All the links and references that Santi was talking about and their treasury proposals through the Intersect process, all down there as well. If you want to support this work, if you want to support these type of interviews and stuff, there’s YouTube memberships down there. There’s also Buy Me A Coffee.

That’s a great way to support the channel. And big shout out and thank you to the TX pipe team for paying for this interview. This is one of my very first interviews that is officially paid for, had to send an invoice and everything for it. So that was really appreciated too.

And hopefully there are many more of those in the future. So technically, this is a promoted post, but it is really, really good stuff that they’re doing. Anyway, guys, hit that thumbs up on your way out. Stay positive.

I’ll see you guys in the next video.