+ +
+
+
+## Run
+
+### From Docker
+
+Run the Docker [image](https://github.com/synapsecns/sanguine/pkgs/container/sanguine%2Frfq-relayer) along with the path to your [YAML configuration file](#configure).
+
+1. `docker run ghcr.io/synapsecns/sanguine/rfq-relayer:latest --config /path/to/config`
+
+### From Source
+
+:::note Requires Go 1.21 or higher
+
+Not generally recommended for end-users.
+
+:::
+
+Clone the Sanguine repository, then run the main.go file along with the path to your [YAML configuration file](#configure).
+
+1. `git clone https://github.com/synapsecns/sanguine --recursive`
+2. `cd sanguine/services/rfq/relayer`
+3. `go run main.go --config /path/to/config.yaml`
+
+## sendChainGas
+
+Boolean flag available to Bridge users. When `sendChainGas` is `true`, the amount to send is specified as `chainGasAmount` in the FastBridge contract on the destination chain.
+
+:::note
+
+`chainGasAmount` is currently set to `0` on all contracts. You can ignore `sendChainGas` by only providing quotes where `sendChainGas` is not set, or `chainGasAmount` is `0`.
+
+:::
+
+## Withdrawals
+
+The `POST /withdraw` endpoint is exposed to allow withdrawals from the relayer wallet without needing to deal with the private key directly. This can be used for manual rebalancing. To use this feature, set the following config values:
+
+```yaml
+enable_api_withdrawals: true
+withdrawal_whitelist:
+ - `config.yml`
+ ```yaml +submitter_config: # please see the more detailed submitter documentation + chains: + 1: + supports_eip_1559: true + gas_estimate: 1000000 +database: + type: sqlite # can be other mysql or sqlite + dsn: /tmp/db # should be the dsn of your database. If using sqlite, this can be a path + +signer: # please see more detailed signer config #can be text, gcp, or aws + type: GCP + file: /config/signer.txt + +screener_api_url: 'http://screener-url' # can be left blank +rfq_url: 'http://rfq-api' # url of the rfq api backend. +omnirpc_url: 'http://omnirpc' # url of the omnirpc instance, please reference the Omnirpc section under Services for proper configuration +rebalance_interval: 2m # how often to rebalance +relayer_api_port: '8081' # api port for the relayer api +volume_limit: 10000 # USD price cap for a bridge under block confirmation minimum (configurable under `chains`) + +base_chain_config: # this is hte base chain config, other chains override it + confirmations: 0 + # Claim (72.5k) + Prove (57.5k) gas limits, rounded up + origin_gas_estimate: 130_000 + # Relay gas limit, rounded up + dest_gas_estimate: 110_000 + quote_offset_bps: 2 + native_token: ETH + quote_pct: 90 + min_gas_token: 1000000000000000000 + fixed_fee_multiplier: 1.25 + +chains: + 1: + rfq_address: "0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E" # rfq contract address on eth + synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" # ccctp contract address on eth + token_messenger_address: "0xbd3fa81b58ba92a82136038b25adec7066af3155" # token messenger address on eth, note: only one of token_messenger_address or synapse_cctp_address actually needs to be present + cctp_start_block: 19341000 + confirmations: 2 + tokens: + USDC: + address: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" + decimals: 6 + price_usd: 1.0 + min_quote_amount: 10000 + rebalance_method: "circlecctp" + maintenance_balance_pct: 20 + initial_balance_pct: 50 + max_rebalance_amount: 500000 + ETH: + address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" + decimals: 18 + price_usd: 2600 + 10: + rfq_address: "0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E" + synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" + token_messenger_address: "0x2B4069517957735bE00ceE0fadAE88a26365528f" + cctp_start_block: 116855000 + l1_fee_chain_id: 1 + # Prove + Claim L1 gas estimate + l1_fee_origin_gas_estimate: 20 + # Relay L1 gas estimate + l1_fee_dest_gas_estimate: 10 + tokens: + USDC: + address: "0x0b2c639c533813f4aa9d7837caf62653d097ff85" + decimals: 6 + price_usd: 1.0 + min_quote_amount: 10000 + rebalance_method: "circlecctp" + maintenance_balance_pct: 20 + initial_balance_pct: 50 + max_rebalance_amount: 500000 + ETH: + address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" + decimals: 18 + price_usd: 2600 + +quotable_tokens: + 10-0x0b2c639c533813f4aa9d7837caf62653d097ff85: + - "1-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" + 1-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48: + - "10-0x0b2c639c533813f4aa9d7837caf62653d097ff85" + 1-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE: + - "10-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" + 10-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE: + - "1-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" + +fee_pricer: + gas_price_cache_ttl: 60 + token_price_cache_ttl: 60 + +cctp_relayer_config: + cctp_type: "circle" + circle_api_url: "https://iris-api.circle.com/v1/attestations" + chains: + - chain_id: 1 + synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" + token_messenger_address: "0xbd3fa81b58ba92a82136038b25adec7066af3155" + - chain_id: 10 + synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" + token_messenger_address: "0x2B4069517957735bE00ceE0fadAE88a26365528f" + base_omnirpc_url: "http://omnirpc" # Make sure this is configured properly + unbonded_signer: + type: GCP + file: /config/signer.txt + http_backoff_initial_interval_ms: 1000 + http_backoff_max_elapsed_time_ms: 300000 + ``` +
-
-
- - `cctp_type`: The type of CCTP to listen to. Can be either `synapse` or `circle`.
- - `chains`: A list of chain ids and their corresponding CCTP contract addresses. If synapse mode, this should be `synapse_cctp_address` and if circle mode, this should be `token_messenger_address`. Both modes cannot be used at once and the other will be ignored if both are set.
- - `base_omnirpc_url`: The base URL for the OmniRPC service.
- - `unbonded_signer`: The signer to use for transactions. Can be either `AWS`, `File` or `GCP`. The file should be a mounted secret. More details can be found [here](../Services/Signer).
- - `port`: The port to run the relayer on (e.g. 8080)
- - `host`: The host to run the relayer on (e.g. localhost). Note: this should not be publicly exposed
- - `http_backoff_initial_interval_ms`: The initial interval for the backoff in milliseconds.
- - `retry_interval_ms`: The interval to wait between attestation request retries in milliseconds. The [CCTP API Rate Limit](https://developers.circle.com/stablecoins/docs/limits) should be kept in mind.
-
-### Observability
-
-The CCTP relayer implements open telemetry for both tracing and metrics. Please see the [Observability](../Observability) page for more info. We'd also highly recommend setting up the [submitter dashboard](../Services/Submitter) as well.
diff --git a/docs/bridge/docs/CCTP/_category_.json b/docs/bridge/docs/CCTP/_category_.json
deleted file mode 100644
index eda3422018..0000000000
--- a/docs/bridge/docs/CCTP/_category_.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "label": "CCTP",
- "position": 3,
- "link": {
- "type": "doc",
- "id": "CCTP/Overview"
- }
-}
diff --git a/docs/bridge/docs/rfq/API/sidebar.ts b/docs/bridge/docs/rfq/API/sidebar.ts
deleted file mode 100644
index 3c0e12fc63..0000000000
--- a/docs/bridge/docs/rfq/API/sidebar.ts
+++ /dev/null
@@ -1,26 +0,0 @@
-import type { SidebarsConfig } from "@docusaurus/plugin-content-docs";
-
-const sidebar: SidebarsConfig = {
- apisidebar: [
- {
- type: "category",
- label: "quotes",
- items: [
- {
- type: "doc",
- id: "rfq/API/get-quotes",
- label: "Get quotes",
- className: "api-method get",
- },
- {
- type: "doc",
- id: "rfq/API/upsert-quote",
- label: "Upsert quote",
- className: "api-method put",
- },
- ],
- },
- ],
-};
-
-export default sidebar.apisidebar;
diff --git a/docs/bridge/docs/rfq/Contracts.md b/docs/bridge/docs/rfq/Contracts.md
deleted file mode 100644
index a5b0947942..0000000000
--- a/docs/bridge/docs/rfq/Contracts.md
+++ /dev/null
@@ -1,51 +0,0 @@
-### Synapse RFQ
-
-The Synapse RFQ contract source code can be found [here](https://github.com/synapsecns/sanguine/tree/master/packages/contracts-rfq) along with generated documentation [here](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html)
-
-| Chain | Address |
-| -------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| Arbitrum | [0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E](https://arbiscan.io/address/0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) |
-| Base | [0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E](https://basescan.org/address/0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) |
-| Ethereum | [0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E](https://etherscan.io/address/0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) |
-| Optimism | [0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E](https://optimistic.etherscan.io/address/0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) |
-| Scroll | [0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E](https://scrollscan.com/address/0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) |
-| Linea | [0x34F52752975222d5994C206cE08C1d5B329f24dD](https://lineascan.build/address/0x34F52752975222d5994C206cE08C1d5B329f24dD) |
-| BNB Chain| [0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E](https://bscscan.com/address/0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) |
-| Blast | [0x34F52752975222d5994C206cE08C1d5B329f24dD](https://blastscan.io/address/0x34F52752975222d5994C206cE08C1d5B329f24dD) |
-
-### On-Chain Architecture & Transaction Flow
-
-The RFQ contract allows users to post bridge requests based on quotes they have received from the solvers. At a high level, the contract works as follows:
-
-1. **User calls bridge**: The user calls the bridge contract with the quote they have received from the RFQ API and passing in origin, destination and other paramaters as a [BridgeParam](https://vercel-rfq-docs.vercel.app/contracts/interfaces/IFastBridge.sol/interface.IFastBridge.html#bridgeparams).
-2. **Bridge emits event**: The bridge contract emits a [`BridgeRequested`](https://vercel-rfq-docs.vercel.app/contracts/interfaces/IFastBridge.sol/interface.IFastBridge.html#bridgerequested) event.
-3. **Solver relays request**: The solver relays the request by calling the [`relay`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#relay) function on the RFQ contract. The contract then pulls the tokens from the solvers wallet (or [msg.value](https://ethereum.stackexchange.com/questions/43362/what-is-msg-value) in the case of eth) and sends them to the user filling their order.
-4. **Solver Calls Prove**: The solver then calls the [`prove`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#prove) function on the RFQ contract to prove they have filled the order. In the current implementation, the function must be called from the solver address.
-5. **User Claims**: If the solver does not call prove within the optimistic window, the user can call the [`claim`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#claim) function to claim their funds back.
-
-### On-Chain Statuses
-
-Like the relayer, each transaction in the RFQ contract has a status. The statuses are as follows:
-
-| Status | Int | Meaning |
-|-----------------|-----|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Null | 0 | Bridge transaction doesn't exist yet on the origin chain. |
-| Requested | 1 | A bridge has been requested, but the [`prove`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#prove) has not yet been called |
-| Relayer Proved | 2 | The relayer has tried to [`prove`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#prove) the transaction, but cannot claim yet. |
-| Relayer Claimed | 3 | The relayer has called [`claim`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#claim) and gotten the funds. |
-| Refunded | 4 | The relayer has not called `claim` within the optimistic period or a dispute has been decided in favor of the user and the users been refunded. |
-
-
-### Dispute Period and Guards
-
-The RFQ system includes a dispute period and guards to ensure the integrity of bridge transactions. Here's how it works:
-
-After a relayer submits a proof for a bridge transaction, there's a set period during which the transaction can be disputed. This period allows for detection and correction of any errors or fraudulent activities. Guards are responsible for monitoring bridge transactions and initiating disputes if they detect issues such as incorrect fill amounts and proofs submitted by the wrong relayer. A successful dispute would end up with the relayer losing their claimable funds.
-
-The current implementation is architectured to enforce honest behavior and also protect honest relayers in cases of blockchain reorgs.
-
-### Other Functionalities
-
-**ChainGas**
-
-`sendChainGas` is a field that is populated by the bridge user, and it's a simple bool flag. If `sendChainGas=true` the amount is specified in the FastBridge contract on the destination chain as `chainGasAmount`. This is currently set to zero in all the contracts, and can thus be ignored by filling orders with either no `sendChainGas` option (or to chains with `chainGasAmount==0`)
diff --git a/docs/bridge/docs/rfq/RFQ.md b/docs/bridge/docs/rfq/RFQ.md
deleted file mode 100644
index d2d9aaf7bd..0000000000
--- a/docs/bridge/docs/rfq/RFQ.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# RFQ
-
-RFQ is a bridge module supported by the Synapse Router that allows different market makers to post quotes on different bridge routes. Users can take these quotes by submitting an on-chain bridge request. In the event these requests are not fulfilled, users can request a refund after a set period of time.
-
-### Actors
-
-With the exception of the smart contract itself, RFQ is agnostic to how users receive quotes and where Solvers choose to post quotes. Below, we explain who the general actors interacting with the contract are and then explain the canonical RFQ implementation.
-
-- **Solvers -** Solvers (also known as fillers) are market makers that provide liquidity & post quotes to the API. They are then in charge of fulfilling requests on-chain.
-- **Users** - End users observe quotes from solvers and post requests on chain. In the event these requests cannot be fulfilled, the user can reclaim their funds after the optimistic window has passed.
-- **Quoter -** The quoter runs a service ran by different interfaces to the Synapse Bridge that allows market makers to post quotes and users to read them. The spec of RFQ does not require this to be an “API” in the traditional sense. Interfaces can use protocols like libp2p, irc and dht’s to communicate quotes.
-
-Right now, RFQ consists of three-different components, with each of the two off-chain components being ran by different actors:
-
-- **[API](./API) -** The RFQ api is an off-chain service ran by Quoters. user-interfaces that allows market makers/solvers to post quotes on different bridge routes. Solvers that have registered with the FastBridge contract can sign messages that post quotes signifying at what price they are willing to bridge tokens on a certain route.
-
- In the canonical implementation, users Solvers authenticated by signing requests with their private key in accordance with [EIP-191](https://eips.ethereum.org/EIPS/eip-191). The canonical implementation can be found [here](https://github.com/synapsecns/sanguine/tree/master/services/rfq).
-- **Fast Bridge Contract -** The fast bridge contract is the core of the RFQ protocol and what allows solvers to fulfill requests from users. A user deposits their funds into the FastBridge contract along with the lowest price they are willing to accept for a given route (a price they get by reading quotes from the Quoter).
-
- In the unlikely event no Solver is available to fulfill a users request, a user can permissionlessly claim their funds back after waiting an optimistic period.
-
- Contract code level documentation can be found [here](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html).
-- **Relayer** - The relayer is a service ran by the solvers. The relayer is responsible for posting quotes & fulfilling requests. While the relayer can be implemented in any way, the canonical implementation is a golang based relayer that provides a way to decide what chains/routes to quote on, how much to quote and which addresses not to relay for.
-
diff --git a/docs/bridge/docs/rfq/Relayer/Relayer.md b/docs/bridge/docs/rfq/Relayer/Relayer.md
deleted file mode 100644
index b47e066ea6..0000000000
--- a/docs/bridge/docs/rfq/Relayer/Relayer.md
+++ /dev/null
@@ -1,282 +0,0 @@
----
-sidebar_position: 0
-sidebar_label: Relayer
----
-:::note
-
-Relayers must be whitelisted in order to fill bridgeRequests.
-
-:::
-
-At a high level, the canonical implementation of the relayer has 3 different responsibilities.
-
-- **Quoting** - Keep track of balances on each chain as well as in-flight funds and continuously post-quotes with these balances using the config to adjust quotes to the solvers specifications and posting to the API.
-- **Relaying -** Fulfill users [BridgeRequests](https://vercel-rfq-docs.vercel.app/contracts/interfaces/IFastBridge.sol/interface.IFastBridge.html#bridgerequested) by relaying their funds on-chain. Once eligible, claim the users funds on the origin chain.
-- **Rebalancing -** In order to handle the complexity of user flows, the Relayer provides an interface that allows funds to be rebalanced. This allows RFQ to be reflexive to cases where flows are mono-directional.
-
-## Architecture
-
-The relayer is a Golang application that polls for events on chain and uses a combo state (db status) and event (on-chain logs) driven architecture to process transactions. The relayer has 3 different event loops going at any given time, specified above and elaborated on below:
-
-### Quoting
-The quoting loop is comparitively simple and updates the api on each route it supports. Quotes are posted using the following formula:
-
- - **Do not quote above available balance**: Available balance is determined by `balance on chain - in-flight funds`. If the token is the gas token, then the minimum gas token amount is subtracted. The relayer will also not post quotes below the `min_quote_amount` specified in the config.
- - **Quote offset**: The quote offset is a percentage of the price of the token. This is used to ensure that the relayer is profitable. The quote offset is added to the price of the token to determine the quote price.
- - **Fee**: The fee is determined by the `fixed_fee_multiplier` in the config. This is multiplied by the `origin_gas_estimate` and `destination_gas_estimate` to determine the fee. This fee is added to the quote price.
-
-### Rebalancing
-
-Automated rebalancing is configurable by token and currently supports CCTP routes as well as native bridging in the case of Scroll. Rebalancing evaluation follows this logic on every `rebalance_interval`:
-
-- For every supported rebalance method, compute the 'total balance' of each token as the sum of all balances across chains that support the given rebalance method.
-- For every supported token, compute the 'maintenance threshold' as the product of the `maintenance_balance_pct` and the 'total balance'. A token is eligible for rebalancing if the current balance is below the 'maintenance threshold'.
-
-To limit the amount of inventory that is inflight, only one rebalance can be pending at a time for each token. As such, we select the 'best' rebalance candidate as the rebalance with the largest delta between origin balance and destination balance.
-
-The final step in evaluating a rebalance is determining the rebalance amount:
-
-- Arrive at an initial rebalance amount by computing the delta between current balance and the initial threshold on origin.
-- Check if this rebalance amount is too much, i.e. it would take the destination balance above its initial threshold. If so, clip the rebalance amount to target the destination initial threshold.
-- Filter the rebalance amount by the configured min and max.
-
-An example of this process is given below:
-
-We are dealing with chains 1, 2, and 3. Chains 1 and 2 support USDC with CCTP, and chain 3 supports USDC but does not support CCTP. Each chain has a `maintenance_pct` of 20%, while chains 1 and 2 have `initial_pct` of 40% and chain 3 has 20%. Assume chain 1 has a balance of 100 USDC, chain 2 has 900 USDC, and chain 3 has 2000 USDC.
-
-The system would trigger a rebalance from chain 2 to chain 1, since the total balance of CCTP-supported chains is 1000 USDC, and chain 1 is below the 20% maintenance threshold. Chain 3 is not considered for rebalance since it does not support CCTP.
-
-The rebalance amount would be initially be targeted as 600 since this would take chain 2 to its 40% initial threshold. However, since chain 1 only needs 300 to reach its initial 40% threshold, the rebalance amount is clipped at 300.
-
-So, the final result is a rebalance of 300 USDC from chain 2 to chain 1, leading to chain 1 having 400 USDC, chain 2 having 600 USDC, and chain 3 having 2000 USDC.
-
-
-1. At `rebalance_interval`, check the `maintenance_balance_pct` of each token on each chain and compare it to the current balance. If the balance is below the `maintenance_balance_pct`, continue
-2. Calculate the amount to rebalance by taking the difference between the maintenance balance and the current balance and multiplying it by the `initial_balance_pct`.
-3. If the amount to rebalance is greater than the `max_rebalance_amount`, set the amount to rebalance to the `max_rebalance_amount`. If the amount to rebalance is less than the `min_rebalance_amount`, do not rebalance.
-4. Repeat after `rebalance_interval`
-
-The implementation for certain native bridges (e.g Scroll) is also supported. It works slightly differently as flows are only supported between Scroll and Mainnet. At a high level, the rebalancer checks inventory on Scroll versus other chains, and if imbalanced, initiates a bridge to mainnet, allowing the CCTP relayer to rebalance funds where needed.
-
-
-### Relaying
-
-The relaying loop is the most complex and is responsible for relaying funds on-chain. The relayer listens to events on-chain and status updates in the database to take move transactions through the states. The states are as follows:
-
-1. An on-chain transaction emits the event [`BridgeRequested`](https://vercel-rfq-docs.vercel.app/contracts/interfaces/IFastBridge.sol/interface.IFastBridge.html#bridgerequested). We store this event in the db with the status [`Seen`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#Seen).
-1. Check if the request is valid, If not, it is marked as [`WillNotProcess`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#WillNotProcess)
-1. Check if there's enough inventory, if not mark as [`NotEnoughInventory`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#NotEnoughInventory) and try again later.
-1. If these checks pass, it's stored as [`CommittedPending`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#CommittedPending). This will automatically reduce the next quote amount posted to the api since the relayers liquidity has been committed.
-1. Check the chain to see if transaction is finalized yet, if not wait until it is.
-1. Once the transaction is finalized on chain, update the status to [`CommitedConfirmed`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#CommitedConfirmed). This means the transaction is finalized on chain and we can now relay it to the destination chain.
-1. Call [`relay`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#relay) on the contract to relay the transaction and update the status to [`RelayPending`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#RelayPending)
-1. Listen for the relay in the logs. Once we get it we mark the transaction as [`RelayComplete`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#RelayComplete)
-1. Call [`Prove()`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#prove) on the contract to prove that we relayed the transaction. Once this is done, we mark the transaction as [`ProvePosting`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#ProvePosting)
-1. Wait for the dispute period to expire. Once it does call [`claim`](https://vercel-rfq-docs.vercel.app/contracts/FastBridge.sol/contract.FastBridge.html#claim) mark the transaction as [`ClaimPending`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#ClaimPending)
-1. Wait for the dispute period to expire. Once it does mark the transaction as [`ClaimComplete`](https://pkg.go.dev/github.com/synapsecns/sanguine/services/rfq/relayer/reldb#ClaimComplete)
-
-## Running a Relayer
-
-### Building From Source
-
-To build the relayer from source, you will need to have Go installed. You can install Go by following the instructions [here](https://golang.org/doc/install). Once you have Go installed, you can build the relayer by running the following commands:
-
-1. `git clone https://github.com/synapsecns/sanguine --recursive`
-2. `cd sanguine/services/rfq/relayer`
-3. `go run main.go --config /path/to/config.yaml`
-
-### Running the Docker Image
-
-The relayer can also be run with docker. To do this, you will need to pull the [docker image](https://github.com/synapsecns/sanguine/pkgs/container/sanguine%2Frfq-relayer) and run it with the config file:
-
-```bash
-docker run ghcr.io/synapsecns/sanguine/rfq-relayer:latest --config /path/to/config
-```
-
-### Withdrawals
-
-The `POST /withdraw` endpoint is exposed to allow for withdrawing from the relayer wallet without having to deal with the private key directly. This can be used for manual rebalancing, if desired. To use this feature, the following config values must be set:
-
-```yaml
-enable_api_withdrawals: true
-withdrawal_whitelist:
- - example config
-```yaml - cctp_type: "synapse" - # prod contract addresses - chains: - - chain_id: 1 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - - chain_id: 43114 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - - chain_id: 42161 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - - chain_id: 10 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - - chain_id: 8453 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - - chain_id: 137 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - base_omnirpc_url: "http://omnrpc-url/" - unbonded_signer: - type: "AWS" - # should be a mounted secret - file: "/config/aws.txt" - http_backoff_initial_interval_ms: 1000 - http_backoff_max_elapsed_time_ms: 300000 - # submitter config for cctp - submitter_config: - chains: - 1: - supports_eip_1559: true - gas_estimate: 1000000 - 42161: - gas_estimate: 30000000 - max_gas_price: 10000000000 - supports_eip_1559: true - 43114: - gas_estimate: 5000000 - max_gas_price: 1000000000000 - supports_eip_1559: true - 10: - gas_estimate: 5000000 - max_gas_price: 2000000000 - supports_eip_1559: true - 8453: - gas_estimate: 5000000 - 137: - gas_estimate: 5000000 - max_gas_price: 10000000000000 - supports_eip_1559: true -``` -
-
-
-
-
- - `submitter_config` - This is covered [here](../../Services/Submitter#Observability). At a high level this controls gas parameters used for on-chain transactions.
- - `database` - The database settings for the API backend. A database is required to store quotes and other information. Using SQLite with a dsn set to a `/tmp/` directory is recommended for development.
- - `type` - the database driver to use, can be `mysql` or `sqlite`.
- - `dsn` - the dsn of your database. If using sqlite, this can be a path, if using mysql please see [here](https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration.html) for more information.
- - `screener_api_url` (optional) - Please see [here](https://github.com/synapsecns/sanguine/tree/master/contrib/screener-api#screening-api) for an api spec, this is used descision on wether to bridge to given addresses.
- - `rfq_url` - URL of the rfq api, please see the [API](../API#api-urls) page for details and the mainnet/testnet urls.
- - `omnirpc_url` - URL of omnirpc to use, Please see [here](../../Services/Omnirpc) for details on running an omnirpc instance.
- - `rebalance_interval` - How often to rebalance, formatted as (s = seconds, m = minutes, h = hours)
- - `relayer_api_port` - the relayer api is used to control the relayer. This api should be secured/not public.
- - `base_chain_config`: Base chain config is the default config applied for each chain if the other chains do not override it. This is covered in the chains section.
- - `enable_guard` - Run a guard on the same instance.
- - `submit_single_quotes` - Wether to use the batch endpoint for posting quotes to the api. This can be useful for debugging.
- - `chains` - each chain has a different config that overrides base_chain_config. Here are the parameters for each chain
- - `rfq_address` - the address of the rfq contract on this chain. These addresses are available [here](../Contracts.md).
-
- - `synapse_cctp_address` (optional) - this is only applicable if **rebalance_method** is set to synapse. This is the address of the CCTP contract available [here](../../CCTP/Contracts).
- - `token_messenger_address` (optional) - this is only applicable if **rebalance_method** is set to cctp. Tells the relayer to use the token messenger instead of synapse.
-
- - `confirmations` - how many confirmations to wait before acting on an event. This will vary per-chain.
- - `tokens` - this is a map of token symbol→token info for this chain. For example, token may be USDC, ETH, etc
- - `address` - address of the token on this chain id
- - `decimals` - number of decimals this token uses. Please verify this against the token contract itself.
- - `min_quote_amount` - smallest amount to quote for a given chain. This should be balanced against expected gas spend for a relayer to be profitable. `min_quote_amount` is to be given in decimal units (so 1000.00 is 1000)
- - `rebalance_method` - rebalance method for this particular kind of token. Some tokens may not have a rebalance method. This is either cctp or token messenger.
- - `maintenance_balance_pct` - percent of liquidity that should be maintained on the given chain for this token. If the balance is under this amount a rebalance is triggered.
- - `initial_balance_pct` - percent of liquidity to maintain after a rebalance. The total of these on all-chains should be 100.
- - `min_rebalance_amount` - amount of this token to try to rebalance
- - `max_rebalance_amount` - maximum amount of this token to try to rebalance at once
- - `quotable_tokens`:
-- `quotable_tokens`: - list of [chain-id]_[token_address]: [chain-id]_[token_address]. For example 1-0x00…. could be paired with 10-0x01
- ```yaml
- "1-0x00":
- - "1-0x01"
- ```
-- `cctp_relayer_config`: See the [CCTP page](../../CCTP/Relayer)
-
-### Observability
-
-The RFQ relayer implements open telemetry for both tracing and metrics. Please see the [Observability](../../Observability) page for more info. There is also a custom [grafana dashboard](https://github.com/synapsecns/sanguine/tree/master/services/rfq/relayer/dashboards/dashboard.json) available for the relayer. We'd also highly recommend setting up the [submitter dashboard](../../Services/Submitter) as well.
-
-
-
-The metrics exposed by the relayer are:
-
-- `inventory_balance`: The balance of the inventory on the chain for a given `token_name` and `relayer`.
-- `quote_amount`: The amount quoted for a given `token_name` and `relayer`.
-- `status_count`: The distribution of non-terminal `QuoteRequestStatus` values over time.
diff --git a/docs/bridge/docs/rfq/_category_.json b/docs/bridge/docs/rfq/_category_.json
deleted file mode 100644
index 8097372c06..0000000000
--- a/docs/bridge/docs/rfq/_category_.json
+++ /dev/null
@@ -1,8 +0,0 @@
-{
- "label": "RFQ",
- "position": 3,
- "link": {
- "type": "doc",
- "id": "rfq/RFQ"
- }
-}
diff --git a/docs/bridge/docusaurus.config.ts b/docs/bridge/docusaurus.config.ts
index d7ed74fca7..9e7b597094 100644
--- a/docs/bridge/docusaurus.config.ts
+++ b/docs/bridge/docusaurus.config.ts
@@ -1,13 +1,32 @@
-import {themes as prismThemes} from 'prism-react-renderer';
-import type {Config} from '@docusaurus/types';
-import type * as Preset from '@docusaurus/preset-classic';
-import * as path from "path";
-import {codecovWebpackPlugin} from "@codecov/webpack-plugin";
+/* eslint-disable prefer-arrow/prefer-arrow-functions */
+import * as path from 'path'
+
+import { themes as prismThemes } from 'prism-react-renderer'
+import type { Config } from '@docusaurus/types'
+import type * as Preset from '@docusaurus/preset-classic'
+import { codecovWebpackPlugin } from '@codecov/webpack-plugin'
+
+const options = {
+ id: 'api', // plugin id
+ docsPluginId: 'classic', // id of plugin-content-docs or preset for rendering docs
+ config: {
+ rfqapi: {
+ // the example config
- ```yaml - submitter_config: # please see the more detailed submitter documentation - chains: - 1: - supports_eip_1559: true - gas_estimate: 1000000 - database: - type: sqlite # can be other mysql or sqlite - dsn: /tmp/db # should be the dsn of your database. If using sqlite, this can be a path - - signer: # please see more detailed signer config #can be text, gcp, or aws - type: GCP - file: /config/signer.txt - - screener_api_url: 'http://screener-url' # can be left blank - rfq_url: 'http://rfq-api' # url of the rfq api backend. - omnirpc_url: 'http://omnirpc' # url of the omnirpc instance, please reference the Omnirpc section under Services for proper configuration - rebalance_interval: 2m # how often to rebalance - relayer_api_port: '8081' # api port for the relayer api - volume_limit: 10000 # USD price cap for a bridge under block confirmation minimum (configurable under `chains`) - - base_chain_config: # this is hte base chain config, other chains override it - confirmations: 0 - # Claim (72.5k) + Prove (57.5k) gas limits, rounded up - origin_gas_estimate: 130_000 - # Relay gas limit, rounded up - dest_gas_estimate: 110_000 - quote_offset_bps: 2 - native_token: ETH - quote_pct: 90 - min_gas_token: 1000000000000000000 - fixed_fee_multiplier: 1.25 - - chains: - 1: - rfq_address: "0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E" # rfq contract address on eth - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" # ccctp contract address on eth - token_messenger_address: "0xbd3fa81b58ba92a82136038b25adec7066af3155" # token messenger address on eth, note: only one of token_messenger_address or synapse_cctp_address actually needs to be present - cctp_start_block: 19341000 - confirmations: 2 - tokens: - USDC: - address: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" - decimals: 6 - price_usd: 1.0 - min_quote_amount: 10000 - rebalance_method: "circlecctp" - maintenance_balance_pct: 20 - initial_balance_pct: 50 - max_rebalance_amount: 500000 - ETH: - address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" - decimals: 18 - price_usd: 2600 - 10: - rfq_address: "0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E" - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - token_messenger_address: "0x2B4069517957735bE00ceE0fadAE88a26365528f" - cctp_start_block: 116855000 - l1_fee_chain_id: 1 - # Prove + Claim L1 gas estimate - l1_fee_origin_gas_estimate: 20 - # Relay L1 gas estimate - l1_fee_dest_gas_estimate: 10 - tokens: - USDC: - address: "0x0b2c639c533813f4aa9d7837caf62653d097ff85" - decimals: 6 - price_usd: 1.0 - min_quote_amount: 10000 - rebalance_method: "circlecctp" - maintenance_balance_pct: 20 - initial_balance_pct: 50 - max_rebalance_amount: 500000 - ETH: - address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" - decimals: 18 - price_usd: 2600 - - quotable_tokens: - 10-0x0b2c639c533813f4aa9d7837caf62653d097ff85: - - "1-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" - 1-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48: - - "10-0x0b2c639c533813f4aa9d7837caf62653d097ff85" - 1-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE: - - "10-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" - 10-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE: - - "1-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" - - fee_pricer: - gas_price_cache_ttl: 60 - token_price_cache_ttl: 60 - - cctp_relayer_config: - cctp_type: "circle" - circle_api_url: "https://iris-api.circle.com/v1/attestations" - chains: - - chain_id: 1 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - token_messenger_address: "0xbd3fa81b58ba92a82136038b25adec7066af3155" - - chain_id: 10 - synapse_cctp_address: "0x12715a66773BD9C54534a01aBF01d05F6B4Bd35E" - token_messenger_address: "0x2B4069517957735bE00ceE0fadAE88a26365528f" - base_omnirpc_url: "http://omnirpc" # Make sure this is configured properly - unbonded_signer: - type: GCP - file: /config/signer.txt - http_backoff_initial_interval_ms: 1000 - http_backoff_max_elapsed_time_ms: 300000 - ``` -
@@ -52,10 +54,10 @@ function Feature({title, Svg, description}: FeatureItem) {
{description}
@@ -66,5 +68,5 @@ export default function HomepageFeatures(): JSX.Element {
+ {chainImg} {chain.name} {id}
+
+ {Object.values(tokens).map((token) => {
+ const tokenImg =
+ typeof token.icon === 'string' ? (
+
-
- {siteConfig.title}
-
-
- {siteConfig.tagline}
-
-
- Docusaurus Tutorial - 5min ⏱️
-
-
-
+//
+// {siteConfig.title}
+//
+//
+// {siteConfig.tagline}
+//
+//
+// Docusaurus Tutorial - 5min ⏱️
+//
+//
+//