Overview

Enso provides blockchain infrastructure designed to abstract away the complexity of smart contract interactions for developers, users, and AI agents alike. Enabling an intent-based paradigm for transacting on-chain, Enso is built as a Tendermint-based L1 chain and offers APIs for developers to declare integration outcomes without handling the intricate details that come with building on top of blockchain smart contracts. The vision is to unlock new areas for innovation by building on-chain products that allow protocol teams to focus on their core strategy and not fall behind or waste time on complex workflows.

Due to the permissionless nature of public blockchains, any developer can already get started and build dApps on top of existing smart contracts. This property is called composability and consists of building new products by adding extra components or enhancing the functionality of existing smart contracts on-chain. However, this requires not only technical expertise, but also time, costs, and extra caution to not introduce vulnerabilities or new attack vectors as a result. Enso addresses this challenge by empowering developers with custom middleware solutions.

Enso itself refers to a network composed of multiple components, including participants that can be classified into Action Providers, Graphers, and Validators—each playing a role in ensuring the network’s functionality and security. Enso’s Shared Network State is the unified data layer that stores and makes available smart contract interactions for developers via the Enso API.

The Shared Network 

Enso’s Shared Network State is designed to aggregate and store smart contract interactions across multiple chains. It provides a unified data layer that enables seamless, efficient, and optimized execution of intents by abstracting the complexities of blockchain integration.

The Shared Network State was created to address key challenges in blockchain development, including:

• Fragmentation: Blockchain networks operate in silos, making it difficult for developers to build cross-chain applications.
• Complexity: Managing interactions with multiple smart contracts across different chains is time-consuming and resource-intensive.
• Scalability: Traditional approaches to blockchain integrations are not sustainable as the ecosystem grows.
• Security and Consistency: Ensuring reliable data consistency across different blockchain states.

The Shared Network State aggregates and structures data across multiple blockchains to facilitate intent execution. It collects and stores contract interactions from various supported blockchains, maintaining a real-time state of smart contract relationships. This data is then organized into standardized formats to ensure compatibility and ease of access, defining common action types like swaps, lending, staking, and approvals.

The system maps optimal pathways for executing these intents, considering historical performance and current network conditions. Before execution, validators ensure the accuracy and security of this data, implementing redundancy mechanisms to maintain data integrity, thus providing a robust framework for developers to interact with blockchain ecosystems efficiently.

Key Features of The Shared Network
Standardized Data Models	Provides a consistent framework for integrating smart contracts, reducing development overhead.
Real-Time Updates	Ensures the latest state of blockchain interactions is readily available for execution.
Efficient Execution	Optimizes pathways to minimize transaction costs and maximize efficiency.
Security Measures	Validators perform simulations and checks to maintain system integrity.

Actions

Actions are the lowest level of granularity within the Enso Engine. They are standardized smart contract interactions designed to enable users to engage with various blockchain protocols without the need for custom integration code.

Each Action represents a discrete on-chain operation, following predefined execution rules and input/output structures. This ensures standardization across different applications and protocols like lending or borrowing on AAVE, swapping on Uniswap, minting an NFT on Opensea or registering a domain on ENS, making them highly reusable.

Actions are modular and developers can combine multiple actions to construct complex workflows tailored to specific needs. Actions are optimized for efficiency, aiming to minimize gas fees and execution time, while also being subject to rigorous security validations by the network to ensure they adhere to best practices.

Examples of Actions:

• Token approvals
• Deposits into lending protocols
• Swapping assets on decentralized exchanges
• Staking tokens for yield generation

Shortcuts

Shortcuts are pre-configured combinations of actions within the Enso Network. They automate multi-step workflows into a single transaction, significantly simplifying user interactions by bundling related operations. This approach not only reduces complexity but also enhances execution efficiency through automation, allowing users to execute complex operations with minimal input.

Examples of Shortcuts:

• Swap, lend, and stake assets in a single action
• Portfolio rebalancing across multiple DeFi protocols
• Yield farming with automatic compounding
• Liquidity provisioning

Actions are the fundamental building blocks, while Shortcuts utilize them to deliver comprehensive, end-to-end solutions for users. When a user submits an intent, such as “maximize yield with my ETH,” the Enso engine identifies the Actions needed to fulfill this intent. These Actions are then bundled into Shortcuts, which execute them as a single, optimized transaction, ensuring that the user receives their desired outcome efficiently.

Currently, developers can integrate Actions and Shortcuts into their applications using Enso’s centralized APIs and SDKs.

The Enso Engine

Enso’s Shortcut Engine is the non-custodial middle layer between users and blockchain networks. Intents represent desired outcomes rather than the specific steps to achieve them. For example, instead of writing code to execute a series of transactions to swap tokens, lend, and then stake, a developer using Enso would simply define the intent of “I want to swap these tokens, lend the result, and stake the lending proceeds.” Through an intent-based execution model, Enso abstracts complexity and improves accessibility, allowing developers to build more quickly.

Unlike traditional transaction-based systems where developers must specify each action or transaction step-by-step (an imperative approach), the intent-based model is fundamentally declarative. In a transaction-based model, each action needs to be explicitly programmed, which can lead to complexity and errors due to the need for detailed knowledge of each blockchain’s mechanics.

In contrast, the intent-based model used by Enso allows developers to declare their end goals, with the system figuring out the execution path, simplifying the development and the integration process. The integration of Enso with on a DEX aggregator like LI.FI and a multipurpose wallet like Infinex demonstrate some use cases. Enso Shortcuts make these intents ‘real’ by providing reliable paths for this execution, shifting the problem from the developer to the system’s solvers.

The Centralized API

Enso supports interactions from both Externally Owned Accounts (EOAs) and Contract Accounts (Smart Wallets).

Applications allowing EOAs to engage with their platform can leverage Enso for all tokenized interactions, where certain DeFi protocols associate transactions with tokens issued to the user’s wallet. For example, lending on Aave results in receiving a tokenized representation of the loan, such as aDAI for DAI deposits.

When interacting from an EOA, all resulting tokens are sent directly to the same account. For instance, if a user swaps 10 tokens, the corresponding 10 tokens will be credited to their EOA.

On the other hand, applications that enable Smart Wallets to interact with their platform can use Enso for both tokenized and non-tokenized interactions. Contrary to tokenized interactions, some DeFi protocols do not issue tokens representing user positions—for example, depositing on Liquity does not generate a tokenized representation of the CDP, and borrowing on Aave does not create a tokenized position reflecting the debt.

When using a Contract Account, both tokens and state are stored within the contract itself. For instance, if a user borrows on Aave and then leverages the borrowed assets, the borrowed tokens and leveraged position remain managed within the Contract Account.

Developers can integrate Enso using three different APIs: (1) Router API, (2) Bundler API, and (3) Metadata API.

Router API

The Router API is a DeFi aggregator and routing service. It finds optimal paths to swap tokens, enter positions, and maximize yield across protocols. You pass in tokens, amounts, and constraints. The API returns transaction data you can broadcast, along with a simulation. It supports various routing strategies for EOAs, smart accounts, or deploying a new smart account.

Bundler API

The Bundler API packages multiple DeFi actions into one transaction. It deploys a minimal smart wallet controlled by the user, then executes all operations through that wallet. By bundling more actions, users often see significant gas savings:

Metadata API

The Metadata API provides token, protocol, and wallet metadata for Enso-supported networks. It uses REST endpoints to retrieve information essential for DeFi operations. Integrate it to quickly access data on tokens, protocols, and the Enso smart wallet.

Available Endpoints:

Enso

• GET /v1/tokens – Lists all supported tokens.
• GET /v1/protocols – Lists available protocols.
• GET /v1/networks – Shows supported networks.
• GET /v1/actions – Returns actions for the Bundle API.
• GET /v1/standards – Lists supported protocols.

Wallets

• GET /v1/wallet – Retrieves smart wallet details.
• GET /v1/wallet/approve – Generates a transaction to approve wallet spending.
• GET /v1/wallet/balances – Returns wallet balance.

Network Participants

The Enso Network operates through the collaborative efforts of three key participant groups: Action Providers, Graphers, and Validators. Action Providers develop and publish smart contract abstractions, Graphers compete to find the most efficient solutions to user intents, and Validators ensure these solutions are secure and maintain the network’s integrity before execution.

Action Providers

Action Providers are developers who publish smart contract abstractions on the Enso Network. Their role involves providing standardized methods for functions like lending, swapping, and staking, optimizing these interactions for lower gas costs and faster execution, and ensuring they are secure through testing and validation.

The process followed by Action Providers to contribute and maintain smart contract abstractions involves:

1. Action Creation: Developers create modular contract abstractions that represent specific DeFi functions (e.g., lending, swapping).
2. Submission and Validation: Submitted actions undergo rigorous validation by Enso’s validator network to ensure security and efficiency.
3. Optimization and Integration: Once validated, the actions are optimized for seamless integration within the Enso ecosystem.
4. Continuous Updates: Action Providers monitor protocol changes and update abstractions accordingly to maintain compatibility.

Action Providers are rewarded for their contributions through a system that considers the usage and effectiveness of their provided smart contract abstractions, which are used by Graphers. Additionally, providers can gain extra incentives by staking $ENSO tokens. The most effective and frequently used actions are compensated more generously, promoting the creation of high-quality contributions.

Graphers

Graphers’ role is to build algorithms that solve consumer requests by combining smart contract abstractions into executable bytecode. Their role involves interpreting user intents to identify the best smart contract interactions, optimizing paths considering transaction costs and execution speed, and refining algorithms for better efficiency. They collaborate with Validators by proposing solutions that are then assessed for accuracy and security.

The process followed by Graphers involves:

1. Intent Reception: Users submit an intent, specifying desired on-chain outcomes such as asset swaps, lending, or staking.
2. Analysis and Computation: Graphers analyze the shared network state to identify available interactions across supported blockchains.
3. Solution Proposal: The optimal execution pathway is proposed and submitted for validation.
4. Validation and Execution: Once validators approve the proposal, the transaction can be executed on-chain.

Just like Action Providers, Graphers are incentivized through a competitive reward system where they earn from consumption fees based on the efficiency of their solutions. Participation might require staking $ENSO tokens to ensure quality, and the environment promotes competition where the most efficient solution for each intent is selected for execution.

Validators

Validators are the participants who secure the Enso Network by validating solutions and maintaining integrity, security, and efficiency by verifying and authenticating the execution of user intents as well as confirming transactions comply with network rules. In return, they earn a portion of the network fees.

Their responsibilities encompass verifying solutions proposed by Graphers for accuracy, validating transaction states against the blockchain’s current state, participating in consensus to determine optimal execution paths, enforcing security to prevent malicious activities, and approving transactions once all validation criteria are satisfied.

To participate, validators must stake $ENSO tokens, demonstrate technical competency in maintaining reliable infrastructure, and adhere to security standards, with a slashing mechanism in place to penalize misconduct.

Participation Incentives

Participant	Incentive	Description
Action Providers	Usage Fees	Earn rewards based on the usage of their abstractions. Whenever their contributions are used in solutions generated by Graphers, they receive a share of the fees. This system incentivizes the creation of high-quality, secure, and efficient abstractions.
Graphers	Competition for Rewards	Earn a share of consumption fees, which motivates them to optimize their algorithms. In this competitive setup, Graphers can capture value by delivering the best result while also securing a piece of the reward for themselves.
Validators	Transaction Fees	Earn rewards for their essential work in securing the network and validating solutions. They receive a portion of the network fees, which incentivizes them to perform their duties accurately and efficiently. In this competitive environment, validators compete to quickly authenticate and validate the best solutions to maximize their earnings.

How Enso Works

Enso processes smart contract interactions through Abstractions, Requests, Solutions, and Settlements. Action Providers contribute abstractions that define contract interactions, which are then used to generate solutions for user requests. The network optimizes execution by selecting the most efficient solution and settling the transaction in a single step.

Abstractions

To build the most comprehensive map of smart contract interactions, Action Providers contribute by populating the Enso Network with abstractions. These abstractions describe how to interact with specific smart contracts, and in return Action Providers are rewarded when they are consumed to generate solutions for Consumer Requests. 

The incentive mechanism is essential to promote an economy where developers are motivated to continually contribute abstractions they believe the ecosystem will need. Additionally, to encourage meaningful contributions, the network permits multiple abstractions serving the same purpose (e.g. deposit). However, to prevent squatting when generating solutions, the abstraction with the most $ENSO tokens staked will be prioritized.

While an Action Type can have multiple abstractions, each abstraction can only be associated with a specific Action Type. This is to ensure scalability for consumption by Graphers when building solutions. An Action Type serves as a wrapper that defines the behavior of the associated abstractions. For instance, a DeFi smart contract requiring the transfer of tokens to receive another token in return would be categorized as a “deposit”. 

As a first step, abstractions are submitted as a specific message action type.

After the message has been added, it is parsed into the following Action Type. 

Smart contract interactions can produce diverse outcomes, including tokens, NFTs, state transitions, and more. To accommodate these, the positions variable captures the results of each execution. Additionally, some smart contracts allow outcomes to be delegated to a different receiver address. To support these scenarios, the network has implemented the SupportsReceiver functionality, enabling advanced use cases like AI execution bots to operate within defined boundaries and permissions.

As new PositionTypes may be needed over time, the network is designed to evolve, and new types can be added through a Governance Module. Positions are deterministically hashed based on the following predefined parameters.

When a new abstraction is contributed, it goes through several phases to ensure its validity within the network:

1. Submission: Action Providers submit an action proposal.
2. Action Provider Validation: Validators verify that the Action Provider is registered within the on-chain providers list.
3. Parsing: Action message data is parsed into an Action Type format, converting relevant values into the Position Type format.
4. Definition Retrieval: The Action Provider’s indexing infrastructure interfaces with the network to retrieve the action definition.
5. Transaction Generation: Bytecode is generated from the action definition.
6. Simulation: The bytecode is simulated to ensure the outcome aligns with the expected position behavior.
7. On-Chain Validation: Positions are validated and stored on-chain, with any missing data modified as needed.
8. Storage: The Action is stored on-chain as part of the network map.
9. Action ID Emission: An Action ID is emitted to finalize the process.

Once these steps are completed, the abstraction becomes part of the Enso Network map. It is then available for use in generating solutions for consumer requests.

Intents Supply Chain

As mentioned earlier, the Enso Network is built on a foundational principle: consumers submit a desired outcome, known as an intent, without needing to define the specific steps required to achieve it. To fulfill these intent requests, the network’s three core participants—Action Providers, Graphers, and Validators—work together in a process structured around three key components: Request, Solution, and Settlement.

The Request

The process begins with the Request, which is an announcement from the Consumer specifying the task they wish to complete and any associated requirements. Below is an example request using the Router API endpoint (/v1/shortcuts/route) to enter a Curve position with $ETH:

Router API request example

This Request is posted to the Enso Network, leaving the details of execution to the network participants. The response will be then returned in a format like this:

The response includes a valid transaction ready for broadcast and a simulation of its execution.

The Solution

When a Request is submitted to the Enso network, Validators monitor the process by verifying the Request’s format. Once validated, the Request is propagated into the network’s mempool—a temporary storage area where unprocessed Requests are held before being included in solution generation.

At this stage, Graphers take over. They interpret the intent, evaluate the consumer’s guidelines, and combine available abstractions to generate an optimized solution. Worth noting, Enso enables any type of smart contract interaction across its integrated blockchains, provided an Action Provider has contributed an abstraction for that specific action.

To ensure the network consistently delivers the best possible solution, Graphers compete with one another. They use proprietary algorithms to determine the most efficient solution path across the network’s actions. These algorithms can vary in complexity, from easier approaches like K-shortest path to advanced computational models. Any solution that can be expressed as bytecode is considered a valid proposal.

Once Graphers generate a solution, the bytecode is linked to the corresponding IntentID. Validators then simulate each proposed solution by forking the target settlement chain with its most recent state. This simulation validates the solution’s executability and ensures correct state transitions by invoking the ViewFunction helpers, included in each abstraction. These helpers embed on-chain getters to cross-reference the expected outcomes with the actual results.

A ViewFunction is a read-only function that queries blockchain data to verify outcomes without changing the state. By embedding a ViewFunction, the system ensures that the generated solutions align with the Consumer’s intent and perform as expected. The purpose of embedding a ViewFunction is to cross-reference the expected outcomes (i.e., what the abstraction is supposed to achieve) with the actual results observed after execution. This ensures that the generated solutions behave as intended and meet the requirements specified in the Consumer’s intent.

On top of that, Validators may also run additional modules for checks such as balances, overrides, and delegate calls. After all Validators confirm the state transitions, their findings are propagated back into the mempool with the associated IntentID and SolutionID.

The network then selects the solution with the highest dollar output and lowest execution cost as the winning proposal, removing all other solutions from the mempool to prevent unnecessary bloat. This built-in caching mechanism ensures the network remains efficient.

Once the network participants select the optimal solution, this is returned in a structured format, tailored to meet the consumer’s specified requirements and constraints, and ready for Execution.

As the Enso network operates across multiple blockchains, where fees may be embedded into the bytecode used for execution, instead of bridging all fees back to the Enso blockchain, the network implements an auction mechanism. Addresses bid Enso tokens for the right to claim fees on respective blockchains, creating an efficient and decentralized fee recovery process.

The $ENSO tokens resulting from these auctions are redistributed among network participants based on their contributions, such as abstraction consumption, solution generation, and validation. This creates a self-sustaining circular economy that incentivizes ongoing participation and adapts to the continuous expansion of blockchains.

The Settlement

Once the Consumer approves the proposed solution, a Settlement agent executes the transaction, ensuring the user’s desired outcome is achieved in a single step.

Settlement is determined by the router strategy selected by developers when submitting requests to the Enso network. There are three available options: Router, Delegate, and Enso Wallet.

The Router option, recommended for EOAs, routes interactions through a single contract that acts as a universal router for all tokenized transactions. The Delegate option, intended for smart accounts, utilizes delegateCall, enabling both tokenized and non-tokenized interactions while keeping all state within the smart account rather than the router. The Enso Wallet option, designed for users who do not already have a smart account, returns calldata for deploying an Enso smart account and executing all logic within it in a single transaction, supporting both tokenized and non-tokenized interactions.

History and Background

Enso’s origins begin in 2021 with a bold entry into the blockchain space through a vampire attack. This approach was designed to bootstrap liquidity for Enso by targeting six prominent DeFi protocols: TokenSets, Index Coop, Indexed Finance, PieDAO, dHEDGE, and PowerPool. A vampire attack essentially involves creating a competitive DeFi platform that lures users and liquidity away from existing protocols by offering more attractive incentives, first introduced by SushiSwap to liquidity providers of Uniswap to migrate their liquidity over to Sushi through token and community incentivization.

In Enso’s case, the vampire attack was executed through a gamified migration process, where users were encouraged to move their liquidity from the targeted protocols to Enso. This was facilitated by the introduction of Enso Arcade, a virtual environment that guided users through the migration with a few simple clicks. Here’s how it worked:

• Incentivization: Users were incentivized with NFTs and Enso’s native tokens upon completing their migration. These NFTs were not just rewards but also contained hidden gems, adding an element of surprise and value to the migration process.
• Process: The migration involved users transferring their strategies, sets, or indexes from the six protocols to Enso. Enso compensated for gas fees, making the switch financially viable for users. This was crucial as gas fees on Ethereum, where many of these protocols operated, could be prohibitively expensive.
• Outcome: While the vampire attack successfully drew attention to Enso, it was not without its challenges. The approach did manage to attract liquidity, with potential TVL of $1.05 billion ready to migrate. However, the crowded DeFi space meant that standing out required more than just attracting users; it demanded continuous innovation.

In 2022, Enso pivoted to focus on social trading, conceptualizing a product that allowed users to create and share strategies for monetizing their DeFi and ERC-20 token investments. The idea was to democratize financial tools by enabling anyone to design and implement their own strategies. However, building this product highlighted a much deeper issue. Integrating with multiple DeFi protocols was an arduous process, consuming over a year of development time and more than $500,000 in audits—all for 15 integrations. The complexity and resource intensity made it clear that a more scalable and efficient solution was needed.

Determined to overcome these obstacles, Enso launched a DeFi super app in 2023, integrating over 50 DeFi protocols. This app offered a single platform to access diverse DeFi functionalities, from swaps and lending to staking and liquidity provisioning. Its seamless user experience drew the attention of other projects, with many teams asking, “How did you manage to integrate so many protocols so quickly?”.

This question led to the birth of Enso’s next evolution: a DeFi abstraction API.

Later that year, Enso released its API to enable other applications to use its underlying infrastructure. The API allows developers to integrate multiple DeFi protocols into their products without rebuilding each connection from scratch. Within the first two weeks of launch, the API had already facilitated $11 million in volume, a testament to the demand for streamlined, developer-friendly solutions. This phase marked a turning point. The Enso team recognized that the challenges they had solved for themselves—simplifying DeFi integration—were widespread across the blockchain industry. By addressing these pain points, they found a broader product-market fit.

Enso has now evolved into a blockchain Shortcut Engine that enables developers to define the desired outcomes without specifying execution details.

Why the Project was Created

Enso was created to address the complexity and inefficiency inherent in integrating dApps across multiple blockchain networks. Developers often encounter significant hurdles when interacting with various smart contracts, which demand extensive technical expertise, time, and resources. Recognizing these challenges, Enso aims to streamline this process by offering a unified infrastructure that abstracts the complexities of blockchain.

In particular, Enso’s approach addresses the issues of (1) fragmentation, where different blockchain ecosystems operate in silos, requiring developers to manage multiple integrations; (2) complexity, as understanding each blockchain framework and smart contract becomes a daunting task; (3) cost, with high expenses for audits, infrastructure, and maintenance that slow down development and heighten financial risks; and (4) scalability, where the lack of efficient tools makes it challenging to scale applications across various blockchains.

Sector Outlook

The development of software over the past decade has been marked by new technologies generating high expectations, only to encounter practical obstacles. This pattern has been particularly pronounced in Web3, where the initial promise of “borderless, unstoppable apps” was hindered by real-world complexities, including fragmented chains, numerous smart contract integrations, costly audits, and a limited range of user-friendly applications.

Web3 has traditionally relied on a transaction-centric paradigm, necessitating meticulous specification of every action—swaps, staking, bridging—in a sequential and granular manner. This approach demands in-depth knowledge of underlying contract intricacies, including gas consumption, addresses, and function calls, often proving cumbersome. The concept of “intents” emerges as a potential solution, enabling users to express their desired outcomes abstractly while delegating the execution path to a specialized solver.

Intents Need Shortcuts

An intent is simply a signed set of declarative constraints that allows a user to outsource transaction creation to a specialized third party. By signing and sharing an intent, a user is effectively granting permission to recipients to choose a computational path on their behalf (see figure below).

With intents, users are able to simply express a desired outcome while outsourcing the task of best achieving that outcome to sophisticated third parties. This contrasts with today’s imperative paradigm of submitting transactions on-chain, where every parameter is explicitly specified by the user and involves gas costs and slippage.

Intents shift the focus from specifying every transaction detail to defining what you want to achieve. You set the goal, and someone else figures out the best way to make it happen. This way, instead of managing every step of the process yourself, you delegate the execution details to a Solver or specialized third party. They handle the complexity of optimizing the outcome for you—they are responsible for aggregating intents and producing valid transactions.

However, the efficacy of this abstract approach hinges critically on the existence of well-defined and thoroughly tested execution paths within the underlying infrastructure.

While various solutions claim to offer seamless DeFi experiences through one-click interfaces or chain-abstraction, a closer examination often reveals underlying complexities. These systems attempt to mask the intricacies of bridging, token approvals, and protocol interactions, but they rarely eliminate them entirely. In essence, they may present a simplified facade, but the fundamental challenges of building and maintaining reliable, interconnected DeFi infrastructure remain. Without robust and integrated routes, users inevitably encounter similar obstacles, hindering the true potential of a truly seamless and frictionless DeFi ecosystem.

Enso’s shortcuts represent a curated library of pre-built, battle-tested modules for common on-chain actions.

Instead of connecting to each project by building contract-specific integrators from the ground up, developers can seamlessly integrate these proven building blocks into their applications by using Enso’s API with an API key obtained from an Enso developer account. This modular approach not only accelerates development cycles but also mitigates the risks associated with developing and deploying complex smart contracts from scratch. Furthermore, by utilizing battle-tested components, developers can enhance the security and reliability of their applications, ensuring robust and efficient operation within the Web3 ecosystem.

Real Examples

• Plug: Rebuilt their entire integration layer in under two days after months of manual protocol setups.
• Spicenet: Integrated Enso Shortcuts to improve liquidity orchestration and execution.
• Glider: Automated trading features without manually coding complex rebalancing or bridging calls.
• Velvet Capital: uses Enso to easily build advanced DeFi strategies.

While this observation mirrors historical trends in Web2, characterized by the rise of microservices, API-first product development, and the outsourcing of specialized functions (“as-a-service”) to external providers (e.g., Uber utilizing Stripe for payments and Twilio for messaging), however, a key distinction in the Web3 landscape lies in its significantly higher degree of fragmentation, evident in the frequent emergence of new blockchains, tokens, and protocols.

In any rapidly evolving space, no single tool solves everything. But seeing teams go from months of development time to days is compelling. The shortcuts approach is reminiscent of how mainstream software development matured: standard libraries, frameworks, and cloud services freed developers to focus on user needs instead of low-level plumbing. As Enso continues to expand these shortcuts, more teams will be able to bypass the tedious process of repeatedly integrating smart contracts and directly focus on developing real user-facing features.

Potential Adoption

Given how quickly blockchain technology is developing, Web3 developers face significant challenges in integrating DeFi functionalities into their applications. Traditionally, and even now, this process has been fraught with complexity, requiring developers to manually integrate with each blockchain or DeFi protocol, which is time-consuming and resource-intensive. With shortcuts, developers no longer need to spend months mastering the intricacies of each blockchain framework or protocol. Instead, they can focus on product innovation, community building, and growth, as Enso handles the heavy lifting of blockchain integration.

The adoption potential of Enso is already being realized in the market. Projects like Bedrock have utilized Enso to implement one-click deposit features, allowing users to interact with DeFi protocols like the uniBTC Berachain Vault with ease. Similarly, Royco has partnered with Enso for the Boyco Berachain launch: Enso’s shortcuts processed $3.1B for Boyco and Berachain’s launch. This led to Enso being the #2 aggregator in volume in the whole ecosystem, #1 across EVM according to DefiLlama in that week, leveraging Enso’s infrastructure to ensure seamless DeFi execution from inception, enhancing user experience and operational efficiency.

Value Proposition

Enso’s value proposition can be conceptualized through the lens of a DeFi application that requires interaction with multiple lending protocols and/or DEXs, such as a yield aggregator. Traditionally, assuming an example with Aave, Compound, and Maker, this process would involve the following steps:

Traditional Method:

1. Individual Protocol Integration: Developers would need to write custom code for each protocol. For Aave, they’d need to understand and implement Aave’s lending pool interactions; for Compound, they’d deal with cTokens and supply/borrow functions; and for MakerDAO, they’d manage collateralized debt positions (CDPs) with different smart contracts.
   • Aave: Developers would need to integrate with Aave’s smart contracts to deposit collateral, borrow assets, and manage interest rates. This involves understanding Aave’s rate model, liquidation thresholds, and interacting with specific functions like deposit, borrow, repay, and withdraw.
   • Compound: Here, they’d integrate with Compound’s protocol to mint cTokens when supplying assets, redeem them when withdrawing, and handle borrowing through functions like mint, redeem, borrow, and repayBorrow. Managing the cToken exchange rate and interest accrual would also be necessary.
   • MakerDAO: Integration with MakerDAO requires understanding the Dai Stablecoin System, setting up CDPs, managing collateral, and interacting with functions like open, lock, draw, wipe, and free. This includes handling stability fees and liquidation ratios.
   • Uniswap: For token swaps, developers would need to connect with Uniswap’s smart contracts, understanding how to use the Router contract for swapping tokens via functions like swapExactTokensForTokens.
2. Audit and Security: Each integration would require separate security audits to ensure there are no vulnerabilities in the interaction with each protocol’s smart contracts, which can be costly and time-consuming.
3. Maintenance and Updates: With each protocol updating independently, developers must continuously monitor and update their code to maintain compatibility, which adds to the complexity and resource requirements.
4. User Experience: Users would need to interact with different interfaces or manage multiple transactions for each action, making the process less intuitive and more error-prone.

Enso as an AI Enabler: Empowering AI Agents in DeFi

The integration of Artificial Intelligence (AI) into DeFi, often termed DeFAI, is a burgeoning frontier, promising to automate complex financial strategies and enhance user interaction with blockchain technologies. However, the gap between AI’s analytical capabilities and its ability to execute on-chain actions has been a significant barrier. Enso emerges as the bridge over this gap, enabling AI agents to not only think but act within the DeFi ecosystem.

Enso’s infrastructure plays a key role in turning AI’s strategic insights into actionable on-chain operations. Projects like Hey Anon have harnessed Enso to allow their AI agents to execute trades, manage portfolios, and automate DeFi strategies across over 180 protocols. This integration means that instead of developers spending months on protocol integrations, AI teams can focus on enhancing the intelligence of their agents, while Enso handles the execution complexity.

As AI continues to evolve, the synergy with platforms like Enso will become increasingly critical. The future of DeFi might well be AI-driven, where intelligent agents manage assets, execute trades, and optimize strategies autonomously. Enso stands at the forefront, enabling this future by providing the infrastructure that makes these AI-driven actions feasible, secure, and efficient.

Using the Protocol 

Before integrating Enso, developers should set up an Enso developer account with API key access. Ensure you have a development environment with Node.js or Python installed. This setup is crucial for interaction with the Enso protocol.

Set Up Enso API Key

1. Create an Enso Account

• Go to the Enso Dashboard.
• Click Continue with Google, select your email, and follow the sign-up flow to finish creating your account.

2. Copy Your API Key

• Once logged in, locate the API Key section.
• Press Copy API Key. If you ever need to revoke or replace this key, click Generate New Key.

3. Test the API Key

• Create a .env file to store your Enso API key and other sensitive data.

• Replace <API_KEY> with your actual API key in the Authorization header of your request.

• Use a sample endpoint (e.g., the route endpoint) to confirm your key works.

4. Start Building

• Use your valid API key for Enso’s endpoints in your application to integrate DeFi interactions, price aggregation, gas optimization, and more.

Guide to Building a DeFi Router with Enso’s API

Step 1: Understand Enso’s API

Before diving into the code, familiarize yourself with Enso’s API by reading the official documentation. 

Key endpoints needed include: 

• Networks: Fetch supported networks. Get Endpoint here.
• Tokens: Fetch tokens available on a specific network. Get Endpoint here.
• Router: Find the best route for swapping tokens. Get Endpoint here.
• Protocols: Fetch protocol details for displaying additional information. Get Endpoint here.

Visit the Enso Developer Docs to understand the request/response structure, parameters, and authentication.

Step 2: Set Up Your Development Environment

a. Create a React Project:

• Use Vite or Create React App with TypeScript support.
• Install dependencies: axios, react-query, wagmi, and ethers.js.

b. Set Up Environment Variables:

• Create a .env file to store your Enso API key and other sensitive data. Example:

c. Install Required Libraries:

• Install Axios for API calls: npm install axios.
• Install React Query for managing API state: npm install @tanstack/react-query.
• Install Wagmi for wallet integration: npm install wagmi viem.

Step 3: Create the Enso Service

As in your code snippet, create a dedicated EnsoService class.

• Base URL: https://api.enso.finance/api/v1
• Headers:
  • Content-Type: application/json
  • Authorization: Bearer <API_KEY>
• Initialize Axios:

Step 4: Use Enso Endpoints to Build Your Router Logic

The Enso REST API provides several key endpoints to help you discover networks, tokens, protocols, and to route (i.e., find optimal paths or bundling) across DeFi. Here’s how each endpoint fits into building a DeFi router:

a. getNetworks

• Purpose: Lists all blockchains or networks Enso supports.
• Usage:

When to Use: If your router needs to support multiple chains, call this to display or filter by chain IDs your app will handle.

b. getTokens (with chainId)

• Purpose: Fetch available tokens on a specific chain.
• Usage:

When to Use: Populate your token dropdown or show which assets a user can swap or route through on each chain.

c. getProtocols

• Purpose: Retrieve a list of protocols integrated with Enso (e.g., DEXes, lending markets).
• Usage:

When to Use: If you want to route users through specific DeFi protocols (for example, for an automated yield strategy), you can display or filter which protocols you’ll allow in your routes.

d. get route

• Purpose: The core of a router—this endpoint returns a recommended path for swapping or interacting with protocols to achieve your specified outcome.
• Usage: 

Key Parameters:

• chainId: The chain where you want the swap/interaction to happen.
• fromAddress: Address from which tokens will be pulled or which initiates the transaction.
• tokenIn, tokenOut: Single or arrays of token addresses you want to convert or handle in your transaction.
• amountIn: The amount of tokenIn you’re using for the route.
• routingStrategy: Set to “router” to tap into Enso’s aggregator logic.

When to Use: This is the main call your DeFi router will make. You send in the user’s desired input token, output token, chain, and amounts, and get back a recommended routing strategy (plus estimated amounts out, fee structure, etc.).

Step 5: Process & Execute the Results

After calling getRoute, you’ll receive a RouteResponse object that includes:

1. Route Steps: A breakdown of each protocol or DEX interaction.
2. Estimated Returns: Amount out or expected final tokens.
3. Gas & Fees: Data relevant to executing the transaction.

Your workflow typically looks like:

1. Present the route information to your user.
2. Confirm any slippage or intermediate steps with the user (if your UX demands it).
3. Execute the returned transaction (or transactions) on-chain. This can be done by sending the transaction data (returned by getRoute) from the user’s wallet or a server-side relayer.

 Step 6: Testing Your Integration

1. Use Test Keys / Test Networks
   • Enso may provide test endpoints or a dev environment. Alternatively, use smaller amounts on a main test chain (e.g., Ethereum Goerli).
2. Check Responses
   • Log the RouteResponse to confirm the route data matches your expectations (token addresses, amounts, etc.).
3. Simulate
   • If you want an extra layer of certainty, run local or blockchain-level simulations (using Enso’s Temper or a tool like Hardhat for EVM) to confirm the transaction calls are valid and produce the expected outcome.

Step 7: Deploying & Maintaining Your Router

1. Production-Ready
   • Ensure your environment variable (VITE_ENSO_API_KEY) is kept secure.
   • Consider using a separate production key if you want to rotate keys for staging vs. production.
2. Monitoring & Updates
   • Monitor your calls to Enso’s API—log any unexpected errors.
   • Periodically check if new versions of Enso’s docs or endpoints are released, since aggregator logic may evolve.
3. Token Management
   • Enso’s token list might update over time—refresh it to ensure your router includes newly supported assets.

Business Model

Currently, Enso operates its business model through a revenue-sharing approach rather than embedding fees directly into the spread. The protocol collaborates with direct developers and various intent networks, sharing a portion of the revenue generated from transactions executed through its solutions. Enso already provides value to platforms like Cowswap, Brink, and Aperture, among others, enabling them to leverage its infrastructure without additional embedded fees.

Instead of taking a spread, Enso focuses on transparent revenue-sharing agreements, allowing partners to maintain control over their fee structures.

Looking ahead, Enso is exploring a transition to a more structured pricing model. This would involve implementing a fixed fee that scales with the volume of transactions processed through its network. The fixed fee would apply to all users of Enso’s services, including both direct developers and third-party intent networks. However, the exact details of this model, including fee tiers and rollout timelines, are still under development and have not been finalized.

Revenue Streams

Enso has two main sources of revenue:

API Integrations:

Enso offers its API to projects and developers, enabling them to integrate Enso’s intent-based solutions into their platforms. For these integrations, Enso charges a fee on a case-by-case basis. The fee structure is tailored to each client, based on specific use cases and volume, ensuring flexibility and alignment with the client’s needs.

Solver Operations:

Enso acts as a solver on multiple protocols, including One Balance and CoWswap, a decentralized exchange (DEX) aggregator. As a solver, Enso generates revenue through:

• Spread Capture: Enso earns revenue through fee sharing from clients by providing competitive solutions compared to other solvers. In the case of CoWswap, Enso’s revenue comes exclusively from native token rewards, which scale based on the quality of Enso’s solutions relative to other solvers.
• Native Token Rewards: Enso also benefits from native token rewards distributed by Cowswap for its participation in the solver network.

Tokenomics

$ENSO is the native token of the protocol. It serves as the safeguard of the network, enabling transactions and incentivizing participants to engage with the ecosystem. The tokenomics are designed to align the interests of users, developers, and validators for sustainable network growth and governance.

Token Distribution

The total supply of $ENSO tokens is capped at 100 million, with the following distribution:

Community: 41.66%

• Foundation (21.5%): A significant portion of the tokens is reserved for ecosystem development, grants, and future network growth initiatives.
• DAO (20.16%): Reserved for decentralized governance, allowing token holders to participate in decision-making.

Investors: 31.84%

• This category represents allocations to private investors and strategic partners who contributed to early-stage funding rounds.

Team: 25.0%

• A quarter of the token supply is allocated to the core Enso team, which includes co-founders, developers, and key contributors.
• These tokens are vested over multiple years to align team incentives with the long-term success of the project.

Advisors: 1.5%

• A small portion is set aside for advisors, who may include industry experts, investors, and strategic partners providing guidance to the project.

Token Emissions

Token Emission and Vesting Schedule

The $ENSO token vesting schedule is designed to ensure a balanced distribution across stakeholders while preventing market instability.

• Community: No cliff, rapid unlock in the first 20 months, then gradual emissions, final vesting completion: ~40 months.
• Advisors: 6-month cliff, fast unlock over 18-24 months, final vesting completion: ~20-25 months.
• Investors: 6-12 month cliff, linear unlock over 20 months, final vesting completion: ~20-24 months.
• Team: 12-month cliff, gradual unlock from 12-40 months, final vesting completion: ~40 months.

Governance

Enso plans to move to a DAO governance system utilizing staked $ENSO tokens. The system is still in progress, and an announcement will be made by Enso when finalized. According to the current documents, the governance would be according to a proposal model that is seen in the majority of protocols, where a proposal is submitted before being voted on by the community.

Risks

Dependency on Enso’s Infrastructure

By relying on Enso for abstracting complex blockchain interactions, developers become heavily dependent on Enso’s infrastructure. If Enso faces downtime, security breaches, or operational issues, the applications built on top could be significantly impacted.

Security of Shortcuts

Although Enso has undergone multiple audits (e.g., by MixBytes, Chainsecurity, ABDK), the use of pre-built shortcuts introduces a potential risk if these shortcuts contain undiscovered vulnerabilities or if they are not kept up-to-date with the latest security patches from the integrated protocols.

Validator Centralization Risks

The current lack of complete decentralization in Enso’s governance could result in centralized decision-making by the Enso team. Additionally, the high staking requirements and technical thresholds for validators might limit participation to a few entities, risking centralization and potentially undermining network security and decentralization.

Smart Contract Interaction Risks

Enso abstracts smart contract interactions, but this abstraction could mask underlying smart contract vulnerabilities if not thoroughly tested. Since Enso interacts with numerous protocols, any vulnerability in these protocols could affect applications built with Enso.

Security

Enso is a fully non-custodial platform, developed with high security principles in mind. While regular audits have been conducted to identify potential vulnerabilities, it is essential to acknowledge that no audit can provide absolute guarantees of safety. As with any decentralized platform, users should exercise caution and assume responsibility for their own risk management.

Audits

Enso has undergone five security audits to ensure the integrity and security of its smart contracts across multiple blockchain networks. It is worthy to note that all Enso’s deployments across the EVM use the same smart contract address.

Audit Date	Auditor	Audit Focus	Vulnerabilities Found	Report Link
02-2023	MixBytes	Enso Weiroll diff, Enso Smart Wallet	Total Issues: 13  Fixed: 12 Acknowledged: 1 Critical: 2 High: 0 Medium: 3 Low: 8	Audit Report
01-2023	Chainsecurity	Enso-Weiroll	Total Issues: 9  Fixed: 8 Acknowledged: 1 Critical: 0 High: 1 Medium: 4 Low: 4	Audit Report
12-2022	ABDK	Enso Weiroll Diff	Total Issues: 9  Fixed: 6 Acknowledged: 1 Critical: 0 High: 1 Medium: 1 Low: 7	Audit Report
08-2022	MixBytes (with DELV)	Weiroll	Total Issues: 4  Fixed: 4 Acknowledged: 0 Critical: 0 High: 0 Medium: 0 Low: 4	Audit Report
06-2022	ABDK (with DELV)	Weiroll	Total Issues: 21  Fixed: 1 Acknowledged: 11 Critical: 2 High: 2 Medium: 1 Low: 16	Audit Report

Team

The Enso Network is led by a team of experienced professionals with deep expertise in blockchain technology, DeFi, and software development.

The core leadership team includes:

1. Connor Howe – (CEO & Co-founder)
   • Connor has been actively involved in the blockchain space since 2016, with a background in building financial infrastructure for digital asset institutions. Before Enso, he was instrumental in developing blockchain solutions at Sygnum Bank, one of the first fully regulated digital asset banks in Switzerland. His focus at Enso is driving strategic growth and ensuring the platform evolves to meet the needs of developers and users.
2. Peter Phillips – (CTO & Co-founder)
   • Peter is an experienced blockchain architect with a background in cognitive systems and software engineering. He previously contributed to blockchain development initiatives at Autark and collaborated with major tech firms like DuckDuckGo and Mozilla. At Enso, Peter leads technical innovation, overseeing the development of the Shortcut Engine and network infrastructure.
3. Milos Costantini – (Core Developer & Co-founder)
   • Milos specializes in blockchain infrastructure and has extensive experience in running validator operations at Swisscom Blockchain. His focus at Enso is on protocol development and ensuring and optimizing efficient execution of intents.

Project Investors

Enso has raised a total of $9.2 million in funding. $5 million from a seed round in April 2021, co-led by Polychain Capital and Dfinity Beacon Fund. Also, $4.2 million from an additional funding round in June 2024; this funding was to support the launch and development of Enso’s first intent engine.

FAQ

What are Shortcuts in Enso?

Shortcuts are like a “plug and play” library of on-chain interactions, and can combine these together to create whole new apps.

Will Enso remain in the backend, or is it planned to aggregate the UX of all Enso’s chains/shortcuts in a frontend?

Enso had a frontend before but found minimal traction, so the protocol now focuses solely on infrastructure. Enso serves as the engine empowering apps to be built.

What is the cost of the Enso API key?

Enso uses a revenue-sharing model for certain advanced features, while many core functionalities are free or included with a base plan. Details on pricing and revenue share can vary; check Enso’s official documentation or contact the team for the most up-to-date information.

How does Enso ensure optimal execution?

Enso uses Graphers—entities that compete to find the best execution path for a given intent. They analyze network conditions, gas fees, and liquidity across multiple supported chains to provide the most cost-effective and efficient solution.

How can I use raw calldata with the bundle API without specifying ABI, function name, or arguments?

Enso supports “actions” that you can assemble into a bundle. You can either define these actions with standard ABI and arguments or by providing already-encoded calldata. Simply pass the desired calldata as part of the action definition in your request. By doing so, you do not need to specify the function signature or arguments in a traditional ABI format.

Does Enso have plans to support Solana?

Enso currently focuses on EVM-compatible chains, but the project roadmap includes expansion into non-EVM ecosystems like Solana, as well as other VMs (e.g., SVM, MVM). The timeline depends on development priorities and ecosystem demand.

What is the reliability of the API uptime?

Enso maintains a stable API uptime that serves multiple teams in production environments. Although exact percentages may vary over time, the service has a proven track record of reliable performance.

Community Links

• Enso Website
• Enso Docs
• Developer Docs
• Enso Whitepaper
• Enso on X
• Enso Developer Telegram
• Discord
• GitHub