> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beinfi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Infi Rail

> Sell per request to agents paying in stablecoin, over x402. The wallet is yours.

Software already discovers and acts on its own. What it does not do is open an
account, enter a card and sign up for a plan. **Infi Rail** charges per request
to whoever pays in stablecoin, using the **x402** protocol — the
`402 Payment Required` that had been sitting in HTTP since 1997 without being
used for anything.

The money lands in **your** wallet. The signed authorization names the
recipient, so there is no field in which Infi could put itself.

## How one charge happens

1. An agent calls your route without paying. Your server answers **402** with
   the price, the network and the address.
2. The agent signs an authorization and repeats the call with an `X-PAYMENT`
   header.
3. Your server asks Infi whether it may serve. We verify the signature at the
   facilitator, record the authorization, check exposure and answer.
4. You serve the response. On-chain settlement happens afterwards, in the
   background.

Step 4 is what matters for latency: **the response does not wait for the
chain.** What the agent waits for is verification, not block confirmation.

## Setting it up

In the dashboard, under **Rail**. Three things:

* **network** — Base or Solana (mainnet in production, testnet in sandbox);
* **your wallet** — where the money lands;
* **sign a message** — we issue a nonce and you sign it with that wallet.

The third step is what prevents the most expensive mistake here. A wrong address
on a chain pays a stranger, permanently, and **there is no chargeback**. The
signature proves the key is yours before any agent pays.

If you use MetaMask, Phantom or another injected wallet, there is a button. If
the key lives on hardware, in a CLI or behind a multisig, the message is shown
for you to sign elsewhere and paste the signature back.

The asset and its decimals are **not** fields: they come from the network's
facilitator. A wrong exponent misprices every charge by a factor of 10^n, and
that is not a decision we let you type.

## Risk

Two things you control, both worth the reading time:

**Max exposure per agent.** The ceiling on what one agent may owe before it is
refused. It is the most a bad actor costs you.

**Grace.** What your server may release on its own while Infi is unreachable. It
has two numbers: per agent, and **total per process**. The total is the one that
actually binds — during grace the payer address comes from an unverified
payload, so a hostile client forges a fresh address per request and mints a
fresh per-agent bucket with it. Only the per-process ceiling limits anything.

## Where charges show up

Under **Payments**, with `?view=all`: card, pix and agent in the same list, with
the network and the transaction hash linking to the explorer.

Only what actually settled is listed. A call paid from an agent's prepaid
balance does not appear as a new transaction — its money arrived when the
package was bought, and counting it again would count it twice.

## Limits today

* Networks: Base and Solana. Settlement depends on the facilitator connected to
  the account.
* An agent is identified by its wallet address and becomes a customer of the
  product — metering, invoicing and history work unchanged.
* Agent payment is its own rail, separate from pix, boleto and card. There is no
  fallback from one to the other: they are different money.