Introduction
Last updated
Last updated
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.
Protocols generally emphasize features over strategies.
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.
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.
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.
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.
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)
Intents can be integrated into any contract, expanding the range of use cases beyond those typically associated with Account Abstraction (AA).
Intentable supports EIP-3074 as an alternative to account abstraction, allowing you to run intents directly from your wallet.
The old saying, "Not your keys, not your coins," 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 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.
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.
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:
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.
Current Situation of Solvers: (Using a different technology than Intentable)
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:
Trust Issues: Users need to trust solvers to execute transactions honestly, which could be challenging if solvers are compromised or act maliciously.
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.
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.
In contrast, Intentable's system operates differently due to the clear separation between users, builders, and solvers. The system can operate in several modes:
First Situation: The User Is Also the Builder Here, the user develops complex transaction logic without revealing it to the solver. The solver's role is similar to a miner's; they only verify whether the transaction can proceed based on predefined conditions.
This setup is beneficial when there's a significant profit potential that might otherwise tempt a solver to execute the transaction for themselves. By keeping the strategy hidden, the user ensures that the solver cannot exploit it.
Second Situation: The Solver Activates the Logic In this scenario, the solver possesses all the know-how, and the user merely specifies their requirements.
For instance, a user wants to exchange 1 ETH for no less than $4000. The solver 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 user gets their desired rate, and the solver earns a profit without revealing their source or profit margin.
Third Mode: User Builds Complex Logic with Solver Involvement This mode is a blend of the first situation, with added benefits of solver involvement. For example, a user 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 user constructs the entire logic but relies on the solver to provide a cheaper flash loan to carry out the transaction.
Fourth Mode: Off-Chain Information Triggers Transactions For instance, a user 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 to send the hash to a webhook, which then activates the pre-built transaction with all the relevant details. The solver detects that the transaction can proceed and executes it.
Fifth Mode: Builder Prepares Transactions and Solver Executes In this scenario, three players are involved: the builder, user, and solver. The builder shares knowledge of potential future transactions for a possible profit. The user sets conditions for the transaction, while the solver acts as a simple operator, similar to a miner, executing the transaction according to the builder's predefined rules.
Users: Manage funds and make decisions.
Builders: Develop strategies and manage business logic.
Solvers: Monitor and execute processes.
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.
