Off-chain describes anything that happens outside of a blockchain’s state. Centralised exchange trading is off-chain — when you buy BTC on Binance, the trade is recorded in Binance’s internal database, not on the Bitcoin chain, and only shows up on-chain if and when you withdraw to a real Bitcoin address. Messages signed by your wallet but not broadcast are off-chain. Payments inside a state channel are off-chain. Data stored on IPFS or Arweave is off-chain relative to Ethereum, even though it is on another distributed system. The general category is “things involving crypto that are not part of the ledger’s official state”.
The reason off-chain exists is that on-chain is slow and expensive. A Bitcoin transaction takes 10 minutes on average to confirm and costs a few dollars in fees. An Ethereum mainnet transaction takes 12 seconds and, depending on congestion, can cost anywhere from a cent to tens of dollars. For high-frequency activity like exchange trading, micropayments, or game interactions, going through the chain for every action is either too slow, too expensive, or both. Off-chain systems handle the volume and settle back to the chain periodically in aggregate.
The Main Off-Chain Categories
Centralised exchanges are the biggest category by volume. Binance, Coinbase, Kraken, Bybit, and the rest of the major venues each process millions of trades per day, and none of those trades are on-chain. When you match a buy order against a sell order on Binance, the exchange updates its internal ledger, adjusts both users’ balances, and does not touch the blockchain at all. The chain only sees activity when someone deposits or withdraws, and even then the activity is batched where possible to minimise fees.
Payment channels and rollups are off-chain in a more technical sense: they execute transactions in their own environment (a channel, a rollup sequencer) and only touch L1 for settlement or state commits. Lightning Network, Arbitrum, Optimism, and Base all do most of their work off the base chain and inherit security from periodic anchoring. Users typically think of Arbitrum as “on-chain” because it is a real blockchain from their perspective, but from Ethereum L1’s perspective, most Arbitrum activity is off-chain and only settled in aggregate.
Custodial wallets and services that hold your crypto on your behalf keep internal ledgers that are updated off-chain. When Coinbase says you have 0.5 BTC, that balance is in their database, not on the blockchain directly, and it represents Coinbase’s obligation to give you 0.5 BTC when you withdraw — not an immediate on-chain claim.
Off-chain data covers things like metadata for NFTs (usually stored on IPFS or centralised servers), oracle inputs before they are published on-chain, content referenced by on-chain contracts, and anything else that lives adjacent to the chain but is not part of its state. An NFT that points to an off-chain image URL is a particularly common case — the token is on-chain but the thing it supposedly represents is off-chain, and if the off-chain storage disappears, the on-chain token points to nothing.
The Trust Tradeoff
Off-chain is faster and cheaper, but it comes at the cost of having to trust whoever is running the off-chain system. The exchange can freeze your account. The payment channel can close uncooperatively. The oracle can publish wrong data. The IPFS node hosting your NFT’s image can stop seeding the file. Every off-chain component is a potential failure point that on-chain components do not have. This is why the crypto-native answer to “why use blockchains at all” is typically “because the trust guarantees of on-chain settlement are genuinely different from anything you can build off-chain” — the entire point of paying the costs of on-chain operation is to get properties that off-chain systems cannot provide.
In practice, most real systems are a mix. Exchanges are off-chain but settle to chains. Rollups execute off-chain but commit state on-chain. Oracles produce data off-chain and post it on-chain. NFTs reference off-chain storage from on-chain tokens. The interesting design question is always “which parts need to be on-chain and which parts are fine off-chain”, and the answer depends on what properties matter for the specific use case.
What This Means for Users
When someone tells you a thing is “on-chain” as a security argument, the useful follow-up is: which parts exactly? A protocol can have on-chain contract logic and still depend on off-chain data (oracles, admin keys, upgradeable proxies) for its actual operation. A wallet service can hold funds in a smart contract but run a centralised frontend that could be compromised. A bridge can post messages on-chain but rely on off-chain validators who could collude. Understanding where the on-chain boundary actually is — and therefore where the trust dependencies lie — is one of the basic skills for evaluating any crypto product.