Change what your pipeline watches.Skip the redeploy.

Key-Value Store is Quicknode's account-level store for the small pieces of state a data pipeline depends on, organized as lists and values. Streams filters, Webhooks, and external applications all read and write the same data, through qnLib functions inside filters and a REST API everywhere else. A list such as watched_wallets drives membership checks. A value such as lastProcessedBlock holds one data point a pipeline updates over time.

Store the list in Key-Value Store instead of hardcoding it in filter code. The filter checks membership with qnLib.qnContainsListItems, and an update through the REST API, or with qnLib.qnUpsertList, changes what that check sees. The running filter reads the current version of the list, so the pipeline keeps processing while the watchlist changes.

Yes. A list in Key-Value Store is account-scoped, so the same watched_wallets list a Streams filter checks with qnLib.qnContainsListItems is available to every Webhook on the account. There is no per-product copy to create or keep in sync. Update the list once through the REST API, and both surfaces read the current version.

A list is a named collection of string items stored under one key, built for membership checks, like matching senders against watched_wallets with qnLib.qnContainsListItems. A value stores one data point under one key, tracked over time, like lastProcessedBlock. Lists answer whether an item belongs to a collection. Values answer what one tracked data point currently holds.

qnLib.qnContainsListItems usage inside your Streams filter, and using your list in Webhooks are included at no cost, on every Quicknode plan. That applies to those lookups, not to writes or storage, so a Streams filter can check a large list as often as it runs. For current terms on everything else, check the Quicknode pricing page.

Key-Value Store is available on every Quicknode plan with nothing separate to buy or provision. qnLib.qnContainsListItems usage inside your Streams filter, and using your list in Webhooks are included at no cost. For current terms on writes and storage, check the Quicknode pricing page.

The REST API and the qnLib functions are two ways into the same underlying data. A Streams filter calls functions like qnLib.qnGetValue natively while it runs. A backend, script, or agent calls the REST API with the same Quicknode API key. Update a list through either surface, and anything reading it, filter or application, reads the current version.

Yes. Key-Value Store data is account-scoped: it lives at the Quicknode account level, not inside one project or endpoint. Every Streams filter and every Webhook on the account reads the same lists and values, and the REST API reaches the same data with the account's API key. Create watched_wallets once, and each pipeline checks one current copy instead of maintaining its own.

Key-Value Store can hold millions of items, so a large watchlist fits in one list like watched_wallets. No need to shard it across systems. Membership checks with qnLib.qnContainsListItems read that same list from inside Streams filters. For current specifics on storage and item counts, check the Key-Value Store docs before sizing a workload.

Yes, items in Key-Value Store are case-sensitive, so 0xAbC1 and 0xabc1 are two different entries. This matters most with blockchain addresses. Store an address in the same case a Streams filter uses when it calls qnLib.qnContainsListItems, or a checksummed entry will not match its lowercase twin. Consistent casing at write time keeps membership checks accurate.

Yes. Two sample apps in the Quicknode Sample App Library are built on the dynamic-watchlist pattern this page describes. Wallet Tracking monitors wallet addresses on Solana and Ethereum, with the watchlist held in Key-Value Store and updated through a simple UI. HyperCore Order Monitor tracks trading orders on Hyperliquid Core, with watched addresses and order statuses in Key-Value Store lists. Both ship with source code you can clone.