What happens in on-chain settlement: a trade's path from quote to ledger

When a project says its trades “settle on-chain,” what exactly happens, and how much of it can be verified? In short: the collateral for a trade sits in a smart contract, the rules for moving it are written in code and the transfers themselves are visible on the blockchain's public ledger.

But the trade price, the decision to enter the trade and many risk checks take shape off-chain. The blockchain shows the outcome, not the reasons. Below we look at the steps that make up a trade's life cycle, what changes when the last step moves onto the blockchain and how this works in the Variational protocol. The general split of functions between the network and servers is covered in the article “Why crypto infrastructure combines on-chain and off-chain components”; here we focus only on settlement.

Booking, clearing and settlement: three different steps

Booking, clearing and settlement are three consecutive stages: the trade is recorded, then it is determined who owes what to whom, and only then are those obligations fulfilled. Mixing up these stages is a common source of confusion in claims about “on-chain settlement.”

In traditional markets, these stages are usually split across institutions: the trading venue records the trade, a clearinghouse calculates obligations and collects margin, and settlement institutions move the money and assets. Each participant keeps its own records, and they reconcile with one another.

For derivatives, “settlement” has a second meaning: the final fulfillment of a contract at a settlement price on its expiration date. The Variational documentation mentions this too: the settlement engine determines the settlement price of contracts at expiry. But Omni, as the documentation puts it, focuses on perpetual contracts, so this function is not used there. The rest of this article uses the first meaning: the movement of collateral.

What makes settlement on-chain

Settlement is called on-chain when obligations are fulfilled through transfers between addresses on a blockchain rather than through an entry in an operator's database. In practice, this rests on three properties.

1. Collateral is held in a smart contract. The funds sit not in a company account but at a contract address that controls them according to predefined logic.
2. Code enforces the rules. The contract determines who can withdraw funds and under what conditions. The rules cannot be changed by bypassing the code — unless the contract allows upgrades, in which case the question shifts to who controls it.
3. State is public. Contract balances and transfer history are visible to anyone who reads the blockchain, without asking the operator.

This changes the trust model but does not eliminate it. You no longer have to rely on the operator keeping honest records, because part of the record is the blockchain itself. Instead, trust shifts to the correctness of the code, to whoever can upgrade it, to the price sources and to the network the contract runs on.

Example: a trade's path in the Variational protocol

In the Variational protocol, the trade is agreed off-chain, while the transfer of collateral into a settlement pool and the recording of the position happen on the blockchain. In its protocol overview, the project describes the protocol as a set of on-chain and off-chain infrastructure for automating the booking, clearing and settlement of derivatives. Users interact with the protocol through applications. The live application is Omni; as of October 2026, its mainnet is in private beta. According to the documentation, the Pro application has not launched.

A trade via RFQ

Trades in the protocol are entered through a request for quote (RFQ). According to the page on trading via RFQ, the sequence at the protocol level is as follows:

1. The taker — the party that needs a price — creates a request describing the instrument.
2. Makers respond with quotes. A quote includes the price and the terms: which settlement pool the trade will be booked in and what margin and liquidation parameters that pool has.
3. The taker selects a quote and approves the smart contract calls to transfer collateral. The documentation stresses that no funds move at this stage.
4. The maker has a final right of confirmation (last look). If the maker approves the contract calls, the trade goes to clearing: a new pool is created if needed, both parties' collateral is transferred into the pool, the trade is booked and the position is recorded in the pool's ledger.

This means the first three steps — agreeing on the price and terms — take place off-chain. The fourth step reaches the blockchain: the transfer of collateral and the recording of the position.

The settlement pool as a ledger

The settlement pool is the protocol's core unit of accounting. According to the documentation, a pool holds open positions, the counterparties' collateral in USDC and the margin and liquidation rules. Pools are isolated from one another: positions in one pool cannot be moved to another or netted against positions in another, and outside participants have no access to others' funds. See the glossary entry “Settlement pool” for more.

A pool can be bilateral or multilateral. In Omni, according to the documentation, each user has their own bilateral pool with the application's single counterparty, the Omni Liquidity Provider (OLP), and all pools follow platform-wide margin and liquidation rules. When a trade is executed on Omni, collateral is transferred from the OLP vault — a smart contract holding OLP's capital — into the user's pool.

A pool can be topped up freely, but only the unused balance can be withdrawn, and only down to the maintenance margin level. This is an example of a rule that restricts the movement of funds: part of the collateral is locked while positions are open against it. The documentation does not specify whether this restriction is enforced by the contract itself or by an off-chain protocol service.

Transactor and watcher

In the Variational protocol, a component called the transactor sends transactions to the network, and the watcher checks their finalization. As described in the protocol overview, the transactor submits the required on-chain transactions on behalf of users and market makers. In Omni, the transactor pays gas for user deposits and withdrawals and, when needed, for transferring OLP funds into new pools. At the same time, according to the fees page, as of October 2026 a flat fee of $0.10 is charged for each deposit or withdrawal, in part to cover gas.

The second component, the watcher, checks whether transactions sent by the transactor have been finalized on the network. The documentation states that it protects against fake deposits and makes sure balances in the application match the state of the blockchain. This leads to an important detail: the numbers in the interface are a reflection of on-chain state synchronized by an external service, not the blockchain itself.

What can and cannot be verified on the blockchain

A public ledger makes it possible to independently verify the movement of funds, but not the logic of the decisions that led to it. The boundary runs roughly as follows.

For Variational, the starting point is the Mainnet Contracts page. It lists the addresses of the protocol treasury, the main OLP vault, the settlement pool factory and the oracle contract on Arbitrum, with links to the Arbiscan block explorer. Presumably, the pools created by the factory can be found through its transactions, but the documentation does not describe how to match a specific pool to a specific user. The contract upgrade process is also not described on the documentation pages we reviewed.

The right-hand column of the table is not a quirk of one project but a general property: the blockchain records what happened, not why. One example is the OLP page: according to the project, OLP never moves traders' funds to external venues and hedges only with its own capital. That user funds remain in the pools can be checked against contract balances. What happens to OLP's capital on external venues cannot be verified from the Arbitrum blockchain.

The limits of transparency

On-chain settlement makes the outcome visible, but that visibility has three limits.

Prices come from outside. The maker forms the quote off-chain, and the index price, which margin and liquidations depend on, comes from an oracle. The contract will faithfully apply the rules, but only to the data it receives. How oracles work and where they fail is covered in a separate article.

The ledger shows movements, not reasons. A collateral transfer looks the same no matter what caused it. To understand why a position was liquidated, or why a firm quote differed from an indicative one shown earlier, you need data from outside the blockchain.

Finality depends on the network. Variational's contracts run on Arbitrum, a layer 2 (L2) network on top of Ethereum. There, a transaction first receives a preliminary confirmation from the sequencer and becomes final only after the transaction batch is finalized on Ethereum. The Variational documentation says the watcher checks finalization but does not specify what level of confirmation it waits for. Soft and hard finality are covered in more detail in “Why crypto applications use layer 2: the Arbitrum example”.

Conclusion: transparency is real but selective

On-chain settlement moves the last step of a trade's life cycle — the transfer of collateral and the recording of the position — onto the blockchain. Price agreement, risk checks and data sources remain off-chain. As a result, you can confirm that funds sit in an isolated contract and moved according to the rules, but you cannot tell from the blockchain alone whether the price was fair.

This raises questions for any protocol that claims on-chain settlement: are the contract addresses published and the code verified, who can upgrade the contracts, where do prices come from and which network confirmation counts as final? Variational publishes its contract addresses in its documentation. The oracle weighting methodology, the contract upgrade process and the level of finality the watcher waits for were not publicly described as of the fact-check date.