Summary
The Chainlink faucet is the official way to get testnet LINK and native test tokens (such as Sepolia ETH) so you can deploy and test smart contracts that use Chainlink services like Data Feeds, VRF, Automation, and CCIP. It is a web app at faucets.chain.link where you connect a wallet, pick a supported testnet, and request tokens.
If you searched for "chain link faucet", you probably need testnet LINK to pay oracle fees or test a Chainlink integration, and you may be stuck on a network that is not listed, a request that failed, or a wallet that will not connect. This page explains what the faucet gives you, how to use it, and what to check when a request does not arrive.
Faucets only solve the token side. Your contracts still need a reliable RPC endpoint to read state, send transactions, and confirm that test tokens actually landed. OnFinality provides RPC API access and dedicated node infrastructure for supported networks, so you can pair testnet tokens with an endpoint you control. Check supported RPC networks to see which testnets are available.
Key Takeaways
- The Chainlink faucet at faucets.chain.link dispenses testnet LINK plus native test tokens for supported testnets such as Ethereum Sepolia and Base Sepolia.
- Faucet tokens are for testing only; they have no mainnet value and cannot be bridged to mainnet.
- You need a compatible wallet (for example MetaMask, WalletConnect, or Coinbase Wallet) and a small amount of native gas token before a request can succeed.
- If tokens do not appear, check the transaction on a block explorer and confirm your RPC endpoint is synced to the correct testnet before requesting again.
- Faucets solve token supply, not connectivity. Pair testnet tokens with a stable RPC endpoint for reads, writes, and log queries.
- OnFinality offers RPC API access and dedicated node infrastructure for supported networks; review RPC pricing and supported RPC networks before you scale a test workflow.
What the Chainlink faucet actually gives you
The Chainlink faucet is a testnet token dispenser. It sends two kinds of assets: LINK tokens on a testnet, and the native gas token for that same testnet (for example ETH on Ethereum Sepolia or Base Sepolia). You use the native token to pay gas and the testnet LINK to pay for Chainlink service usage in your test contracts.
These tokens exist only on testnets. They are not mainnet LINK, they have no market value, and they cannot be moved to mainnet. Treat them as disposable test credit: request only what you need, and expect per-wallet or per-network limits.
- Testnet LINK for paying oracle and service fees in test environments.
- Native test tokens such as Sepolia ETH for gas.
- Support for multiple testnets, with the exact list changing over time on the official faucet page.
- Wallet-based requests, so the receiving address is the wallet you connect.
Quick recommendation: when the faucet is enough, and when it is not
Use the official Chainlink faucet when you are learning Chainlink services, running a demo, or testing a contract on a supported testnet. It is the fastest path to testnet LINK and native gas tokens.
The faucet is not a substitute for RPC infrastructure. If your requests fail, transactions hang, or your app cannot read contract state, the problem is usually connectivity or configuration, not token supply. In that case, fix the endpoint first, then request tokens.
| Criterion | What to check | Why it matters |
|---|---|---|
| You only need testnet LINK or gas tokens | Your target testnet is listed on the official Chainlink faucet page | Unsupported networks will not dispense tokens, so confirm the list before troubleshooting your wallet |
| Your wallet connects but transactions fail | The wallet's RPC endpoint points to the same testnet as the faucet request | A mismatched endpoint makes balances and confirmations look wrong even when the faucet succeeded |
| You need repeatable test runs or CI | Whether a shared public endpoint is stable enough for your test volume | Automated tests can exhaust shared endpoints; a managed or dedicated endpoint is more predictable |
| You are preparing for production | Mainnet endpoint capacity, failover, and archive needs | Faucet workflows end at testnet; production requires a separate infrastructure decision |
Requesting testnet LINK step by step
The flow is short, but each step depends on the previous one. Connect a wallet that supports the target testnet, select the network, and submit the request. Then confirm the transfer on a block explorer before you assume something is broken.
- Open the official Chainlink faucet page and choose the testnet you are building on.
- Connect a compatible wallet such as MetaMask, WalletConnect, or Coinbase Wallet.
- Make sure the wallet is switched to the same testnet you selected.
- Submit the request and wait for the confirmation.
- Open the transaction in the network's block explorer and verify the recipient address and amount.
Chain settings to verify before you blame the faucet
Most "faucet not working" reports are actually network configuration problems. If your wallet is on the wrong chain, the tokens may have arrived but will not display. Verify the chain ID, currency symbol, and explorer URL against the network you requested.
For example, Ethereum Sepolia and Base Sepolia are different networks with different chain IDs. A wallet pointed at one will not show balances from the other. The same applies to BNB Chain Testnet versus BNB Smart Chain mainnet.
| Criterion | What to check | Why it matters |
|---|---|---|
| Network name | The wallet network label matches the faucet selection | Wrong network labels hide correct balances |
| Chain ID | The chain ID matches the official value for that testnet | A wrong chain ID sends requests to a different chain or fails outright |
| RPC URL | The endpoint is reachable and points to the intended testnet | An unreachable endpoint makes balances and receipts appear missing |
| Block explorer | The explorer URL matches the network | You need the right explorer to confirm whether the faucet transaction landed |
| Native currency symbol | The symbol matches the testnet gas token | Mismatched symbols confuse gas estimation and balance display |
Confirming a faucet transfer with JSON-RPC
Once you have an endpoint for the testnet, you can confirm a faucet transfer directly instead of relying on wallet display. Query the balance of the receiving address, then fetch the transaction receipt if you have the hash.
The example below uses a placeholder endpoint variable. Replace it with the RPC URL for your testnet from the supported RPC networks page, or use the public endpoint shown on the matching network page.
- Use eth_getBalance to confirm the native test token arrived.
- Use eth_getTransactionReceipt to confirm the faucet transaction was mined.
- Use the LINK token contract's balanceOf method to confirm testnet LINK arrived.
When tokens do not arrive: a short debug path
Work from the outside in. First confirm the request was accepted, then confirm the transaction was mined, then confirm your wallet is reading the right chain. Only after those checks should you request again, because repeated requests can hit rate limits.
| Criterion | What to check | Why it matters |
|---|---|---|
| Symptom | Likely cause | Next step |
| Wallet will not connect | Browser wallet unlocked and site permissions granted | Reconnect or try a different supported wallet |
| Request rejected immediately | Per-wallet or per-network limits, or unsupported testnet | Wait for the limit window or switch to a supported testnet |
| Transaction pending for a long time | Testnet congestion and gas settings | Check the explorer, then retry only after the pending state clears |
| Explorer shows success but wallet balance is zero | Wallet network and RPC endpoint | Switch the wallet to the correct testnet or update the endpoint |
| Contract call fails after funding | Gas limits, LINK allowance, and contract address | Funding is not the only prerequisite for a successful Chainlink call |
From faucet to a stable test environment
Faucets are a starting point. Once your test suite grows, the limiting factor is usually the endpoint: shared public RPC URLs can be slow or rate-limited during peak test activity, which makes faucet-funded tests look flaky.
OnFinality provides RPC API access and dedicated node infrastructure for supported networks, including testnets where available. You can review RPC pricing for plan details and supported RPC networks for the current list. If you are choosing between shared and dedicated capacity, the RPC provider selection guide covers the tradeoffs.
- Use a managed RPC endpoint for repeatable test runs and CI jobs.
- Keep testnet and mainnet endpoints separate in configuration.
- Monitor balance and nonce behavior rather than assuming faucet failures.
- Move to dedicated nodes when shared capacity becomes the bottleneck.
Frequently Asked Questions
Is the Chainlink faucet free?
Yes. The official Chainlink faucet dispenses testnet tokens at no cost, subject to per-wallet and per-network limits. The tokens have no mainnet value.
Can I get mainnet LINK from a faucet?
No. Faucets only issue testnet tokens. Mainnet LINK must be acquired through exchanges or other legitimate channels.
Why did my faucet request succeed but my wallet still shows zero?
The most common cause is a wallet pointed at the wrong network or an RPC endpoint that is not synced to the correct testnet. Confirm the chain ID and endpoint, then check the transaction on the matching block explorer.
Does the Chainlink faucet support every testnet?
No. The supported list changes over time and is shown on the official faucet page. If your target network is not listed, you will need another source of test tokens for that chain.
Do I need an RPC provider to use faucet tokens?
You need an RPC endpoint to read balances, send transactions, and confirm receipts. A wallet's default endpoint may work for simple tests, but managed or dedicated endpoints are more predictable for repeated test runs.