The Intents Engine (IE): A Basic Text-to-tx Simulator Contract.

V2: 0x1e000000c5DA511236680015004A004Feb100Cce

V2: 0x1e004e0000CF85eE484Bd679486Fb1BB006E0000

V2: 0x1eaf8F6A000013F1960000E4e34106690000925b

V2: 0x1eb4c48c00F5000B8823Cdc9000c8e2a00002B00

Note: L2 will be used to rapidly prototype a stable and sufficient IE for common crypto commands and showcase iterative upgrades. Many dev resources here will cater to the current L2 prototype until the release of V3 on L1. V2 marks the product of the first dev cycle and core IE feature completion with enhanced UX features like batch commands and swap-and-send.

From natural language:

• Wallet preview (check tx)
• Security checkpoint (forbid tx)
• Command translation (make tx)

IE should deterministically and transparently operate to provide these utilities in an uncensorable medium like a Solidity smart contract.

V2 is a POC of this. Short demo and explainer thread on X.

IE is approaching things from first-principles and a "show" rather than "tell" approach. There will be some experimentation.

Some things in V2 are likely still very underoptimized for this particular use case, but users might yet be surprised at how efficient the "text to transaction" capabilites of IE currently are.

The bigger project of IE, in line with its AGPL license and OSS philosophy, is to identify syntax and phrasing for common types of onchain transactions in English to start, and standardize this format for the broader "intents" ecosystem. The following are identified as categories and phrases that should demonstrate this for many, if not most, natural language commands related to crypto and digital assets.

aliases: transfer

Words: 4

[action] [object] [value] [asset]

send vitalik 1 ETH

Words: 5

[action] [value] [asset] [to/for] [object]

send 1 ETH to/for vitalik

aliases: exchange

Words: 5

[action] [value] [asset] [to/for] [object]

swap 1 ETH to/for DAI

Words: 6

[action] [value] [asset] [to/for] [minOutputAmount] [object]

• swap 1 ETH to/for 2500 DAI

aliases: exchange

Note: A minOutputAmount can be specified for swaps. It ensures that you receive a minimum output amount of object at the end of the swap, otherwise the transaction will revert. The default value is set to 0.

Phrases are provided in the order in which they are most expected. They are "naturalized" to lower case. The IE contract automatically does this, but front-ends should nonetheless try and format as close as possible (i.e., through a simple LLM trained or prompted on these examples below).

In terms of usual English, we assume the subject of each command is the user account which is more explicit in the case of checking an ERC4337 userOp (where sender is the user). And the object receives assets or contract calls. value is the token or ETH amount involved in the action and the asset is the particular item sent or issued from (initially ETH or ERC20 to cover fungibles and most immediate security needs that could benefit from IE).

You MUST include spaces in the string provided to IE in order for it to understand word separation.

Note: to/for is an identified filler word common to most of the transactions we will cover so it is highlighted.

As you might notice, there are patterns. Because after all this is typical language and logic we are talking about here. For example, value will precede asset. object will either follow the action or be at the end. If at the end, there will be a filler of for/to. (Yeah I know this is what people learn in grammar schools but the exercise will likely yield good results.)

Also, let's try and be as helpful as possible at the top of the command funnel. E.g., if there is msg.value in a command, then we should assume ETH is involved.

Actions should also have aliases to catch more cases. Though it will be cheaper to use the primary word (for example, 'send' or 'swap' with preference to familiarity, and if there indecision, the shorter), it is helpful to do more and catch different ways of phrasing transactional commands, like "send" can equate to "transfer" when it comes to onchain assets. Adhering to Solidity and smart contract functions themselves in word choice makes the most sense as well (e.g., ETH.send/transfer, IERC20.transfer, UNI.swap, CURVE.exchange).

Run: curl -L https://foundry.paradigm.xyz | bash && source ~/.bashrc && foundryup

Build the foundry project with forge build. Run tests with forge test. Measure gas with forge snapshot. Format with forge fmt.

Note: Tests currently run on a virtual blockchain fork to check ENS properly.

lib
├─ forge-std — https://github.com/foundry-rs/forge-std
├─ solady — https://github.com/vectorized/solady
src
├─ IE — Intents Engine
test
└─ IE.t - Test Contract

These smart contracts and testing suite are being provided as is. No guarantee, representation or warranty is being made, express or implied, as to the safety or correctness of anything provided herein or through related user interfaces. This repository and related code have not been audited and as such there can be no assurance anything will work as intended, and users may experience delays, failures, errors, omissions, loss of transmitted information or loss of funds. The creators are not liable for any of the foregoing. Users should proceed with caution and use at their own risk.

See LICENSE for more details.