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.