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

# Service layer

> The oracle, bridge, indexer, and program services that run beside the validators, bringing prices and collateral in and serving committed data out.

Services run beside the validators. Prices and collateral come in at the network layer, and committed data goes out from the state layer. None of them can change a balance on its own: whatever they produce becomes chain state only through consensus.

| Service | What it does |
| - | - |
| [Oracle](#oracle) | Each validator computes and signs its own prices, certified inside consensus |
| [Bridge](#bridge) | Moves collateral between Intention and other chains, with a dispute period on withdrawals |
| [Indexer](#indexer) | Serves committed data through REST and WebSocket APIs |
| [Program services](#program-services) | Compute account state that needs history, such as fee tiers, and commit the result back |

## Oracle

The validator set is the oracle. There is no external oracle network. Each validator runs its own oracle sidecar that turns venue data into an index price and an external perpetual mid per instrument. The validator signs both, and the network certifies them in the same consensus round that commits the trades using them.

Per validator — off the consensus pathInside consensusTrading venuesOracle sidecarone per validatorThe validator validates and signsGossiped between validatorsCertified per epoch and roundCarried in the blockKernel — mark price · margin · liquidation · fundingsettles against the prices committed in the same consensus event

Aggregation runs per validator, off the consensus path. Certification runs inside consensus, so there is no separate oracle transaction and no gap between a price being published and being used. The mark price is not certified: the kernel on every node derives it deterministically from the certified prices and the order book. [Index price](https://docs.intention.xyz/trading/index-price.md) covers how sources are weighted and clamped.

## Bridge

The bridge moves collateral between Intention and other chains. Deposits are locked in a contract on the external chain, observed by validators, and credited as ordinary Intention transactions. Withdrawals are deliberately slower: they run in two phases with a dispute period in between.

Requested on IntentionSigned by validators, registered on the contractit does not pay outDispute perioda configured window must elapseFinalizedfunds releasedInvalidatedcancelled before anything movesWhy it waitsEvery catastrophic bridge failure has the same structure: an attacker obtains the ability to authorize a withdrawal, and the funds are gone in the same block. A dispute period converts an instant, irreversible loss into a window in which monitoring and humans can act. The cost is that legitimate withdrawals wait too.elapseddisputed

1. Validators sign the withdrawal and register it on the external contract. Nothing is paid out yet.
2. During the dispute period, the withdrawal can be cancelled before any funds move.
3. The withdrawal is finalized.

Most catastrophic bridge losses happen when an attacker can authorize a withdrawal and drain funds in the same block. The dispute period turns that into a window in which monitoring can act. A designated role can also lock the whole bridge. That power is a real trust assumption, accepted because a bridge failure is irreversible. The bridge is [audited separately](https://docs.intention.xyz/protocol/security/audits.md).

## Indexer

The indexer serves committed blocks as queryable data through the [REST and WebSocket APIs](https://openapi.intention-testnet.xyz/). The kernel already emits typed output with every change tied to its transaction, so the indexer only reshapes data; it never reconstructs it. Any disagreement with the chain is a bug.

split by ageFull nodecommitted blocks, streamed as typed recordsCacherecent — from memoryFile storehistorical — durableData servicepresents both as one streamGateway → REST · WebSocketaccess, quotas, routingWhy the fork existsHead-following is latency-sensitive and small; historical queries are throughput-sensitive and large. One backfill down a shared path would stall the live one.A serving layer, not a source of truthThe kernel emits typed, attributed output, so the indexer reshapes rather than infers. A disagreement with the chain is a bug in the indexer.

Recent data is served from memory and history from file storage, so backfilling months of history never slows a market maker following the live feed. The indexer only knows committed data: an order still in the mempool will not appear yet. For anything that matters, such as an audit or a dispute, check against the chain or your own [full node](https://docs.intention.xyz/developers/run-a-node.md).

## Program services

Some account state depends on history, such as a fee tier based on thirty days of volume. Computing it inside every block would be wasteful, so a program service computes it outside the block and commits the result back to the chain. Execution then reads it like any other configuration. Today the one running service is volume-based fee tiers.

Committed trading historyProgram servicewindowed computation, outside the blockreads the fee table live from the chainChanged since last applied?Nothing writtenProtocol transactionChain stateRead during executionin constant timeDiffing is on rates, not tier positionsA threshold that moves, or a tier that is re-priced, changes what an account pays without changing its tier index.The chain resolves the final rateA period is recorded as applied only after every batch commits; a crash replays the whole period, which is safe because the computation is idempotent.

The chain stays the authority. A service only proposes values; only what the chain accepts counts. Rates are always resolved against the fee configuration on the chain, never a local copy. See [Fees](https://docs.intention.xyz/trading/fees.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.