relayer/config at develop · webb-tools/relayer

Name	Name	Last commit message	Last commit date
parent directory ..
block-header-relay	block-header-relay
development	development
example	example
exclusive-strategies	exclusive-strategies
README.md	README.md

Relayer Configration files

This directory contains the example configuration files for the relayer. The relayer is configured using a set of TOML file(s) which can be thought of as a set of blueprints for the relayer. In the following section we will describe the different configuration entries and how to use them.

Index

Global Configuration
- port
- features
- evm-etherscan
  - chain-id
  - api-key
- assets
  - name
  - decimals
  - price
EVM Chain Configuration
Substrate Node Configuration

Global Configuration

The global configuration file is used to configure the relayer. It is usually located at a file called main.toml in the config directory.

port

The port on which the relayer will listen for incoming connections.

Type: number
Required: false
Default: 9955
env: WEBB_PORT

Example:

port = 9955

features

The features section is used to enable or disable the relayer features.

Type: table
Required: false
Default: { governance-relay = true, data-query = true, private-tx-relay = true }
env: WEBB_FEATURES_GOVERNANCE_RELAY, WEBB_FEATURES_DATA_QUERY, WEBB_FEATURES_PRIVATE_TX_RELAY

Example:

[features]
governance-relay = true
data-query = true
private-tx-relay = true

governance-relay

Enable or disable the governance-relay feature. Enabling this feature will allow the relayer to relay proposals and vote on them between the chains.

Type: bool
Required: false
Default: true
env: WEBB_FEATURES_GOVERNANCE_RELAY

Example:

[features]
governance-relay = true

data-query

Enable or disable the data-query feature. Enabling this feature will allow the relayer to work as a data query oracle.

Type: bool
Required: false
Default: true
env: WEBB_FEATURES_DATA_QUERY

Example:

[features]
data-query = true

private-tx-relay

Enable or disable the private-tx-relay feature. When enabled, the relayer will be able to relay private transactions.

Type: bool
Required: false
Default: true
env: WEBB_FEATURES_PRIVATE_TX_RELAY

Example:

[features]
private-tx-relay = true

evm-etherscan

Etherscan api configuration for chains. This config is required if private-tx-relay is enabled. example:

[evm-etherscan.goerli]
chain-id = 5
api-key = "$ETHERSCAN_GOERLI_API_KEY"
[evm-etherscan.polygon]
chain-id = 137
api-key = "$POLYGONSCAN_MAINNET_API_KEY"

chain-id

Etherscan chain id, this are used to fetch gas prices from the explorer. example:

chain-id = 5

api-key

Etherscan api key, this are used to fetch gas prices from the explorer. example:

api-key = "$ETHERSCAN_GOERLI_API_KEY"

Assets

The assets section is used to configure the unlisted assets that the relayer will be able to work with.

Unlisted assets are assets that are not listed in any exchange, and the relayer cannot get the price of the asset from any exchange. So, the price of the asset must be configured manually. These are mainly used for testing purposes and for assets that are not listed in any exchange.

Type: table
Required: false
Default: {}
env: WEBB_ASSETS_<ASSET_NAME>_NAME, WEBB_ASSETS_<ASSET_NAME>_PRICE, WEBB_ASSETS_<ASSET_NAME>_DECIMALS

Example:

[assets]
tTNT = { name = "Test Tangle Network Token", price = 0.10, decimals = 18 }

name

The name of the asset.

Type: string
Required: true
env: WEBB_ASSETS_<ASSET_NAME>_NAME

Example:

name = "Test Tangle Network Token"

price

The price of the asset in USD.

Type: number
Required: true
env: WEBB_ASSETS_<ASSET_NAME>_PRICE

Example:

price = 0.10

decimals

The number of decimals of the asset.

Type: number
Required: true
env: WEBB_ASSETS_<ASSET_NAME>_DECIMALS

Example:

decimals = 18

EVM Chain Configuration

The EVM chain configuration file is used to configure the relayer to work with a specific EVM chain. It is usually located at a file called evm/<chain-name>.toml in the config directory.

The value of this configuration is a table, and the name of the table is the name of the chain, for example:

[evm.ethereum]
chain-id = 1
name = "ethereum"
# ...

So, in general it is [evm.<chain-name>], where <chain-name> is the name of the chain. The following sections describe the different configuration entries and how to use them.

name

The name of the chain. This name will be used to identify the chain in the relayer.

Type: string
Required: true
env: WEBB_EVM_<CHAIN_NAME>_NAME

Example:

name = "ethereum"

chain-id

The chain id of the chain. This id will be used to identify the chain in the relayer.

Type: number
Required: true
env: WEBB_EVM_<CHAIN_NAME>_CHAIN_ID

Example:

chain-id = 1

http-endpoint

The HTTP(s) RPC endpoint for this chain, used for watching events, and sending transactions. Input can be single http-endpoint or array of multiple http-endpoints.

Type: string | string[]
Required: true
env: WEBB_EVM_<CHAIN_NAME>_HTTP_ENDPOINT

Example:

Single Endpoint

http-endpoint = "https://mainnet.infura.io/v3/<project-id>"

Multiple Endpoints

http-endpoint = ["https://mainnet.infura.io/v3/<project-id>","https://rpc.testnet.network"]

ws-endpoint

The WebSocket RPC endpoint for this chain, used for watching events, and sending transactions.

Type: string
Required: true
env: WEBB_EVM_<CHAIN_NAME>_WS_ENDPOINT

Example:

ws-endpoint = "wss://mainnet.infura.io/ws/v3/<project-id>"

private-key

The private key configuration specifies the private key of the account on the EVM chain used for signing transactions. The format of the private key depends on its value:

If the private key starts with 0x, it is considered a raw (64 bytes) hex-encoded private key. Example: 0x8917174396171783496173419137618235192359106130478137647163400318.

If the private key starts with $, it is considered an environment variable containing a hex-encoded private key. Example: $MAINNET_PRIVATE_KEY.

If the private key starts with '> ', it is considered a command that the relayer will execute to obtain the hex-encoded private key. Example: > ./getKey.sh mainnet-privatekey.

If the private key doesn't contain special characters and has 12 or 24 words, it is considered a mnemonic string. The words should be separated by spaces, and the string should not be enclosed in quotes or any other characters.

Type: string
Required:
- true if features.governance-relay is true
- true if features.private-tx-relay is true
- false otherwise
env: WEBB_EVM_<CHAIN_NAME>_PRIVATE_KEY

Example:

private-key = "0x8917174396171783496173419137618235192359106130478137647163400318"

Warning The private key should be kept secret, and should not be hard-coded in the configuration file. Instead, it should be loaded from an environment variable, or a file.

block-confirmations

The number of block confirmations to wait before processing an event.

Type: number
Required: false
Default: 0
env: WEBB_EVM_<CHAIN_NAME>_BLOCK_CONFIRMATIONS

Example:

block-confirmations = 5

enabled

Enable or disable this chain. If this is set to false, then the relayer will not consider this chain while loading the configuration files.

Type: bool
Required: false
Default: true
env: WEBB_EVM_<CHAIN_NAME>_ENABLED

Example:

enabled = true

explorer

The block explorer URL for this chain. This is used to generate links to the transactions, useful for debugging.

Type: string
Required: false
Default: null
env: WEBB_EVM_<CHAIN_NAME>_EXPLORER

Example:

explorer = "https://etherscan.io"

beneficiary

The address of the beneficiary account on this chain. This is used to receive the fees from relaying transactions. It is optional, and if not provided, the relayer will use the account address of the provided private-key for this chain.

Type: string
Required: false
Default: null
env: WEBB_EVM_<CHAIN_NAME>_BENEFICIARY

Example:

beneficiary = "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"

Tx Queue

The tx queue is used to store the transactions that are waiting to be sent to the chain. The relayer uses a database to store the transactions, and the configuration for the database is stored in the tx-queue section of the configuration file.

max-sleep-interval

The maximum time to sleep between sending transactions. This controls the rate at which the relayer sends transactions to the chain.

Type: number
Required: false
Default: 10000ms
env: WEBB_EVM_<CHAIN_NAME>_TX_QUEUE_MAX_SLEEP_INTERVAL

polling-interval

Polling interval for checking pending transaction state. This configuration controls the rate at which RPC client queries on chain for transaction status.

Type: number
Required: false
Default: 12000ms
env: WEBB_EVM_<CHAIN_NAME>_TX_QUEUE_POLLING_INTERVAL

Example:

tx-queue = { max-sleep-interval = 5000, polling-interval = 12000 }

Relayer fee Config

This configuration is used to configure profit percentage margin for relayer and set maximum amount relayer can refund to user while withdrawing.

relayer-profit-percent

The percentage of profit relayer will get from the transaction fee.

Type: number
Required: false
Default: 5

max-refund-amount

The maximum amount of native token that relayer will refund to the user in USD.

Type: number
Required: false
Default: 5

Example:

relayer-fee-config = { relayer-profit-percent= 5, max-refund-amount = 5 }

Contracts

The contracts section is used to configure the contracts that the relayer will use to interact with the chain. The contracts are identified by their address and type, and the configuration for each contract is stored in a list, each has a different type and address.

Here is an example of the configuration for the contracts:

[[evm.ethereum.contracts]]
contract = "VAnchor"
address = "0x8eB24319393716668D768dCEC29356ae9CfFe285"
deployed-at = 3123412
# ...

[[evm.ethereum.contracts]]
contract = "SignatureBridge"
address = "0xd8dA6BF26964aF9D7eEd9e03E03517D3faA9d045"
deployed-at = 3123413
# ...

contract

The type of the contract. This is used to identify the contract, and the relayer will use this to determine which contract to use for a specific operation. Each contract type has its own configuration, and different internal service that will handle the contract operations.

Type: enum
Possible values:
- VAnchor
- SignatureBridge
Required: true
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_CONTRACT

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"

address

The address of the contract on the configured chain.

Type: string
Required: true
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_ADDRESS

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
address = "0x8eB24319393716668D768dCEC29356ae9CfFe285"

deployed-at

The block number at which the contract was deployed. This is used to determine the starting block number for scanning events.

Type: number
Required: true
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_DEPLOYED_AT

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
deployed-at = 3123412

Events Watcher

The events watcher is used to watch for events emitted by the contracts. The relayer uses this configuration values to determine how the relayer will poll the events from that contract.

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { enabled = true, poll-interval = 12000 }

enabled

Enable or disable the events watcher for this contract.

Type: bool
Required: false
Default: true
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_EVENTS_WATCHER_ENABLED

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { enabled = true }

enable-data-query

Enable or disable the data query for this contract. When enabled, it allows the relayer to query the contract's events, such as the leaves.

Type: bool
Required: false
Default: true
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_EVENTS_WATCHER_ENABLE_DATA_QUERY

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { enable-data-query = true }

poll-interval

The interval at which the relayer will poll for events from the contract.

Type: number
Required: false
Default: 7000ms
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_EVENTS_WATCHER_POLL_INTERVAL

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { poll-interval = 12000 }

max-blocks-per-step

The maximum number of blocks to scan for events in a single step. This controls the rate at which the relayer scans for events from the contract, and also affects the speed at which the relayer synchronizes with the chain.

Type: number
Required: false
Default: 100
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_MAX_BLOCKS_PER_STEP

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { max-blocks-per-step = 500 }

sync-blocks-from

The block number to start scanning for events from. This value can override the deployed-block configuration value but is only used during the initial synchronization of the chain. If not specified, the relayer uses the deployed-block configuration value as the default starting block number.

Type: number
Required: false
Default: null (will use the value of the deployed-at configuration value)
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_SYNC_BLOCKS_FROM

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { sync-blocks-from = 3123412 }

print-progress-interval

The interval at which the relayer will print the progress of the syncing process. This is used to show the user the progress of the syncing process which could be useful for debugging purposes.

Type: number
Required: false
Default: 30000ms
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_PRINT_PROGRESS_INTERVAL

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
events-watcher = { print-progress-interval = 60000 }

Proposal Signing Backend

A Proposal Signing backend is used for signing proposals that the relayer will submit to be signed and later executed on the target chain. Currently, there are two types of proposal signing backends, the Mocked one, and the DKG based one.

type

The type of the proposal signing backend to use.

Type: string
Required: true
Possible values:
- Mocked
- Dkg
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_PROPOSAL_SIGNING_BACKEND_TYPE

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
proposal-signing-backend = { type = "Mocked", private-key = "0x..." }

Let's take a look at each one of them.

Mocked Proposal Signing Backend

The mocked proposal signing backend is used for testing purposes, and it is mostly used for our local and integration tests. This backend will sign the proposals with a mocked keypair; hence should not be used in production environment.

Available configuration values:

[[evm.ethereum.contracts]]
contract = "VAnchor"
proposal-signing-backend = { type = "Mocked", private-key = "0x..." }

private-key

The private key to use for signing the proposals. Only used by the mocked proposal signing backend.

Type: string
Required:
- true if the type is Mocked
- false otherwise
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_PROPOSAL_SIGNING_BACKEND_PRIVATE_KEY

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
proposal-signing-backend = { type = "Mocked", private-key = "0x..." }

Dkg Proposal Signing Backend

The DKG proposal signing backend is used for signing the proposals using the DKG configured node.

Available configuration values:

[[evm.ethereum.contracts]]
contract = "VAnchor"
proposal-signing-backend = { type = "Dkg", chain-id = 1080 }

chain-id

The node's chain-id to use for signing the proposals. Only used by the DKG proposal signing backend.

Type: string
Required:
- true if the type is Dkg
- false otherwise
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_PROPOSAL_SIGNING_BACKEND_CHAIN_ID

Example:

[[evm.ethereum.contracts]]
contract = "VAnchor"
proposal-signing-backend = { type = "Dkg", chain-id = 1080 }

Linked Anchors

The Linked Anchors configuration is used to define the linked anchors for the VAnchor contract. This configuration is only available when the type is set to VAnchor.

The configuration value is a list of Linked Anchors, defined in a human-readable format. However, the relayer will convert them to a raw format before using them.

Required: false
Default: null (defaults to an empty list)
Available configuration values:

[[evm.ethereum.contracts]]
contract = "VAnchor"
linked-anchors = [
  { type = "Evm", chain-id = 1, address = "0x..." },
  { type = "Raw", resource-id = "0x..." },
]

type

The type of the linked anchor definition.

Type: string
Required: true
Possible values:
- Evm
- Raw
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_LINKED_ANCHORS_<INDEX>_TYPE

chain-id

The chain-id of the linked anchor definition. Only used by the Evm types.

Type: number
Required:
- true if the type is Evm
- false otherwise
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_LINKED_ANCHORS_<INDEX>_CHAIN_ID

Example:

[[evm.ethereum.contracts]]
type = "VAnchor"
linked-anchors = [
  { type = "Evm", chain-id = 1, address = "0x..." },
  ]

address

The address of the linked anchor definition. Only used by the Evm type.

Type: string
Required:
- true if the type is Evm
- false otherwise
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_LINKED_ANCHORS_<INDEX>_ADDRESS

Example:

[[evm.ethereum.contracts]]
type = "VAnchor"
linked-anchors = [
  { type = "Evm", chain-id = 1, address = "0x..." },
]

resource-id

The resource-id of the linked anchor definition. Only used by the Raw type.

Type: string
Required:
- true if the type is Raw
- false otherwise
env: WEBB_EVM_<CHAIN_NAME>_CONTRACTS_<INDEX>_LINKED_ANCHORS_<INDEX>_RESOURCE_ID

Example:

[[evm.ethereum.contracts]]
type = "VAnchor"
linked-anchors = [
  { type = "Raw", resource-id = "0x..." },
]

Substrate Node Configuration

The Substrate Node configuration file is used to specify the configuration settings required for the relayer to work with a specific Substrate Node. The file is typically located in the config directory and named substrate/<node-name>.toml.

The configuration value is a table, and its name corresponds to the name of the node. For example:

[substrate.tangle]
chain-id = 1080
name = "tangle"
# ...

In general, the configuration table for a node is identified as [substrate.<node-name>], where <node-name> is the name of the network. The following sections outline the different configuration entries and how to use them.

name

The name of the Substrate node.

Type: string
Required: true
env: WEBB_SUBSTRATE_<NODE_NAME>_NAME

Example:

[substrate.tangle]
name = "tangle"

chain-id

The chain-id of the Substrate node.

Type: number
Required: true
env: WEBB_SUBSTRATE_<NODE_NAME>_CHAIN_ID

Example:

[substrate.tangle]
chain-id = 1080

http-endpoint

The RPC endpoint of the Substrate node.

Type: string
Required: true
env: WEBB_SUBSTRATE_<NODE_NAME>_HTTP_ENDPOINT

Example:

[substrate.tangle]
http-endpoint = "http://localhost:9933"

ws-endpoint

The RPC WebSocket endpoint of the Substrate node.

Type: string
Required: true
env: WEBB_SUBSTRATE_<NODE_NAME>_WS_ENDPOINT

Example:

[substrate.tangle]
ws-endpoint = "ws://localhost:9944"

enabled

Whether the Substrate node is enabled or not. If it is not enabled, the relayer will not try to add it to the list of available nodes.

Type: bool
Required: false
Default: true
env: WEBB_SUBSTRATE_<NODE_NAME>_ENABLED

Example:

[substrate.tangle]
enabled = true

explorer

The explorer of the Substrate Network. This is used to display clickable links to the explorer in the logs.

Type: string
Required: false
Default: null
env: WEBB_SUBSTRATE_<NODE_NAME>_EXPLORER

Example:

[substrate.tangle]
explorer = "https://tangle-explorer.webb.tools"

suri

SURI stands for "secret URI". It is a mnemonic phrase that can be used to generate a private key. This is used to sign extrinsics. We will refer to this as the "s" for now. The value is a string (s) that we will try to interpret the string in order to generate a key pair. In the case that the pair can be expressed as a direct derivation from a seed (some cases, such as Sr25519 derivations with path components cannot).

This takes a helper function to do the key generation from a phrase, password and junction iterator.

If s begins with a $ character it is interpreted as an environment variable.
If s is a possibly 0x prefixed 64-digit hex string, then it will be interpreted directly as a MiniSecretKey (aka "seed" in subkey).
If s is a valid BIP-39 key phrase of 12, 15, 18, 21 or 24 words, then the key will be derived from it. In this case:
- the phrase may be followed by one or more items delimited by / characters.
- the path may be followed by ///, in which case everything after the /// is treated as a password.
If s begins with a / character it is prefixed with the Substrate public DEV_PHRASE and interpreted as above.

In this case they are interpreted as HDKD junctions; purely numeric items are interpreted as integers, non-numeric items as strings. Junctions prefixed with / are interpreted as soft junctions, and with // as hard junctions.

There is no correspondence mapping between SURI strings and the keys they represent. Two different non-identical strings can actually lead to the same secret being derived. Notably, integer junction indices may be legally prefixed with arbitrary number of zeros. Similarly an empty password (ending the SURI with ///) is perfectly valid and will generally be equivalent to no password at all.

The value of this string could also start with $ to indicate that it is an environment variable, in which case the value of the environment variable will be used.

Warning: This is a sensitive value, and should be kept secret. It is recommended to use an environment variable to store the value of this string.

Type: string
Required: true
env: WEBB_SUBSTRATE_<NODE_NAME>_SURI

Example:

[substrate.tangle]
suri = "$TANGLE_SURI"

Tx Queue

The transaction queue is a queue of transactions that are waiting to be sent to the Substrate node.

max-sleep-interval

The maximum sleep interval between sending transactions to the Substrate node.

Type: number
Required: false
Default: 10000ms
env: WEBB_SUBSTRATE_<NODE_NAME>_TRANSACTION_QUEUE_MAX_SLEEP_INTERVAL

Example:

[substrate.tangle]
tx-queue = { max-sleep-interval = 10000 }

Pallets

The pallets are the different pallets that are used by the relayer. Each will define its own configuration which will eventually be used by the relayer to start a different service for each pallet.

There are currently 3 different pallets that are supported by the relayer:

DKG
DkgProposals
DkgProposalHandler
Type: table
Required: false
Default: null (empty table)

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"

[[substrate.tangle.pallets]]
pallet = "DkgProposals"
# ...

pallet

The type of the pallet. This is used to determine which pallet to use.

Type: string
Required: true
Possible values:
- DKG
- DkgProposals
- DkgProposalHandler

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"

events-watcher

The events watcher is used to watch for events emitted by the pallet.

Type: table
Required: false
Default: null (empty table)

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"
events-watcher = { enabled = true }

enabled

Whether the events watcher is enabled or not. If it is not enabled, the relayer will not try to watch events emitted by the pallet.

Type: bool
Required: false
Default: true
env: WEBB_SUBSTRATE_<NODE_NAME>_PALLET_<INDEX>_EVENTS_WATCHER_ENABLED

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"
events-watcher = { enabled = true }

polling-interval

The polling interval is the interval at which the relayer will poll the Substrate node for new blocks.

Type: number
Required: false
Default: 6000ms
env: WEBB_SUBSTRATE_<NODE_NAME>_PALLET_<INDEX>_EVENTS_WATCHER_POLLING_INTERVAL

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"
events-watcher = { enabled = true, polling-interval = 6000 }

max-blocks-per-step

The maximum number of blocks to process per step.

Type: number
Required: false
Default: 100
env: WEBB_SUBSTRATE_<NODE_NAME>_PALLET_<INDEX>_EVENTS_WATCHER_MAX_BLOCKS_PER_STEP

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"
events-watcher = { enabled = true, max-blocks-per-step = 100 }

sync-blocks-from

The block number from which to start syncing events from. This is useful if you want to start the relayer from a specific block instead of block zero.

Type: number
Required: false
Default: 0
env: WEBB_SUBSTRATE_<NODE_NAME>_PALLET_<INDEX>_EVENTS_WATCHER_SYNC_BLOCKS_FROM

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"
events-watcher = { enabled = true, sync-blocks-from = 42069 }

print-progress-interval

The interval at which the relayer will print the progress of the syncing process. Useful for debugging.

Type: number
Required: false
Default: 12000ms
env: WEBB_SUBSTRATE_<NODE_NAME>_PALLET_<INDEX>_EVENTS_WATCHER_PRINT_PROGRESS_INTERVAL

Example:

[[substrate.tangle.pallets]]
pallet = "DKG"
events-watcher = { enabled = true, print-progress-interval = 12000 }

Files

config

Directory actions

More options

Directory actions

More options

Latest commit

History

config

Folders and files

parent directory

README.md

Relayer Configration files

Index

Global Configuration

port

features

governance-relay

data-query

private-tx-relay

evm-etherscan

chain-id

api-key

Assets

name

price

decimals

EVM Chain Configuration

name

chain-id

http-endpoint

ws-endpoint

private-key

block-confirmations

enabled

explorer

beneficiary

Tx Queue

max-sleep-interval

polling-interval

Relayer fee Config

relayer-profit-percent

max-refund-amount

Contracts

contract

address

deployed-at

Events Watcher

enabled

enable-data-query

poll-interval

max-blocks-per-step

sync-blocks-from

print-progress-interval

Proposal Signing Backend

type

Mocked Proposal Signing Backend

private-key

Dkg Proposal Signing Backend

chain-id

Linked Anchors

type

chain-id

address

resource-id

Substrate Node Configuration

name

chain-id

http-endpoint

ws-endpoint

enabled

explorer

suri

Tx Queue

max-sleep-interval

Pallets

pallet

events-watcher

enabled

polling-interval