Glossary

Oracle Layer

The network which provides the prices, in this case, the Bolt Liquidity network. It acts as the authoritative source of price data for the entire ecosystem.

IBC Client (or Light Client)

A component that lives on top of the network where the outpost resides. It can verify the history of the Oracle Layer trustlessly. Since blockchains cannot communicate directly with the external world (e.g., making HTTP requests), the IBC client starts with a trusted state (genesis) and can then, given compressed data of the Oracle Layer (headers), track the history of the chain. The history primarily consists of state roots, which are fingerprints of the Oracle Layer state used to prove the value of a certain portion of state.

Outpost

A blockchain network or system that receives and utilizes the price data from the Oracle Layer. Outposts implement the necessary components to verify and integrate the received price information.

State Root

A cryptographic hash that represents the entire state of a blockchain at a specific point in time. It's used as a reference point for proving the inclusion of specific data in the blockchain's state.

Merkle Proof

A cryptographic proof that allows for efficient and secure verification of the contents of large data structures. In the context of blockchain, it's used to prove that a specific transaction or state is part of a given block or state root.

IBC (Inter-Blockchain Communication)

A protocol that enables different blockchain networks to exchange data and assets in a secure and standardized way. It's the foundation for cross-chain communication in the Universal Outposts system.

Prover

The entity or component responsible for generating proofs about the state of the Oracle Layer. It constructs Merkle proofs and packages the necessary information for verification by the outposts.

Proving State

A mechanism by which a Prover, possessing a state key, state value, and its corresponding Merkle proof, can prove to a Verifier (which only has the State root of chain A) that the claimed state is valid and part of the agreed-upon state root.

Slippage

Slippage refers to the variance between the quoted execution price of a trade and the final price at which it settles. On DEXs and order book systems, slippage arises primarily from:

• Liquidity depth: When available liquidity at the quoted price is insufficient, orders must be executed across multiple price levels (order books) or along the price curve (AMMs), resulting in a worse average execution price.

• Market volatility: Price movements occurring between order submission and on-chain confirmation can cause trades to settle at less favorable rates.

• Execution mechanics: In AMMs, the constant product or bonding curve adjusts the marginal price as trade size increases relative to pool reserves; in order books, large trades may consume multiple resting orders.

Formally, slippage is expressed as a percentage deviation from the expected execution price:

In practice, slippage represents the implicit cost of trading in environments where liquidity or execution speed is constrained.

Verifier

The component on the outpost side that checks the validity of proofs received from the Prover. It uses the IBC Client and the received state root to verify the authenticity of the price data.

Relayer

An off-chain process that facilitates the transfer of IBC packets between chains. It monitors for events on both chains and submits the appropriate transactions to relay data.

Consensus State

The agreed-upon state of a blockchain at a specific height, typically including the state root and other consensus-critical information.