Summary
A Base faucet dispenses small amounts of testnet ETH on Base Sepolia, the OP Stack testnet that mirrors Base mainnet closely enough to rehearse deployments. You need it because every transaction on Base Sepolia — deploying a contract, minting a test token, calling a payable function — costs gas, and gas is paid in Sepolia ETH, which has no real value and cannot be bought on exchanges.
The catch is that "base faucet" is not one product. Coinbase runs a faucet through its Developer Platform, Chainlink lists Base Sepolia among its faucet networks, and several RPC providers operate their own faucets. Each has different claim limits, token coverage, and gating. Picking the wrong one, or hitting a rate limit mid-deploy, is the usual reason developers end up stuck.
This page walks through where to claim Base Sepolia ETH, how to confirm the funds actually arrived using a Base Sepolia RPC endpoint, and how to keep a testnet workflow running when a faucet is dry or rate-limited. It also covers when a dedicated RPC endpoint — such as OnFinality's Base Sepolia service — makes sense alongside a faucet, and how to debug the most common post-claim failures.
Key Takeaways
- A Base faucet issues testnet ETH on Base Sepolia (chain ID 84532), not on Base mainnet; mainnet ETH must be bridged or withdrawn from an exchange.
- Faucet limits differ by provider — some are UI-only, some expose an API, and most rate-limit per address or per account per 24 hours.
- Always verify a claim with an RPC call (eth_getBalance) before assuming the faucet failed; propagation and indexing delays are common.
- Keep a Base Sepolia RPC endpoint configured separately from Base mainnet so you never accidentally deploy to production.
- For repeatable CI or team workflows, a dedicated RPC endpoint plus a scripted faucet claim is more reliable than manual browser claims.
- If a faucet is dry, alternatives include other faucet providers, bridging Sepolia ETH from Ethereum Sepolia, or requesting from a team member's balance.
Which Base faucet should you use?
Base Sepolia is the testnet most developers mean when they search for a Base faucet. It uses Sepolia ETH as its gas token and shares the OP Stack architecture with Base mainnet, so contracts and tooling behave the same way. The faucet landscape splits into three practical categories: exchange-operated faucets, oracle/partner faucets, and RPC-provider faucets.
Exchange-operated faucets (Coinbase Developer Platform is the canonical one) tend to offer the widest token coverage — ETH plus test USDC, EURC, and cbBTC — and often expose a programmatic API. Partner faucets such as Chainlink's list Base Sepolia alongside many other networks and are useful when you also need LINK for oracle testing. RPC-provider faucets are convenient if you already use that provider's endpoint, but they usually gate claims behind an account or API key.
The decision is less about which faucet is "best" and more about which one matches your workflow: a one-off manual claim, a scripted CI job, or a team that needs repeatable funding.
| Criterion | What to check | Why it matters |
|---|---|---|
| Faucet type | Whether the faucet is UI-only or exposes an API; which tokens it drips; per-address and per-account limits | A UI-only faucet blocks CI automation; a faucet that only drips ETH leaves you without test USDC for payment flows |
| Coinbase Developer Platform faucet | Claim limits per 24 hours, token list (ETH, USDC, EURC, cbBTC), API/SDK availability | Best fit if you need multiple asset types and want to script claims; requires a CDP account |
| Chainlink faucet | Whether Base Sepolia is listed, LINK availability, wallet connection options | Useful when your test also needs LINK for oracle or CCIP integration |
| RPC-provider faucets | Account or API key requirement, drip size, cooldown | Convenient if you already use that provider, but ties your testnet funding to a single vendor |
| Community and aggregator faucets | Uptime, whether the faucet is currently empty, captcha or social gating | Fallback when primary faucets are rate-limited, but less predictable for repeatable workflows |
Claim steps and what to confirm before you deploy
The mechanics are similar across faucets: connect or paste a wallet address, select Base Sepolia, and submit the claim. The differences that matter are the network selection (make sure you are on Base Sepolia, not Base mainnet or Ethereum Sepolia) and the confirmation step. A faucet UI showing "success" does not guarantee the transaction is mined or that your balance reflects it.
Before you deploy anything, confirm three things: the address you claimed to is the address your deployer uses, the network in your wallet or config is Base Sepolia (chain ID 84532), and the balance is visible over RPC. That last check is the one most developers skip, and it is the source of most "the faucet didn't work" reports.
- Use a dedicated test wallet, not a wallet that holds mainnet assets.
- Add Base Sepolia to your wallet with chain ID 84532 and the Base Sepolia explorer (sepolia.basescan.org) so you can inspect the claim transaction.
- If the faucet offers an API, capture the request and response so you can replay it in CI later.
- Wait for at least one confirmation before running a deploy script; some faucets batch drips.
Verify the claim over Base Sepolia RPC
The fastest way to confirm a faucet claim is a single JSON-RPC call. Point it at a Base Sepolia endpoint — OnFinality publishes a public Base Sepolia endpoint at https://base-sepolia.api.onfinality.io/public — and query the balance of the address you claimed to.
If the balance is zero, check the claim transaction on sepolia.basescan.org before retrying. If the transaction is pending or failed, the faucet, not your RPC, is the problem. If the transaction succeeded but your balance is still zero, you may be querying the wrong network or a stale endpoint.
curl -X POST https://base-sepolia.api.onfinality.io/public -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0xYourAddress","latest"]}'- Confirm the returned hex value is non-zero and convert it from wei to ETH.
- Cross-check the same address on sepolia.basescan.org to rule out endpoint lag.
When a faucet is dry or rate-limited
Faucets run out. When that happens, the useful move is not to refresh the page but to change the funding path. There are four reliable alternatives, roughly in order of effort.
First, try a different faucet category — if the exchange faucet is rate-limited, an oracle or RPC-provider faucet may still have funds. Second, bridge Sepolia ETH from Ethereum Sepolia if you already hold some there; Base Sepolia accepts bridged Sepolia ETH. Third, ask a teammate to send a small amount from their testnet balance. Fourth, for teams running CI, script the claim against a faucet API and cache the funded address so jobs do not depend on a live faucet at run time.
If you are repeatedly blocked, that is a signal to separate testnet funding from testnet RPC. A dedicated Base Sepolia endpoint from OnFinality removes endpoint rate limits from the equation, so the only variable left is the faucet itself.
| Criterion | What to check | Why it matters |
|---|---|---|
| Symptom | Likely cause | Next step |
| Faucet says success, balance is zero | Claim transaction status on sepolia.basescan.org | Distinguishes a faucet failure from an RPC or network mismatch |
| Faucet returns a rate-limit error | Per-address vs per-account limits; time since last claim | Switching faucet category is faster than waiting out the cooldown |
| Deploy script fails with insufficient funds | Chain ID in config (should be 84532) and deployer address | A mainnet config pointed at a testnet wallet will always fail |
| Balance visible in explorer but not in app | RPC endpoint URL and whether it is Base Sepolia or Base mainnet | Mixing endpoints is the most common silent failure |
Base Sepolia chain settings to keep alongside your faucet notes
Keep these settings in the same place as your faucet bookmarks so you never have to look them up mid-debug. They match the Base Sepolia network configuration OnFinality publishes.
For a managed endpoint, OnFinality's Base Sepolia RPC is available at https://base-sepolia.api.onfinality.io/public over HTTP. For production Base mainnet, the equivalent endpoint is https://base.api.onfinality.io/public. Both are listed on the OnFinality supported networks page alongside other chains.
| Criterion | What to check | Why it matters |
|---|---|---|
| Setting | Value | Notes |
| Network name | Base Sepolia Testnet | Use the exact name when adding to a wallet |
| Chain ID | 84532 | Base mainnet is 8453; mixing them sends funds to the wrong network |
| Currency symbol | ETH (Sepolia Ether) | Faucet drips are denominated in ETH |
| Explorer | https://sepolia.basescan.org | Use it to confirm faucet transactions |
| OnFinality RPC | https://base-sepolia.api.onfinality.io/public | HTTP transport; suitable for scripts and dApp configs |
Scripting faucet claims and RPC checks in CI
Manual faucet claims do not scale to a team or a CI pipeline. The pattern that works is: claim once to a long-lived test address, store that address in CI secrets, and verify its balance over RPC at the start of each job. If the balance is below a threshold, trigger a faucet API claim and wait for confirmation before proceeding.
The example below uses a Base Sepolia RPC endpoint to check the balance and only calls the faucet when needed. It does not assume a specific faucet API shape — substitute the endpoint and payload from whichever faucet you use.
- const RPC = 'https://base-sepolia.api.onfinality.io/public';
- const balance = await fetch(RPC, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_getBalance', params: [address, 'latest'] }) }).then(r => r.json());
- if (BigInt(balance.result) < MIN_WEI) { await claimFromFaucet(address); }
- Poll eth_getBalance until it rises above the threshold or a timeout expires, then fail the job with a clear message.
Where OnFinality fits next to a faucet
A faucet solves one problem: getting test ETH to an address. It does not solve endpoint reliability, archive access, or the transition from testnet to mainnet. Those are RPC concerns, and they are where a managed provider earns its place.
OnFinality offers RPC API access to Base Sepolia and Base mainnet, plus dedicated nodes for teams that need isolated infrastructure. If you are evaluating providers, compare them on the criteria that matter for Base workloads — HTTP and WebSocket support, archive data, rate limits, and failover — rather than on faucet drip size. The RPC provider selection guide covers those criteria in detail, and the pricing page shows how plans are structured.
- Use the public Base Sepolia endpoint for quick checks and early development.
- Move to an API key or dedicated node when CI jobs or multiple developers share the endpoint.
- Keep Base mainnet and Base Sepolia endpoints in separate config files to avoid cross-network mistakes.
Frequently Asked Questions
Is the Base faucet for mainnet or testnet?
Base faucets dispense testnet ETH on Base Sepolia (chain ID 84532). There is no faucet for Base mainnet ETH, because mainnet ETH has real value. To get mainnet ETH on Base, withdraw from an exchange that supports Base or bridge from another chain.
How much Base Sepolia ETH does a faucet give?
Drip sizes vary by provider and change over time. Some faucets drip a fraction of an ETH per claim, others drip more but rate-limit per address or per account per 24 hours. Check the faucet's own documentation for current limits rather than relying on a fixed number.
Why is my Base Sepolia balance still zero after claiming?
Check the claim transaction on sepolia.basescan.org first. If it is pending or failed, the faucet is the issue. If it succeeded, confirm your RPC endpoint is Base Sepolia and not Base mainnet, and that you queried the same address you claimed to.
Can I claim Base Sepolia ETH programmatically?
Some faucets expose an API or SDK — Coinbase Developer Platform is the most commonly used for Base Sepolia. Others are UI-only. For CI, script against a faucet that offers an API and cache a funded address so jobs do not depend on a live faucet at run time.
Do I need a separate RPC endpoint to use a faucet?
No, but you need an RPC endpoint to verify the claim and to deploy contracts. A public endpoint is fine for early work; a managed endpoint such as OnFinality's Base Sepolia RPC is more predictable when multiple developers or CI jobs share it.
What if every Base faucet is empty?
Try a different faucet category, bridge Sepolia ETH from Ethereum Sepolia, or ask a teammate to send a small amount from their testnet balance. For teams, the durable fix is to fund a long-lived test address once and reuse it.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
