Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
EigenLayer x Tangle - Monetizing & Pricing Verifiable, Autonomous Services: Strategies for a Decentralized Future featuring @zknark
Recorded: April 2, 2025 Duration: 0:36:20Space Recording
Short Summary
Tangle is launching a layer one blockchain focused on crypto infrastructure services and is running a builders program with prizes to encourage developer participation. The platform aims to innovate by creating a decentralized cloud owned by developers, operators, and restakers, allowing for monetization of open-source software. Tangle is also partnering with Espresso to offer decentralized rollup options.
Full Transcription
all right welcome everyone we're back with the third infinite layers this week
the most that we've ever done uh we have a lot going on so i'm excited to bring in drew today
from tangle network uh tangle i'm not going to try to describe it i'm going to let drew do that
so yeah feel free to go ahead and give us a quick intro to yourself as well as your company.
Awesome, yeah.
Thanks Nata for having me on.
I'm Drew, I'm the founder of Tangle.
We're building the layer one for on-demand services,
specifically crypto infrastructure services today.
Hopefully a lot of different web software services tomorrow. These services,
the idea is we build an infrastructure as code SDK to help developers compose, build
infrastructure services, monetize them using our software, and then a platform where they
can deploy them and customers can instance them.
The primary goal being to help developers monetize software faster.
That's been our goal since the beginning.
In addition to helping developers kind of monetize these things and deploy them faster.
Yeah.
Got it. So infrastructure as code is something that's well known
and used in the traditional software space, AWS.
And then there's a handful of other companies
that kind of have, I would say, cross-cloud
or arbitrary infrastructure as code platforms
that kind of work across different cloud environments.
But there isn't really that much that I know of
in the blockchain world. Would you say that you all are kind of work across different cloud environments. But there isn't really that much that I know of in the blockchain world.
Would you say that you all are kind of introducing that idea or paradigm to crypto or has this existed before?
Yeah, I mean, maybe the closest way that it exists today is through these app chain deployment SDKs, right?
deployment SDKs, right? Cosmos SDK, Substrate, OpStack, Layer 2 frameworks are kind of
maybe the first incarnations of infrastructure as code almost. And we'd love to go into this on,
I think the reason for this is how we monetize infrastructure in our industries,
I think primarily driven by these types of platforms right now,
because most of the money, and I kind of did a little, I did a research review before this on
EigenDA, but most of the money that these projects or infrastructures are generating is from
transactions, fees, sequencing fees, data costs, data availability and whatnot.
So right now, I think that's where the landscape is at.
And what we're trying to bring is maybe the now tail end of these types of services that aren't blockchains or aren't layer twos,
but can support general services. And something unique with our SDK, and it was motivated by how we
initially started, is we're building it so that it works in a multi-agent setting. So you are
given this set of tools to launch multi-agent systems. Helps you build oracles quickly, multi-party computations quickly,
and compose these things together to build more and more complex or new services. Yeah.
Got it. So you mentioned MCP, you mentioned oracles. What are some of the use cases that
you see in general that you all would
consider supporting or maybe already support? Yeah, I think right now, a big focus for us
and has been since, for anyone that knows me since the dawn of the company has been bridges.
So Tangle really started, originally, it was a project called called web and we were building a private bridge.
You can think of it like tornado cache style bridge. And we had different infrastructure
components that we needed to launch and launch many of. And we wanted to have an easy way to
spin up, let's say similar to Eigenlayer, like a trust network that people would help run
and that the users could trust. And this trust network had multiple parties in it,
and we wanted to launch many of them. And so we built this SDK kind of initially to support bridges,
kind of initially to support bridges, bridge frameworks.
And so right now we have templates.
We call them blueprints.
So if you're building on Tangle, you build blueprints.
And we have templates with Hyperlane.
So you could deploy Hyperlane security modules as a service.
We've got templates with layer zero.
If you want to deploy DVNs as a service,
they're all open source. So we plan to launch them, but we definitely encourage developers to
use them. I think we're one of three now DVNs open source on the internet. Haven't seen many
others. So even if you wanna build on layer zero,
please use our software, you know,
we're actively contributing to it.
Yeah, we've got bridges.
I actually, we haven't done an MCP yet.
It's mostly NPC that we've been-
MCMC, yeah, NPC.
But yeah, we've done some like generic,
you can do threshold signatures or threshold encryption.
We've done some AI agent services.
So a developer can build an infrastructure for an AI agent system or use one of these to deploy agents into trusted execution environments.
We work with FALA on that.
But I think, and maybe it's where we are in the market right now. I'm definitely, of course, it sounds silly, but shifting my focus to really
what are the types of services that are generating revenue right now or will, because I think there's a lot of tech that we're interested in but we might not have
the users for it so yeah so um before we jump in I know you have a presentation we're going to dive
into before we get into some more um discussion but how is Tangle utilizing eigenlayer or is it
more about some of these blueprints or using uh AVS services that are built on eigenlayer or is it more about some of these blueprints or using AVS services that are built
on Eigenlayer like Hyperlane? Yeah, so I'd say initially it's the latter right now. So our SDK,
you can use it to deploy Eigenlayer AVSs with and you can leverage our tools like peer-to-peer
networking and you can leverage these other blueprints we've built to take an existing piece of software
and turn it into an Eigenlayer AVS
and leverage Eigenlayer for security.
Down the line, we plan to cover the former,
which is have Eigenlayer provide security to Tangle,
to power services on Tangle,
and maybe vice versa. It's a bit of cross-pollination. Because I think, A, we don't know what the cost of security really should be
when you're a customer of these projects. And I can go into that, how we're thinking about this.
I can go into that, how we're thinking about this.
But a lot of what we're thinking about is the sort of AWS model.
Like what's the cost of your customer and you want a bridge or you want an indexer?
How do we get the cost of that as low as possible?
Because I think launching a layer one, for example,
you learn very quickly how quick you can spend your money.
People are all out there.
They want you to pay them a lot of money to run open source infrastructure.
And so I'm hoping that we can kind of put a dent in that market where the pricing becomes a lot more transparent and people can actually invest in it and maybe take a little bit of market share from these behemoths.
Super interesting. Okay, cool. So let's dive into your presentation and then we'll
jump back into more discussion. Cool. Yeah. Let me
just let's see. Okay okay i can share my screen awesome
cool let me know if you can see this yes awesome yeah i mean this is our old
call a pitch deck but uh deck on what tangle is and
sort of how how we've architected it and what we've built and how our tokenomics work today
um and for anyone that's interested to get involved we're running a builders program
right now you can get to it from our website uh Tangle.tools, and come collaborate and build services with us.
There will be prizes for people who build things with specific partners.
Yeah.
But as mentioned, we're building a platform for services and with the goal of being a marketplace for innovation.
So we want developers to build blueprints.
We wanna enable people to restake at any asset.
And we want these developers to be able to monetize
their software through reusable instances
that customers request.
We see open source software as being super abundant.
It's, you know, there's an open source software as being super abundant it's you know there's there's an open
source project that's maintained for pretty much any useful monetizable infrastructure in crypto
and yet at the same time if you're launching a protocol you don't have a decentralized cloud
to actually instance this software and there's also no clear way to invest
in this type of asset class.
So on Tangle, we're building this infrastructure
with the goal that it becomes owned
by the developers, the operators, and the restakers,
the security providers.
If you're a developer, you build these reusable specifications
called blueprints.
You deploy these blueprints on Tangle.
Once they're on Tangle, customers can instance them.
And these instances can serve different user bases, customers.
So you could have a blueprint for a bridge and you might have different
customers who pay for that bridge who use different assets to secure it and have different operators.
So we've taken this notion of like an AVS and we've made this sort of a meta AVS system.
meta AVS system. The types of services that we're we've been interested in, of course, come down to
like restaking is you can do verifiable computations. And I've mentioned that our
infrastructure is geared towards multi-agent systems. So the first thing the customer does,
if they want to instance a blueprint, is they're going to select
the participants. You can select different participants, many, maybe one. You can supply
some configuration options and a payment. And once submitted or requested, there's some logic
on chain that might approve or reject this request.
But if it's approved, there will be a service running. And if there's computations running,
they might succeed or fail. And this framework that we've been building in lends itself really
nicely to saying, you know, what if the computations the operators run have proofs attached with them?
It makes things very hard to falsify or to lie about.
There's a lot of services.
We can consider all the services that
can be done using verifiable computation,
and then the rest we can say, at least I've been calling,
they have quality of service metrics
that might trigger failure. we can we can say at least i've been calling they have quality of service metrics that
might trigger failure um and with this framework we've built a variety of examples
for example you can deploy layer 0 dvns you can use different security validation mechanisms call it um like different types of threshold signatures
you can have different assets that secure them and all monetized differently for different sets of
users um so that's this example we've done something similar with Hyperlane where you can, again, use different ways, assets to secure a Hyperlane instance.
We have AI agents that you can deploy into FALA.
You can, again, restake on these and add custom monetization into your blueprints for different agent frameworks.
frameworks indexers for example is another area that obviously there's big
usage and monetization in our industry but no real open decentralized um instancing systems for
um yeah and this is our ecosystem won't spend too much time there. But I'll tell you about our tokenomics
and hopefully drive this point home of monetizing software.
The way our platform works is when a developer builds a blueprint
and they deploy it to Tangle,
any of the service fees from the instances of those blueprints
will be passed on to that developer. the service fees from the instances of those blueprints
will be passed on to that developer.
Right now, we have it hard fixed on chain.
It can be governed, but 50% of the service fees
go to the developer of this technology.
This is kind of like a way to ensure
there are long-term incentives for that developer
to maintain it, but also benefit from it.
Beyond that, the operators and restakers of these services get like 30% of the raw fees that are
generated from this service. And there could be other custom assets that the blueprint or the customers are using to incentivize the operators
as well. And then finally, the last tranche is like what the platform itself gets.
And within this giant lifecycle, the customer gets this service and they get eventually
guarantees around the quality of service that these operators provide through custom slashing.
that we wanted to drive revenue to it and we want to drive its value through being a security
collateral for services. So if it's being restaked, it generates more, it earns a higher
share of the revenue of the services. But yeah, this is how it's like broken down.
um but yeah this is how it's like broken down um these parameters are governable but the idea is
is to reward developers we want to be developer centric platform um and then next reward operators
and finally reward this infrastructure and the idea would be the developers
eventually own this platform.
They benefit from the aggregate of all of the services that are running.
Yeah, that's what I've got.
I could jump into code if we're there or we could do more questions.
Hmm. Code would be kind of cool.
I really love the revenue sharing thing.
That's kind of what stood I really love the revenue sharing thing. That's kind of what stood
out to me the most. I feel like obviously there's a lot of different people attempting different
techniques for monetizing open source software. So this seems to be a really cool approach
to where you build something valuable, people use it it and you kind of like can you know make recurring revenue based on that yeah i think the the most common challenge here is like copying right but
it's a topic for an entire entire new discussion but it it's something that i think
is like i'm a supporter of the idea of copying code,
like of the idea of like taking open source software
and turning it into something better.
So hopefully we see that happen on Tangle,
but we still see the original creators benefit
from their tools.
Absolutely.
Yeah, do you want to do a cutting demo or anything?
Yeah, I won't do a demo, but I'll show you all.
Or we can, yeah, we can take a look at GitHub or something like that.
Yeah, some repos.
So if you're interested in like keeping up with what we're building,
and we're definitely building a lot,
but you can go to this awesome tangle blueprints page um but i'll show you like layer zero dvn um blueprint we just pushed some new change to it um and i'll also show you like
the hello oh no blueprint template yeah as we go through a blueprint template I mean
if you go to our docs you will be able to install our CLI and using it you'll be able to create
blueprints and these blueprints will get you set up with a library and a binary.
And you can configure it to also create an eigenlayer AVS.
And this binary is what your operators will run.
And the library is something that can be used
and composed in other blueprints um so for this
for example we've got a layer 0 dvn and for anyone that's not familiar with the like layer 0 dvn
flow there's there's obviously a uh dvn tutorial building
end tutorial building.
There's like a tutorial online building these things.
And you can kind of go through.
It's a very short tutorial.
And therefore it should it should be a very short.
Thing to implement.
So this is like the main.
Let's call it main AVS.
You have a handler for processing packets,
and that should tell you whether or not you are the verifier of this packet
and whether you've been paid for it.
And then you implement your logic in this.
We have this type of structure where you can inject any type of context.
You can hook into any type of events that are happening on these blocks and handle them.
This is like a task handler.
And then these would be extensions.
We would have to, this would be now like,
this is a template, of course.
What you'd want to do to ensure that the packet is valid
and what to do in order to validate it.
And let's see, yeah, there's context.
This should be.
So basically you can get most of your business logic done in that one
lib.rs file uh to get started at least yeah exactly you would do it all in the library
and when you want to hook it up now to a node we have this um call it standard uh runner
called the blueprint runner and it functions very similarly to Axum. So if you're
familiar with the Axum HTTP server, you create a router, and what you're doing is routing different
event producers to these job handlers. So it's almost like an HTTP server, except that you can now create any type of event producer
so this producer is is polling ethereum or any or an evm um and you hook this producer with a
consumer and you can filter these events for different jobs so as you can see this is like a router that is going to process this packet and it's going to filter
based on this contract so like it's only going to listen to those events from this contract
and that contract was set up yeah right here i mean the address is to do so you would normally
put this in an environment variable,
and you're off to the races.
Something that's really great that we got working recently
is actually a full end-to-end test now,
where you have two EVMs forming a bridge between each other
and using this DV dvn to verify packets um and commonly what we've seen is that actually
and you can see it here right like testing this stuff is harder than building it in most cases
requires more software and so that's what we're hoping to do with all these little composable bits.
I could show you another blueprint.
This one, for example, generates threshold signatures.
And you can then import this library into a different blueprint.
And maybe you want to run a keygen.
And now you've added a new job to your blueprint by using someone else's job. different blueprint, and maybe you want to run a keygen.
And now you've added a new job to your blueprint
by using someone else's job.
And you can compose these together
to create something more feature-rich or secure,
whatnot.
Similarly, there's this binary that your operators will run on tangle we have some
different type of layers that you're going to filter for um but they all sort of follow the
same structure where you kind of create this runner and this is what your operators run. Okay. Yeah.
Got it.
So when you say that this is what the operators run, you're still kind of like talking about the individual unique, like
business logic of that, of that, I would say, implementation for
what you're trying to build in that one that one lib.rs file and that's kind
of where you would start right yeah you can think of it like the library is your http routes and
that main rs is you starting the server okay and the idea is that you can plug in peer-to-peer networking. You can use some of the more complicated tools in the SDK
to build like a multi-party computation
or to run a full consensus protocol
in your, let's say, library.
Okay, that was really helpful.
And I think that what I like the most about kind of like what you all have done in the sense of tailoring for developers is that you have a lot of content that's out there in terms of reference architectures and examples and just code for people to kind of dive in and run because that's kind of the best way to get started. Obviously documentation is great as well, but I feel like a lot of times I've seen
certain teams and companies launch and then there's not really much there for developers.
I think what you all have provided is just a lot to work with. I'm curious, what are some of the
teams that you're excited to work with or that you're already maybe working with or maybe that you feel like might make sense
to work with in the future?
Yeah, I think, so this goes to like monetizing
this type of tech, right?
And it's where infrastructure is code.
So I think the right question is,
what infrastructure do you monetize?
And the market right now says like roll-ups,
data availability, sequencing, bridges,
oracles, and these are all quite saturated, right? I think you guys are doing DA really well,
so it doesn't make sense to like build more DA, right? There's probably enough DA
and maybe enough oracles, But I think something I still
see today, and we want to make the developers' life and experience more interesting and easier,
is actually, I think still deploying rollups is cumbersome. So we're working with Espresso to build rollup as a service blueprints
so that users or customers have other options
beyond these centralized RASs.
And maybe these blueprints can be fine-tuned to use EigenDA
as well as their own custom DA stuff.
But just getting to a one-click decentralized roll-up is,
we don't even have it yet today, I think.
So that's something like we're hoping to do with this sort of library binary structure.
These libraries, they can provide quick ways to run through people's tutorials,
especially espressos.
We've done it with just the Arbitrum Nitro stack.
But we found like, yeah, it's still cumbersome to go through their tutorials.
Yeah, I think with oracles and bridges specifically, there's a lot of design space there that can allow someone to build to build something that's unique that doesn't already exist that can bring value that might not be the same see data
availability is kind of just like a very you know basic uh very low level component there's not a
lot of you know innovation that can really happen in the sense of like what you can do there you're
just like storing data right for a couple of weeks but for oracles you can actually bring all types of real world information like on chain with bridges
there's a lot of different ways that you can kind of consider what networks to implement and like
you know how that actually looks so i feel like yeah there's just a lot more experimentation that
can kind of happen in those in those areas sure i think yeah i mean it's a good it's a great one um bridges i
think bridges and oracles almost fit our sdk like the best um but the re the yearly revenue of them
together i don't think technically compares to how much these sequencers are generating right totally totally
but i think this is a good question like you know and this has been my challenge now like even this
week last week is really sequencers right now might be making um the revenue is around maybe
200 to 300 million a year right now. Maybe I'm off hugely on that.
I'm not sure.
I'm not sure what yours is and EigenDA,
but I think it's a couple million a year,
I imagine, of revenue.
I'd be wrong.
You're talking about for EigenDA?
Yeah.
I don't have the numbers,
but yeah, I mean, we have customers
and they're paying revenue.
You know, revenue is coming in based on usage.
It is an actual like almost crypto type of software as a service product.
Yeah, I mean, it's like clear that if, you know, the roll ups are generating a lot of revenue, the sequencers.
They're spending that revenue.
They seem to be kind of like where, you know, there's a lot of value capture in general.
Kaido from our team wrote a blog post that made the case that it's a lot more, it makes a lot more sense from many perspectives to launch an L2 versus an L1 based on that argument, actually.
based on on on that argument actually um it's it's definitely really cool uh he's done a lot
It's definitely really cool.
of great content in terms of um you know here and there explaining his own ideas as well as
eigenlayer but um yeah definitely check out his blog post i can kind of maybe link to that yeah
nice yeah i mean on on oracles i'm curious i don't know if you have these thoughts but i'm close with some oracle
company founders and it's it's a very competitive landscape right like you've got a finite set of
d5 protocols and the large amount of the business is like providing price feeds totally maybe you
do it cheaper than others but bringing more niche data on chain, I don't know if we have the demand for it yet. I mean, it's a cool.
very, very like unique, or you have an implementation of
something like a prediction market that you want to build
that you think is going to be amazing. And you want to kind of
bring some of that real world information on chain, it'll be
part of your application as opposed to like an open
infrastructure that other people use and you monetize. That's
kind of the way I would look at it. It's kind of like, and more
of an application specific thing. So if you build a really
cool prediction
market, you want to kind of have full control over what data is available for your, for
your application, you can just kind of build it and you don't have to rely on someone else.
That's kind of the way I'm thinking of it in general. So
cool. Yeah, I think that could be a good angle to think about it with. Obviously, you have like
projects on Eigenlayer doing generally providing the framework or the SDK for web proofs,
ZKTLS proof. So it's like, hey, here's how you could build applications on us.
But I wonder how they'll monetize. It could be a very great business to be running,
like monetizing per query or per proof. Yeah, it's something I'm trying to think of. I mean,
on that topic, like we're building now, I don't know if you're familiar with RFQ systems,
building now, I don't know if you're familiar with RFQ systems, but in finance, in trading,
and mostly since the days of 0x, when you wanted to get good order matching of your trades,
you wouldn't do this on-chain. Long ago, we couldn't support order books on-chain.
So what you would do is we would have these protocols
where you would gossip your request for a quote
on what the price of some asset is.
And you can do order matchmaking off chain.
Right?
So if you wanted to buy some assets,
you could find some sellers off chain on a on a gossip network
and we're doing this right now tangle for like cloud services so if you want a service you're
a customer you maybe you want maybe we get to this point where you want a data feed
that's how maybe i'll think about it you want a data feed and the market will give you a bunch
of prices and you can choose the cheapest or you
could choose by maybe some reputation. Maybe you want an RPC, right? You want these infrastructure
services as a customer and you maybe, you don't know this is happening under the hood.
It's like a kosh, right? You just see prices and you can pick.
it's like a kosh right you get you just see prices and you can pick um but i think that's how
our our cloud should be um like what's the value prop of the decentralized cloud it's like
it's open permissionless people can charge whatever they want and if they can find customers
and if they can find customers,
like we should be competing.
I think how Kosh brands is like,
they have cheaper cloud, right?
So I think maybe we're kind of trying to get to this place
with all this infrastructure.
Totally. Awesome.
Okay, well, this has been really helpful
and I appreciate you coming on
and spending some time with us today. So before we wrap it up, what are some things that developers can kind of do to kind of start looking into building on Tangle and connecting with your team and maybe your community?
Yeah, definitely. I mean, if I could present one last thing.
last thing yeah let's do it i would say uh come to tangle you can get to our builders program here
Yeah, let's do it.
you can apply here um we're running it's not even going to be four weeks it's going to be
some continuous education there'll be continuous um hackathon programs where we will
continuous hackathon programs where we will kind of take you through end to end building out these
blueprints and we'll get you effectively started with either wrapping some interesting open source
tech and deploying it or building something new from scratch. There'll be workshops and there'll
be hands-on education from my team.
And yeah, we would love to have you join us.
We've got a lot of examples we'll be educating you through,
and we can help work together to find customers
for these things.
Awesome, I love those types of programs.
So kind of brings people in and gives them kind of like guided advice and win-win situation, I think.
Yeah, for sure. And there will be some great sponsors and hopefully prizes that you can earn by working with us and through these programs.
Awesome. Cool. Well, thanks for coming on today and thanks for your time and everyone that
came by to watch thank you for your time as well we're going to link to tangle and some of the
different uh repos and things that we were sharing today in the comments on youtube so if you missed
some of this or if you want to just go get those resources those will be up in just a few minutes
so that wraps up uh this episode Infinite Layers with Tangle.
Thanks for coming through.
We're going to have more starting next week.
Bye, everyone.
Awesome.
Thanks for joining.
