> For the complete documentation index, see [llms.txt](https://docs.bardiel.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bardiel.tech/technical-architecture/sessions-billing-and-x402.md).

# Sessions, Billing & x402

## Sessions, Billing & x402

Bardiel does not talk to miners directly.\
All compute and validation flows go through **Cortensor Router**, which manages:

* sessions
* routing and queuing
* billing and rate limits

This page explains how Bardiel uses sessions and billing, and what builders in **Base, Virtual, ERC-8004, and other agent ecosystems** need to know — and what they do **not** need to worry about.

***

### What Is a Session?

A **session** on Cortensor is a logical container that groups:

* a funding source (Stake-to-Use or x402)
* a series of tasks and responses
* routing / validation configuration

Bardiel behaves as a smart session manager:

* creates sessions when needed (for example, per app, per market, per registry, or per integration)
* reuses sessions to amortize setup costs
* tracks remaining budget and risk per session

The exact layout — one session per agent, per market, per registry, or per Bardiel instance — is an internal implementation detail and can differ between testnet and mainnet.

***

### Funding Modes

Bardiel supports two main funding paradigms on Cortensor.

#### 1. Stake-to-Use

* A pool of staked COR (or other supported assets) backs a session.
* Usage against that session consumes budget over time.

Good for:

* high-volume internal integrations
* long-lived services and markets
* Base-native apps or automation systems with recurring workloads
* Virtual services such as GAME and ACP markets
* longer-term ERC-8004 integrations where stake and SLAs matter
* other agent ecosystems that want more stable capacity planning

Bardiel can map app-, market-, or ecosystem-side identities — for example a Base app, an ACP market, a large agent, or an ERC-8004 registry — to specific stake-backed sessions under the hood.

***

#### 2. x402 Pay-Per-Use

* Inspired by HTTP status code 402 (Payment Required).
* Each request includes or references a payment authorization.

Good for:

* per-call billing
* multi-tenant environments
* integrations where a wallet, gateway, protocol, or marketplace handles user payments
* Base-native and other onchain apps that want payment-gated trust or execution requests

When Bardiel calls Cortensor, it can attach x402 metadata so that each delegation, validation, factcheck, or arbitration call is accounted for at the network boundary.

From Bardiel’s perspective:

* x402 is the mechanism that lets Bardiel act as a **pay-per-call client of Cortensor**
* over time, selected Bardiel routes may also support ecosystem-specific payment paths layered on top of x402

***

### What Builders See (and Don’t See)

From a builder’s perspective — whether you are integrating from **Base**, **Virtual**, **ERC-8004**, or another ecosystem:

* you call **Bardiel**
* Bardiel ensures that each Cortensor call:
  * has a valid session
  * has funding (stake or x402)
  * respects rate limits and budgets

You do **not** need to:

* create or manage Cortensor sessions directly
* attach x402 payment headers yourself in the default integration path
* keep track of miner-level billing details

In the default flow, session and billing are owned by Bardiel and configured by **Virtual / Cortensor operators**, and, where relevant, by ecosystem or market operators integrating Bardiel.

Future “advanced mode” integrations may expose:

* optional hints to pin tasks to specific Bardiel-managed sessions
* per-agent, per-app, per-market, or per-registry budget settings at the Bardiel layer

***

### Rate Limits and SLAs

Because Bardiel sits between **agent ecosystems** and **Cortensor**, it is subject to two kinds of limits:

1. **Caller-side limits**
   * per-agent, per-app, per-market, or per-registry request quotas
   * protections against abusive or misconfigured workloads
2. **Cortensor-side limits**
   * session- or stake-based rate limits
   * router-level quality of service and SLA-aware routing

Bardiel’s policy engine may factor these into decisions:

* reject tasks if the associated budget is exhausted
* automatically downshift from `oracle` to `safe` if the caller cannot afford the higher tier
* prioritize certain tasks when SLAs must be met (for example, settlement jobs, market-critical validation, or high-priority app workflows)

Exact SLA models and pricing are outside this document and will be defined by:

* **Virtual / Cortensor** governance and commercial agreements
* ecosystem- or market-level agreements where Bardiel is integrated
* any **ERC-8004-compatible** registries or protocols that choose to use Bardiel as a validator or oracle

***

### Observability and Traceability

Each Bardiel call is associated with internal identifiers that connect:

* the ecosystem or app request
* the Bardiel decision
* the Cortensor sessions and Router calls

On the response, Bardiel surfaces:

* `trace_id` – a unique identifier for this Bardiel decision
* `bardiel_version` – the version of Bardiel that handled the request

Internally, Bardiel maps these to:

* one or more Cortensor session IDs
* x402 or payment references (where applicable)
* per-call cost and latency metrics

These mappings are used in:

* **Data & Telemetry** (aggregated dashboards and metrics)
* debugging across ecosystem ↔ Bardiel ↔ Cortensor

Examples include:

* Base app ↔ Bardiel ↔ Cortensor
* Virtual / ACP ↔ Bardiel ↔ Cortensor
* ERC-8004-compatible market ↔ Bardiel ↔ Cortensor

***

### Summary

* Bardiel uses **Cortensor sessions** to group tasks and funding.
* Sessions can be backed by **Stake-to-Use** or **x402 pay-per-use**.
* Builders across Base, Virtual, ERC-8004, and other ecosystems integrate with **Bardiel**; session and billing details are handled internally.
* Rate limits and SLAs are enforced across both the **caller side** and the **Cortensor side**, with Bardiel in the middle making policy decisions.
* `trace_id` and internal telemetry keep the whole pipeline observable without exposing low-level network complexity to end users.