> ## 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

> Venda por requisição pra agentes que pagam em stablecoin, via x402. A carteira é sua.

Software já descobre e age sozinho. O que ele não faz é abrir conta, colocar
cartão e assinar plano. O **Infi Rail** cobra por requisição de quem paga em
stablecoin, usando o protocolo **x402** — o `402 Payment Required` que existia
no HTTP desde 1997 e nunca tinha sido usado pra nada.

O dinheiro cai na **sua** carteira. A autorização assinada nomeia o
recebedor, então não existe campo em que a Infi pudesse se colocar.

## Como uma cobrança acontece

1. Um agente chama sua rota sem pagar. Seu servidor responde **402** com o
   preço, a rede e o endereço.
2. O agente assina uma autorização e repete a chamada com o header
   `X-PAYMENT`.
3. Seu servidor pergunta pra Infi se pode servir. A gente verifica a
   assinatura no facilitator, registra a autorização, checa exposição e
   responde.
4. Você serve a resposta. A liquidação on-chain acontece depois, em background.

O passo 4 é o que importa pra latência: **a resposta não espera a chain**. O que
o agente espera é a verificação, não a confirmação de bloco.

## Configurar

No painel, em **Rail**. Três coisas:

* **rede** — Base ou Solana (mainnet em produção, testnet em sandbox);
* **sua carteira** — onde o dinheiro cai;
* **assinar uma frase** — a gente emite um nonce e você assina com a carteira.

O terceiro passo é o que impede o erro mais caro aqui. Endereço errado em cripto
paga um desconhecido, para sempre, e **não existe chargeback**. A assinatura
prova que a chave é sua antes de qualquer agente pagar.

Se você usa MetaMask, Phantom ou outra carteira injetada, tem um botão. Se a
chave está em hardware, CLI ou multisig, a frase aparece pra você assinar por
fora e colar a assinatura.

O ativo e o número de decimais **não** são campos: vêm do facilitator da rede.
Expoente errado erra toda cobrança por um fator de 10^n, e isso não é uma
decisão que a gente deixa você digitar.

## Risco

Duas coisas que você controla, e valem o tempo de leitura:

**Exposição máxima por agente.** O teto do que um agente deve antes de ser
recusado. É o custo máximo de um agente mal-intencionado.

**Grace.** O que seu servidor pode liberar sozinho se a Infi estiver fora do ar.
Tem dois números: por agente e **total por processo**. O total é o que realmente
limita — durante o grace o endereço do pagador vem de um payload não verificado,
então um cliente hostil cria um endereço novo por requisição e um bucket novo
com ele. Só o teto por processo limita algo.

## Onde as cobranças aparecem

Em **Pagamentos**, com `?view=all`: cartão, Pix e agente na mesma lista, com a
rede e o hash da transação linkando pro explorer.

Só entra o que liquidou de verdade. Chamada paga do saldo pré-pago de um agente
não aparece como transação nova — o dinheiro dela entrou quando o pacote foi
comprado, e contar de novo seria contar duas vezes.

## Limites hoje

* Redes: Base e Solana. A liquidação depende do facilitator conectado na conta.
* Um agente é identificado pelo endereço da carteira, e vira cliente do produto
  — medição, fatura e histórico funcionam iguais.
* Pagamento de agente é rail próprio, separado de Pix, boleto e cartão. Não
  existe fallback de um pro outro: são dinheiros diferentes.