Add instructions for Arbitrum support

docs/contracts/uniswapx/guides/becomeQuoter.md

@@ -60,34 +60,6 @@ Response (status 200 - OK):
 
 There is a latency requirement on responses from registered endpoints. Currently set to 500ms, but is subject to change. If you do not wish to respond to a quote request, you must return an empty response with status code `204`.
 
-# (Optional) Signed Order Webhook Notifications
-
-Signed open orders can always be fetched via the UniswapX API, but to provide improved latency there is the option to register for webhook notifications. Quoters can register an endpoint with their filler address, and receive notifications for every newly posted order that matches the filter. 
-
-**Filter**
-
-Orders can be filtered by various fields, but most relevant here is `filler`. When registering your webhook notification endpoint, we recommend you provide the `filler` address that you plan to use to execute orders and to receive the last-look exclusivity period. Alternatively the webhook can be configured to send all open orders to your endpoint. 
-
-**Notification**
-
-Order notifications will be sent to the registered endpoint as http requests as follows:
-
-```jsx
-method: POST
-content-type: application/json
-data: {
-    orderHash: "the hash identifier for the order", 
-    createdAt: "timestamp at which the order was posted",
-    signature: "the swapper signature to include with order execution",
-    orderStatus: "current order status (always should be `open` upon receiving notification)",
-    encodedOrder: "The abi-encoded order to include with order execution. This can be decoded using the Uniswapx-SDK (https://github.com/uniswap/uniswapx-sdk) to verify order fields and signature",
-    chainId: "The chain ID that the order originates from and must be settled on",
-    filler?: "If this order was quoted by an RFQ participant then this will be their filler address",
-    quoteId?: "If this order was quoted by an RFQ participant then this will be the requestId from the quote request",
-    swapper: "OPTIONAL: the swapper address"
-}
-```
-
 # Requirements for Moving to Prod
 
 All new quoter instances will start by being onboarded to our [Beta environment](https://beta.api.uniswap.org/v2/uniswapx/docs), where they will need to demonstrate at least **5 valid Exclusive RFQ fills** in order to be moved to production. The [Beta environment](https://beta.api.uniswap.org/v2/uniswapx/docs) serves valid mainnet orders that should be filled against production contracts, it just does not receive traffic from any production interfaces. 

docs/contracts/uniswapx/guides/createFiller.md

@@ -39,7 +39,7 @@ bytes fillData = /* Call data to be sent to your executor contract */;
 executor.execute(order, fillData);
 ```
 
-For convenience, we’ve provided an [example Executor Contract](https://github.com/Uniswap/UniswapX/tree/v1.1.0/src/sample-executors) which demonstrates how a filler could implement a strategy that executes a UniswapX order against a Uniswap V3 pool.
+For convenience, we’ve provided an [example Executor Contract](https://github.com/Uniswap/UniswapX/tree/v1.1.0/src/sample-executors) which demonstrates how a filler could implement a strategy that executes a UniswapX order against a Uniswap V3 pool. These contracts should be deployed to each chain that the filler would like to support.
 
 ## 2A. Retrieve & Execute Signed Dutch Orders
 
@@ -51,10 +51,42 @@ GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=1&limit=1
 
 It’s up to the individual filler to architect their own systems for finding and executing profitable orders, but the basic flow is as follows:
 
-1. Call `GET` on the `/orders` of the UniswapX Orders Endpoint as written above, to retrieve open signed orders
-2. Decode returned orders using the [UniswapX SDK](https://github.com/Uniswap/UniswapX-sdk/#parsing-orders)
-3. Determine which orders you would like to execute
-4. Send a new transaction to the [execute](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L29) or [executeBatch](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L37) methods of the [Dutch Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/DutchOrderReactor.sol) specifying the signed orders you’d like to fill and the address of your executor contract
+1. Call `GET` on the `/orders` of the UniswapX Orders Endpoint as written above, to retrieve open signed orders. Dutch Orders are available on Mainnet (`chainId=1`) and Arbitrum (`chainId=42161`).
+2. Decode returned orders using the [UniswapX SDK](https://github.com/Uniswap/UniswapX-sdk/#parsing-orders).
+3. Determine which orders you would like to execute.
+4. Send a new transaction to the [execute](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L29) or [executeBatch](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L37) methods of the [Dutch Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/DutchOrderReactor.sol) specifying the signed orders you’d like to fill and the address of your executor contract.
+
+### (Optional) Signed Order Webhook Notifications
+
+Signed open orders can always be fetched via the UniswapX API, but to provide improved latency there is the option to register for webhook notifications. Quoters can register an endpoint with their filler address, and receive notifications for every newly posted order that matches the filter. 
+
+**Filter**
+
+Orders can be filtered by various fields, but most relevant here is `filler`. When registering your webhook notification endpoint, we recommend you provide the `filler` address that you plan to use to execute orders and to receive the last-look exclusivity period. Alternatively the webhook can be configured to send all open orders to your endpoint.
+
+**Filter**
+
+To register your webhook endpoint, please reach out [here](mailto:[email protected]).
+
+**Notification**
+
+Order notifications will be sent to the registered endpoint as http requests as follows:
+
+```jsx
+method: POST
+content-type: application/json
+data: {
+    orderHash: "the hash identifier for the order", 
+    createdAt: "timestamp at which the order was posted",
+    signature: "the swapper signature to include with order execution",
+    orderStatus: "current order status (always should be `open` upon receiving notification)",
+    encodedOrder: "The abi-encoded order to include with order execution. This can be decoded using the Uniswapx-SDK (https://github.com/uniswap/uniswapx-sdk) to verify order fields and signature",
+    chainId: "The chain ID that the order originates from and must be settled on",
+    filler?: "If this order was quoted by an RFQ participant then this will be their filler address",
+    quoteId?: "If this order was quoted by an RFQ participant then this will be the requestId from the quote request",
+    swapper: "OPTIONAL: the swapper address"
+}
+```
 
 ## 2B. Retrieve & Execute Signed Limit Orders
 The process for retrieving and executing limit orders is the same as Dutch Orders above except that Limit Orders will be retrieved from the [Limit Orders Endpoint](https://api.uniswap.org/v2/limit-orders) (full API docs [here](https://api.uniswap.org/v2/uniswapx/docs)) and executed against the [Limit Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/LimitOrderReactor.sol). The process is: