Tangle's Uniqueness
Tangle's multi-asset restaking infrastructure is built to be multi-chain and has notable differences between Eigenlayer and other restaking infrastructures. To start, Tangle has the notion of Blueprints, which are reusable specifications for AVSes. Developers on Tangle deploy Blueprints and users request service instances from these Blueprints. This fundamental difference allows developers to create and monetize services without having to operate the infrastructure for those services. It also puts a focus on reusable service infrastructures that can be deployed with different levels of security and decentralization. Our focus is to build the decentralized crypto cloud, for instanceable service infrastructure similar to what AWS provides for the average developer.
Tangle Blueprints vs. Eigenlayer AVS
Tangle Blueprints are different from an Eigenlayer AVSes. Firstly, a Tangle Blueprint is a specification for an actively validated service. This means that alone, a Tangle Blueprint doesn't represent a live system. Rather, it represents a template for a service deployment that can be instantiated multiple times.
Tangle Blueprints represent an additional abstraction over service infrastructures that allow developers to both create and monetize services without having to operate the infrastructure for those services. For example, every developer interacting with Eigenlayer today is also develping and deploying an AVS. On Tangle, a developer can create and deploy a Blueprint and not manage the AVSes that instantiate that Blueprint. This is the benefit of developing and restaking on Tangle. Tangle Blueprints allow developers to build and deploy service infrastructure specifications in a framework as straightforward as deploying a smart contract.
A visual distinction between Tangle and other restaking networks.
Eigenlayer can be summarized as a system w/ Tangle Blueprints, where each Blueprint is instantiated at most once. That is, for each unique Blueprint, there is and will only ever be 1 AVS running that Blueprint's specification. Note, it is entirely possible for Eigenlayer to support a similar architecture by re-deploying the same AVS multiple times under different names, brands, or whatever. However, this is not the default behavior of Eigenlayer nor is it the intended use in public.
Below we show our diagram for Tangle, with a yellow bar indicating the shared security pool across service instances. Note, the shared security pool only overlaps the first row of AVSes of each blueprint. This is Eigenlayer's default behavior.
Eigenlayer but w/ Tangle Blueprints
Next, we show Tangle's full architecture with multi-asset support and support for reusable Blueprint specifications. Note, the shared security pool overlaps all AVSes of each blueprint. In Tangle, it is also designed to enable AVS instances to self-select the assets they want backing their service. The end-user service requesters can configure an AVS to utilize fewer asset types than are available to them. This is Tangle's default behavior.
Tangle
Developer Focused
At Tangle's core is primarily to be developer focused. This is why our AVS framework is built in Rust. It is also why we have as our goal to make Blueprint creation and deployment as straightforward as smart contract development and deployment. Building offchain infrastructure should be easy! Our Gadget CLI will be a step-wise improvement in the developer experience of building AVSes for any blockchain ecosystem.
Tangle's AVS Gadget also supports compiling to WebAssembly, which allows the gadget to be deployed in nearly any computing environment. The Gadget supports running other program binaries and docker images, and these templates will be readily available in our developer documentation. The Gadget acts as a blockchain analogue to Kubernetes, allowing developers to build complex service infrastructures that interact with cloud services, databases, web infrastructure, and unique computing environments such as TEEs, GPUs, FPGAs and more.
Our Blueprint focused architecture favors developers because it allows developers to build reusable services that benefit any ecosystem. A developer could build an Oracle Blueprint that provides arbitrarily requested data feeds. Users could request many service instances from this Blueprint, each for different blockchain applications and ecosystems. If the service instances are useful and valuable, the developer will earn a portion of the fees generated by the service instances. This is the power of Tangle's Blueprint architecture.
Incentivized Blueprints
Tangle at its core will have a mechanism to incentivize Blueprint creation. This is because the more useful and valuable service instances that are created from a Blueprint, the more fees the Blueprint creator will earn. This is a fundamental difference between Tangle and Eigenlayer. In Eigenlayer, the AVS operator earns fees from the service instances they operate and the generated AVS token. In Tangle, the Blueprint creator earns fees from the service instances that are created from their Blueprint, the operators earn fees for operating the instances, and collectively if the token holders vote to incentivize it, both the restakers and developer will earn TNT incentives.
Inflationary incentives for Blueprints are dictated by the native governance system on Tangle. Token holders vote to add Blueprints to an incentivized set of Blueprints. The more useful a Blueprint is, the more likely it should be to become incentivized in the native governance system.
Operator customizability
In Tangle, operators register for Blueprints rather than for individual AVSes. Registering for Blueprints onboards the operator to the underlying service that may be requested in the future. Operators can require approvals for any service requests, putting them in a position of power to accept and reject operating AVSes for users and applications they do not wish to support. This is a fundamental difference between Tangle and Eigenlayer.
A useful Service Blueprint also makes operators more money, as it allows operators to run multiple AVSes with the same infrastructure. This is because the Blueprint is a specification for the service infrastructure, and the AVSes are the instances of that service infrastructure. Operators can run multiple AVSes with the same infrastructure, which allows them to earn more fees from the service instances they operate. If the service instances are useful and valuable, the operator will earn a portion of the fees generated by the service instances.
Restaking Any Asset
Tangle is built to support any asset type. This means that any asset can be restaked in Tangle's infrastructure. Assets are added to the restaking infrastructure through governance. This puts power in the community to decide which assets should be supported by the restaking infrastructure.