---
name: ark-faucet
description: Request, contribute, or monitor valueless Signet Ark test sats through arkfaucet.com. Use when an agent needs test sats, the faucet's current tark1 deposit address, service readiness, or public 24-hour activity for Bark, Ark, Arkade, or ArkAPI development.
---

# Ark Faucet

Use the public JSON API. It requires no account, API key, cookie, or CAPTCHA.

Service URLs:

- Clearnet: `https://arkfaucet.com`
- Tor setup guide: `https://arkfaucet.com/tor/`
- Tor v3 onion: `http://n53zprw4sj3du4tytje4gicmpu7vp43bueeznvg4urioiix63exbenyd.onion`
- I2P setup guide: `https://arkfaucet.com/i2p/`
- I2P service: `http://vdth7f4yn5yzh2rpgwo5m5hegx7yvvvsw46jxsi2phknzk5zacxq.b32.i2p`

Use one base URL consistently. When privacy, network policy, or censorship resistance calls for Tor, access the onion URL through a Tor-capable client and use its same-origin API paths.
For I2P, use a local I2P HTTP proxy and the verified `.b32.i2p` origin. Never use a public gateway for faucet addresses or responses.

## Check readiness and activity

- Use `GET /api/health` for a lightweight JSON process check or `HEAD /api/health` for a bodyless readiness probe. Neither accesses the wallet.
- Use `GET /api/status` when wallet balance, limits, allowed amounts, Ark server, endpoints, or the current faucet deposit address are needed. `HEAD /api/status` is bodyless but still performs the full status check, so do not use it as the routine health probe.
- Use `GET /api/activity` for privacy-safe hourly balance, received-sat, and distributed-sat aggregates covering the last 24 hours. Aggregates are monitoring data, not proof that a particular claim or deposit settled.

## Claim Signet sats

1. Use Bark `0.6.0` or newer, preferably the current `0.6.1` release, connected to `https://ark.signet.2nd.dev/`. Check with `bark --version` before claiming. The faucet runs Bark `0.6.1`. Older Bark releases can generate an address but cannot decode the current Ark server's VTXO format.
2. Obtain a fresh, checksum-valid `tark1` address from that wallet. Never invent an address, submit the example placeholder, alter a wallet-produced address, or use a mainnet address.
3. If no compatible Bark wallet exists, create a separate one without overwriting any existing wallet:

```bash
bark --datadir ~/.bark-arkfaucet create --signet --ark https://ark.signet.2nd.dev/
bark --datadir ~/.bark-arkfaucet address
```

Do not add `--force`; it can destroy an existing wallet in the selected data directory.

4. Fetch `GET https://arkfaucet.com/api/status` and confirm `ark_server` matches the wallet.
5. Choose an amount listed in `allowed_amounts` that does not exceed `daily_remaining_sats` or `wallet_balance_sats`.
6. Send JSON to `POST https://arkfaucet.com/api/request` with `Content-Type: application/json`:

```json
{"address":"tark1YOUR_VALID_ADDRESS","amount_sats":500}
```

7. Treat the claim as complete only when the response has HTTP 200, `success: true`, and `status: "sent"`.

Example:

```bash
curl -sS https://arkfaucet.com/api/request \
  -H 'Content-Type: application/json' \
  -d '{"address":"tark1YOUR_VALID_ADDRESS","amount_sats":500}'
```

Tor status example:

```bash
curl --socks5-hostname 127.0.0.1:9050 \
  http://n53zprw4sj3du4tytje4gicmpu7vp43bueeznvg4urioiix63exbenyd.onion/api/status
```

I2P status example:

```bash
curl -x http://127.0.0.1:4444 \
  http://vdth7f4yn5yzh2rpgwo5m5hegx7yvvvsw46jxsi2phknzk5zacxq.b32.i2p/api/status
```

## Fund the faucet

1. Fetch `GET /api/status` immediately before sending and read `deposit_address`; do not rely on a copied address from documentation or an earlier session.
2. Confirm `network` is `signet` and `ark_server` matches the sending wallet.
3. Send only valueless Signet Ark sats to the returned `tark1` address. A deposit does not create an account, claim credit, or entitlement to future payouts.
4. Confirm the public balance through `GET /api/status` and received activity through `GET /api/activity`. Allow for wallet synchronization before treating unchanged values as a failure.

## Handle failures safely

- For HTTP 400 or 415, correct the request. A response code of `invalid_address` means the address prefix, encoding, or checksum was rejected; obtain a fresh address from the compatible wallet instead of editing it. Do not retry the same invalid payload.
- For `wrong_ark_server`, use `required_ark_server`, configure a compatible wallet, and generate a fresh address before retrying.
- If a send succeeds but the wallet reports `invalid GenesisTransition type`, upgrade to the current Bark `0.6.1` release or newer, sync it, and use a fresh address. Do not keep retrying the old client.
- For HTTP 429, inspect `code`. Obey the `Retry-After` header or `retry_after_seconds`; do not evade IP or address limits.
- `address_rate_limited` means obtain a fresh wallet address only for a genuinely new testing need, not to bypass the faucet policy.
- For HTTP 503, retry with bounded exponential backoff. Stop after a few attempts and report the service as unavailable.
- Never claim mainnet value: this faucet serves Signet only and its sats have no monetary value.
- Tor claims share the same per-address and global daily limits as clearnet. A per-IP limit is not applied on the onion service because Tor clients do not expose a dependable client IP.
- I2P claims share the same per-address and global daily limits, with no per-IP limit on the I2P service.

Current API details are published at:

- `https://arkfaucet.com/openapi.json`
- `https://arkfaucet.com/llms.txt`