Skip to main content
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.

​
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 path
Inside consensus
Trading venues
Oracle sidecarone per validator
The validator validates and signs
Gossiped between validators
Certified per epoch and round
Carried in the block
Kernel — 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 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 Intention
Signed by validators, registered on the contractit does not pay out
Dispute perioda configured window must elapse
Finalizedfunds released
Invalidatedcancelled before anything moves
Why 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.
elapsed
disputed
  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.

​
Indexer

The indexer serves committed blocks as queryable data through the REST and WebSocket APIs. 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 age
Full nodecommitted blocks, streamed as typed records
Cacherecent — from memory
File storehistorical — durable
Data servicepresents both as one stream
Gateway → REST · WebSocketaccess, quotas, routing
Why 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.

​
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 history
Program servicewindowed computation, outside the blockreads the fee table live from the chain
Changed since last applied?
Nothing written
Protocol transaction
Chain state
Read during executionin constant time
Diffing 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.