To facilitate onboarding both for the private but especially for the public testnet, we'll want a service that can behave as an ETH and KEEP faucet. To start with, it doesn't need to support token grants, just direct token transfers. To make this generic and open-sourcable, we want to make this work for generic ERC20 tokens. We'll want to add token grant stuff later on.
One endpoint:
POST /api/v0/fund/:token
Body:
{
amount: "<hex, in wei or token>"
account: "<hex, account address>"
}
Response:
{
success: true,
transaction: "<tx id of transfer>"
}
OR
{
error: "<message>"
}
Pre-handled errors:
Faucet is out of the requested token. (status 503)
Faucet does not know of the specified token type. (status 404)
Faucet cannot communicate with the Ethereum backend. (status 502)
:token can be ETH for Ether (which gets custom handling), or KEEP for Keep (which gets generic ERC20 handling).
The faucet service should be configurable with a private key + account address for the account it will be using to fund requesters. We'll eventually want to add rate-limiting as well, so a single account can't drain the faucet through DoS-ish behavior.
The faucet service should also accept a config map that maps ERC20 denomination to an ERC20 contract address:
To facilitate onboarding both for the private but especially for the public testnet, we'll want a service that can behave as an ETH and KEEP faucet. To start with, it doesn't need to support token grants, just direct token transfers. To make this generic and open-sourcable, we want to make this work for generic ERC20 tokens. We'll want to add token grant stuff later on.
One endpoint:
Pre-handled errors:
:token
can beETH
for Ether (which gets custom handling), orKEEP
for Keep (which gets generic ERC20 handling).The faucet service should be configurable with a private key + account address for the account it will be using to fund requesters. We'll eventually want to add rate-limiting as well, so a single account can't drain the faucet through DoS-ish behavior.
The faucet service should also accept a config map that maps ERC20 denomination to an ERC20 contract address:
As well as config that allows for connecting to an Ethereum backend, which should follow the same structure as the Keep client.
We should probably spin this up in its own repo.