Faucet
Run a development-token faucet as a bounded service, not an unlimited key exposure.
A faucet is a service that transfers development tokens from a funded account to a requester, allowing developers and test accounts to pay transaction fees without a manual transfer. A private development cluster needs one to fund users and test accounts, but it must be a bounded service, not an unlimited faucet key behind a public endpoint.
Example bounded policy
| Setting | Value | Meaning |
|---|---|---|
| Faucet port | 9900 | Dedicated faucet listener. |
| Per-request cap | 1000000000 lamports | 1 SOL maximum per request. |
| Per-time-window cap | 10000000000 lamports | 10 SOL total for the configured window. |
| Time window | 60 seconds | Rate-limit interval. |
The faucet service uses its own keypair. Run it as a separate, single-purpose workload rather than inside the bootstrap validator, mount only the faucet key as read-only, and keep its network exposure intentional. The faucet public key is included at genesis; the faucet secret key must be protected like any other funded authority.
The example limits are expressed in lamports for configuration and passed to solana-faucet as SOL. They yield the 1 SOL request cap, 10 SOL time-slice cap, and 60-second window shown below.
Deployment rules
- Bind the service only where it is intended to be reachable; development networks do not need an internet-wide faucet by default.
- Apply network-layer rate limits in addition to faucet limits if it is exposed beyond a trusted environment.
- Monitor request failures, cap hits, balance, and process restarts.
- Define a refill procedure and approval boundary before the faucet balance becomes low.
- Never reuse a validator identity, vote authority, stake authority, or withdraw authority as the faucet key.
Verification
Before advertising the faucet, verify that a bounded request succeeds, a request above the cap fails, and the time-window budget resets as expected. Record the cluster genesis hash alongside the faucet endpoint so a client cannot mistake a faucet for a different development network.
What not to publish
Do not publish faucet private keys, unbounded funding endpoints, internal hostnames, or balances that make a test environment attractive for abuse. A public documentation page should describe the request contract and limits, not the custody details.