Server Configuration

Reference for all Fynd server flags, worker pool tuning, blocklist configuration, logging, and monitoring.

Run options

All on-chain protocols available on your configured Tycho endpoint are fetched by default, so --protocols is optional. The --tycho-url also defaults to the Fynd endpoint for the selected chain.

fynd serve

To run on a different chain:

fynd serve --chain base

--rpc-url defaults to the public endpoint https://eth.llamarpc.com. For production, use a dedicated endpoint:

fynd serve \
  --rpc-url https://your-rpc-provider.com/v1/your_key

Specify protocols explicitly:

fynd serve \
  --protocols uniswap_v2,uniswap_v3,ekubo_v3,fluid_v1

See the full list of available protocols.

Including RFQ Protocols

Include RFQ (Request-for-Quote) protocols alongside on-chain protocols. Use the all_onchain keyword to combine auto-fetched on-chain protocols with specific RFQ protocols:

fynd serve \
  --protocols all_onchain,rfq:bebop

Or specify both on-chain and RFQ protocols explicitly:

fynd serve \
  --protocols uniswap_v2,uniswap_v3,rfq:bebop

Limitations:

• RFQ protocols cannot run alone. At least one on-chain protocol is required.

• When encoding is enabled (encoding_options in the quote request), RFQ quotes require an additional round-trip to the RFQ provider to fetch a signed quote. This can add significant tail latency to solve times. If you are using RFQ protocols, consider quoting first without encoding to evaluate the price, and only request encoding once you are confident the quote is worth executing.

Environment variables:

• RFQ protocols require API keys passed via environment variables. Check the RFQ protocol docs for the specific variables each protocol needs.

Flag reference

Run fynd serve --help for the full list.

Required

Flag	Env Var	Description
--tycho-api-key	TYCHO_API_KEY	Tycho API key

Optional

Flag	Env Var	Default	Description
--rpc-url	RPC_URL	https://eth.llamarpc.com	Node RPC endpoint for the target chain. Use a dedicated endpoint in production.
--tycho-url	TYCHO_URL	(chain-specific)	Tycho URL. Defaults to the Fynd hosted endpoint for the selected chain.
--chain	—	Ethereum	Target chain
-p, --protocols	—	(all on-chain)	Protocols to index (comma-separated). If omitted, all on-chain protocols available on your configured Tycho endpoint are fetched. Use all_onchain to combine auto-fetched protocols with explicit entries (e.g. all_onchain,rfq:bebop).
--http-host	HTTP_HOST	0.0.0.0	HTTP bind address
--http-port	HTTP_PORT	3000	API port
--min-tvl	—	10.0	Minimum pool TVL in native token (ETH)
--tvl-buffer-ratio	—	1.1	Hysteresis buffer for TVL filtering. Components are added when TVL >= min_tvl and removed when TVL drops below min_tvl / tvl_buffer_ratio.
--traded-n-days-ago	—	3	Only include tokens traded within this many days.
--worker-router-timeout-ms	—	100	Default solve timeout (ms)
--worker-router-min-responses	—	0	Early return threshold (0 = wait for all pools)
-w, --worker-pools-config	WORKER_POOLS_CONFIG	worker_pools.toml	Worker pools config file path
--blocklist-config	BLOCKLIST_CONFIG	tycho-simulation default	Path to blocklist TOML config file. Components listed here are excluded from the Tycho stream.
--disable-tls	—	false	Disable TLS for Tycho connection
--min-token-quality	—	100	Minimum token quality filter
--gas-refresh-interval-secs	—	30	Gas price refresh interval
--reconnect-delay-secs	—	5	Reconnect delay on connection failure
--gas-price-stale-threshold-secs	—	(disabled)	Health returns 503 when gas price exceeds this age. Disabled by default.
--enable-price-guard	—	false	Enable price guard validation against external price sources.
--price-guard-lower-tolerance-bps	—	300	Max allowed deviation (bps) when the quote's output is below the provider's expected amount.
--price-guard-upper-tolerance-bps	—	10000	Max allowed deviation (bps) when the quote's output is above the provider's expected amount.
--price-guard-fail-on-provider-error	—	false	Reject quotes when all price providers fail with infrastructure errors.
--price-guard-fail-on-token-price-not-found	—	false	Reject quotes when no provider lists the token.

Worker pools (worker_pools.toml)

Worker pools control solver thread count and routing strategies. The default config ships with one pool:

# worker_pools.toml
[pools.bellman_ford_2_hops]
algorithm = "bellman_ford"
num_workers = 3
task_queue_capacity = 1000
max_hops = 2
timeout_ms = 500

All pools solve every incoming order in parallel. Fynd picks the best result across pools within the timeout.

Worker pool fields

Field	Default	Description
algorithm	(required)	Algorithm used for the pool ("most_liquid" or "bellman_ford")
num_workers	CPU count	Number of OS threads dedicated to this pool
task_queue_capacity	1000	Maximum number of orders that can be queued simultaneously
min_hops	1	Minimum number of hops required for routing
max_hops	3	Maximum number of hops permitted for routing
timeout_ms	100	Maximum time in milliseconds allowed per order processing in this pool
max_routes	(no limit)	Maximum number of candidate routes to evaluate per order

To use a custom config file:

fynd serve -w my_worker_pools.toml

Blocklist config

By default, Fynd loads blocklist.toml from tycho-simulation. The default excludes components with known simulation issues (e.g., rebasing tokens on UniswapV3 pools). Override with --blocklist-config:

fynd serve --blocklist-config my_blocklist.toml

The config file uses a [blocklist] section listing component IDs to exclude:

[blocklist]
components = [
    "0x86d257cdb7bc9c0df10e84c8709697f92770b335",
]

Logging and monitoring

Logs

Control log verbosity with RUST_LOG:

# Minimal output
RUST_LOG=warn fynd serve ...

# Default (recommended)
RUST_LOG=fynd=info fynd serve ...

# Debug solver internals
RUST_LOG=info,fynd_core=debug fynd serve ...

# Trace-level (very verbose, not recommended)
RUST_LOG=info,fynd_core=trace fynd serve ...

Prometheus metrics

---

Tuning tips

Worker pools

• More workers = more orders can be solved concurrently. Each worker is a dedicated OS thread, so avoid exceeding your CPU core count across all pools.

• Lower max_hops = faster solves but may miss better multi-hop routes.

• Higher max_hops = explores deeper routes but takes longer. Pair with a higher timeout_ms.

• Multiple pools with different max_hops and timeout_ms let you trade off speed vs. route quality — e.g. a fast 2-hop pool alongside a slower 3-hop pool.

• Lower max_routes = more predictable latency on large graphs, at the cost of potentially missing a better route.

Request routing

• Lower --worker-router-min-responses = faster response with multiple pools — set to 1 to return as soon as the first pool finishes, at the cost of potentially missing a better result from a slower pool.

Metrics are exposed at http://localhost:9898/metrics (always on). Scrape this endpoint with Prometheus or any compatible tool. Available metrics: solve duration, response counts, failure types, and pool performance.