Merge pull request #67 from BootNodeDev/decouple-base

Decouple base

Author: lmcorbalan

solidity/.env.example

@@ -32,4 +32,5 @@ export ITT_INPUT = "TOKEN INPUT ADDRESS"
 export ITT_OUTPUT = "TOKEN OUTPUT ADDRESS"
 export AMOUNT_IN = "AMOUNT IN"
 export AMOUNT_OUT = "AMOUNT OUT"
+export SENDER_NONCE = "SENDER_NONCE"
 export DESTINATION_DOMAIN = "DESTINATION DOMAIN ID"

solidity/README.md

@@ -1,10 +1,63 @@
-# ERC7683 Router
+# ERC7683 Reference Implementation
 
-A reference ERC7683 implementation
+## Overview
 
-TODO - add some more description
+This project is centered around the [Base7683](./src/Base7683.sol) contract, which serves as the foundational component
+for implementing the interfaces defined in the
+[ERC7683 specification](https://github.com/across-protocol/ERCs/blob/master/ERCS/erc-7683.md). The contract is designed
+to be highly flexible, supporting any `orderDataType` and `orderData`. The logic for handling specific `orderData` types
+within the process of resolving and filling orders is intentionally left unimplemented, allowing inheriting contracts to
+define this behavior.
 
-## Deploy a Router7683
+While adhering to the `ERC7683` standard, `Base7683` introduces additional functionality for `settling` and `refunding`
+orders. These functions are not part of the `ERC7683` specification but are included to provide a unified interface for
+solvers and users across all implementations built on this framework.
+
+Inheriting contracts must implement several key internal functions to define their specific logic for order resolution,
+filling, settlement, and refunds. These include:
+
+- `_resolveOrder(GaslessCrossChainOrder memory _order)` and `_resolveOrder(OnchainCrossChainOrder memory _order)` for
+  resolving orders into a hydrated format.
+- `_fillOrder(bytes32 _orderId, bytes calldata _originData, bytes calldata _fillerData)` for processing and filling
+  orders.
+- `_settleOrders(bytes32[] calldata _orderIds, bytes[] memory _ordersOriginData, bytes[] memory _ordersFillerData)` for
+  settling batches of orders.
+- `_refundOrders` for both `OnchainCrossChainOrder` and `GaslessCrossChainOrder` types, enabling the implementation of
+  specific refund logic.
+- `_localDomain()` to retrieve the local domain identifier.
+- `_getOrderId` for computing unique identifiers for both `GaslessCrossChainOrder` and `OnchainCrossChainOrder` types.
+
+These functions ensure that each inheriting contract provides its specific behavior while maintaining a consistent
+interface across the framework. You'll find more details of this function interfaces documented on the
+[Base7683](./src/Base7683.sol).
+
+As reference, the following contracts build upon `Base7683`:
+
+1. [BasicSwap7683](./src/BasicSwap7683.sol) The `BasicSwap7683` contract extends `Base7683` by implementing logic for a
+   specific `orderData` type as defined in the [OrderEncoder](./src/libs/OrderEncoder.sol). This implementation
+   facilitates token swaps, enabling the exchange of an `inputToken` on the origin chain for an `outputToken` on the
+   destination chain.
+
+2. [Hyperlane7683](./src/Hyperlane7683.sol) The `Hyperlane7683` contract builds on `BasicSwap7683` by integrating
+   `Hyperlane` as the interchain messaging layer. This layer ensures seamless communication between chains during order
+   execution.
+
+## Extensibility
+
+Both `BasicSwap7683` and `Hyperlane7683` are designed to be modular and extensible. Developers can use them as reference
+implementations to create custom solutions. For example:
+
+- To implement a different `orderData` type, you could replace `BasicSwap7683` with a new contract that inherits from
+  `Base7683`. The `Hyperlane7683` contract can remain unchanged and continue to provide messaging functionality.
+- Alternatively, you could replace the Hyperlane-based messaging layer in `Hyperlane7683` with another interchain
+  messaging protocol while retaining the `BasicSwap7683` logic.
+
+This modular approach enables a high degree of flexibility, allowing developers to adapt the framework to various use
+cases and requirements.
+
+## Scripts
+
+### Deploy
 
 - Run `npm install` from the root of the monorepo to install all the dependencies
 - Create a `.env` file base on the [.env.example file](./.env.example) file, and set the required variables depending
@@ -19,7 +72,7 @@ Set the following environment variables required for running all the scripts, on
 If the network is not listed under the `rpc_endpoints` section of the [foundry.toml file](./foundry.toml) you'll have to
 add a new entry for it.
 
-For deploying the router you have to run the `npm run run:deployRouter7683`. Make sure the following environment
+For deploying the router you have to run the `npm run run:deployHyperlane7683`. Make sure the following environment
 variable are set:
 
 - `DEPLOYER_PK`: deployer private key
@@ -29,10 +82,12 @@ variable are set:
 - `PROXY_ADMIN_OWNER`: address of the ProxyAdmin owner, `ROUTER_OWNER` would be used if this is not set. The router is
   deployed using a `TransparentUpgradeableProxy`, so a ProxyAdmin contract is deployed and set as the admin of the
   proxy.
-- `HYPERLANE7683_SALT`: a single use by chain salt for deploying the the router. Make sure you use the same on all chains
-  so the routers are deployed all under the same address.
+- `HYPERLANE7683_SALT`: a single use by chain salt for deploying the the router. Make sure you use the same on all
+  chains so the routers are deployed all under the same address.
 - `DOMAINS`: the domains list of the routers to enroll, separated by commas
 
+### Open an Order
+
 For opening an onchain order you can run `npm run run:openOrder`. Make sure the following environment variable are set:
 
 - `ROUTER_OWNER_PK`: the router's owner private key. Only the owner can enroll routers
@@ -44,6 +99,8 @@ For opening an onchain order you can run `npm run run:openOrder`. Make sure the
 - `AMOUNT_OUT`: amount out
 - `DESTINATION_DOMAIN`: destination domain id
 
+---
+
 ## Usage
 
 This is a list of the most frequently needed commands.
@@ -53,74 +110,60 @@ This is a list of the most frequently needed commands.
 Build the contracts:
 
 ```sh
-$ forge build
+$ yarn build
 ```
 
 ### Clean
 
 Delete the build artifacts and cache directories:
 
 ```sh
-$ forge clean
-```
-
-### Compile
-
-Compile the contracts:
-
-```sh
-$ forge build
+$ yarn clean
 ```
 
 ### Coverage
 
 Get a test coverage report:
 
 ```sh
-$ forge coverage
+$ yarn coverage
 ```
 
 ### Format
 
 Format the contracts:
 
 ```sh
-$ forge fmt
+$ yarn sol:fmt
 ```
 
 ### Gas Usage
 
-Get a gas report:
-
-```sh
-$ forge test --gas-report
-```
-
 ### Lint
 
 Lint the contracts:
 
 ```sh
-$ npm run lint
+$ yarn lint
 ```
 
 ### Test
 
 Run the tests:
 
 ```sh
-$ forge test
+$ yarn test
 ```
 
 Generate test coverage and output result to the terminal:
 
 ```sh
-$ npm run test:coverage
+$ yarn test:coverage
 ```
 
 Generate test coverage with lcov report (you'll have to open the `./coverage/index.html` file in your browser, to do so
 simply copy paste the path):
 
 ```sh
-$ npm run test:coverage:report
+$ yarn test:coverage:report
 ```

solidity/package.json

@@ -27,8 +27,8 @@
     "prettier:check": "prettier --check \"**/*.{json,md,yml}\" --ignore-path \".prettierignore\"",
     "prettier:write": "prettier --write \"**/*.{json,md,yml}\" --ignore-path \".prettierignore\"",
     "test": "forge test -vvv",
-    "test:coverage": "forge coverage",
-    "test:coverage:report": "forge coverage --report lcov && genhtml lcov.info --branch-coverage --output-dir coverage",
+    "test:coverage": "forge coverage --no-match-coverage \"(test|mock|node_modules|script)\"",
+    "test:coverage:report": "forge coverage --no-match-coverage \"(test|mock|node_modules|script)\" --report lcov && genhtml lcov.info --ignore-errors inconsistent,inconsistent --branch-coverage --output-dir coverage",
     "deployHyperlane7683": "forge script script/DeployHyperlane7683.s.sol:DeployHyperlane7683 -f $NETWORK --broadcast --verify --slow -vvv",
     "run:deployHyperlane7683": "dotenv-run-script deployHyperlane7683",
     "deployToken": "forge script script/DeployToken.s.sol:DeployToken -f $NETWORK --broadcast --verify --slow -vvv",

solidity/script/OpenOrder.s.sol

@@ -28,7 +28,7 @@ contract OpenOrder is Script {
         address outputToken = vm.envAddress("ITT_OUTPUT");
         uint256 amountIn = vm.envUint("AMOUNT_IN");
         uint256 amountOut = vm.envUint("AMOUNT_OUT");
-        uint256 senderNonce = Hyperlane7683(localRouter).senderNonce(sender);
+        uint256 senderNonce = vm.envUint("SENDER_NONCE");
         uint32 originDomain = Hyperlane7683(localRouter).localDomain();
         uint256 destinationDomain = vm.envUint("DESTINATION_DOMAIN");
         uint32 fillDeadline = type(uint32).max;
@@ -45,6 +45,7 @@ contract OpenOrder is Script {
             senderNonce,
             originDomain,
             uint32(destinationDomain),
+            TypeCasts.addressToBytes32(localRouter),
             fillDeadline,
             new bytes(0)
         );