Merge branch 'main' into arbi

.gitignore

@@ -1,2 +1,8 @@
 out
-cache
+cache
+
+ui/node_modules
+ui/.next
+ui/.env
+
+.env

.gitmodules

@@ -1,6 +1,3 @@
-[submodule "lib/solady"]
-	path = lib/solady
-	url = https://github.com/vectorized/solady
 [submodule "lib/forge-std"]
 	path = lib/forge-std
 	url = https://github.com/foundry-rs/forge-std

README.md

@@ -2,6 +2,7 @@
 
 The **Intents Engine** (IE): A Basic *Text-to-tx* Simulator Contract.
 
+<<<<<<< HEAD
 ## Deployments
 
 ### Mainnet
@@ -13,6 +14,19 @@ V1: [`0x1E00000000Cf8ba83e0005c59c1Bf1C4682C8E00`](https://etherscan.io/address/
 V1.2: [`0x1e00003a669bb466d6B49800000099E1abDD6600`](https://arbiscan.io/address/0x1e00003a669bb466d6b49800000099e1abdd6600#code)
 
 `Note:` L2 will be used to rapidly prototype a stable and sufficient IE for common crypto commands. Many dev resources here will cater to the current L2 prototype until the release of V2 on L1.
+=======
+## Deployment
+
+### IE V1
+
+#### Ethereum Mainnet (L1)
+
+[`0x1E00000000Cf8ba83e0005c59c1Bf1C4682C8E00`](https://etherscan.io/address/0x1e00000000cf8ba83e0005c59c1bf1c4682c8e00#code)
+
+##### Deployed Bytecode
+
+[`QmZVdxJyTCJBF7gfE5BrSavCHtMDScZjpLYH5qaMExhW49`](https://content.wrappr.wtf/ipfs/QmZVdxJyTCJBF7gfE5BrSavCHtMDScZjpLYH5qaMExhW49)
+>>>>>>> main
 
 ## Uses
 
@@ -22,56 +36,73 @@ From natural language:
 - 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. 
+IE should deterministically and transparently operate to provide these utilities in an uncensorable medium like a Solidity smart contract.
 
-[V1](./src/IE.sol) is a POC of this.
+[`V1`](./src/IE.sol) is a POC of this. [*Short demo and explainer thread on X.*](https://x.com/z0r0zzz/status/1758392014737920209?s=20)
 
 ## Command Syntax (⌘)
 
 IE is approaching things from first-principles and a "show" rather than "tell" approach. There will be some experimentation.
 
-Some things in V1 are likely very underoptimized for this particular use case.
+Some things in `V1` are likely very underoptimized for this particular use case.
 
 The bigger project is to identify syntax and phrasing for common types of onchain transactions in English to start. The following are identified as categories and phrases that should demonstrate this for many if not most natural language commands to generate txs.
 
-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).
+### Send
 
-You MUST include spaces in the string provided to IE in order for it to understand word separation.
+aliases: *transfer*
 
-Note: `to/for` is an identified filler word common to most of the transactions we will cover so it is highlighted.
+#### < A >
+*Words: 4*
 
-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
+**[action] [object] [value] [asset]**
+> *send vitalik 1 ETH*
 
-Also, let's try and be as helpful as possible. If there is `msg.value` in a command, then we will assume ETH is involved.
+#### < B >
+*Words: 5*
 
-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.
+**[action] [value] [asset] [to/for] [object]**
+> *send 1 ETH to/for vitalik*
 
-### Send
-- *V1*
+------------------------------------
 
-*Words: 4*
+### Swap
 
-[action] [object] [value] [asset]
-- **send vitalik 1 ETH**
+aliases: *exchange*
 
+#### < A >
 *Words: 5*
 
-[action] [value] [asset] [to/for] [object]
-- **send 1 ETH to/for vitalik**
+**[action] [value] [asset] [to/for] [object]**
+> *swap 1 ETH to/for DAI*
 
-aliases: *transfer*
+#### < B >
+*Words: 6*
 
-### Swap
-- *V1*
+[action] [value] [asset] [to/for] [minOutputAmount] [object]
+- **swap 1 ETH to/for 2500 DAI**
 
-*Words: 5*
+aliases: *exchange*
 
-[action] [value] [asset] [to/for] [object]
-- **swap 1 ETH to/for DAI**
+Note: In `V1.1` on Arbitrum, 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`.
 
-aliases: *exchange*
+------------------------------------
+
+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*).
 
 ## Getting Started