What is relayfor.si?

AI credit

How payouts become credit, how to buy more in USDC, and how each call is paid.

Every token has one credit account, in dollars. Its router keys spend it on AI, and only on AI.

Where credit comes from

  • Payouts. The AI's share of each payout is credited at the price at that moment: SOL at Pyth's SOL/USD less the price's stated uncertainty, USDC at $1, other tokens once sold for USDC.
  • Purchases. Anyone can buy credit for an account in USDC, from $20. Each USDC adds $1 once the transfer is final.

Credit never expires. It is not money: it can't be withdrawn, moved to another account or paid out.

Buy credit

On the dashboard, open Credit, pick the token's account and press Buy credit. Enter the amount (from $20) and press Pay: your connected Solana wallet approves the USDC transfer, which needs a little SOL for the network fee too. The credit lands once Solana finalizes it, usually within a minute or two.

From your server, POST /accounts/{id}/purchases with amount_usd ($20 to $1,000,000) and the payer wallet answers a USDC transfer for that wallet to sign, and the same payment as a Solana Pay link:

curl https://relayfor.si/api/project/v1/accounts/<mint>/purchases \
  -H "Authorization: Bearer $RELAYFOR_SECRET_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "amount_usd": "50", "payer": "<the paying wallet>" }'

The transaction expires with its blockhash in about a minute; make another purchase if it does. Poll the purchase until status is credited.

Reading the balance

AmountMeans
spendable_usdWhat new calls can reserve now
balance_usdCredit left, what running calls hold included
reserved_usdHeld by calls still running or waiting on their cost
credited_usdEvery credit the account ever received
spent_usdEverything its calls were charged

Your server reads it with GET /accounts/{id}; an agent reads its own with GET /api/v1/balance and its router key. The ledger lists every change: fee_credit, purchase, call_charge and adjustment.

When an account's spendable credit falls under $5, the account.low_balance webhook tells you, once until it is topped up.

How a call is paid

From reserve to chargeExample
max_tokens
  1. Check
  2. Reserve
  3. Answer
  4. Charge
The account's balance$0.50
Reserved
$0.0152
Charged
...
Freed
...

1,200-token prompt, $0.50 balance

Before a call starts, it reserves its worst case: the whole prompt plus the longest answer max_tokens allows. You pay only what the model wrote, and the rest goes back at once. Without a limit the reserve is the model's whole output, 128,000 tokens here, and a small balance can't cover it: the call is refused with 402 insufficient_balance.
  1. Check. The key, the model and the body. Nothing is reserved for a request that can't run.
  2. Reserve. The call holds its worst case: the prompt plus the longest answer max_tokens allows, at the model's price plus 20%, and never less than $0.001. A balance that can't cover it answers 402 insufficient_balance at once.
  3. Answer. The model writes, streamed or whole.
  4. Charge. The call is charged what the model wrote, and the rest of its reserve goes back at once.

So spendable_usd dips while calls run and springs back as they end. A lower max_tokens lets more calls fit in the same balance at once.

On this page