# Introduction

## Why Intents

Blockchain protocols are becoming increasingly versatile and complex. Today, users often need to interact with multiple protocols to achieve their goals.\
\
It's more practical for most users to focus on the WHAT rather than the HOW

Users should be able to define their desired outcomes and let the Solvers handle the rest.

<figure><img src="https://3548253646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRzsuKmVKyjwseeiTE9zD%2Fuploads%2FwcGXd68j5w0zbwVF7Scm%2F01-05-2024%2022-38-48.png?alt=media&#x26;token=a6fe1857-4cf3-42f7-850a-939f340ddc6b" alt=""><figcaption><p>Stop loss &#x26; Take profit Intent example</p></figcaption></figure>

Protocols generally emphasize features over strategies.&#x20;

For instance, a user might want to set a stop-loss on their staking assets, liquidity pool tokens, or yield farming positions. However, there isn't a universal "stop-loss" strategy that works across all protocols.&#x20;

Some protocols support this feature, while others do not, and sometimes a stop-loss strategy requires coordinating across multiple protocols.

For example, extracting LP tokens from staking might require sending them to a liquidity pool to withdraw assets, and then swapping one of those assets for a safer option.&#x20;

Intents enable this by allowing users to express such complex scenarios as an intent without needing to understand all the technical details.\
\
For a comparison of a use case done with and without intent, see [here](https://docs.intentable.io/intents-vs.-traditional-methods).

## The Benefits of Account Abstraction

Wallets based on private keys/seed phrases, which represent the majority of wallets in use today, have significant limitations when it comes to executing transactions.<br>

For instance, signed transactions can't be deferred, failed transactions can't be retried, transaction batching isn't supported, and a wallet must have enough of the native token to pay for gas fees. These are just a few of the constraints that limit their flexibility. (see[ full list](https://docs.intentable.io/capabilities))

{% hint style="info" %}
Intents can be integrated into any contract, expanding the range of use cases beyond those typically associated with Account Abstraction (AA).
{% endhint %}

{% hint style="info" %}
Intentable supports [EIP-3074](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3074.md)  as an alternative to account abstraction, allowing you to run intents directly from your wallet.
{% endhint %}

## The Benefits of EIP-712

The old saying, "[Not your keys, not your coins](https://docs.intentable.io/platform)," remains relevant, yet it's no longer enough.\
\
Gone are the simple times of just transferring coins where your wallet transparently showed what you were committing to.\
\
Today, most protocol interactions involve [blindly singing](https://docs.intentable.io/platform) an arbitrary array of bytes. Some wallets attempt to catch up by displaying user-friendly information, but they are limited in the protocols they support and in the functionality they provide.

Intents utilize the EIP-712 standard to display every contract call, including numbers, addresses, strings, arrays, tuples, and many other input types in a user-friendly manner. This approach provides users with full transparency into the inner workings of the intent's transactions, eliminating the need to rely solely on the UI where the intent was created.

Moreover, the flow and conditions are embedded in the EIP-712 message, enabling the user to review the entire intent plan on the trusted wallet display.

<figure><img src="https://3548253646-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRzsuKmVKyjwseeiTE9zD%2Fuploads%2FWFUdd7vDkIIsyHzA7e0N%2F02-05-2024%2018-04-11.png?alt=media&#x26;token=8e4bb7bf-db60-4947-b48b-c5531a1d9103" alt=""><figcaption><p>EIP-712 </p></figcaption></figure>

## The benefits of No-Code Builder

**Speed:** In modern blockchain-based applications, time-to-market is crucial. There's a growing demand to tap into emerging markets and protocols while keeping up with the latest trends. No-code tools allow for rapid solution building and testing in a matter of hours rather than weeks, facilitating quick testing of various solutions and enabling a much faster response to market needs.

**Security:** No-code platforms are easier to test and encourage a more standardized approach to building applications. This standardization leads to fewer bugs and greater reliability, irrespective of the builder's technical skills.

**Builders**: No-code platforms empower domain experts to build applications without needing to rely on technical experts. This eliminates the need for programmers to partner with domain experts, resulting in more efficient and business-focused solutions.

## Why Solvers

The separation of responsibilities allows the entire system to function more efficiently. While builders specialize in strategy and business logic, solvers focus on the low-level technical aspects of monitoring and execution.

This structure enables each party to concentrate on its specific role:

:man:**Users:** Manage funds and make decisions.

:construction\_site:**Builders:** Develop strategies and manage business logic.

:clock730:**Solvers:** Monitor and execute processes.

**Example: Batch Sending of Salaries**

* **Users:** Provide funds and decide when to send salaries.
* **Builders:** Develop the Intent to manage invoice numbers, recipient names, and other relevant details.
* **Solvers:** Monitor the conditions and execute salary transactions when gas prices are low.

### What makes Intentable different from other solutions that focus on intent

**Current Situation of Solvers:** (<mark style="background-color:orange;">Using a different technology than Intentable</mark>)

Solvers are crucial in intent-centric blockchain systems for executing user-defined transactions efficiently. However, their intermediary role introduces potential vulnerabilities, primarily concerning security and trust. These solvers have the potential to gain undue control over user transactions, posing risks of misuse or theft of user funds.

**Difficulties:**

1. **Trust Issues:** Users need to trust solvers to execute transactions honestly, which could be challenging if solvers are compromised or act maliciously.
2. **Lack of Transparency:** The logic that solvers use may not always be clear, making it difficult to audit transactions and ensure they align with user intent.
3. **Security Risks**: With solvers having significant control, they could potentially carry out distributed denial-of-service (DDoS) attacks against the system. This could disrupt operations by flooding the network with false transactions or offering misleading rates.

   Example: Consider a user who wants to exchange 1 ETH at the best possible price, with the market rate being $4000. A fair solver would facilitate the transaction at around that price. However, a malicious solver could aim to execute a DDoS attack by offering an exchange rate of $4200.

   The malicious solver might then monopolize the transaction process, but without the intention to execute the transaction. This way, they can overwhelm the system with false offers, effectively "jamming" it and preventing legitimate solvers from operating, thereby causing service disruptions.

:smirk\_cat:**Profit-Taking Problem:** A significant challenge in the current solver system arises from conflicts of interest. When an opportunity for profit, such as arbitrage, presents itself, solvers may prioritize their own interests over the user's. This is comparable to "the cat keeping the cream," where solvers could identify profitable opportunities through their privileged access to user intentions and execute those trades for themselves instead of for the user.

### Intentable's advantages

In contrast, Intentable's system operates differently due to the clear separation between <mark style="background-color:purple;">**users**</mark>, <mark style="background-color:green;">**builders**</mark>, and <mark style="background-color:blue;">**solvers**</mark>. The system can operate in several modes:

**First Situation: The&#x20;**<mark style="background-color:purple;">**User**</mark>**&#x20;Is Also the&#x20;**<mark style="background-color:green;">**Builder**</mark> Here, the <mark style="color:purple;">user</mark> develops complex transaction logic without revealing it to the <mark style="color:blue;">solver</mark>. The <mark style="color:blue;">solver's</mark> role is similar to a miner's; they only verify whether the transaction can proceed based on predefined conditions.&#x20;

This setup is beneficial when there's a significant profit potential that might otherwise tempt a <mark style="color:blue;">solver</mark> to execute the transaction for themselves. By keeping the strategy hidden, the <mark style="color:purple;">user</mark> ensures that the solver cannot exploit it.

**Second Situation: The&#x20;**<mark style="background-color:blue;">**Solver**</mark>**&#x20;Activates the Logic** In this scenario, the <mark style="color:blue;">solver</mark> possesses all the <mark style="background-color:yellow;">know-how,</mark> and the <mark style="color:purple;">user</mark> merely specifies their requirements.&#x20;

For instance, a <mark style="color:purple;">user</mark> wants to exchange 1 ETH for no less than $4000. The <mark style="color:blue;">solver</mark> can search various sources, including decentralized exchanges (DEX), centralized exchanges (CEX), or even over-the-counter (OTC) markets, to find the best price or better. This way, the <mark style="color:purple;">user</mark> gets their desired rate, and the <mark style="color:blue;">solver</mark> earns a profit without revealing their source or profit margin.

**Third Mode:&#x20;**<mark style="background-color:purple;">**User**</mark>**&#x20;Builds Complex Logic with&#x20;**<mark style="background-color:blue;">**Solver**</mark>**&#x20;Involvement** This mode is a blend of the first situation, with added benefits of solver involvement. For example, a <mark style="color:purple;">user</mark> might buy an asset to sell it elsewhere for a significant profit, but needs a flash loan worth millions to complete the transaction. Here, the <mark style="color:purple;">user</mark> constructs the entire logic but relies on the <mark style="color:blue;">solver</mark> to provide a cheaper flash loan to carry out the transaction.

**Fourth Mode: Off-Chain Information Triggers Transactions** For instance, a <mark style="color:purple;">user</mark> wants to purchase a certain coin but is unsure which one. They might follow Elon Musk and want to buy whatever coin he mentions. They can create a transaction with a hash code and use a service like [Zapier ](https://zapier.com/)to send the hash to a webhook, which then activates the pre-built transaction with all the relevant details. The <mark style="color:blue;">solver</mark> detects that the transaction can proceed and executes it.

**Fifth Mode:&#x20;**<mark style="background-color:green;">**Builder**</mark>**&#x20;Prepares Transactions and&#x20;**<mark style="background-color:blue;">**Solver**</mark>**&#x20;Executes** In this scenario, three players are involved: the <mark style="color:green;">builder</mark>, <mark style="color:purple;">user</mark>, and <mark style="color:blue;">solver</mark>. The <mark style="color:green;">builder</mark> shares knowledge of potential future transactions for a possible profit. The <mark style="color:purple;">user</mark> sets conditions for the transaction, while the <mark style="color:blue;">solver</mark> acts as a simple operator, similar to a miner, executing the transaction according to the <mark style="color:green;">builder's</mark> predefined rules.

<br>

<br>