Why crypto infrastructure combines on-chain and off-chain components

Why don’t trading protocols that call themselves on-chain run entirely on the blockchain? Because a blockchain does a few things well — it holds funds according to the rules of code, keeps a public ledger and lets anyone verify the result — but it is poorly suited to fast computation, private strategies and working with external data.

That is why almost all crypto infrastructure is hybrid: some functions are performed by smart contracts, others by the operator’s ordinary servers. So the key question is not whether a project is “decentralized” but where exactly the line runs between verifiable code and trust in the operator.

Below we look at why this happens, where different functions usually live and how it looks in a concrete example: the documentation of the Variational protocol.

What a blockchain does well, and what it doesn’t

A blockchain guarantees that all nodes reach the same result, and that guarantee is paid for in speed, cost and publicity. This gives three groups of reasons to move functions off-chain.

Determinism and external data

Blockchain nodes must get the same result from the same inputs. As ethereum.org explains, if a contract itself queried an external API for, say, the ETH/USD rate, different nodes could get different answers and consensus would break. So external data is brought on-chain by oracles — applications that obtain information off-chain and write it to the blockchain. For the same reason, an oracle usually consists of an on-chain contract and off-chain components.

Latency and cost

Every on-chain action is a transaction that has to be ordered, executed and paid for in gas. In a volatile market, quotes update more often than it makes sense to write them to the blockchain. Recalculating margin across hundreds of positions on every price move is also a task that is cheaper and faster to handle on a server, sending only the resulting changes on-chain.

Strategy privacy

Everything written to a public blockchain is visible to everyone. A market maker that quoted prices and hedged positions entirely on-chain would reveal its strategy to competitors. So market makers’ pricing and risk management logic generally stays private and runs off-chain.

The typical split of functions

The typical pattern is this: off-chain goes everything that requires speed, external data or confidentiality; on-chain goes what needs to be verifiable and protected by the rules of code. This is not a law but a common compromise, and in specific projects the line may fall elsewhere.

Example: how Variational splits it

Variational’s documentation explicitly describes the protocol as “a set of on-chain and off-chain infrastructure”, and its various pages make it possible to piece together what sits where. Below are the facts from the documentation, with our interpretations marked separately.

On-chain. The contracts page lists the contracts on Arbitrum: the settlement pool factory, the main OLP vault, the oracle contract and the protocol treasury. According to the OLP page, a user’s funds are held on-chain, in that user’s settlement pool, and serve as collateral for their positions.

Off-chain. According to the protocol overview, the oracle receives price feeds from multiple data providers and combines them (as we understand it, what reaches the chain through the oracle contract is the already aggregated result); the transactor submits transactions on-chain on behalf of users and market makers. The watcher checks that these transactions are finally recorded on-chain and protects against fake deposits. The partners page states that the protocol interacts with Arbitrum through the RPC providers Alchemy and QuickNode, and that Fireblocks provides the signatures for oracle data.

Market maker and margin engine. According to the description of OLP, its vault is a smart contract, while its quoting engine and risk system are proprietary algorithms that analyze data from external venues. The documentation does not say in so many words where they run; that these computations run off-chain is our interpretation. The same applies to the margin and liquidation engine from the protocol overview: we placed it on the diagram above based on the description of its functions, not on a direct statement in the documentation.

The moment the boundary is crossed. According to the description of RFQ, no funds move until the maker’s final confirmation (last look): the taker only approves smart contract calls, and the collateral is transferred to the pool and the trade is registered after that confirmation. In Omni’s simplified flow, after OLP’s checks and the user’s slippage limit check, collateral is transferred from the OLP vault to the user’s pool. The exchange of requests and quotes, as we understand it, happens off-chain. In other words, what is recorded on-chain is the result of the agreement, not the process of reaching it.

Where the trust boundary lies

The trust boundary lies at the points where a contract relies on an external source. In hybrid trading systems there are usually three such points: prices, operator commands and transaction ordering on the chain itself.

Prices. BIS Bulletin No 76 sets out the oracle dilemma: full decentralization requires complex consensus protocols and reduces efficiency, while partial centralization adds trusted parties to a system designed to be trustless. A proprietary oracle signed through a single custodial provider, in our assessment, falls on the second path. That means price correctness depends on the aggregation methodology and on who controls the signing key. Variational’s weighting methodology has not been publicly disclosed.

Operator commands. If liquidations are calculated by an off-chain engine and executed by an operator transaction, what matters is which checks the contract performs when it receives such a command. The pages of Variational’s documentation we reviewed do not describe this — the question remains open.

Transaction ordering. Even the “on-chain” part has layers. According to the Arbitrum documentation, the sequencer receives and orders transactions. Fast “soft” confirmation depends on its honesty, while “hard” finality comes when batches of transactions are finally recorded on Ethereum. If the sequencer censors transactions or is unavailable, they can be pushed through the parent chain, but with a delay — up to 24 hours, according to the Arbitrum documentation. More in “Why crypto applications use layer 2: the Arbitrum example”.

How to check where the boundary lies

The check starts with a question: what happens if the off-chain part stops or acts in bad faith? A few steps of documentation analysis help answer it.

First, find the contract addresses in the documentation and see whether their source code is published in a block explorer. Second, find out who signs the oracle data and whether the aggregation methodology is disclosed. Third, look for a description of the emergency scenario: can users recover their collateral directly through the contract if the interface and the operator’s services are unavailable? The Variational documentation we reviewed does not describe such a procedure. Fourth, distinguish between soft and hard transaction confirmation on an L2.

How to check project claims in general is covered in “How to read documentation and check a crypto project’s claims”, and how oracles work in a separate piece, “Oracles: how outside data reaches the blockchain and where it breaks”.

Bottom line: hybrid as the norm, the boundary as the question

A hybrid architecture is not a sign of “insufficient decentralization” but a consequence of the blockchain’s properties: it is deterministic, public and expensive to compute on. So the question “on-chain or not” says little about a system. It is more useful to ask which guarantees come from code and which rest on the operator.

The Variational example shows that collateral and positions, according to the documentation, are accounted for in Arbitrum contracts, while prices, quotes and transaction submission depend on the team’s infrastructure; judging by the description of its functions, the same applies to margin calculation. Open questions remain about the oracle methodology, the checks performed on liquidation and the path for withdrawing funds if services fail. The same three questions apply to any hybrid system: their answers show where the code ends and trust begins.