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 Virtual and ERC-8004 developers need to know (and don’t 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 ACP market, per ERC-8004 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 Virtual services (GAME / ACP markets)

• longer-term ERC-8004 integrations where stake and SLAs matter

Bardiel can map Virtual- or ERC-8004-side identities (for example “this ACP market”, “this large Virtual agent”, or “this ERC-8004 registry”) to specific stake-backed sessions under the hood.

---

2. x402 Pay-Per-Use

• Inspired by HTTP 402 Payment Required.

• Each request includes or references a payment authorization.

Good for:

• per-call billing

• multi-tenant environments

• integrations where a facilitator (wallet, gateway, or marketplace) handles user payments

When Bardiel calls Cortensor, it can attach x402 metadata so that each delegation/validation/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 on behalf of Virtual and ERC-8004 callers.

---

What Builders See (and Don’t See)

From a Virtual or ERC-8004 developer’s perspective:

• You call Bardiel (via GAME Worker/Function, ACP, or an ERC-8004 integration).

• 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

• 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 applicable, by ERC-8004 registry operators).

Future “advanced mode” integrations may expose:

• optional hints to pin tasks to specific Bardiel-managed sessions

• per-agent, per-market, or per-registry budget settings at the Bardiel layer

---

Rate Limits and SLAs

Because Bardiel sits between Virtual / ERC-8004 and Cortensor, it is subject to two kinds of limits:

1. Caller-side limits (Virtual / ERC-8004)

   • per-agent, 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 QoS 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, ACP settlement jobs or high-priority ERC-8004 validations)

Exact SLA models and pricing are outside this document and will be defined by Virtual/Cortensor governance and commercial agreements, and by any ERC-8004 registries that choose to use Bardiel as a validator or oracle.

---

Observability and Traceability

Each Bardiel call is associated with internal identifiers that connect:

• the Virtual or ERC-8004 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/payment references (where applicable)

• per-call cost and latency metrics

These mappings are used in:

• Data & Telemetry (aggregated dashboards and metrics)

• debugging across Virtual / ERC-8004 ↔ 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.

• Virtual and ERC-8004 developers only integrate with Bardiel; session and billing details are handled internally.

• Rate limits and SLAs are enforced across both the caller side (Virtual / ERC-8004) 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 complexity to end-users.