Bitcoin test sats for AI agents
Fund AI agent test wallets with free Bitcoin Signet sats over Ark, Lightning, or on-chain. Use the JSON API without an account, API key, or CAPTCHA.
Choose your agent
Use ArkFaucet to exercise wallet funding, payment requests, structured error handling, and queued payout workflows before building with real funds. The faucet skill describes the API; your agent still needs HTTP tools and a compatible receiving wallet.
1. Check the faucet before requesting sats
curl --fail --silent --show-error https://arkfaucet.com/api/statusConfirm network is signet. Read supported_rails, allowed_amounts, daily_remaining_sats, and rate_limits. The total allowance changes with the wallet balance; avoid hardcoding it.
The current request sizes are 500, 1,000, and 1,500 sats. A successful health check only confirms process readiness; use status to check available funds.
2. Prepare a compatible destination
| Method | Destination | What to expect |
|---|---|---|
| Ark | Fresh tark1 address from a compatible Bark Signet wallet | HTTP 200 with success: true and status: sent |
| Lightning | Fresh Signet BOLT11 invoice beginning lntbs | Match the invoice amount to the request; check the receiving wallet after success |
| On-chain | Fresh lowercase tb1 Signet SegWit address | HTTP 202; poll the returned private status URL until the payout finishes |
For Ark, check minimum_bark_version and ark_server in the status response. The current minimum is Bark 0.6.2 and the server is https://ark.signet.2nd.dev/. Follow Second’s Signet wallet setup using a separate test wallet. Keep funded wallets separate and do not replace them with --force.
A tb1 prefix alone cannot distinguish Signet from testnet. Confirm the network in the wallet. For invoices, follow the Lightning Signet guide.
3. Request sats through the API
Replace the example destination with the complete fresh address from your wallet. This command submits a claim; the placeholder itself is not valid.
curl --silent --show-error --include https://arkfaucet.com/api/request \
-H 'Content-Type: application/json' \
--data '{"rail":"ark","destination":"tark1YOUR_FRESH_ADDRESS","amount_sats":500}'For Lightning use rail: lightning and the complete invoice. For on-chain use rail: onchain and the complete Signet address. Keep the selected rail and amount consistent.
4. Handle the result
Ark and Lightning return HTTP 200 with success: true and status: sent on success. Confirm receipt in your wallet before continuing a workflow that spends those sats.
On-chain returns HTTP 202 with status: pending and claim_status_url. Poll that exact URL with GET, keeping its token private. pending and processing are not finished. sent means broadcast, not blockchain confirmation; check your wallet for confirmations. Stop on failed or unknown.
Broadcast normally waits for the next five-minute Ark round. The on-chain rail has a shared two-payout limit per rolling 24 hours, so check availability before choosing it.
Limits and recovery
- 400 or 415: read the JSON error and correct the destination, amount, rail, or content type before another request.
wrong_ark_server: use the returnedrequired_ark_serverand generate a new compatible address.- 429: report
Retry-Afterorretry_after_secondsand stop. Do not rotate IPs, change transports, or swap destinations to bypass a limit. payout_unknownor an on-chainunknownstatus: stop without a replacement claim; the original payment may have been sent.- Other 503 errors: use bounded backoff and stop after a few attempts. If a connection drops after submitting a claim, do not assume the payment failed.
Clearnet allows up to five reserved or successful claims per IP per rolling 24 hours and one per destination. Tor and I2P share a five-claim hourly allowance alongside destination and global caps. Pending and uncertain payments also reserve capacity.
Keep building
Read the faucet skill, OpenAPI contract, or compact service documentation. Privacy transport setup: Tor and I2P.