Off-Chain

Internet of Things · Network · Communication · Solutions

Definition

Off-Chain refers to transactions, data storage, and computation conducted outside the blockchain main chain. Off-chain solutions execute high-frequency, high-capacity, or privacy-sensitive operations off the chain, only anchoring the key results or hashes on-chain, thereby improving throughput, reducing gas costs, and protecting privacy. Complementing the immutable and decentralized features of on-chain operations, off-chain is commonly used in payment channels, state channels, sidechains, and preprocessing before data is put on-chain.

Technical Features and Architecture

Characteristics of off-chain technology include: High Performance — not limited by the main chain TPS, supporting massive data collection and real-time settlement; Low Cost — reducing the number of on-chain transactions and lowering on-chain fees for cross-border settlement; Privacy Protection — sensitive data can be kept off-chain, only proofs are put on-chain; Scalability — achieved through Layer 2, sidechains, state channels, etc. Typical architectures include: off-chain databases or data synchronization layers, off-chain computing engines, and anchoring and verification mechanisms with the main chain. In cross-border scenarios, off-chain can handle intermediate settlements across multiple countries and currencies, with batch anchoring performed when final on-chain settlement occurs.

Application in IoT and cross-border scenarios

The off-chain applications in the Internet of Things (IoT) and cross-border scenarios include: IoT data — massive data collection and logistics tracking data are stored and processed off-chain, with only key traceability hashes recorded on-chain ; cross-border payments and settlement — off-chain multilateral netting and reconciliation are completed, with final on-chain settlement periodically carried out on-chain; charging and energy — real-time billing for charging management is done off-chain and, after combining with metering data, is batch recorded on-chain for evidence; supply chain and traceability — traceability records detailed circulation off-chain, anchoring key nodes on-chain. SimtoLink provides stable cross-border connectivity for IoT solutions that coordinate off-chain and on-chain.

Where Off-Chain Data Stays in Cross-Border IoT

Off-chain means meter streams, location points, session progress, and multilateral netting are handled outside the main chain first. Charge-detail records, temperature and humidity samples from a logistics node, and meter curve data are large and can identify a person. Putting them on the main chain is expensive, and they are hard to correct in time. The off-chain system keeps the original readings, checks them, and forms the net amount. The chain receives only the result hash that the parties have already accepted, the net amount, and the participant identifiers. Everyday queries then stay off-chain, and dispute review stays off-chain. The main chain only proves that the parties acknowledged this result at the time.

The retention boundary has to be written in advance. High-frequency samples, sessions that are not yet closed, line items that identify a person or a vehicle, and amounts still inside the dispute window may stay off-chain. What must leave the off-chain store and be anchored is the net amount after both sides have confirmed it, the hash of the split ratio, and the anchor time. The anchor time should be later than the moment the dispute window closes. If the result is anchored while the window is still open, a late catch-up reading or a corrected energy total cannot change the on-chain result, while the off-chain figure has already changed. The two sides then stay inconsistent.

Anchor Cadence and the Dispute Window

Off-chain handling is appropriate when original vouchers are kept for at least as long as the dispute window, each anchor batch has a stable batch number, every participant can recompute the hash from the original vouchers with the same algorithm, and the off-chain clock can be compared with the business time zone. Cross-border netting also has to name which exchange-rate time on which day is used. That time can sit in the off-chain batch note, and the hash of the note is what gets anchored. A hash that cannot be recomputed is only a string of characters. It cannot settle a dispute over energy or money.

The Hash Is Present and the Original Is Not

A common mistake is to delete the line items as soon as the hash is anchored. If the other party questions the reading of one vehicle or one meter, the off-chain store can no longer rebuild it, and the chain has no line items. Another is to treat a commit in the off-chain database as final and ignore confirmation depth on the main chain, so the page shows the net amount as settled while the anchor transaction is still in the mempool. A third is that details from several countries are hashed with different field orders, and the algorithm note was never written into the batch. Each party then computes a different digest and still believes it matches the chain. Keep the original vouchers until the dispute period ends, write the hash algorithm and field order into the batch note, and mark the off-chain state clearly as pending anchor or anchor confirmed.

The batch note should also name the participants, time zone, currency, and the net-amount basis, such as how energy is rounded and whether tax is already included. The note may stay off-chain, but its digest should be anchored together with the result digest. If only the amount is anchored and the basis is not, the other party recomputes with a different rounding rule, the hashes differ, and the dispute has no shared source document. If a batch crosses a daylight-saving change, write the day boundary by the calendar of the meter or the site, not by midnight in Coordinated Universal Time in place of the local business day. When a catch-up reading arrives, create a new batch instead of rewriting a batch that is already anchored. Material exported for audit should include both where the line items are stored and the height of the anchor. A manual correction keeps the value before, the value after, and the operator.

Pending anchor and confirmed should not share one export action. An unconfirmed net amount cannot enter the payment flow. When audit samples a batch, the batch number should retrieve both the line-item location and the anchor height together.


Related Terms

Return to International IoT SIM Card Glossary