Faucet

The faucet grants SUPRA to a Move account on Devnet and Testnet. There is no EVM faucet: an EVM address is funded by crossing SUPRA from a Move account, as described in Funding an account.

Requesting a grant

The faucet is served from a network’s RPC host, https://rpc-<network>.supra.com. The path carries the API version the network’s faucet is served under:


GET https://rpc-devnet.supra.com/rpc/v4/wallet/faucet/<move_address>
GET https://rpc-testnet.supra.com/rpc/v1/wallet/faucet/<move_address>

Devnet’s faucet URL is also in its network parameters.

The response is either {"Accepted": "<transaction_hash>"}, or "TryLater" when the faucet has no minter free at that moment. Accepted means the funding transaction has been submitted, not that it has executed: read it back with GET https://rpc-devnet.supra.com/rpc/v4/wallet/faucet/transactions/<hash> on Devnet, or GET https://rpc-testnet.supra.com/rpc/v1/wallet/faucet/transactions/<hash> on Testnet. The read-back returns the funding transaction, and its status field is "Success" once the transaction has executed. A "TryLater" does not count against the account.

Limits

The faucet limits each account to a grant amount per request, a cooldown between grants, a number of grants per day and a balance ceiling. The values configured on a network’s node are listed in the description of the faucet operation on that network’s API page, which the node serves at https://rpc-devnet.supra.com/docs on Devnet and https://rpc-testnet.supra.com/docs/ on Testnet, where the node’s build lists them.

The daily count resets at 00:00 UTC. Each node counts requests in memory and clears the counts when it restarts, so the cooldown and the daily count can differ between the nodes behind a load-balanced endpoint. The faucet refuses an account whose balance is at or above the ceiling rather than topping it up, until its balance is below the ceiling again, for example after crossing some of it to SupraEVM.

Faucet requests are also limited per client IP address, before they reach the node. The limit is counted across every faucet endpoint on the network, of every API version, so requests for different accounts from one address draw on the same allowance. Devnet and Testnet are counted separately. Reading back a faucet transaction, as above, is not limited. A request over the limit is refused with status 429 and a Retry-After header giving the number of seconds to wait.

Refusals

A refusal from the node is an error response with a JSON body of the form {"message": "<text>"}:

Refusal	Status	Message
Balance at or above the ceiling	`400`	`Faucet request rejected: receiver balance <balance> meets or exceeds the configured upper cap of <ceiling>. If you have a genuine need to accumulate a lot of test tokens, reach out to the Supra team with KYC.`
Inside the cooldown	`429`	`Account <account> recently received some tokens. Please try again in <seconds>s.`
Over the daily count	`429`	`The faucet request count for account <account> exceeds the daily limit of <limit>. Come back after "<hh>h : <mm>m :<ss>s"`

Balances in the first message are in quants. The balance is checked before the cooldown and the daily count.

Requesting more SUPRA

If you need more SUPRA than the faucet’s limits allow, whether per account or per IP address, email support@supra.com with this subject line, exactly as written:


[Supra Faucet] Funding request

Requests with this subject are routed straight to the team that handles funding requests, and handled ahead of general support mail. In the body, give:

the network: Devnet or Testnet;
the Move address to fund, and the EVM address you will cross to, if you have one;
how much SUPRA you need, in SUPRA rather than quants;
what you are building or testing, and why the faucet’s limits are not enough.