Gas infrastructure behind one API.
Monitor wallets, define funding policies, and track every execution without building chain-specific gas infrastructure yourself.
Business concepts in. Chain complexity out.
The public API should expose concepts like:
- Wallets
- Policies
- Funding
- Thresholds
- Balances
- Execution status
Not provider-specific implementation details.
Example: create a policy
POST /v1/policies
{
"walletId": "wal_01J...",
"type": "threshold",
"threshold": "0.005",
"targetBalance": "0.02",
"limits": {
"maxDailyUsd": "100"
}
}{
"id": "pol_01J...",
"status": "active",
"walletId": "wal_01J...",
"network": "base",
"gasAsset": "ETH"
}Errors should tell you whether you need to act.
{
"error": "no_route_available"
}{
"error": {
"code": "NO_ROUTE_AVAILABLE",
"message": "GasTanker could not find an eligible route for this funding request.",
"retryable": true,
"actionRequired": false,
"requestId": "req_01J..."
}
}Every error should answer:
- 1.What happened?
- 2.Will GasTanker retry?
- 3.Does the customer need to act?
- 4.Which request or operation does this refer to?
Amounts are explicit.
Financial infrastructure should never make developers guess units.
Responses should expose enough information to make unit handling obvious.
{
"amount": {
"baseUnits": "18000000",
"decimals": 9,
"formatted": "0.018",
"asset": "SOL",
"network": "solana"
}
}Redundant on purpose.
Unit confusion is too expensive to hide behind convenience.
Retrying an API request should not mean paying twice.
Every money-moving API operation uses idempotency.
If the client retries the same request, GasTanker returns the existing operation rather than creating a second movement.
“Submitted” is not the same as “complete.”
Funding operations expose their lifecycle.
created
→ validating
→ quoting
→ executing
→ submitted
→ confirming
→ settling
→ completedIf GasTanker cannot determine what happened:
unknown
→ resolvingnot:
failed
→ retry blindlyStart with monitoring, free.
No private keys. No custody migration. No sales call.
Start monitoring free