> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://docs.ampdb.io/api/mcp` to find what you need. # Providers A provider is a named connection to a source of chain data, like an Ethereum node's RPC endpoint. Amp has no chain connections built in: before it can extract a chain's data, you register a provider for it. Providers keep connection details out of [datasets](/get-started/concepts/datasets). A raw dataset only says which kind of data it extracts and from which network, like `evm-rpc` from `mainnet`, and Amp finds a provider that matches. So several datasets can share a provider, you can switch endpoints without changing a dataset, and credentials never appear in a dataset's definition. ## What a provider contains You write a provider as a TOML file. Every provider has a `kind`, and most have a `network`; the other fields depend on the kind: ```toml [mainnet.toml] kind = "evm-rpc" network = "mainnet" url = "${RPC_URL}" rate_limit_per_minute = 600 ``` * `kind`: the kind of source, which decides how Amp talks to it and which tables it can fill. `evm-rpc` is the JSON-RPC API of Ethereum and other EVM chains. * `network`: the chain, in lowercase letters, digits, and hyphens, like `mainnet`, `base`, or `solana-mainnet`. Use the names of [The Graph's networks registry](https://github.com/graphprotocol/networks-registry), which Amp follows. * The kind's own fields, like `url`, where to reach the endpoint, and `rate_limit_per_minute`, how many requests Amp may send it per minute. Each kind's page documents its fields. ## Kinds | Kind | Source | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | [`evm-rpc`](/providers/evm-rpc) | The JSON-RPC API of Ethereum and other EVM chains | | [`solana`](/providers/solana) (Experimental) | Solana's RPC API, and Old Faithful, its archive of past blocks | | [`tempo`](/providers/tempo) | Tempo's JSON-RPC API | | [`bittensor`](/providers/bittensor) (Experimental) | The JSON-RPC API of Subtensor, Bittensor's node | | [`bitcoin-rpc`](/providers/bitcoin-rpc) | Bitcoin's JSON-RPC API | | [`eth-beacon`](/providers/eth-beacon) | The REST API of Ethereum's beacon chain, its consensus layer | | [`stellar`](/providers/stellar) | Stellar's RPC API | | [`phaser`](/providers/phaser) (In development) | A Phaser bridge, which serves chain data over Arrow Flight | | [`static`](/providers/static) (In development) | A directory or bucket of CSV files, for [static datasets](/datasets/static-datasets) | | [`adbc-postgres`, `adbc-snowflake`](/managing-amp/pipelines/destinations) (Unstable) | A PostgreSQL or Snowflake database that Amp exports datasets to, rather than extracts from | ## How Amp picks a provider When a worker extracts a raw dataset, it looks for every registered provider with the dataset's kind and network. If there are several, it spreads its requests across them, favoring the ones that answer fastest, and sends less to one that fails. So registering two providers for the same network gives you more capacity, and keeps extraction going when one endpoint has trouble. To use a single provider for a deployment, name it when you deploy: ```bash ampctl dataset deploy acme/eth_mainnet@1.0.0 --provider mainnet_rpc ``` The deployment then fails if that provider can't be used, rather than switching to another one. ## Secrets A provider can refer to environment variables as `${NAME}`, like `url = "${RPC_URL}"`. Amp stores the reference, not the variable's value, and replaces it with the value from `ampd`'s environment only when it uses the provider. So API keys and tokens stay out of what Amp stores, and you can rotate them by restarting `ampd` with new values. If a variable isn't set, Amp can't use the provider: it logs `Variable not found: RPC_URL`, and extraction fails with `No provider found for kind 'evm-rpc' and network 'mainnet'` when no other provider matches. In distributed mode, set the variables wherever Amp uses providers: on the workers, which extract data, and on the query servers, for functions that call a chain's RPC API, like [`eth_call`](/querying/functions/eth-call). ## Registering providers You register a provider with `ampctl`, under a name, which must start with a lowercase letter or `_` and contain only lowercase letters, digits, and `_`: ```bash ampctl provider register mainnet_rpc ./mainnet.toml ``` `ampctl` reads the file and sends its fields to the controller, which stores the provider as a TOML file named after it, with its `${NAME}` references as written: see [Provider files](/get-started/concepts/providers#provider-files). So `ampctl provider inspect mainnet_rpc` shows `"url": "${RPC_URL}"`. Registering it again under the same name replaces it. Jobs that start afterwards use the new settings, and so does a failed job's next try; a running job keeps the settings it started with. The file you register can also be a URL, in object storage (`s3://`, `gs://`, `az://`) or on disk (`file://`). [Managing Providers](/managing-amp/providers) covers listing, inspecting, and removing providers, and [Providers](/providers) documents each kind. ## Provider files Amp keeps providers as TOML files in the providers location of its [storage](/running-amp/storage). A file named `mainnet_rpc.toml` there is a provider named `mainnet_rpc`, with its `${NAME}` references as written. * Registering a provider writes its file, replacing any file with its name, and removing a provider deletes its file. * When you run Amp yourself, you can also add providers by putting their files there, without registering them.