On-Chain Settlement

Internet of Things · Network · Communication · Solutions

Definition

On-Chain Settlement (On-Chain Settlement) refers to payment, clearing, and revenue sharing completed through blockchain smart contracts. Unlike traditional centralized clearing, on-chain settlement writes the settlement logic into on-chain smart contracts, enabling automatic, transparent, and tamper-proof fund transfers among multiple parties. It applies to scenarios requiring multi-party reconciliation and trust, such as cross-border charging roaming, energy trading, revenue sharing, and supply chain finance. On-chain settlement is often combined with off-chain netting, where high-frequency reconciliation is completed off-chain and final settlement is done on-chain.

Technical Features and Architecture

Technical features of on-chain settlement include: Automatic Execution — smart contracts automatically trigger settlement according to preset rules; Transparent and Auditable — all settlement records can be checked on-chain; Reduced Intermediaries — lowers costs of correspondent banks and SWIFT for cross-border settlement; Multi-Party Collaboration — supports revenue sharing among multiple roles such as CPOs, eMSPs, and aggregators. Typical architecture includes: off-chain reconciliation and CDR aggregation, on-chain smart contracts (settlement rules, revenue sharing ratios), and stablecoin or fiat currency channels. Cross-border scenarios need to consider exchange rates, compliance (such as cross-border fund regulation), and Gas cost optimization.

Application in IoT and cross-border scenarios

The application of on-chain settlement in IoT and cross-border scenarios includes: Charging Roaming——between CPOs and eMSPs of cross-border charging stations and EV charging stations, on-chain settlement and revenue sharing based on OCPI CDR; Energy Trading——on-chain settlement of microgrids and green electricity P2P transactions; Logistics and Supply Chain——on-chain payment for cross-border logistics tracking and supply chain finance; IoT Device Billing——on-chain multi-party accounting for data pool sharing and other scenarios. SimtoLink provides one card, multiple countries connectivity for EV charging stations, logistics equipment, etc., ensuring stable cross-border transmission of CDR and settlement data.

Transfers an On-Chain Settlement Contract Actually Constrains

On-chain settlement hands an amount that has already been calculated to a contract for transfer. It does not calculate the charging session or the logistics track again. What the contract can enforce is only the participants, shares, currency, amount, and credential digest written into it. Voltage reported by a charger, a vehicle identifier, and road temperature are outside the contract's judgment unless they have first been reduced to a digest both sides accept. The IoT side therefore prepares the closed detail record or the netting result. The settlement side then pays the net amount, under the contract, to the operator, the e-mobility provider, or the site owner.

A transfer that can be executed has to answer four questions: which address or account the money leaves, in what proportion it is split and to whom, which batch of credentials it cites, and whether the dispute period for those credentials has ended. If the proportion lives in an off-chain table and the contract receives only a total, any party can claim the table was changed. Pass the proportion and the credential digest in together, and the amount can be recomputed later. In a cross-border case the currency or the anchored asset must also be written down. Do not agree the conversion verbally after the contract has already summed the amounts.

Credentials That May Enter Final Settlement

A credential may enter final settlement when the session or billing period is closed, the catch-up and appeal window has ended, the participants agree on the net amount and the digest, and the confirmation rule for the on-chain asset is accepted by all parties. The rule should state how many following blocks are required, or the finality standard that chain uses. Who pays gas or the transaction fee should also be in the business agreement. Otherwise the amount received is smaller than the contract amount and looks like a short payment. If one country requires extra review before funds leave, a batch whose review is unfinished should stay off-chain. Do not push an amount that is not yet permitted into the contract just to get it on-chain first.

Exchange Rate, Confirmations, and Split Ratios

Mistakes tend to cluster in a few places. The page rate at the moment the transaction is submitted is used instead of the rate agreed for the batch. The status is shown as settled while the transaction is still in the mempool. The split ratio exists only in the operations console, and the contract pays equal shares. A charging session that is not yet closed is settled early, and a later energy correction cannot be recovered. Another problem is to treat a device signature as authorization to move funds. If the device key leaks, the contract still executes. Fund authorization should come from the account that is allowed to dispose of the asset. The device signature only proves where the reading came from. The settlement page should separate three states: credentials aligned, transaction broadcast, and confirmation count met. Do not let one of them stand in for the other two.

Contract events must match the off-chain batch number. A list exported for finance should include the transaction hash, the confirmation count, and the batch number of that net amount. A balance change in a wallet cannot say which week and which charging batch the money belongs to. A change of split address needs its own approval. It cannot be tucked into the memo of an ordinary settlement transaction. If one participant's address is temporarily unavailable, the whole batch should stay untransferred. Do not pay the part that can be paid and leave the rest as a verbal remainder. Once that remainder leaves the contract, later collection no longer has an automatic basis. Two consecutive payments to the same address must be distinguished by batch number. While the confirmation count is short, show the amount as in flight, not as received.

Which party the fee is deducted from should be written in the batch note. Check the gap between the amount received and the contract amount against that note. Do not book it directly as a short-payment dispute. If a participant's address is not ready, keep the whole batch untransferred, so a partial payment does not leave the remaining execution without a basis inside the contract.


Related Terms

Return to International IoT SIM Card Glossary