| `protected-shard` | `newSeq[ProtectedShard](0)` | Shards and its public keys to be used for message validation, shard:pubkey. Argument may be repeated |
| `relay-service-ratio` | `"60:40"` | This percentage ratio represents the relay peers to service peers. For example, 60:40, tells that 60% of the max-connections will be used for relay protocol and the other 40% of max-connections will be reserved for other service protocols (e.g., filter, lightpush, store, metadata, etc.) |
| `rln-relay-cred-path` | | The path for persisting rln-relay credential |
| `rln-relay-membership-index` | | The index of the onchain commitment to use |
| `rln-relay-dynamic` | `false` | Enable waku-rln-relay with on-chain dynamic group management: true\|false |
| `rln-relay-id-key` | | Rln relay identity secret key as a Hex string |
| `rln-relay-id-commitment-key` | | Rln relay identity commitment key as a Hex string |
| `rln-relay-eth-client-address` | `ws://localhost:8540/` | WebSocket address of an Ethereum testnet client e.g., `ws://localhost:8540/` |
| `rln-relay-eth-contract-address` | | Address of membership contract on an Ethereum testnet |
| `rln-relay-eth-private-key` | | Private key for broadcasting transactions |
| `execute` | `false` | Runs the registration function on-chain. By default, a dry-run will occur |
| `rln-relay-cred-password` | | Password for encrypting RLN credentials |
| `rln-relay-bandwidth-threshold` | `0 # to maintain backwards compatibility` | Message rate in bytes/sec after which verification of proofs should happen |
| `staticnode` | | Peer multiaddr to directly connect with. Argument may be repeated |
| `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated. **Deprecated!** Please use `shard` and/or `content-topic` instead |
| `shard` | | Shard to subscribe to. Argument may be repeated |
| `num-shards-in-network` | | Number of shards in the network. Used to map content topics to shards when using autosharding |
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
| `filternode` | | Peer multiaddr to request content filtering of messages |
| `filter-subscription-timeout` | `300 # 5 minutes` | Timeout for filter subscription without ping or refresh it, in seconds. Only for v2 filter protocol |
| `filter-max-peers-to-serve` | `1000` | Maximum number of peers to serve at a time. Only for v2 filter protocol |
| `filter-max-criteria` | `1000` | Maximum number of pubsub and content topic combinations per peer at a time. Only for v2 filter protocol |
| `rest-allow-origin` | | Allow cross-origin requests from the specified origin. When using the REST API in a browser, specify the origin host to get a valid response from the node REST HTTP server. This option may be repeated and can contain wildcards (?,\*) for defining URLs and ports such as `localhost:*`, `127.0.0.1:8080`, or allow any website with `*` |
| `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.<br/>Formatted as:`<protocol>:volume/period<time-unit>`<br/>- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`<br/>-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`<br/>-volume must be an integer value, representing number of requests over the period of time allowed.<br/>-period\<time-unit\> must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`<br/>- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.<br/>- In case of multiple set of the same protocol limit, last one will take place.<br/>- if config is not set, - which is the default - means unlimited requests are allowed.<br/>-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.<br/><br/>Examples:<br/>`--rate-limit="100/1s"` - default for all protocols if not set otherwise.<br/>`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.<br/>`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br/>`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.<br/>`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. |
