/

The Onchain Financial Stack: Settlement, Execution, and Application Layers

WEEKLY DIGEST

SENTORA LEARN

The Onchain Financial Stack: Settlement, Execution, and Application Layers

The Onchain Financial Stack: Settlement, Execution, and Application Layers

A position held in an onchain market carries exposure across four distinct layers, each of which offers a different guarantee and fails in a different way. Separating them is what allows a risk function to assign an internal owner to every exposure before capital is committed.

A position held in an onchain market carries exposure across four distinct layers, each of which offers a different guarantee and fails in a different way. Separating them is what allows a risk function to assign an internal owner to every exposure before capital is committed.

Sentora Research

Sentora Research

Ethereum mainnet makes a transaction irreversible in roughly thirteen minutes. Moving the same funds off a rollup and back to mainnet conventionally takes seven days. Both numbers describe the same position, they differ by a factor of about 800, and they come from different layers of the same infrastructure. A liquidity plan built on the first number and settled against the second is the ordinary way an institution discovers that an onchain position has more than one owner.

That division into layers resembles the separation between clearing, execution and product manufacture in a traditional market: a structured note distributed by a bank depends on the issuer that wrote it, the venue where its hedge trades, and the central securities depository that records who owns it. A failure at the depository stops the note from working while leaving the note itself intact. 

Onchain markets divide along similar lines, namely settlement, execution, and application; with one material difference: these layers are technically composable, so a single transaction can touch all of them at once and either complete in full or revert in full.

The lowest of those layers is the settlement layer, the network whose validators agree the ordering of state changes and the point at which those changes become irreversible. Every layer above it inherits those guarantees and adds assumptions of its own. Locating a risk correctly means identifying which layer introduced it.

Figure 1. What each layer guarantees and what it leaves open. Every layer inherits the guarantees beneath it and adds assumptions of its own.

What the Settlement Layer Guarantees

The settlement layer provides an ordered record of state changes and a point after which reversing one becomes economically impractical. It guarantees that a transfer recorded in a finalised block happened, that it happened before or after any other transfer, and that no participant can unilaterally undo it.

Those guarantees are the full extent of what the layer offers. Solvency of the counterparty, accuracy of the price used to value the collateral, and the commercial merit of the transaction all sit outside its scope, because the layer has no view on the substance of what it records. Institutions accustomed to a central counterparty that performs novation, netting and default management should treat the settlement layer as a registry and a clock, and should locate the risk-absorbing functions elsewhere in their own control framework.

Finality is the property that matters most for an operational team. Ethereum mainnet reaches economic finality after two epochs, which is roughly thirteen minutes under normal conditions, and networks using other consensus designs finalise faster or slower. Because finality is a gradient, the confirmation threshold becomes a decision the institution makes and documents, and the number of confirmations required before a customer balance is credited is a control the payments and reconciliation functions own.

The Execution Environment Determines Who Orders Your Transaction

Cost drives most activity that a fintech would touch off the base settlement network entirely. Ethereum mainnet now functions predominantly as a settlement and data availability layer, with execution occurring on rollups that batch transactions and post the results back to it. The arrangement lowers cost by one to two orders of magnitude and introduces a set of dependencies that the base layer does not carry.

A rollup relies on a sequencer to order incoming transactions. Where a single entity operates that sequencer, which is the common case, the institution has acquired a counterparty with the ability to delay or censor a transaction while remaining unable to steal from it. Rollups publish escape mechanisms that allow a transaction to be forced through the base layer when the sequencer becomes unavailable, and the latency of those mechanisms is measured in hours.

Withdrawal timing is the second dependency, and it differs by proof system. An optimistic rollup assumes a batch is valid and allows a challenge window, conventionally seven days, before a withdrawal to the settlement layer completes. A validity rollup, commonly described as a zero-knowledge rollup, proves correctness cryptographically and settles withdrawals as soon as the proof is accepted. 

Figure 2. Withdrawal timing by proof system. A liquidity plan assuming same-day repatriation from an optimistic rollup is built on the wrong number.

The Application Layer Holds the Capital and Writes the Rules

The contracts at the application layer are where the commercial arrangement lives, and they are what a product presentation usually describes. 

  • A credit market contract holds deposits, records debt, computes the interest rate from utilisation, and defines the conditions under which a third party can close a position. 

  • An exchange contract holds inventory and prices trades against it. 

  • A share-accounting contract issues a claim on a pool of underlying assets and computes the exchange rate at which that claim redeems.

Two properties of this layer deserve separate attention from a risk reviewer. 

  • The first is code-execution risk, meaning the possibility that the contract contains a defect or an unintended interaction that a counterparty can exploit. 

  • The second is discretion, meaning the set of parameters that a governance process or a named administrator can change after capital has been committed. 

An immutable contract carries the first exposure on its own. An upgradeable contract carries both, and the identity of the parties holding the upgrade rights becomes a counterparty question with a technical surface.

Application contracts also consume inputs they do not produce. Almost every credit position depends on an external price feed to value its collateral, and that feed is a distinct dependency with its own failure mode. Counting the price source as part of the venue understates the number of parties the position relies on.

The Access Layer Is the Part the Institution Owns

The settlement, execution, and application layers are shared infrastructure that the institution uses without controlling. On top of them, there is a fourth layer the institution builds, staffs and is examined on: the access layer, which includes the custody arrangement holding the keys, the signing policy governing which transactions can be submitted, the address screening applied to inbound and outbound transfers, the monitoring that detects a parameter change, and the reconciliation that ties onchain balances back to the internal ledger.

Most operational losses at regulated firms originate in this layer, which is also the only layer where the institution's own controls reach. A custody model that satisfies a client asset requirement, a quorum signing policy that prevents a single operator from moving funds, and an approved venue list maintained through a described due-diligence process are all access-layer controls. Each of them governs how the institution's people and systems interact with the market. A defect inside an application contract sits beyond their reach, which is why custody quality and code quality have to be assessed as separate questions.

Figure 3. Where the institution's own controls reach. Custody quality and code quality are separate questions and need separate evidence.

Mapping the Layers to Owners and Failure Modes

Layer

What it guarantees

What it leaves open

Typical internal owner

Characteristic failure

Settlement

Ordering of state changes, and irreversibility after finality

Solvency, valuation and commercial suitability of anything recorded

Treasury and operations, through confirmation policy

Reorganisation before finality; extended finality delay under network stress

Execution

Low-cost inclusion and fast confirmation within the rollup

Timely withdrawal to the settlement layer; freedom from sequencer censorship

Treasury and liquidity management

Sequencer outage or censorship; withdrawal delay of up to seven days on an optimistic rollup

Application

That the contract behaves as its code specifies

Whether the code specifies the right thing, and whether parameters hold

Risk, through venue diligence

Code-execution defect; adverse parameter change; failure of a consumed price feed

Access

Whatever the institution's own controls provide

Everything occurring in the three layers below it

Operations, compliance and technology

Key compromise; unauthorised signing; reconciliation break

Figure 4. Layer responsibility map. Internal owners are indicative and should be reassigned to match the firm's own three lines of defence structure.

Settling Ownership One Layer at a Time

The layer map earns its place by breaking one unanswerable problem into four tractable ones. Each layer resolves to a single fact that has to be established and recorded, and each of those facts has a recognisable shape once it is complete.

Layer

The fact to establish

What a complete entry contains

Settlement

Which network finalises the position, and the confirmation threshold applied before a customer is credited

A named network, an expected time to finality, and a confirmation threshold the payments function has written down and can defend

Execution

Who operates the sequencer, and what becomes of the funds if it stops producing blocks

A named operator, a documented escape procedure with its latency in hours, and a withdrawal window measured against the liquidity plan

Application

Whether the contract is immutable, and where it is not, who holds the rights to change it

Either immutability, or named key holders with a stated timelock. An unnamed upgrade authority is an unpriced counterparty

Access

The internal owner of custody, signing, screening, monitoring and reconciliation

A named owner per control, each of whom has read the exposure sitting in the layer beneath theirs

Figure 5. The ownership test, one line per layer. A line nobody inside the firm can complete is itself a finding.

Two conditions break the map even when all four answers arrive. 

  1. Composability, because a single transaction can deposit into one venue, post the resulting claim token as collateral in a second, and wrap the whole position in a third, at which point a defect in the innermost venue reaches every claim above it and the layers stop being separable. 

  2. Shared inputs, because two venues on two different rollups can consume the same price feed, hold the same tokenized cash instrument as their reserve, or route withdrawals through the same bridge, so spreading capital across execution environments protects against a sequencer failure while leaving a common input entirely concentrated. Positions exposed to either need a dependency map alongside the layer map.

There is also a limit worth stating to whoever signs the paper: custody arrangements and signing policy govern how funds move under the institution's own authority, and a loss originating inside an application contract happens on the far side of that boundary. Offering custody controls as the answer to code-execution risk is the most common category error in a first internal approval paper, and it survives because both sound like security.


Understanding where a position sits in the stack is the first step in governing it. Sentora's platform provides the deployment, monitoring and reporting infrastructure that regulated institutions use to operate across these layers.