Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
All right, I've got a pretty interesting one here. I've
got the team from m Labs. I've ben Hart, Chase
and Luke joining me on this episode to talk about
their implementation of babel fees called Fezer. I like the
name here, guys, welcome to the podcast.
Speaker 2 (00:16):
Hi there, Thanks for having us, Thanks for having us.
Speaker 1 (00:19):
Okay, so this implementation is quite interesting. I've got a
little bit of a sneak peek into this one, so
I've got a bit of an understanding here. But can
we talk about firstly what babel fees are and what
your Fezer implementation is going to achieve with what you're building.
Speaker 2 (00:36):
Sure. So, babel fees is a paper that's been around
in the Carodino community for quite some time. It's a
feature that has been sort of advertised that it would
come to Cardono eventually. It's taken a very long time,
and the fundamental idea is that you should be able
to pay network fees for transactions in more than just NATA,
(00:57):
and the paper kind of describe a process where spos
could essentially be receiving a bundle of tokens that might
represent their fees, or that it would be sort of
a voucher system where they would have ad US wopped
out for them. So there's these kind of awkward situations
(01:22):
where you're kind of asking spos to receive tokens that
they might not be interested in receiving. I think a
lot of spos, to be clear, are quite happy to
receive most major card on a CNTs. But at the
same time, it's I can see why it took so
(01:44):
long to implement this because it's quite complicated. It did
require that we at least have a dex on chain,
so that limited until well after Plutus, and at this
point we realized that the ideas in Babel fees are
quite good, but there's a leaner implementation that we could
(02:06):
make that would actually solve more problems. So not just
network fees, but also min aida and also transaction collateral
can all be handled by a service today without changing
the ledger. So this is a project that we've been
pursuing across the last few funds of Catalyst, and now
we can launch it as a service. It's gone through
(02:27):
an audit with certa K and it works in a
single transaction where people are able to swap out their
tokens for ATA we're going to launch with a white
list of at least the top ten or fifteen native
tokens on Cardano, and at this point, people will also
be able to yeah, skirt those other issues that are
(02:49):
just more reasons why people who are maybe new to
the chain would have to go to otherwise, maybe to
a centralized exchange. So fees a swap allows people to
to really seamlessly make these make these transactions. And what
we'd like to do is actually get integrated into some
of Cardano's wallets as well as Cardono DeFi apps as
(03:13):
well and other verticals within the DAP community. And the
reason for that is you're able to interact with those
smart contracts just the same without without any ada. So
where I see this as really useful as maybe someone's
got a ton of stable coin and not much aida
(03:34):
they would be able to say, go into liquid and
start getting yield on it, get ata out that they
could go and transact elsewhere, and again you never have
to go into a centralized exchange and have that leg
time where you're going through KYC.
Speaker 1 (03:51):
Gotcha, Okay, So I'm trying to picture exactly how the
user experience will be when they're going to a certain platform.
You painted the pitch there just before I was going
to ask. So someone coming in with maybe some wrapped USDC,
coming in by one chain into the condundit ecosystem, and
then where they start they have to swap for AIDA.
(04:13):
Then they can start then swapping AIDA for another condundatay
of token. So can you explain with FeSO how that
experience might work instead, So the user comes in with
wrap views DC, what happens next?
Speaker 2 (04:27):
Right? So I think you can picture any transaction that
currently happens on caron onto with like a widget at
the bottom that says like use Visa swap pay token,
pay fees in and select your currency, right, and then
you know, you may have a link to some terms
of service and you can go and sort of just
essentially check a box to decide, Uh, yeah, I'd like
(04:51):
to opt in to FESA swap services. Under the hood.
What that means is we're going to rebalance the transaction
and you're gonna pay just slightly above dex rates for
those for that exchange.
Speaker 1 (05:07):
Right, So I'll just stop it. So you said like
a widget within that experience, So this is in the
wallet that will pear at the widget wippear on the wallet,
and then it could appear.
Speaker 2 (05:17):
On the wallet or it could appear within a DAP
so you could see it like on Liquid, you could
see it in Indigo for example, or on any of
the decks. Is So we're really looking to have integrations
across both of those spectrums and in game experiences as well,
where people are able to take advantage of those of
(05:38):
the service and opt into what essentially opt into this
sort of mode of working on Cardano where you're not
necessarily working with Ada, where instead you're working with our
ATA and you're sort of swapping things out in parallel
with whatever else you might be doing, whether it's point
to point or interacting with a dap.
Speaker 1 (06:01):
Okay. You also mentioned in that last sentence are Ada,
So there's still eighter involved within the process, just the
user doesn't need the AIDA.
Speaker 2 (06:10):
Correct, we're essentially trading your token for ADA, Like, yeah,
we haven't made any changes to the card on a ledger,
it's still taking ADA for the fee.
Speaker 1 (06:19):
Yeah, yep, yeap okay brilliant. Now the other platform out
there that's doing something very similar Aquarium from Fluid Tokens.
I've got a really good understanding of how that one works,
and there's like a batcher or some code that the
sbos need to run in the background to actually process
those particular transactions, So it's a bit of off chain code.
(06:42):
Does feeser have anything like that that sbo's stepbook operators
out there can take advantage of and be part of
this ecosystem, because I remember in the original white paper
for Babel fees there was that type of encouragement for
bos to trade and accept those tokens. Whatever's going through
(07:04):
SPO is involved in this one. It sounds more like
a smart contract involvement for this.
Speaker 2 (07:10):
Yeah, I'm going to let Chase answer the broader question
around parallelization, but we didn't do batchers, and spos are
just as involved as they are in standard cardono transactions
with this one. They receive ADA exactly the way they
normally do.
Speaker 3 (07:27):
Yeah, So, as Ben said, the spos are involved just
like normal transactions, but instead of batchers. The way fesis
war works is that so firstly, we don't submit sort
of a transaction that has to be batched later on
to be fulfilled. We actually just return you the augmented
transaction immediately. So it's a much smoother kind of flowy
(07:49):
user experience. The way we deal with that is that
we have on the technical side, we have orchestration in
the background that essentially manages this whole handling of like
uh which what we call positions, Which positions we're going
to choose to handle this sort of you know, swapping
tokens for ATA, and then we handle all this paralyzation
(08:14):
and contention management basically in the back end. However, it
is as you said, basically just a smart contract that
augments any transaction that you give it, and it'll return
a transaction that is ready to submit immediately for the user,
and it will include that fee swapping with our automatic
(08:36):
wallet that will give you a you know, some amount
of ATA that you can use for as Ben said,
transaction fees, collateral, mineta, anything like that within the transaction
that you previously had. So which is going to rebalance it.
We're going to manage on the back end the orchestration
to choose with minimum contention which auto wallet we assign you.
(09:03):
And basically the back end handles all of this orchestration,
and what the user gets at the very end is
a transaction that is immediately ready to submit does not
have to be patched literal at all.
Speaker 1 (09:14):
That sounds cool. That's different to what I'm experienced at
the moment, So thank you for that explanation. Now, in
regards to the fees and a revenue source for this,
so I'm assuming there's a fee you Ben you mentioned
there's going to be a slight markup on the Dex
transaction or whatever it might happen. What are we looking
(09:34):
at for this service.
Speaker 2 (09:37):
Yeah, it's going to be a fairly minor fee, like
something to the effect of ten percent of your fees
will end up funding the operations of the app. What
I'd say is like, largely, we've been able to be
(10:00):
strap the service through Catalyst, so that leaves us without
a huge amount of development costs to recoup. So largely
what we've created is an environment where we're not looking
to make huge, huge amounts of money. It would be nice,
but at the end of the day, we're really looking
(10:21):
to create a situation where we're just isolated from risk
as we're providing the service, and that little percentage bump
make sure that if it takes us some time to
get back to a Dex and swap things out, that
we're never going to experience loss in that process. That's
the main effort. We'd like to make a few dollars,
(10:42):
but it's not necessarily something that's going to drive m
labs as a whole. We always have a lot of
different business lines. This is just one of them, and
a fairly small one. But the goal is really to
provide just a more usable experience, especially for I really
think the gaming ecosystem at the end of the day
is going to see a lot of use out of this,
(11:04):
just because like a lot of those tokens aren't necessarily
listed on DEXes, and this is a situation where they
can come to us to essentially be a liquidity provider
for fees for their users over the course of a
month of operations or however long they want to engage
with us. And this is going to let tokens that
(11:27):
normally wouldn't get listed or don't have huge amounts of
liquidity still be able to provide like aight to fees
for their users if that's how they want to use
their token essentially, or if the token has created independent
value through its use in the game, to sort of
bring that value into the real world a little bit
(11:47):
more and again, just that user experience of not having
to go to a centralized dex and go get ata
I think is going to lead to a much more
pleasant onboarding experience for caronno users.
Speaker 1 (12:03):
Yeah, I definitely think so too. Sounds absolutely awesome what
you guys put together. Now, my very last question here
is around the implementation of this. I'm assuming you guys
will have a revenue source for implementing it for various projects,
So that's one thing. But if a project wanted to
go out and start implementing it themselves, how much time effort,
(12:25):
development costs will and how long would it take for
them to implement something like this.
Speaker 2 (12:32):
So, if you're using our APIs, our goal is that
people adopting this could pick it up and inject it
into their wallet, injected into their DApp over the course
of an afternoon. Right Realistically, like this should be like
as we get the website up, you'll see it's just
a handful of lines of code, and like one of
(12:54):
those is just an import because we'll be publishing an
NPM package. But at the end of the day, we
want this to be a really smooth experience to adopt.
It shouldn't be like it's not just for Haskell companies.
In fact, we're mainly focused on people who've got their
back end in JS, and we will have other SDKs
(13:14):
come out over time. Even if you have to do
raw HDP calls, you should be able to do this
in an afternoon or a day pretty easily. We'll have
quite good documentation. This should be pretty low friction for
someone to bring into their DAP or into the wallet,
and obviously we recognize that these products have larger release
(13:37):
cycles than that. It probably won't be that immediate, but
we don't want this to be a big lift. We
want this to be really really low friction, and there's
no reason why it needs to be high friction that
we found just yet.
Speaker 1 (13:49):
Awesome. That sounds absolutely brilliant. All right, guys, is there
anything else that you want to include on this before
we sign off?
Speaker 2 (13:56):
I would just say that it's launching within the next
sixty days and we should see something on pastnet very soon.
Speaker 3 (14:05):
Do we want to mention the c CIP we're working on.
Speaker 2 (14:09):
Yeah, we could mention the CIP. Thank you, Luke Chase.
You've written a CIP, you want to tell people about it?
Speaker 3 (14:14):
Uh? Yeah, So I'm still working on the CIP, but
essentially our goal is to standardize this HTTP API that
we talked a lot just a bit ago, right, So,
as Ben said, it really won't take more than an
afternoon just to use this API, but we do want
to standardize this as part of it as part of
a CIP, so that our goal is to essentially have
(14:38):
this kind of a transparent API with the transparent behavior
and that you can expect and maybe potentially other services
can also follow along with this API, and that's the
goal of the CIPH. You should be able to see
the CIP up on the you know, as a PR
on the Credit and Improvement Proposals rebook soon. It is
(15:01):
basically a finalized draft that we're working on reviewing right now,
and yeah, it should have In fact, when that PR
is up, you should everyone should be able to see
just you know, how easy it'll be to integrate it
because it's literally just one HDTV call and all the
expected behavior and everything. It's all in the cap as well.
(15:21):
So yeah, okay, brilliant.
Speaker 1 (15:25):
If I managed to get the links for that before
this interview is published, I'll make sure it's in the
documentation and show notes down below, and I'll gather anything
else I can find about freezer as well put in
the show notes. But gentlemen, thank you so much for
joining me on this episode and educating me a little
bit more about Babel fees and what you guys have
been working on.
Speaker 2 (15:47):
Thank you so much for having us, Thank you, Thanks
Speaker 1 (15:50):
Awesome, Thanks guys,