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

# The Grid for agent builders

> Five concrete properties that make Grid suitable for agent-driven payment workflows.

If you have read [What is Grid](/user-guide/what-is-gen), you know the Grid is a Layer 1 built
for agentic payments. This page answers the next question: what specifically
makes it a good fit for that workload, compared with a general-purpose chain or
a traditional card or bank rail. The answer is a small set of properties: five
of them, each of which maps to something an agent payment integration
actually needs.

## What agentic payments require

An agent does not pay the way a human does. It transacts at machine cadence,
often hundreds or thousands of times per hour, in amounts that can be a
fraction of a cent. It needs a settlement decision in time to act on it inside
a single API round-trip. It chains payments across providers (call a model,
call a search tool, call a payment processor) without a human in the loop. It
needs to operate under a programmatic policy that bounds how much it can spend,
on what, and for how long. And it transacts in money that does not move under
its feet: stablecoins, not a volatile native asset.

Use that profile as the rubric. The five properties below each address one
piece of it.

## Sub-cent transaction cost

The Grid prices fees so a single payment can be economically meaningful at a
fraction of a cent. Per-token LLM billing, per-row dataset access, per-second
streamed compute: these are workloads where a fee of a few cents per
settlement would dominate the price of the thing being paid for. the Grid's fee
model is designed to disappear into the noise at that scale.

*Example:* an agent paying 0.2 cents per LLM completion can settle each call
on-chain without the fee exceeding the call price. On a chain where a transfer
costs tens of cents, the same workload must be batched off-chain or
abandoned.

## Stablecoin-denominated fees (no gas-token volatility)

On the Grid, the settlement currency, the unit of account, and the fee currency are
all stablecoins. Fees are quoted in USD and paid in a stablecoin the signer
chooses. There is no separate native gas token an agent must hold, top up, or
hedge against.

*Example:* an agent funded with USDC pays for an API call and the fee on that
same activation out of its USDC balance. A finance team can budget the agent
in dollars and audit its spend in dollars. A price spike in some unrelated
asset cannot make tomorrow's payments cost ten times what today's did.

## Sub-second deterministic finality

The Grid finalizes blocks at a 10-millisecond cadence and offers two settlement
modes: an optimistic acknowledgement under 50 ms for latency-sensitive flows,
and deterministic finality in 400–800 ms for settlement-grade guarantees. The
optimistic path fits comfortably inside a normal HTTP round-trip. An agent
can pay and continue on the same request.

*Example:* an HTTP 402 payment challenge (server returns 402 with a price,
client pays, server verifies and serves) completes in a single user-visible
request. The agent does not have to hold a connection open while waiting for a
slow chain.

## Programmable payment policies (budget caps, conditional release)

An agent typically spends on behalf of a principal (a user or a service that
funded it). the Grid models that relationship as a **delegation**: an on-chain
record, signed by the principal, that scopes what the agent may spend, with
whom, and until when. Spending ceilings can be per-activation, per-day, or
per-counterparty. The principal can revoke or tighten a delegation at any
time. An activation that exceeds its delegation is rejected at submission, not
caught after the fact in an audit log.

*Example:* a procurement agent is given a \$50/day cap and a counterparty
allow-list of three approved data vendors. It can transact freely inside that
envelope. An attempt to pay a fourth vendor or exceed the daily cap is
refused before any money moves.

> Note: the surface a developer programs against is the delegation primitive
> described above. Specific enforcement details (which fields are checked at
> submission versus at execution, and how revocations propagate) continue to
> evolve on DevNet. Treat delegations as the contract; check the
> [CLI reference](/reference/cli/install) and the [JSON-RPC reference](/reference/rpc/overview)
> for the current enforcement matrix before relying on a particular check in production.

## Persistent on-chain identity for agents (portable receipt history)

An agent on the Grid has a stable on-chain identity (an entity with a wallet and a
signing key) and every payment it makes is a signed, ordered record on the
chain. That history is not tied to a particular vendor account, app, or
custodian. It moves with the agent.

*Example:* a researcher agent that has paid 4,000 small fees to a dozen data
providers over six months can present that record to a new provider as proof
of standing (for a discount, a higher rate limit, or simply faster
onboarding). The receipt history is the agent's reputation, and it is portable.

## What the Grid does not give you

The Grid is the settlement and coordination layer, not the agent itself. It does
not orchestrate tools, decide which model to call, broker between agents, or
provide the application framework you wrap around an LLM. Use the agent
framework you already use (LangChain, an OpenAI Agents runtime, AP2-based
flows, or your own) and use Grid for the part underneath: identifying the
parties, holding their balances, enforcing the spending rules, and settling
each payment.

## Next steps

* [Activations](/user-guide/concepts/activations): the unit of work an agent submits when it pays.
* [Entities and accounts](/user-guide/concepts/entities-and-accounts): how an agent and its principal are represented on-chain.