Networks

projects:
  - id: main
 
    # (OPTIONAL) This array configures network-specific (a.k.a chain-specific) features.
    # For each network "architecture" and corresponding network id (e.g. evm.chainId) is required.
    # You don't need to define networks as they will be automatically detected from configured endpoints.
    # Only provide network list if you want to customize features such as failsafe policies, rate limit budget, finality depth, etc.
    networks:
      - architecture: evm
        # When "evm" is used, "chainId" is required, so that rate limit budget or failsafe policies are properly applied.
        evm:
          # (REQUIRED) chainId is required when "evm" architecture is used.
          chainId: 1
          # (OPTIONAL) fallbackFinalityDepth is optional and allows to manually set a finality depth in case upstream does not support eth_getBlockByNumber(finalized).
          # In case this fallback is used, finalized block will be 'LatestBlock - fallbackFinalityDepth'.
          # Defining this fallback helps with increasing cache-hit rate and reducing redundant 'retry' attempts on empty responses, as we know which data is finalized.
          # DEFAULT: auto-detect - via eth_getBlockByNumber(finalized).
          fallbackFinalityDepth: 1024
 
        # (OPTIONAL) A network-level rate limit budget applied to all requests despite upstreams own rate-limits.
        # For example even if upstreams can handle 1000 RPS, and network-level is limited to 100 RPS,
        # the request will be rate-limited to 100 RPS.
        rateLimitBudget: my-limiter-budget
 
        # (OPTIONAL) Refer to "Failsafe" section for more details.
        # Here are default values used for networks if not explicitly defined:
        failsafe:
          timeout:
            # On network-level "timeout" is applied for the whole lifecycle of the request (including however many retries happens on upstream)
            duration: 30s
          retry:
            # It is recommended to set a retry policy on network-level to make sure if one upstream is rate-limited,
            # the request will be retried on another upstream.
            maxCount: 3
            delay: 100ms
            jitter: 0ms
            backoffMaxDelay: 1s
            backoffFactor: 1.5
          # Defining a "hedge" is highly-recommended on network-level because if upstream A is being slow for
          # a specific request, it can start a new parallel hedged request to upstream B, for whichever responds faster.
          hedge:
            delay: 200ms
            maxCount: 3
    
    upstreams:
    # Refer to "Upstreams" section to learn how to configure upstreams.
    # ...
# ...