> **Source:** https://permissionless.fi/en/28-exchange-architecture
> From *Permissionless Finance* (Permissionless Finance: From Perpetual Futures to the On-Chain Global Market) by Eric Cheung. Licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

# Chapter 28: From the Monolithic Black Box to Layered Architecture

In November 2022, FTX—one of the top three cryptocurrency exchanges by global trading volume—collapsed within days, revealing a gap of more than $8 billion between customer assets and corporate liabilities [1]. The bankruptcy investigation exposed a central engineering fact: the platform had never technically segregated customer assets from corporate assets, and all funds were commingled in a wallet system that lacked cryptographic access controls [2][3]. The affiliated trading firm Alameda Research received a secret exemption from the automated liquidation system, and before the system collapsed, no publicly available method allowed outside observers to detect these violations [4]. This event was not an isolated case; rather, it laid bare a structural flaw in the architectural design of centralized exchanges.

This flaw can be defined as the monolithic black box architecture. In a traditional centralized exchange, the core functions of the trading system—including the matching engine, the clearing and settlement system, asset custody, the market-making system, and the risk-control system—are all integrated and run within a single opaque server cluster controlled by one entity: the exchange itself. The data that users see in the front-end interface and through the API are merely the selective output of this black box. Inside the box, users have no way whatsoever to verify whether assets are being kept safe, whether orders are matched honestly according to price-time priority, or whether liquidation parameters are being secretly altered to trigger improper liquidations.

When we apply the lens of systems engineering to this architecture, the lesson of FTX is no longer merely an isolated case of *one management team's moral failure*; it is a textbook instance of systemic architectural failure. The monolithic black box architecture concentrates all of a system's operating trust assumptions in a single entity, thereby creating an enormous single point of trust failure across the entire financial ecosystem. In distributed-systems theory, the failures of different components are typically independent of one another. In a monolithic trust architecture, however, because all functions share the same root of trust, once that root becomes corrupted or collapses, the propagation of failure is total and instantaneous. The system moves directly from a state of seemingly flawless operation into one of complete collapse, with no intervening buffer or graceful degradation.

This brings us to the central question of this chapter: starting from the first principles of engineering, can we design a fundamentally different architecture for a trading system? Such an architecture must preserve the performance advantages of centralized exchanges (low latency and deep liquidity) while decomposing the *monolithic black box* into multiple independent and verifiable modules, minimizing the trust dependency at each one. Its core objective is to build a highly resilient system in which, even if the operating entity of one module suffers a moral hazard or a technical failure, the core functions of the whole system and the safety of user assets remain protected by cryptography and consensus mechanisms.

Solving this problem is not a simple binary choice between a centralized exchange (CEX) and a decentralized exchange (DEX). The analyses in the preceding nine parts have repeatedly exposed a central tension: centralized exchanges deliver the best trading performance but require users to bear extremely high trust risk, whereas early decentralized exchanges eliminated trust risk through fully on-chain execution yet were constrained by the physical limits of blockchains and could not meet the microsecond latency and high throughput that professional trading demands. We therefore need an engineering solution that strikes an optimal balance between *trust minimization* and *performance maximization*. This search is not without precedent. Over several centuries, and through repeated crisis-driven reform, traditional finance gradually built a layered trust architecture that separates matching, clearing, custody, and regulation. The establishment of institutions such as the central counterparty (CCP) and the DTCC was, in essence, a decomposition of the early monolithic financial black box [5]. The cryptocurrency market, however, is attempting to achieve this goal through technical code rather than regulatory agencies. A new generation of infrastructure, exemplified by application-specific blockchains (app-chains) such as Hyperliquid, is demonstrating the feasibility of this migration from monolithic to layered design [6]. Through customized consensus mechanisms and specially optimized state machines, these systems are attempting to find a new and efficient frontier between performance and trust.

This chapter serves as the overall blueprint for building a trustless financial system (Figure 28-1), guiding the reader from the perspective of an analyst to that of a systems architect. It first uses the trust stack to dissect the implicit trust embedded in the life cycle of a single trade; it then traces, along the *trust-performance frontier*, the migration path from the monolithic black box to a layered, transparent architecture; it proceeds to conduct an architectural audit of representative protocols such as Hyperliquid; and it finally distills these into an engineering framework for judging *sufficient decentralization*.

![Figure 28-1](./images/fig-28-1-en.png)

**Figure 28-1.** A comparison of the monolithic black box architecture and the layered architecture (conceptual schematic: on the left, a centralized exchange fuses five functions—asset custody, matching and execution, clearing and settlement, data oracles, and governance—into an opaque black box controlled by a single entity, with trust concentration reaching 100%, so that once the single root of trust is corrupted, failure propagates completely and instantaneously; on the right, the layered architecture decomposes the same five functions into mutually independent, separately verifiable trust layers, running from the asset-custody layer at the bottom to the governance layer at the top, with each layer optimized independently along the trust-performance frontier and isolated from the others by trust boundaries, lowering trust concentration to 20% or even close to 0)

## 28.1 A trust anatomy of the CEX monolithic black box

Before discussing how to build a trustless financial system, we must first identify precisely what the current system requires users to trust. When we say that centralized exchanges carry structural risk, that risk is not an abstract notion; it is embedded deep in their architectural design. In using a centralized exchange, a user makes at least five implicit trust assumptions over the life cycle of every trade. Most users are entirely unaware of them—until a crisis erupts and these implicit assumptions are systematically violated.

### 28.1.1 The five trust assumptions in a trade's life cycle

When a user opens a long position in Bitcoin perpetual futures on a centralized exchange, that user traverses a long and fragile chain of trust. Each step in this chain is an implicit trust assumption. This example is not a hypothetical thought experiment but a routine operation that millions of traders repeat every day. Every click of the trade button, every entry of an order quantity, means that the user is entrusting the safety of their funds and the fairness of their trades to a centralized, opaque system.

The first is trust in the asset-custody layer. The user deposits dollar stablecoins into the exchange, which marks the start of the entire trade life cycle. At that instant, the user must trust that the exchange will safeguard these funds. Such trust means believing that the exchange will not misappropriate customer assets for high-risk investments, will not lose the private keys through internal mismanagement, and will not invoke various pretexts to refuse a withdrawal when the user requests one. This assumption is the foundation for all subsequent trading, yet it rests entirely on the exchange's reputation and the moral commitments of its management.

The second is trust in the matching and execution layer. When a user places a limit buy order, they must trust that the exchange's matching engine will execute the order honestly according to price priority and time priority. Although users can obtain some order-book data through the API, they cannot verify the completeness or authenticity of that data, and the exchange is fully capable of hiding internal orders or fabricating liquidity in the API output. Users must therefore trust that the exchange will not let its proprietary market-making desk exploit an informational advantage to jump the queue, will not deliberately delay their orders to capture front-running profits, and will not, under extreme market conditions, prevent them from closing positions by severing their connection.

The third is trust in the clearing and settlement layer. Once each trade is executed, account state is taken over by this layer, which performs two kinds of continuously recurring work: clearing (reckoning the books) and settlement (posting the transfers). Clearing translates a *trade event* into a *change in account state*: it recomputes long and short positions, realized and unrealized profit and loss (P&L), and margin utilization, and it nets the multiple trades of a single account. Settlement is the actual transfer of value, including continuous mark-to-market against the mark price, the periodic funding payments unique to perpetual futures, and the booking of P&L at position closure. In both of these processes, the user must trust the exchange to keep the books and move the funds honestly—neither tampering with the account records nor distorting the mark-to-market and the funding rate. The fairness and transparency of the mark price are the shared benchmark of this layer: it drives both the routine mark-to-market settlement and the determination of whether margin is sufficient. Users must therefore be especially confident that the exchange will not manipulate the mark price in order to trigger liquidations that should not occur, will not abuse the auto-deleveraging (ADL) mechanism when a bankruptcy event arises, and that its declared insurance fund genuinely exists and is properly managed. Liquidation and auto-deleveraging are merely this layer's default-handling tools when an account becomes insolvent, not the whole of its function (the strict distinction among clearing, settlement, and liquidation is developed systematically in Section 28.4.3).

The fourth is trust in data authenticity. The prices, depth, trading volumes, and other data that users see on the exchange's front end are their sole basis for making trading decisions. Users must trust that these data are genuine rather than fabricated. This means believing that trading volume has not been artificially inflated by wash trading, that the order book is not flooded with ghost liquidity, and that market depth reflects genuine buying and selling intent rather than numbers invented by the exchange to manufacture an illusion of prosperity.

The last is trust in governance fairness. The exchange holds the unilateral power to change the rules. If the exchange revises its fee formula, adjusts liquidation parameters, or alters its market-maker agreements, users must trust that these changes serve the overall interest of the market rather than the exchange's private gain. At the same time, users must trust that such rule changes will be disclosed to all market participants promptly and publicly, rather than made in secret.

These five trust assumptions form the foundation on which a centralized exchange operates. The core engineering insight, however, is this: the violation of any one of the five can inflict irrecoverable losses on users. More critically, in most cases users have no way at all to verify whether these trusts are being honored. Before a collapse, no publicly available method can detect that assets have been misappropriated. From the standpoint of behavioral finance, the way users form trust in a centralized platform is often shaped by cognitive biases: the availability heuristic leads users to substitute a platform's past record of normal operation for a rational assessment of its architectural security, while the herding effect leads large numbers of users to abandon independent judgment in response to the social signal that *everyone else is using it*. These cognitive limitations imply that the value of a layered architecture lies not only in providing verifiability for rational users, but also in protecting—through the architecture itself—those users who are cognitively unable to assess trust risk correctly. This unverifiable trust is precisely the root of systemic risk.

### 28.1.2 The trust stack model

To analyze the trust assumptions in a trading system more systematically, we propose the *trust stack* method of analysis. This method decomposes the trust assumptions of a trading system into five layers, from asset custody at the very bottom to the governance mechanism at the top. This layered model applies not only to centralized exchanges but equally to decentralized exchanges and to various hybrid architectures.

At the very bottom of the trust stack is the asset-custody layer, whose core question is whether assets are safe; the consequences of its trust failure are the most severe—assets are directly misappropriated or lost—and in a centralized exchange it depends entirely on the exchange's internal management and moral restraint. The second layer up is the matching and execution layer, which concerns whether orders are matched honestly; its trust failures manifest as front-running, queue-jumping execution, and price manipulation. Because the matching engine runs on private servers, outsiders cannot verify the fairness of order matching and can only accept the final execution results the exchange provides. The third layer is the clearing and settlement layer, responsible for post-trade clearing and settlement and for using liquidation as default handling when an account is insolvent (the distinction among the three is detailed in Section 28.1.1). When its trust is broken, the consequences include both the covert distortion of the books and settlement and unfair liquidations and abuse of auto-deleveraging; yet the clearing-and-settlement conventions and liquidation parameters are often treated as trade secrets that users cannot review. The fourth layer is the data and oracle layer, responsible for the authenticity of prices and market data; when its trust fails, the market is flooded with fake volume and price manipulation, and the exchange, as the sole data provider, holds a complete informational monopoly. The top layer is the governance layer, which determines how rules are set and changed; its trust failures manifest as covertly changing the rules for profit. In a centralized exchange, this governance is usually implicit, with the power to interpret and amend the rules held entirely by management.

Table 28-1 summarizes the core question, the consequences of trust failure, and the verification difficulty at each of the five layers. The *verification difficulty* column reveals a consistent pattern: from the bottom layer to the top, verification difficulty is generally high, which means that under the current centralized architecture users lack effective external means of verification at nearly every layer.

| Layer | Core question | Consequences of trust failure | Verification difficulty |
| :--- | :--- | :--- | :--- |
| Layer 5: governance layer | How are rules set and changed? | Covertly changing rules for profit | Very high (usually black-box decisions) |
| Layer 4: data layer | Are prices and data genuine? | Fake volume / price manipulation | High (requires complex data forensics) |
| Layer 3: clearing and settlement layer | Are clearing (reckoning) and settlement (posting) executed per the rules? | Distorted books / unfair liquidation / ADL abuse | High (internal algorithms undisclosed) |
| Layer 2: matching layer | Are orders matched honestly? | Front-running / queue-jumping / order delay | Very high (full order flow unobtainable) |
| Layer 1: custody layer | Are assets safe? | Assets misappropriated or lost | Very high (no on-chain verifiable reserves) |

**Table 28-1.** The five-layer trust stack model with its consequences of trust failure and verification difficulty (Data source: compiled by the author)

The analytical value of the trust stack is that it lets us ask three key questions about any trading system at each layer. First, who is being trusted—a particular entity, a piece of code, or a validator set? Second, can this trust be verified—does the user have any means of checking whether the trust is being honored? Third, can this trust be replaced—is there a technical mechanism that can eliminate the dependence on this particular entity? Through this structured questioning, we no longer reduce the problem of trust to a binary opposition between centralized and decentralized; instead, we turn it into a precise problem of engineering design.

The core strength of the trust stack model is that it offers a unified template for comparative analysis across different trading systems. The trust stack of a traditional financial centralized exchange, for example, is entirely different from that of a generalized automated market maker (AMM). Likewise, the trust stack of a perpetual futures exchange on an app-chain differs from that of a centralized exchange. This layered perspective lets us move beyond a simple binary account and into the details of system architecture.

The layers of the trust stack fail in different ways. The asset-custody layer is the most fundamental, and its failure is irreparable because the assets cannot be recovered. A failure in the matching and execution layer may amount only to a poorly executed trade and causes no permanent loss of assets. A failure in the clearing and settlement layer may distort the books or lead to unfair liquidations, but as long as the clearing, settlement, and liquidation rules are transparent, users can at least appeal. A failure in the data layer may lead to poor decisions, yet once the data are published on chain they remain externally verifiable. A failure in the governance layer is the most insidious: rule changes can be hidden temporarily, until a crisis brings them to light.

In addition, the layered design provides a framework for understanding why different exchanges choose different trust-minimization strategies: centralized exchanges and app-chain exchanges often make opposite trust trade-offs at the custody layer and the matching and execution layer (see the trust-stack audit in Section 28.5), and system designers choose the optimal architecture accordingly, adapting to their specific circumstances.

### 28.1.3 FTX's extreme failure mode

The true value of the trust stack model is that it is not merely a theoretical framework but an analytical tool that helps us understand the real risks that exist in practice. When we revisit an actual historical event, the model's usefulness becomes especially clear.

When FTX collapsed in November 2022, a gap of more than $8 billion opened between customer assets and corporate liabilities, and at the moment of collapse the firm could not honor redemptions on demand [1]. The subsequent bankruptcy investigation and court filings revealed a grave engineering fact: the platform had never technically segregated customer assets from corporate assets [7]. All assets were commingled in a single wallet system, and no code-level access control or multi-signature mechanism existed to prevent management from drawing on customer funds at will [8]. The only safeguard was management's verbal promise and the users' one-sided trust.

This is precisely the extreme instance of the monolithic black box architecture defined at the opening of this chapter: all functional modules are concentrated in an opaque cluster controlled by a single entity, and the account balance a user sees on the front end is merely a number in a database, backed by no cryptographic proof. Whether assets were transferred to an affiliated market maker, whether orders were matched honestly, and whether liquidation parameters were secretly altered to protect internal accounts—users could neither know nor, still less, verify.

The core defect of the monolithic black box architecture lies in its correlation trap. In a well-designed distributed system, the failures of different components are expected by design to be independent of one another. Yet even in a carefully designed distributed system, common-mode failure—the simultaneous failure of multiple components triggered by a shared software dependency, infrastructure provider, or operational process—remains a systemic risk that is difficult to eliminate entirely. In a monolithic architecture, this problem is pushed to its extreme: all functional modules share the same root of trust. This means that once that root becomes corrupted or fails, the system faces not a partial degradation but the simultaneous collapse of all trust layers.

Examining this collapse through the trust stack model, we can see clearly the catastrophic consequences of the monolithic black box. At the custody layer, customer funds were directly misappropriated to cover the trading losses of an affiliated firm. At the matching layer and the clearing and settlement layer, internal accounts were granted special privileges that allowed them to bypass the ordinary risk controls and liquidation mechanisms. At the governance layer, the setting and enforcement of rules served the interests of the controlling party entirely, rather than fairness to market participants. Not only were all five trust layers concentrated in the same entity, but that entity used its complete control to violate its implicit promises to users at every layer.

It was precisely to address this single-point-of-failure risk that the traditional financial system gradually developed an architecture of functional separation (see Section 28.3). In modern traditional finance, the exchange handles only matching, the clearinghouse handles risk management and settlement, the custodian bank handles asset safekeeping, and the regulator oversees the rules. Each function is performed by an independent entity, which greatly reduces systemic risk. By recombining all of these functions into a single opaque entity, the cryptocurrency centralized exchange represents, in architectural terms, a severe regression. Academic research shows that this excessive concentration of trust forces centralized exchanges to hold capital reserves far larger than those of traditional financial institutions in order to withstand potential run risk—yet even so, it cannot fundamentally eliminate the possibility of insider malfeasance [9].

FTX's collapse was not an isolated event. In the years that followed, the industry found that other centralized exchanges in the cryptocurrency market suffered from similar architectural defects. Commingled assets, the absence of on-chain verifiable proof of reserves, and inadequate technical barriers against insider malfeasance are not the individual misfortunes of one platform but inherent defects of the monolithic black box architecture of centralized exchanges.

### 28.1.4 Trust concentration and systemic risk

To assess quantitatively the risk level of different trading-system architectures, we introduce trust concentration as an analytical metric. Trust concentration measures what fraction of the trust layers in a trading system are controlled by the same entity. Its basic definition is as follows: for the five layers of the trust stack, if $k$ of them are controlled by the same entity, that entity's trust concentration is $k/5$. When one entity controls all five layers, trust concentration reaches 100%; when the five layers are controlled by independent entities, the maximum trust concentration of any single entity is only 20%. This definition uses equal weighting—that is, it assumes the five layers carry the same risk weight. In practical assessment, one can introduce differentiated weights according to the severity of the consequences of each layer's trust failure; for example, because a custody-layer failure causes irreversible asset loss, its weight should exceed that of a data-layer failure, which merely biases trading decisions. A weighted trust concentration reflects the actual distribution of a system's fragility more precisely. One illustrative weighting scheme is as follows: custody layer 0.35 (asset loss is irreversible), clearing layer 0.25 (directly affects solvency), matching layer 0.20 (affects the fairness of trading), data layer 0.12 (indirectly affects decision quality), and governance layer 0.08 (affects the direction of rule evolution). Under this weighting, if an entity controls all five layers, the weighted trust concentration is still 100%; but the partial de-trusting of different layers produces differentiated reductions in concentration.

In a typical centralized exchange, all five trust layers are controlled by the same operating entity. Its trust concentration therefore reaches 100%. Such extremely high trust concentration implies extremely high systemic risk. Should the controlling entity's internal controls fail, or should its management act in bad faith, the entire system fails rapidly. No external check exists that could sound a warning or intervene before the crisis strikes.

By contrast, the separated architecture of the traditional financial system substantially lowers trust concentration through institutional design. If the five trust layers are the responsibility of an independent exchange, a central counterparty clearinghouse, a custodian bank, a data provider, and a regulator, respectively, then each entity's trust concentration is only 20%. Although users must still trust these centralized institutions, the trust is dispersed. The failure of one entity does not necessarily lead to the collapse of the others, and the entities have an incentive to monitor one another.

An ideal decentralized architecture pursues a trust concentration close to 0%. In such an architecture, no layer depends on the moral commitment of any single entity; each is instead controlled by open-source code, a consensus algorithm, or a decentralized validator set. Assets are held in custody by smart contracts, the matching and clearing logic executes publicly on the blockchain and is verified by the whole network, data are supplied by a decentralized oracle network, and governance is carried out through on-chain voting by token holders.

Trust concentration is not only a security metric; it also bears directly on the fairness and resilience of the market. The higher the concentration, the greater the room for the controlling party to engage in rent-seeking by exploiting its informational privilege and rule-making power, and the worse the market's fairness. At the same time, high concentration means the system carries a severe single-point-of-failure risk and lacks resilience in the face of internal corruption or external attack. Lowering trust concentration—decomposing the monolithic black box into a layered, transparent architecture—is therefore an engineering necessity for building a resilient on-chain financial system.

Measuring trust concentration provides an objective framework for assessing the relative margin of safety of different trading systems. If an emerging trading platform, by placing its custody layer in an on-chain smart contract and delegating its clearing layer to an independent app-chain, achieves a trust concentration markedly lower than that of a competitor that concentrates all functions in a single entity, then that platform holds a structural advantage along the systemic-risk dimension. This improvement in the margin of safety does not translate directly into an improvement in user experience (which also depends on factors such as latency, liquidity depth, and interface design), but it lowers the probability that users suffer catastrophic losses under extreme market conditions.

Trust concentration also explains the relationship between regulatory pressure and architectural choice. An exchange with higher trust concentration, lacking any architectural technical constraint on insider malfeasance, must compensate for its deficient architectural trust through stricter external regulatory scrutiny and more frequent proof of reserves. This is, in essence, a substitution mechanism that offsets an architectural defect with institutional cost.

## 28.2 The trust-performance frontier

Given that the centralized architecture carries such a severe single-point-of-failure risk, why not simply migrate every stage of trading onto the blockchain? If smart contracts could execute predetermined logic flawlessly and cryptographic proofs could eliminate the dependence on a single entity, building a *fully on-chain*, trustless trading system would seem to be the only ultimate solution. Reality, however, is otherwise: in the engineering practice of decentralized finance, a fundamental physical constraint stands between trust minimization and performance maximization. This trade-off does not stem from a temporary limit of current engineering capability; it is dictated by the inherent constraints of distributed-systems theory. Understanding this frontier between trust and performance is a prerequisite for designing any robust on-chain financial architecture.

### 28.2.1 The performance cost of a fully on-chain architecture

Executing the matching, clearing, and settlement of every order on a blockchain network means that every trade's change of state must be confirmed by the consensus of the whole network's nodes or its validator set. Although such global verification achieves an extremely high degree of trust minimization, it exacts a significant performance cost, first evident in a sharp increase in system latency. The internal processing latency of a top centralized exchange's matching engine is typically in the microsecond range, but this figure is meaningful only for colocated users; for ordinary users connecting through a remote API, end-to-end latency typically ranges from 10 to 100 milliseconds, encompassing network transmission, authentication, and risk-control checks. Binance, for example, has continuously increased its matching engine's order-processing capacity from the 1.4 million orders per second published in its 2017 white paper [10], and the peak capacity of leading exchanges now reaches the order of millions per second. By contrast, even an app-chain designed specifically for high-performance trading tends to remain at the millisecond or sub-second level: through its customized HyperBFT consensus, Hyperliquid achieves a median end-to-end latency of about 200 milliseconds and a processing capacity of roughly 200,000 orders per second [11], still three orders of magnitude short of a centralized exchange's microsecond response. Since the Merge, the block time of the Ethereum mainnet has been fixed at about 12 seconds (proof of stake), with a throughput of only 15–30 transactions per second [12], wholly unable to meet the speed requirements of high-frequency trading.

Beyond the hard limits on latency and throughput, a fully on-chain architecture also entails significant economic costs. In a centralized exchange, matching against the internal order book is almost costless, and users pay only a very small percentage fee upon final execution. In a fully on-chain model, however, every placement, cancellation, or modification of an order consumes network resources and incurs a corresponding transaction fee. This mechanism not only greatly increases traders' friction costs but also severely constrains liquidity providers. In the discussion of the structural arbitrage residual in Chapter 18, the efficiency gap between centralized and decentralized exchanges is, in essence, the quantifiable manifestation of this *cost of trustlessness*.

More seriously, the complete transparency of a fully on-chain architecture, while it solves the trust problem, also introduces a new market-making dilemma. In a fully transparent on-chain environment, a market maker's order flow and capital movements are openly visible to all network participants, which makes them highly vulnerable to attacks based on maximal extractable value (MEV) [13]. To hedge this additional risk created by on-chain transparency, market makers are forced to adopt a series of defensive behaviors: widening the bid-ask spread, reducing quoted depth, increasing the frequency of quote flickering, and, in extreme cases, withdrawing liquidity entirely. In the end, this cost of trustlessness is passed on to all ordinary traders through multiple channels. Attempting to force every stage of trading onto the blockchain therefore not only struggles technically to meet the performance requirements of a professional market but also carries economic frictions that are difficult to overcome.

### 28.2.2 The systemic risk of a fully off-chain architecture

Given that a fully on-chain architecture faces such formidable performance and cost challenges, should we retreat to a fully off-chain, centralized model? The answer is no. The current centralized exchange is the very archetype of the fully off-chain model, and its extremely high performance rests entirely on an extreme concentration of trust: while users enjoy microsecond latency and cost-free cancellation, they are forced to entrust the full power over asset safekeeping, order matching, clearing execution, and rule-making to a single opaque entity.

The core defect of this fully off-chain black box architecture is that users have no technical means of verifying what actually happens inside the box. Even if a centralized exchange voluntarily chooses to improve transparency—by publishing proof of reserves periodically or disclosing some wallet addresses, for instance—such transparency still rests on a voluntary basis. The exchange can change its disclosure rules at any time, or even stop publishing key data on the eve of a crisis. Such non-architectural guarantees often prove worthless under extreme market conditions. The FTX collapse analyzed in Section 28.1.3 amply demonstrates that when one entity holds both control over assets and the power to interpret the rules, no internal risk-control mechanism or management promise can withstand the systemic default induced by the temptation of enormous gain.

Another latent hazard of the fully off-chain architecture is the high correlation of its failures: as analyzed in Section 28.1.3, all functional modules of the monolithic black box share the same root of trust, and once that root fails—through a hacking attack, internal misappropriation, or a regulatory freeze—the collapse is total and instantaneous, with no buffer between flawless operation and a complete standstill. To retreat to the fully off-chain black box merely because a fully on-chain architecture is not performant enough is therefore to trade a short-term expedient for long-term risk.

### 28.2.3 Characterizing the trust-performance frontier

Through the comparative analysis of fully on-chain and fully off-chain architectures, we can see clearly a fundamental trade-off in system design: trust minimization and performance maximization cannot both be achieved to the fullest along the same dimension. This trade-off can be described as a *trust-performance frontier*. If we place the degree of trust minimization (verification depth) on the horizontal axis and system performance (the reciprocal of latency, or throughput) on the vertical axis, then, under given technical conditions, all feasible architectural designs form a set whose Pareto frontier is the trust-performance frontier. Any architectural choice can find its footing only on or inside this frontier; it cannot surpass the frontier itself. In most engineering settings, this frontier curve is convex: when the number of validators is used as a proxy for verification depth, the communication overhead of Byzantine fault-tolerant (BFT) consensus tends to grow superlinearly as the validator set expands, so that the performance cost of deepening verification further from a high-trust region increases at the margin. Verification depth and the number of validators are not the same dimension: an app-chain with only about twenty validators still achieves greater trust minimization than a centralized exchange controlled by a single entity. Convexity is therefore a reasonable characterization of the frontier's shape rather than a strict theorem. This convexity is consistent with the layered strategy: provided that the trust requirements of the layers are heterogeneous and separable, rather than pushing the whole system to one extreme of the frontier, it is better to select a different position on the frontier for each layer, thereby obtaining a superior overall combination of trust and performance. This concept shares a common theoretical root with the widely discussed *scalability–decentralization–security* trilemma of the blockchain field; both arise from the computation and communication overhead inherent in global verification within distributed systems. The trust-performance frontier differs from the trilemma in that the former focuses on the two-dimensional trade-off between trust assumptions and execution efficiency in a trading-system architecture, whereas the latter is a more general constraint on blockchain design as a whole.

Locating three representative categories of trading-system architecture on this frontier makes their respective trade-offs along the trust and performance dimensions immediately visible. In Table 28-2, from the traditional centralized exchange to the Ethereum-mainnet DEX, the degree of trust minimization and the level of performance exhibit a nearly perfect negative correlation, whereas the app-chain architecture attempts to open a new feasible region between the two extremes.

| Architecture type | Degree of trust minimization | Performance (latency and throughput) | Position on the frontier |
| :--- | :--- | :--- | :--- |
| Traditional centralized exchange | Very low (relies entirely on a single entity) | Very high (microsecond latency, throughput in the millions) | Upper-left end of the frontier |
| Ethereum-mainnet decentralized exchange | Very high (whole-network consensus verification) | Very low (latency on the order of ten seconds, low throughput) | Lower-right end of the frontier |
| High-performance app-chain (such as Hyperliquid) | Relatively high (customized consensus, decentralized verification) | Moderate (sub-second latency, throughput on the order of 200,000) | Middle of the frontier, toward the right |

**Table 28-2.** The positions of three trading-system architectures on the trust-performance frontier (Data source: compiled by the author)

On this frontier curve, the traditional centralized exchange sits at the upper-left extreme, trading away trust minimization entirely for the highest performance. The decentralized exchange built on a general-purpose layer-1 network such as Ethereum sits at the lower-right extreme, achieving the greatest degree of trustlessness but forced to endure lower performance. The app-chain architectures that have since emerged, such as Hyperliquid, attempt to find a more balanced equilibrium point on the frontier. Through customized consensus mechanisms and specially optimized network architecture, they raise performance to a level sufficient to support professional derivatives trading while maintaining a relatively high degree of trust minimization.

As the underlying technology advances—through more efficient consensus algorithms, more sophisticated zero-knowledge proofs, and the adoption of parallel execution environments—this trust-performance frontier is indeed shifting toward the upper right. This means that, in the future, systems will be able to obtain higher performance while maintaining the same degree of trust minimization. Yet however the technology evolves, the additional computation and communication overhead of trustless verification is an objective reality, and under any known consensus model that overhead will not be eliminated entirely. Lower trust assumptions generally come with some form of performance compromise.

### 28.2.4 The logic of layered architecture

The trade-off between trust and performance is unavoidable, and neither the fully on-chain nor the fully off-chain approach is an ideal final solution. The way to resolve this tension lies in breaking the fixed assumption that *the system must, as a single whole, choose one position on the frontier*. A complete trading system is not an indivisible monolith but a trust stack composed of multiple functional layers. The layers differ in the severity of the consequences of trust failure and in their sensitivity to performance. The optimal architectural design should therefore evaluate the requirements of each layer independently and choose the best position on the trust-performance frontier for each. This is the underlying logic of layered architecture.

Three representative layers make this differentiated trade-off clear. A trust failure in the asset-custody layer is irreversible, while deposits and withdrawals are low-frequency operations that are insensitive to latency; this layer should therefore pursue trust minimization to the fullest (custody optimizes for safety). The matching and execution layer directly determines the fluidity of trading and the quality of liquidity, with stringent requirements for latency and throughput; as long as matching is verifiable after the fact, it can tolerate a degree of trust assumption in exchange for performance (matching optimizes for performance). The clearing and settlement layer sits between the two: computationally intensive in normal times yet insensitive to the latency of any single transaction, it must, during violent volatility, balance sufficient performance with an extremely high degree of trust minimization to guarantee the fairness of the rules (clearing sits in between). The optimal positions of these three layers, together with the specialized requirements of the data and oracle layer and the governance layer, are established layer by layer as design principles in Section 28.4.

The core idea of layered architecture is to reject the *one-size-fits-all* compromise. By decomposing the vast monolithic black box into independent modules and implementing a customized trust-performance trade-off within each, layered architecture can preserve the performance advantages of a centralized exchange at the critical stages while achieving the security guarantees of a decentralized network at the critical risk points. This engineering method of recombining the layers is the core design framework for building the next generation of robust on-chain financial systems.

## 28.3 The layered trust architecture of traditional finance

The trust problems facing the perpetual futures market—counterparty risk, asset safety, and the fairness of the rules—are not new problems of the cryptocurrency era. Over centuries of crisis and reform, traditional finance developed a mature trust infrastructure that includes central counterparty clearinghouses, central securities depositories, and regulators. These institutions are, in essence, the traditional-finance version of the trust stack, each corresponding to one or more layers of the stack. Only by understanding the operating logic, strengths, and limitations of these known solutions can we judge in which respects an on-chain architecture is an improvement, in which a regression, and in which merely a different trade-off.

### 28.3.1 The historical evolution of functional separation

Traditional finance did not begin with a well-developed trust infrastructure. The nineteenth-century exchange was likewise a monolithic black box, in which trade matching, clearing and settlement, and asset safekeeping all took place within the same exchange or broker. Under this architecture, problems such as counterparty default, brokers' misappropriation of customer funds, and price manipulation occurred frequently—strikingly similar to the problems that today's cryptocurrency centralized exchanges face.

The financial history of the past 200 years is a history of crisis-driven reform. Every major crisis pushed some layer of the trust stack toward independence and institutionalization. The Great Crash of 1929 directly gave rise to the U.S. Securities and Exchange Commission (SEC) in 1934, making the governance layer independent. The Wall Street paperwork crisis of 1973—the breakdown of the settlement system for paper stock certificates—prompted the creation of the Depository Trust Company (DTC, later the depository subsidiary of the Depository Trust & Clearing Corporation, DTCC), marking the independence of the custody layer [14]. Black Monday in 1987 drove the strengthening of clearing mechanisms, and the G20 Pittsburgh consensus after the 2008 global financial crisis directly gave rise to the reform of mandatory central counterparty clearing for over-the-counter (OTC) derivatives—embodied in the Dodd-Frank Act and the European Market Infrastructure Regulation (EMIR)—establishing the independent status of the clearing layer [15].

Traditional finance took 200 years to decompose the trading system from a monolithic black box into five independent layers, each managed by a different institution. At the governance layer are independent regulators such as the Commodity Futures Trading Commission (CFTC) and the SEC; at the data layer, regulated data providers such as Bloomberg and Reuters; at the clearing layer, independent central counterparties such as CME Clearing and LCH; at the matching layer, regulated matching institutions such as the New York Stock Exchange and Nasdaq; and at the custody layer, independent central depositories such as the DTCC and custodian banks. Each layer is operated by a different specialized entity, with institutional checks and balances among them. In the span of a mere decade, cryptocurrency centralized exchanges recombined these five layers into a single entity—an architectural regression whose extreme consequence was precisely the collapse of FTX.

### 28.3.2 The CCP and clearing-layer trust

The central counterparty is the core mechanism by which traditional finance addresses clearing-layer trust. Its most critical function is novation. Once a buyer and a seller reach a trade, the CCP steps in, and the original trade is replaced by a trade between the buyer and the CCP and another between the CCP and the seller. The CCP becomes the central counterparty to all trades, so the buyer need not trust the seller—only the CCP [16]. In the language of the trust stack, the CCP concentrates clearing-layer trust from *trust your counterparty* into *trust one strictly regulated, specialized clearinghouse*. This differs fundamentally from the crypto market. In crypto perpetual futures there is no central counterparty, and a trader's counterparty is either a market maker or another trader. Counterparty risk is fully exposed, or borne implicitly by the exchange—yet the exchange may be unable to bear it, as the FTX episode plainly showed. Some leading crypto exchanges have established insurance funds and auto-deleveraging mechanisms that functionally assume part of the CCP's risk-mitigation role. The key difference between these mechanisms and an institutionalized CCP, however, is this: the insurance fund is limited in size and lacks any cross-platform mutualization layer, there is no mutual-aid mechanism analogous to the *loss-sharing by non-defaulting clearing members* in a default waterfall, and there is certainly no central bank acting as lender of last resort to backstop liquidity. They are therefore only an incomplete replica of the CCP's functions, not a genuine institutional substitute.

The CCP absorbs default losses layer by layer through the default waterfall (Chapter 1 has already discussed the basic mechanism of the central counterparty and the default waterfall; the point is restated here briefly in the context of clearing-layer trust): in sequence, the defaulter's initial and variation margin, the defaulter's contribution to the default fund, the CCP's own capital (its *skin in the game*), the mutualized sharing of losses from the default funds of non-defaulting clearing members, and finally the recovery and resolution procedures [17].

Compared with the crypto market, the CCP holds significant advantages. First, trust is concentrated but strictly regulated: the user need only trust one specialized institution supervised by a central bank or the CFTC. Second, the default waterfall has depth—not one major CCP defaulted even during the 2008 financial crisis, which proved the mechanism's effectiveness [18]. Yet the CCPs' effective performance in 2008 rested on an important implicit premise: central banks around the world provided a backstop for the entire financial system through emergency liquidity support, and this sovereign-credit support is an institutional advantage that a decentralized system cannot replicate. Third, because the CCP's own capital ranks ahead of the clearing members in the default waterfall, the CCP has a strong incentive to maintain the quality of its risk controls.

The CCP also has limitations, however, and these limitations are precisely the directions in which an on-chain system might improve. The CCP is itself a *too big to fail* single point: if it runs into trouble, the entire market seizes up—which has been identified as a new form of systemic risk [19]. The London Metal Exchange (LME) nickel contract crisis of March 2022 laid this limitation bare. When the nickel price rose about 250% over three trading days (climbing to roughly 3.5 times its level), the LME (the decision was made at the exchange level, not by its clearinghouse, LME Clear) chose to suspend trading and retroactively cancel executed trades. This discretionary governance decision provoked serious doubts among market participants about the fairness of the exchange and its clearing infrastructure, and it led to multiple lawsuits [20]. The episode shows that a CCP's discretionary power under extreme market conditions can conflict with its positioning as neutral infrastructure. In addition, the CCP has a high barrier to entry: only large financial institutions can become clearing members, and small participants must go through intermediaries, making it a professional club rather than a permissionless system. The CCP's operating hours are also limited, and it does not support around-the-clock trading. Its transparency, moreover, is insufficient: its risk models and stress tests are confidential, so clearing members and end users cannot fully verify the quality of its risk controls—a form of regulated opacity.

### 28.3.3 The DTCC and custody-layer trust

The DTCC is the core institution that addresses custody-layer trust. Its core functions include central securities depository services and net settlement. All securities traded in the U.S. market are ultimately held in custody by the DTCC and its subsidiaries; buying and selling are merely transfers of title on its books, and physical certificates no longer move. Trust is concentrated from *every broker safely holds my shares* into *the DTCC safely holds everyone's shares* [21]. Through net settlement, of the trillions of dollars in daily trades, the funds or securities that actually need to be transferred amount to only a small fraction of total trade value, which greatly reduces settlement risk and funding requirements. According to reported figures, in 2024 the DTCC processed securities transactions worth about $3.79 quadrillion and provided custody and asset services for roughly $99 trillion in assets [22].

Within the trust stack, the DTCC solves the core problem of asset custody: assets are held in a strictly regulated, specialized institution independent of the exchange and the broker, so that even if a broker fails, customers' securities remain safe. Compared with the crypto market, the DTCC guarantees, through law and institutional design, the separation of customer assets from the broker's own assets, whereas most cryptocurrency centralized exchanges commingle customer assets with their own. As for settlement delay, the DTCC currently operates on T+1 settlement, whereas an on-chain system can achieve near-instant settlement. Yet, while instant settlement eliminates settlement risk, it also sacrifices the capital efficiency of net settlement: traditional T+1 settlement offsets large volumes of opposing trades within the settlement window, so that the funds actually transferred amount to only a small fraction of total trade value. As for transparency, the DTCC is subject to regulatory audit but is not fully transparent to external participants, whereas in an on-chain system all balances are publicly auditable.

The DTCC's success demonstrates the institutional value of separating custody from the trading and market-making functions. Its depository subsidiary, the DTC (in operation since 1973 and folded into the DTCC as its holding company in 1999), has never lost customer assets in its entire operating history [23]. This approach, however, is a form of centralized institutional trust that depends on a combination of law, regulation, and specialized institutions. The crypto market can achieve the same goal through decentralized architectural trust. In principle, the asset segregation of a smart contract is stronger than the DTCC's, because the code executes deterministically according to preset logic, excluding the possibility of selective default by management. Yet the code itself carries the risk of bugs, and once a flaw appears its consequences are equally deterministic, since an attacker can exploit the vulnerability systematically. The DTC custody system, with more than 50 years of operating record and well-developed legal recourse mechanisms, offers a proven alternative safeguard [23].

### 28.3.4 The CFTC/SEC and governance-layer trust

Regulators play an irreplaceable role in the trust stack. The CFTC regulates the U.S. futures and derivatives markets, setting margin standards, position limits, and market-maker obligations, prosecuting manipulation and fraud, and overseeing the operation of central counterparties. The SEC regulates the securities markets, performing similar functions [24]. Within the trust stack, these agencies address trust at the governance layer and, in part, at other layers, ensuring that the rules are fair, that participants have channels of appeal, and that rule changes follow due process.

Regulation as a trust mechanism has notable advantages. The first is enforcement power: regulators have the legal authority to penalize violators or shut down offending institutions—a hard power that on-chain governance currently lacks. The second is professional judgment: regulators command experts in finance, law, and technology and can make complex discretionary decisions, and in extreme situations human judgment may be superior to the rigid execution of code. Finally, being regulated is itself a trust signal that lowers participants' cost of gathering information.

But regulation also has limitations. Regulatory processes are often measured in months or years, whereas market changes are measured in days or hours, so regulation always lags innovation. A regulator can govern only the markets within its jurisdiction, whereas the crypto market is global. There is also the risk of regulatory capture, in which the regulated can influence the regulator and skew the rules toward industry interests. Regulators can usually detect problems only after the fact and can hardly guarantee in advance that all is well; FTX, for instance, was never flagged by the CFTC before its collapse, because FTX exploited the regulatory fragmentation among multiple jurisdictions and, through a complex corporate structure (incorporated in the Bahamas, operating in Hong Kong, serving users worldwide), effectively evaded the effective jurisdiction of any single regulator.

Compared with on-chain governance, regulators' rule-making is expert-led and legally binding, whereas on-chain governance relies on token-holder voting and can be manipulated by large holders. Regulators' human enforcement is subject to delay but carries coercive force, whereas on-chain code executes automatically without delay but is rigid. Regulators' rule-change procedures are transparent but slow, whereas on-chain governance may be fast or slow. Regulators offer legal remedies such as courts and arbitration, whereas the verdict of code in an on-chain system is usually final.

### 28.3.5 An overall assessment of the traditional trust architecture

The traditional trust architecture—the combination of the CCP, the DTCC, and regulators—has successfully solved many core problems. The CCP resolves counterparty default excellently, and the DTCC resolves asset misappropriation excellently; regulators' containment of price manipulation is moderate, and their guarantee of rule fairness is relatively good (the specific mechanisms of each institution are given in Sections 28.3.2–28.3.4).

The traditional trust architecture also has unsolved problems, however, and these are precisely the opportunities for on-chain systems. The traditional architecture serves only regulated local markets and excludes the world's large unbanked population, whereas an on-chain system is permissionless and open to anyone worldwide. Traditional institutions operate on business days and during trading hours, whereas an on-chain system natively supports around-the-clock operation. The traditional architecture's T+1 settlement still carries a full day of settlement risk, whereas on-chain settlement completes within block confirmation. The traditional architecture's risk models and position data are not fully transparent, whereas in an on-chain system all rules, trades, and positions are visible to everyone. In the traditional architecture, new products require a lengthy regulatory approval process, whereas an on-chain system is permissionless and innovation can be deployed instantly. Moreover, the core institutions of the traditional architecture themselves become systemic single points that require a government backstop, whereas the decentralization of an on-chain system in theory eliminates this single-entity risk.

From this, we can distill three paradigms for realizing trust. The first is institutional trust, exemplified by traditional finance, in which the source of trust is law, regulation, and specialized institutions, and the core mechanisms include the default waterfall, independent custody, and enforcement. Its advantages are 200 years of validation, coercive force, and professional judgment; its disadvantages are a high barrier to entry, geographic limits, slowness, and opacity. The second is platform trust, exemplified by the cryptocurrency centralized exchange, in which the source of trust is trust in the exchange or platform, and the core mechanisms are internal systems, brand reputation, and voluntary audits. Its advantages are the highest performance and the best user experience; its disadvantage is complete dependence on a single entity, with an extreme risk of collapse. The third is architectural trust, exemplified by on-chain systems, in which the source of trust is code, cryptography, and consensus mechanisms, and the core mechanisms are smart contracts, on-chain clearing, and on-chain governance. Its advantages are transparency, global reach, around-the-clock operation, and permissionlessness; its disadvantages are limited performance, rigid rules, and the risk of code vulnerabilities.

The optimal solution may not be to choose one of the three, but to blend all three. At the asset-custody layer, architectural trust is the strongest—the equivalent of a code version of the traditional depository. At the clearing and settlement layer, architectural trust and institutional trust can be combined, taking the depth of the CCP's waterfall together with the transparent verifiability of the chain. At the governance layer, institutional, architectural, and platform trust can be blended. The design principle of layered architecture is precisely to find, at each layer, the optimal blend of these three trust paradigms.

### 28.3.6 Functional inheritance from the CCP to on-chain clearing

The narrative that on-chain finance is meant to replace traditional finance is mistaken; it pits the two against each other and ignores the institutional wisdom that traditional finance has accumulated over the long run. A better narrative is that on-chain finance is a technical upgrade of traditional finance's trust infrastructure. It uses code to achieve what the central counterparty already achieves through law, on-chain transparency to achieve what the depository already achieves through audit, and DAOs or multi-signature schemes to achieve what regulators already achieve through administrative procedure.

This functional inheritance manifests in several respects. The CCP's novation is realized on chain by a smart contract acting as the impersonal counterparty to all trades, which eliminates the CCP's own default risk but loses the human judgment for handling extreme situations. The default waterfall is realized on chain as margin, the insurance fund, liquidity-provider takeover of liquidated positions, and auto-deleveraging, each step publicly auditable and automatically executed, eliminating the delay of human intervention—but its depth may fall short of a traditional CCP's, and there is no government backstop. The on-chain waterfall also typically lacks a layer corresponding to *skin in the game* (in which own capital bears losses ahead of members), and auto-deleveraging trims the positions of the profitable side, which is not equivalent, in either the population affected or the incentives, to the mutualized loss-sharing by non-defaulting clearing members in a traditional waterfall. Daily marking is upgraded on chain to real-time mark-price computation and continuous margin monitoring—from daily to per-second—reducing risk exposure, though the smoothing of the mark price may lag in a fast-moving market. Margin calls become instant liquidation on chain. This eliminates settlement risk but also denies the trader a second chance to top up margin, making the system more rigid. In a high-volatility environment, however, instant liquidation avoids the danger of risk exposure widening during the call period and may in fact be more prudent. This is all the more true under a multichain architecture, where cross-chain fund transfers often take several minutes or more—limited by source-chain confirmation and bridging delay—so that adding margin in practice becomes extremely difficult, which further reinforces instant liquidation as the appropriate default. Confidential stress tests become real-time risk monitoring based on public data, which anyone can run independently, though there is as yet no standardized framework.

The design goal of an on-chain clearing and settlement system is not to replace the central counterparty but to realize its core functions through technical means while overcoming its limitations. This raises the key design questions: can an on-chain system achieve a default waterfall of equal depth? How can the optimal balance between risk control and user experience be found? How can the problem of incentive alignment be solved in an on-chain system? These questions constitute the core challenges of building a resilient on-chain financial system.

## 28.4 Design principles of layered architecture

The essence of layered architecture is not simple modular partitioning but a precise engineering strategy of trade-offs: it allows a system to select the optimal architectural position independently at each functional layer, according to that layer's specific requirements for trust minimization and performance maximization [25], thereby abandoning the crude mode of the monolithic black box entirely and building instead a transparent, verifiable, and highly resilient financial ecosystem.

Layered architecture comprises six core design principles: the first five correspond to the five layers of the trust stack, addressing each layer's distinctive trust challenge and establishing the corresponding standard for technical implementation; the sixth concerns the design of the interfaces between layers, ensuring secure coordination among the modules.

### 28.4.1 De-trusting the asset-custody layer

The asset-custody layer sits at the very bottom of the trust stack and is the foundation of the entire system's security. In the monolithic black box architecture, users' assets are concentrated in a wallet controlled by a single entity, a design that creates the most severe single-point-of-failure risk. Should the controlling entity succumb to moral hazard or suffer a security breach, all users' assets face irreversible loss. The design principle of the asset-custody layer is therefore clear: it must achieve maximal de-trusting and, even at the cost of sacrificing some performance, must guarantee the safety of assets.

In engineering terms, this means stripping away, to the greatest extent possible, a centralized entity's unilateral control over user assets. Modern on-chain financial systems typically use smart contracts as the vehicle for asset custody, employing immutable code logic to strictly constrain the flow of funds and the conditions for withdrawal. Under this architecture, the transfer of assets no longer depends on management's promise but is bound by cryptographic proof and predefined consensus rules. To strengthen security further, multi-party computation (MPC) and hardware security modules (HSMs) are widely applied in key management, ensuring that even if some nodes are compromised, an attacker cannot reassemble the complete signing authority [26].

In addition, the asset-custody layer must be able to operate independently of the other layers. Even if the matching engine crashes or the clearing and settlement system fails, users' assets must be able to remain safely in the custody smart contract, or users must be allowed to withdraw their funds back to the underlying blockchain network through an emergency exit mechanism. In practice, however, the emergency exit mechanism faces operational risk: when an app-chain stops producing blocks entirely, the exit mechanism must rely on preset timeout-triggered logic, and in a mass-exit scenario the gas fees on the underlying network may spike sharply, making the exit cost uneconomical for small users. This design logic is of a piece with the traditional-finance principle that the custodian bank is independent of the exchange, but in the on-chain environment it is realized through mathematics and code rather than law and regulation. Smart-contract custody, however, carries an inherent legal vulnerability. In August 2022, the U.S. Treasury's Office of Foreign Assets Control (OFAC) added the immutable smart-contract addresses of Tornado Cash to its sanctions list, showing that a smart contract, too, can become the object of sovereign sanction; yet in November 2024, in Van Loon v. Department of the Treasury, the U.S. Court of Appeals for the Fifth Circuit ruled that an immutable smart contract does not constitute sanctionable "property" within the meaning of the International Emergency Economic Powers Act (IEEPA), and the Treasury accordingly delisted it in March 2025 [27]. This reversal shows that the legal boundaries of smart-contract sanctions are still evolving, but while the sanctions were in force, the legal risk faced by users interacting with the sanctioned contract was real. Moreover, the conflict between a judicial freeze order and the immutability of a smart contract has yet to be adequately resolved within the legal framework. Thus, while cryptographic custody effectively eliminates the operator's moral hazard, it does not eliminate legal risk or sovereign risk, and these two kinds of risk lie beyond the capacity of the technical architecture. At this layer, performance metrics such as transaction latency and throughput recede to secondary importance, because depositing and withdrawing assets are low-frequency operations, whereas security is the non-negotiable bottom line.

### 28.4.2 The verifiability of the matching and execution layer

Unlike the asset-custody layer, whose core demand is security, the matching and execution layer is the most performance-demanding stage of the entire trading system. Microsecond latency and throughput of tens of thousands of orders per second are necessary conditions for ensuring market liquidity and the trading experience. Subjecting the matching of every order to global consensus verification on the underlying blockchain would produce a performance loss that no active market could bear. The design principle of the matching and execution layer is therefore this: while meeting the demand for high performance, constrain the behavior of the matcher through after-the-fact verifiability mechanisms so as to ensure that orders are executed honestly.

In a layered architecture, the matching engine is usually designed as a high-performance independent module that can run on a customized app-chain or exist as an off-chain compute node. To prevent the matcher from exploiting its informational privilege to front-run or manipulate prices, the system must introduce strict fairness-guarantee mechanisms. The order-matching engine must strictly follow the price-time priority principle, and its execution results must be endorsable by cryptographic proof [28].

One engineering direction under active research and early exploration is the use of batch proofs or zero-knowledge proof techniques. The matching engine processes vast numbers of orders at high speed off chain and then periodically submits state updates and execution proofs to the chain for verification. This approach preserves the efficiency of centralized matching while, through mathematical proof, stripping the matcher of the ability to act maliciously. Users need not verify the correctness of every trade in real time as it occurs, yet they can be confident that any matching that violates the established rules cannot pass the final on-chain verification. In this way, the matching and execution layer finds an effective balance point on the frontier between trust and performance: it tolerates local centralization in the execution process but, through global verifiability, eliminates one-sided trust in the matcher's honesty.

### 28.4.3 The clearing and settlement layer: from reckoning and posting to default handling

The clearing and settlement layer connects the results of matching and execution with the state of asset custody, and it is the layer of an on-chain system that corresponds most closely to the function of the traditional central counterparty. Yet it is precisely at this layer that the ambiguity of the Chinese terminology most easily obscures a key engineering distinction. In the context of financial infrastructure, clearing, settlement, and liquidation are three concepts that must not be used interchangeably. Clearing is *reckoning the books*—the state transition after a trade is executed but before funds actually move: replacing the counterparty with the system through novation, performing multilateral netting across multiple trades, recomputing positions and realized P&L, and updating margin utilization. Settlement is *posting*—the actual change of hands of value: mark-to-market against the mark price, the periodic funding transfers unique to perpetual futures, the formal booking of realized P&L at position closure and the release of margin, and, layered on top in the on-chain setting, finality confirmation. Liquidation is another matter entirely: it is the forced closure of a position triggered when account equity falls below the maintenance margin, the layer's handling mechanism in the event of default, not the whole of the layer's function. Many design discussions misjudge risk precisely because they blur all three together under the single word *clearing*. Accordingly, this section decomposes the clearing and settlement layer into three sub-functions—clearing, settlement, and liquidation—and establishes the design principle of each.

The overall design principle of this layer is that all rules must be executed consistently and transparently, so that no one—including the system's developers—can covertly alter parameters or interfere with the process. In traditional finance, this function is assumed by the central counterparty, which raises capital efficiency and isolates systemic risk through multilateral net settlement [29]. The goal of the on-chain architecture is not to abolish this function but to replace the dependence on a trusted clearinghouse with deterministic code and consensus verifiability.

**Clearing: the deterministic recomputation of account state.** The clearing sub-function answers the question of *what a given trade means at the account level*. In a traditional central counterparty, novation means the buyer and seller no longer expose each other to credit risk and instead face only the clearinghouse as their common counterparty; in an on-chain system, this role is assumed by a smart contract or the state machine of an app-chain, so that after a trade both sides' positions are recorded according to uniform rules, and a default by either side does not propagate directly to its counterparty but is absorbed by the system. Multilateral netting consolidates a single account's multiple trades into a net change in position, and positions, realized P&L, and margin utilization are recomputed accordingly. The core requirement of the clearing sub-function is determinism: every margin determination and every update to the books must be independently recomputable by each validator, yielding the same result. This is precisely the on-chain embodiment of the principle that *the clearing authority must be a single point, while verification must be open to everyone*—the business-layer discretion over clearing is concentrated in a single deterministic engine, while the consensus layer guarantees that every step of that engine's output can be recomputed and checked by any node.

**Settlement: the actual delivery of value.** Unlike a traditional contract, which settles once at expiry, the settlement of perpetual futures occurs continuously. Mark-to-market settlement continuously revalues positions against the mark price, reflecting unrealized P&L in account equity in real time; funding settlement transfers funds between the long and short sides at fixed intervals, which is the core mechanism that lets perpetual futures anchor to the spot despite having no expiry; and closing settlement formally books realized P&L and releases margin when a position is closed out. In the on-chain environment, settlement adds a further layer of finality: a change of state becomes irreversible only after it is written into a block and confirmed by consensus. The design principle of the settlement sub-function is the transparency and immutability of posting—every funding transfer and every booking of P&L should be auditable on chain, foreclosing the covert transfers common in centralized exchanges.

**Liquidation: the line of defense for handling default.** When account equity falls below the maintenance margin, the liquidation mechanism steps in and forcibly closes the position to prevent it from going bankrupt. The complexity of liquidation requires this layer to possess a moderate degree of computational performance while maintaining an extremely high standard of trust minimization: if the liquidation rules could be changed at will, or if the liquidation engine could selectively ignore certain high-risk positions, the entire system's solvency would fail rapidly. The triggering conditions and execution flow of liquidation must therefore be hard-coded as public smart-contract or app-chain consensus logic. In implementation, the system needs a distributed liquidation orchestrator that continuously monitors the risk exposure of all accounts and, when the margin ratio falls below the maintenance threshold, triggers liquidations in an orderly fashion according to the urgency of the exposure. Modern liquidation engines generally adopt a partial-liquidation strategy—closing only the smallest fraction of a position needed to restore the account above the maintenance margin, rather than the traditional full liquidation—thereby reducing market impact while lowering the risk of a systemic reaction set off by a liquidation cascade.

To prevent an attacker from manufacturing spurious liquidations by manipulating oracle prices, the liquidation sub-function must establish a robust interface with the data layer and build a manipulation-resistant mark-price system. A mature mark-price construction typically includes the index price (the median of prices across multiple exchanges), a basis moving-average term (which uses an exponential moving average to characterize the deviation between the contract mid-price and the index price and adds it to the index price additively), price-band protection (which limits the jump magnitude of the mark price when the deviation exceeds a threshold), and an outlier-exclusion mechanism (which automatically excludes any single data source exhibiting an extreme deviation). When liquidation is still insufficient to cover the losses, the insurance fund serves as the next line of defense to absorb bankruptcy losses; its operating state must likewise be fully on chain, and the injection and depletion of its funds should be bound by strict smart-contract constraints, ensuring that under extreme market conditions the system absorbs tail losses in a transparent and predictable manner rather than relying on an opaque internal bailout.

The relationship among the three sub-functions constitutes the internal logic of this layer: clearing comes first, keeping the books consistent before any further matching occurs; settlement then effects the actual transfer of value and confers on-chain finality; and liquidation is the last line of defense, maintaining the system's solvency when a default occurs. This distinction also runs through the chapters that follow—the next chapter's design of a decentralized clearing and settlement architecture rests precisely on treating clearing, settlement, and liquidation as each performing its own role, rather than conflating them.

### 28.4.4 Manipulation-resistant design of the data and oracle layer

The data and oracle layer is the sole bridge through which an on-chain system interacts with the external real world. Because a blockchain is itself a closed, deterministic state machine, it cannot directly perceive the prices of external assets or the occurrence of real-world events. It must therefore rely on an oracle network to bring this critical data into the system securely. The design principle of the data layer is to eliminate the fragility of a single data source and to ensure that the price information fed into the system is genuine, manipulation-resistant, and highly available.

The core of the oracle problem is how to introduce subjective or external information into a trustless system without undermining the system's overall security [30]. If a derivatives protocol with billions of dollars in locked value depends on a single exchange's API to obtain its mark price, that API becomes the critical point of fragility for the entire system. An attacker need only use a flash loan to create a brief price spike in a single market to trigger large-scale erroneous liquidations and reap excess profit.

To honor this design principle, the layered architecture must adopt a distributed oracle network. Such a network aggregates quotes from multiple independent data providers and multiple exchanges and removes outliers, thereby producing a robust composite price. In addition, oracle nodes must stake assets, using an economic incentive mechanism to ensure that they report data honestly. If a node submits erroneous data that deviates from consensus, its staked assets are slashed. Through this cryptoeconomic design, the data layer converts trust in *authenticity* into a reliance on economic rationality and decentralized consensus, thereby providing a solid data foundation for the clearing and execution above it.

### 28.4.5 The procedural legitimacy of the governance layer

Any complex financial system must evolve continuously as market conditions change, which inevitably involves parameter adjustments, contract upgrades, or the deployment of new features. The governance layer is responsible for managing these processes of change. In the monolithic black box, governance is implicit, and management can change the rules at will without notifying users. The design principle of the governance layer is therefore this: all rule changes must be public and thoroughly debated, and their execution must be verifiable and predictable.

Decentralized governance mechanisms aim to eliminate the unilateral control of a few insiders over the system. In an ideal layered architecture, governance power is distributed to token holders or to a council of representatives elected by the community. Any major change to the system—adjusting the base fee rate, revising the liquidation penalty ratio, or upgrading the core smart contracts—must be initiated through an on-chain proposal and put to a vote over a prescribed period [31]. On-chain governance participants may face legal-liability risk: the CFTC's enforcement precedent against Ooki DAO shows that DAO token holders who participate in governance voting may be deemed members of that unincorporated association and thereby bear joint legal liability for the association's debts [32].

More important still, the governance layer must introduce a time-lock mechanism. Even after a change proposal passes, it cannot take effect immediately but must wait a fixed cooling-off period in a time-lock contract. This cooling-off period provides an escape window for users who disagree with the change, allowing them to withdraw their assets safely before the rules change. Through this design, the system not only constrains governance power but also grants users the ultimate right to vote with their feet. The governance layer is no longer a center of power that issues commands unilaterally, but an engine of rule evolution based on consensus and transparent procedure.

### 28.4.6 Modular design of the interfaces between layers

The success of a layered architecture depends not only on the robust design within each layer but also on how the five layers coordinate securely and efficiently. The last design principle therefore concerns the interfaces between layers: the system must maintain a high degree of modularity and composability, so that the layers can evolve independently while the risk of cross-layer attacks is guarded against.

Modularity means that each layer should provide services externally through a standardized interface while hiding its internal implementation details. The clearing and settlement layer, for example, need not know which specific matching algorithm the matching and execution layer uses; it need only receive trade records in a particular format. Likewise, the matching engine need not care whether the asset-custody layer uses multi-party computation or a hardware security module; it depends only on the proof of available balance that the custody layer provides. This decoupled design greatly reduces the system's complexity, letting developers focus on optimizing the performance or security of a specific layer without having to restructure the whole system.

Modularity also introduces a new challenge, however: interface risk. An attacker often will not attack a hardened layer directly but will instead seek vulnerabilities in the passing of information between layers. For example, if the data layer's latency in passing price information to the clearing layer is too high, the liquidation logic may make erroneous judgments based on stale data. Interface design must therefore include strict data validation, timeout handling, and graceful-degradation mechanisms. When a layer fails or is attacked, the system should be able to isolate it through the interface protocol, preventing the risk from spreading to the other layers and thereby safeguarding the ultimate resilience of the entire financial ecosystem.

## 28.5 A trust-stack audit of current architectures

Applying the trust stack model to the major trading architectures in the current market reveals the trust state of these systems across the five layers of asset custody, matching and execution, clearing and settlement, data and oracles, and governance. A system's trust audit can not only quantify precisely the trust concentration of different architectures but also lay out clearly the engineering path along which the industry is evolving from the monolithic black box toward a layered, transparent architecture. The following examines, in turn, the trust assumptions and verifiability of the typical centralized exchange, the AMM-type decentralized exchange, the app-chain decentralized exchange, and the emerging hybrid architecture at each layer.

### 28.5.1 The trust stack of a typical CEX

The architecture of a typical centralized exchange is, in essence, a highly integrated monolithic system, and its trust stack exhibits extreme concentration. Under this architecture, over the entire life cycle of completing a trade, the user must deliver complete trust at all five trust layers to a single entity: the exchange operator. The fragility of this trust structure was amply exposed in the several industry crises of 2022, which demonstrated that when trust concentration reaches 100%, the system's single-point-of-failure risk becomes unbearable [33].

At the asset-custody layer, the user must trust the exchange completely to safeguard the deposited funds. Centralized exchanges typically manage customer assets with internally controlled hot and cold wallet systems, which means the operator has the technical ability to move funds at will. Although some exchanges have introduced proof-of-reserves mechanisms in an attempt to improve transparency, such mechanisms have a fundamental limitation. Proof of reserves is usually based on an asset snapshot at a particular point in time combined with a Merkle tree structure; while it can prove that the exchange controls a certain quantity of assets, it often cannot provide proof of liabilities of equal strength [34]. Worse, the transparency of this off-chain system is provided voluntarily by the exchange and can be withdrawn at any time, rather than being enforced by the underlying architecture. The lag of the snapshot also leaves the exchange room to move funds temporarily in order to pass an audit.

At the matching and execution layer, a centralized exchange's internal order book and matching engine are entirely opaque to the outside. The user must trust the exchange to execute orders fairly, strictly according to price priority and time priority, without exploiting an informational advantage to front-run, and without deliberately delaying retail orders under extreme market conditions to protect the interests of its proprietary market-making desk. Because the matching process lacks verifiable cryptographic evidence, users who suffer unfair treatment often cannot prove it.

The clearing and settlement layer is likewise an opaque black box. Post-trade clearing of the books (the recomputation of positions, P&L, and margin), mark-to-market and funding settlement, and the triggering and execution of liquidations are all carried out inside the exchange. Although the exchange usually discloses its margin-calculation formulas and liquidation-triggering rules, the specific execution of these rules cannot be audited. During violent market swings, the exchange holds the implicit power to modify the mark-price algorithm or adjust liquidation parameters. The original intent of this flexibility may be to prevent cascading liquidations from triggering a systemic collapse, but in substance it grants the exchange the unilateral power to decide the fate of users' assets.

The data layer and the governance layer further intensify the concentration of trust. The exchange is both the sole provider of market data and the sole maker of the system's rules. Users have no way to verify the authenticity of order-book depth, nor any way to guard against fake volume misleading market sentiment. As for governance, fee adjustments, the listing of new contracts, and modifications of market-maker agreements are all decided unilaterally by the exchange's management, without due process or community oversight.

Table 28-3 maps the foregoing analysis onto the five layers of the trust stack, presenting the trust state and verifiability of a centralized exchange at each layer. The *trust state* column reflects the degree of trust the user must deliver to the exchange operator at that layer, while the *verifiability assessment* column measures the technical feasibility of an external observer independently confirming the operating condition of that layer. Reading the two columns together reveals a central contradiction: the centralized exchange demands complete trust from users at every layer yet offers effective external means of verification at almost none.

| Layer | Trust state | Object of trust | Verifiability assessment |
| :--- | :--- | :--- | :--- |
| Asset custody | Complete trust | Exchange operator | Very low; proof of reserves offers only a limited static snapshot |
| Matching and execution | Complete trust | Exchange operator | None; the internal matching-engine logic is invisible to outsiders |
| Clearing and settlement | Complete trust | Exchange operator | Low; the rules are public but the specific execution cannot be audited |
| Data and oracle | Complete trust | Exchange operator | Low; data authenticity relies entirely on the platform's self-discipline |
| Governance | Complete trust | Exchange management | Very low; rule changes lack transparency and any mechanism for participation |

**Table 28-3.** A trust-stack audit of a typical centralized exchange (Data source: compiled by the author)

Table 28-3 shows clearly that the typical centralized exchange exhibits, without exception, a state of *complete trust* across all five layers, with verifiability ranging from *very low* to *none*. This severe mismatch between trust and verifiability means that users have the fewest means of verification precisely where they most need protection. Taken together, the trust concentration of a typical centralized exchange reaches 100%. This mode of fully merging the trading, custody, clearing, and settlement functions within a single entity would be unthinkable in the traditional financial system [35]. As discussed in Section 28.3, traditional finance has, through institutional evolution, built a framework of mandatory functional separation. In pursuing the highest performance, the monolithic black box architecture of the centralized exchange sacrifices every attribute of trust minimization.

### 28.5.2 The trust stack of AMM-type DEXs

AMM-type decentralized exchanges mainly serve spot swaps and are not in the same category as the perpetual futures derivatives on which this book focuses; they are included here only within the trust-stack audit, as one link in the evolutionary lineage of four architecture types, and are not elaborated. Their core achievement is a high degree of trust minimization at the asset-custody layer through smart contracts: user assets are locked in an on-chain liquidity-pool contract, deposits and withdrawals strictly follow public code logic, no single entity holds the private-key authority to misappropriate funds, and the custody-default risk of a centralized exchange is thereby fundamentally eliminated.

Yet while the automated market maker solves custody-layer trust, it introduces new challenges at the other layers. The matching and execution layer abandons the central limit order book (CLOB) and instead relies on algorithmic pricing such as the constant-product formula; this eliminates trust in a centralized matching engine, but the execution process is exposed in the public mempool, making trades highly vulnerable to MEV attacks, in which validators can extract value from users through front-running or sandwich attacks. At the clearing and settlement layer, because the AMM mainly serves the spot, its logic is relatively simple, usually taking the form of instant swaps of tokens within the liquidity pool; once extended to derivatives, however, it must rely on an external oracle to supply the mark price for computing the funding rate and triggering liquidations, thereby shifting the trust risk to the data layer. The data and oracle layer thus becomes the most fragile link in this type of architecture: once the oracle is manipulated or fails, it can lead to large-scale erroneous liquidations, and even multi-source aggregation and economic staking cannot eliminate this risk entirely. The governance layer generally adopts a DAO model, which improves transparency but faces the problems of voting power concentrating among large holders and low decision-making efficiency.

Table 28-4 summarizes the foregoing analysis within the trust-stack framework. AMM-type DEXs display a marked divergence: the custody layer achieves a breakthrough close to zero trust, while the execution and data layers retain residual trust of differing forms. Unlike the uniform *complete trust* of the centralized exchange in Table 28-3, their trust distribution varies as a gradient across the layers.

| Layer | Trust state | Object of trust | Verifiability assessment |
| :--- | :--- | :--- | :--- |
| Asset custody | Highly trustless | On-chain smart contract | High; the contract code is publicly auditable, and asset flows are traceable on chain |
| Matching and execution | Partially trustless | Algorithmic pricing and block-ordering parties | Moderate; the pricing logic is transparent, but transaction ordering is subject to MEV |
| Clearing and settlement | Highly trustless (spot) / partially trustless (derivatives) | Smart contracts and external oracles | High (instant spot settlement) / moderate (derivatives depend on oracles) |
| Data and oracle | Partial trust | Decentralized oracle network | Moderate; multi-source aggregation, but a manipulation window remains |
| Governance | Partially trustless | DAO and token holders | Moderate; the voting process is transparent on chain but may be dominated by large holders |

**Table 28-4.** A trust-stack audit of AMM-type decentralized exchanges (Data source: compiled by the author)

The key pattern that Table 28-4 reveals is *solid at the base, weak at the top*: the custody layer and the spot clearing layer reach *high* verifiability, but this gradually gives way to *partial trust* as one moves up the layers. The MEV problem at the matching and execution layer and the manipulation window at the data and oracle layer constitute the two persistent bottlenecks of this type of architecture, and they also point to the directions in which the later app-chain architecture improves.

### 28.5.3 The trust stack of app-chain DEXs

The app-chain decentralized exchanges exemplified by Hyperliquid and the fourth-generation dYdX represent the current frontier of engineering exploration on the trust-performance frontier. By *app-chain*, this chapter means an independent blockchain network customized for a single application scenario, whose consensus mechanism, state machine, and network parameters are all deeply optimized around a specific use (such as derivatives trading). An app-chain differs from a general-purpose rollup in that a rollup inherits the security of the underlying chain and submits state proofs to it, whereas an app-chain maintains an independent validator set and consensus process. An app-chain differs from a traditional sidechain in that a modern app-chain is usually based on BFT consensus (such as Cosmos SDK's Tendermint or Hyperliquid's HyperBFT) rather than a simple multi-signature scheme or merged mining. dYdX v4's migration from StarkEx (an Ethereum-based rollup solution) to an independent app-chain built on the Cosmos SDK is a landmark case of this architectural paradigm shift, motivated precisely by the desire to obtain full customization of the consensus and execution layers so as to move order-book matching fully on chain. These protocols abandon the traditional path of building applications on a general-purpose smart-contract platform and instead develop an independent blockchain optimized specifically for trading. This architectural choice achieves an unprecedented, finely balanced equilibrium across the layers of the trust stack.

At the asset-custody layer, the app-chain architecture exhibits partial trustlessness. Because the app-chain itself typically does not host native assets, users must transfer funds from a mainnet such as Ethereum onto the app-chain through a cross-chain bridge. The security of the cross-chain bridging contract therefore becomes the core trust assumption of this architecture. Historical data show that cross-chain bridges are the infrastructure most prone to attack in the decentralized finance ecosystem; by cumulative amount stolen, at one point more than 40% of major hacking losses in 2022–2023 occurred at this link [36]. An app-chain usually relies on its validator set to jointly maintain the security of the cross-chain bridge, which means that the safety of users' assets shifts from trusting Ethereum's mainnet consensus to trusting the app-chain's local validator set.

The matching and execution layer is where the app-chain architecture's core innovation lies. By natively integrating a central limit order book at the consensus layer, these systems achieve a highly trustless matching process. All order submissions, cancellations, and matches are executed within a block, and the results are visible to everyone and immutable. Although the physical constraints of distributed consensus keep an app-chain's block time at the level of a few hundred milliseconds—unable to reach a centralized exchange's microsecond latency—this performance compromise buys complete transparency at the execution level, an acceptable trade-off for the great majority of non-high-frequency traders [37].

The clearing and settlement layer likewise achieves a high degree of trustlessness. Post-trade clearing of the books, mark-to-market, and funding settlement all execute deterministically on chain according to uniform rules, and the margin requirements, liquidation-triggering conditions, and the operating mechanism of the insurance fund are all hard-coded into the app-chain's underlying protocol. Every liquidation event can be audited precisely through on-chain data, sharply compressing the room for implicit governance maneuvering that is pervasive in centralized exchanges (though the specific liquidation parameters can still be adjusted through the governance process; see Section 28.6.3).

At the data layer, for crypto-native assets, an app-chain can directly use the trade prices generated by its on-chain order book, thereby freeing itself to a great extent from dependence on an external oracle. Only when derivatives on traditional financial assets are introduced does it again face the trust degradation that oracles bring.

At the governance layer, however, current app-chain projects generally exhibit partial trust. To ensure the system's capacity for rapid iteration and its ability to respond to sudden events, the core development team often retains control over protocol upgrades and the adjustment of key parameters. Although these projects usually promise to follow a roadmap of progressive decentralization, at the present stage the concentration of governance power remains a link in their trust stack that cannot be ignored.

Table 28-5 maps the trust state of the app-chain architecture onto the five-layer model. Unlike the centralized exchange's across-the-board *complete trust* and the AMM-type DEX's *solid at the base, weak at the top* pattern, the app-chain architecture displays a distinctive distribution—*solid in the middle, under pressure at both ends*: the three middle layers of matching, clearing, and data all reach *highly trustless*, while the custody layer at one end (constrained by cross-chain bridge security) and the governance layer at the other (constrained by concentrated team control) each retain trust assumptions of differing degrees.

| Layer | Trust state | Object of trust | Verifiability assessment |
| :--- | :--- | :--- | :--- |
| Asset custody | Partially trustless | Cross-chain bridge contract and validator set | Moderate; traceable on chain but exposed to the security risk of cross-chain bridging |
| Matching and execution | Highly trustless (residual validator-MEV risk exists) | On-chain order book and consensus mechanism | High; all matching logic and results are fully public on chain, but validators still have the potential ability to manipulate transaction ordering |
| Clearing and settlement | Highly trustless | Protocol-level hard-coded rules | High; the liquidation process strictly follows the code and is auditable after the fact |
| Data and oracle | Partially trustless | On-chain native data-generation mechanism | Moderate; crypto-asset prices are generated by on-chain trades but face the risk of self-referential price manipulation |
| Governance | Partial trust | Core development team and early validators | Moderate; the decision process has limited transparency and relies on the team's self-discipline |

**Table 28-5.** A trust-stack audit of app-chain decentralized exchanges (Data source: compiled by the author)

Comparing Tables 28-3, 28-4, and 28-5, a clear evolutionary trajectory emerges: from the centralized exchange's across-the-board *complete trust* over all five layers, to the AMM-type DEX's first breakthroughs at the custody and clearing layers, and then to the app-chain architecture's extension of *highly trustless* to the matching and data layers. The trustlessness assessment of the data and oracle layer, however, requires a more cautious correction: the JELLY (JELLYJELLY) incident of March 2025 showed that even when prices are generated entirely by on-chain trades, the price of a low-liquidity token can still be maliciously manipulated, forcing the market-making vault (HLP) to take over the liquidated position and bear an enormous unrealized loss (peaking at about $13.5 million), which exposed the inherent fragility of the self-referential pricing mechanism. The incident was ultimately quelled only by a vote of the validator set to force a delisting and settle at an off-market price (see Section 28.6.4), which simultaneously exposed discretionary intervention at the governance layer [38]. By the trust concentration metric proposed in Section 28.1.4, the app-chain architecture retains a dependence on a single entity at only the governance layer and part of the custody layer (the cross-chain bridge) among the five layers of the trust stack, giving an equal-weighted trust concentration of about 30% to 40%, markedly below the centralized exchange's 100%. Under the weighting scheme proposed in Section 28.1.4, because the app-chain achieves a high degree of trustlessness at the three middle layers of clearing, matching, and data and retains a dependence only at the custody and governance layers, its weighted trust concentration is about 25% to 30%. The difference between the two measures arises not from the middle layers (which are trustless under both measures, contributing close to zero to the residual concentration) but from the weighting's reallocation of weight to the custody layer (0.35): the app-chain's core residual risk—the cross-chain bridge—happens to sit at this custody layer whose weight is raised, so the weighted measure in fact highlights the cross-chain bridge's status as the decisive residual risk rather than systematically producing a more optimistic figure. Table 28-5 also lays bare, however, the app-chain's two structural weak points: the cross-chain bridge risk at the custody layer and the team's concentrated control at the governance layer, and these two links constitute the main bottlenecks to the further decentralization of the app-chain architecture.

### 28.5.4 The trust stack of hybrid architectures

Between the centralized exchange's monolithic black box and the app-chain's fully on-chain approach, an emerging model known as the hybrid architecture is gradually taking shape. The core design philosophy of this architecture is selective trustlessness: applying strict de-trusting at the layers most likely to cause catastrophic consequences, while retaining centralized, high-efficiency operation at the layers with the highest performance requirements.

The hybrid architecture first undertakes a thorough reform at the asset-custody layer. Users' funds are no longer deposited into a wallet controlled by the exchange but are instead held in an independent on-chain smart contract or a regulated third-party MPC custody system. This design ensures that the exchange cannot unilaterally misappropriate customer assets and greatly reduces the risk of the operator doing so. Under extreme market conditions, however, on-chain asset withdrawal may face frictions such as delay from network congestion, spiking gas fees, and cross-chain bridge congestion, so that the theoretical *instant exit* cannot always be realized frictionlessly in practice. The combination of multi-party computation and multi-signature technology requires that asset transfers pass through multi-party authorization, substantially raising the security boundary of the custody layer [39].

At the clearing and settlement layer, the hybrid architecture tends to move rule execution on chain. After the exchange completes matching off chain, it submits the results to an on-chain smart contract for the final confirmation of clearing the books, settling funds, and liquidating positions. This design guarantees the transparency and immutability of the rules, and users can audit the system's solvency and the fairness of its liquidation logic at any time.

At the matching and execution layer, however, the hybrid architecture continues to retain an off-chain centralized engine. This is because, for institutional investors and high-frequency market makers, microsecond latency and extremely high throughput are indispensable. By keeping the matching process off chain, the hybrid architecture can offer liquidity depth and a trading experience fully consistent with those of a traditional centralized exchange. Although this retains, to some degree, a trust black box at the execution level, by introducing cryptographic techniques such as zero-knowledge proofs, some hybrid architectures have begun to attempt to provide after-the-fact verifiability of matching results without sacrificing performance.

The trust state of the data layer and the governance layer in a hybrid architecture usually falls between the two extremes. Data are still generated mainly by a centralized engine, but because settlement occurs on chain, fabricating fake volume becomes more difficult and costly. The governance layer may adopt a mechanism combining a multi-signature council with a time lock, providing users an exit window while preserving responsiveness.

The trust distribution of the hybrid architecture displays an *interleaved* character quite unlike that of the three preceding architectures: rather than pursuing uniform de-trusting across all layers, it directs limited engineering resources precisely at the layers with the most severe consequences (custody and clearing) while retaining centralized, high-efficiency operation at the performance-sensitive layer (matching). This strategic trade-off is clearly reflected in the table below: two starkly different trust states—*highly trustless* and *partial trust*—coexist within the same architecture, forming a sharp layered contrast.

| Layer | Trust state | Object of trust | Verifiability assessment |
| :--- | :--- | :--- | :--- |
| Asset custody | Highly trustless | On-chain smart contract or third-party MPC custody | High; asset segregation is enforced by code or multi-party authorization |
| Matching and execution | Partial trust | Off-chain centralized matching engine | Low to moderate; some systems introduce ZKPs to provide after-the-fact verifiability |
| Clearing and settlement | Highly trustless | On-chain smart contract | High; the settlement rules are transparent and immutable on chain |
| Data and oracle | Partial trust | Generated by a centralized engine, constrained by on-chain settlement | Moderate; the cost of fabricating fake data is raised by on-chain settlement |
| Governance | Partial trust | Multi-signature council combined with a time lock | Moderate; rule changes are procedurally constrained but still led by a few |

**Table 28-6.** A trust-stack audit of the hybrid architecture (Data source: compiled by the author)

Table 28-6 reveals the core design logic of the hybrid architecture: the verifiability of both the custody layer and the clearing layer reaches the *high* grade, which ensures the safety of user assets and the fairness of rule execution—even if the matching engine is operated entirely by a centralized entity, the final ownership of funds is still adjudicated by on-chain contracts. Although the matching and execution layer retains *partial trust*, techniques such as zero-knowledge proofs are gradually closing this trust gap. Comparing Tables 28-3 through 28-6, the evolutionary path of the four architectures along the trust stack is plainly visible: from the centralized exchange's across-the-board opacity, to the AMM-type DEX's breakthrough at the base, to the app-chain's extension in the middle, and then to the hybrid architecture's precise trade-offs across the layers. The hybrid architecture represents the industry's pragmatic choice following a deep understanding of the trust-performance frontier. It acknowledges that different types of market participants have starkly different sensitivities to trust. Retail investors may value the full safety of their assets more highly, whereas high-frequency trading firms are willing to bear a degree of verifiable trust risk for the lowest execution latency. Through modular interface design, the hybrid architecture allows components at different layers to be freely combined, pointing to a path of progressive evolution for the on-chain financial infrastructure of the future.

## 28.6 Hyperliquid's architectural choices

Turning to the frontier of engineering practice, Hyperliquid is one of the protocols most representative of the current state of the trust-performance frontier. As an app-chain designed specifically for high-performance derivatives trading, each of its architectural choices—from building its own layer-1 network and a built-in central limit order book to the design of its liquidity-provider vault and validator set—is a carefully considered trade-off between trust and performance. Dissecting its architecture shows clearly how the layered-design philosophy comes to ground under real engineering constraints, and at which layers the system compromises in pursuit of the highest performance.

### 28.6.1 The app-chain and the on-chain order book

Hyperliquid's technology stack is built on a specially customized layer-1 blockchain. Its core architecture comprises an app-chain based on the HyperBFT consensus algorithm, a fully on-chain central limit order book, a bridge contract connecting to Ethereum, and a liquidity-provider vault that handles automated market-making along with an on-chain liquidation engine [40] [6]. The first core question raised by this architectural choice is: why build its own layer-1 network rather than build on an Ethereum layer-2 network?

Building on an Ethereum layer-2 network (such as Arbitrum or Optimism) means one can inherit the security of the Ethereum mainnet but must also inherit its performance constraints. The latency of a layer-2 network is usually greater than one second—a level of latency unacceptable to high-frequency traders and market makers—and it comes with non-negligible gas costs [41]. The performance limits of a layer-2 network stem from its architectural design. To inherit Ethereum's security, a layer-2 network must periodically submit state proofs or transaction data to the Ethereum mainnet, and the speed of this process is limited by the mainnet. Beyond that, transactions on a layer-2 network must ultimately be confirmed on the Ethereum mainnet, which adds to overall latency. In choosing to build its own layer-1 network, Hyperliquid in essence treats the app-chain as a dedicated chip customized for the single purpose of perpetual futures trading, rather than emulating a trading environment on a general-purpose processor. Through deep customization from the underlying network stack to the consensus algorithm, Hyperliquid achieves deep optimization for end-to-end latency [42]. This specialized design means that every component of the system can be optimized for trade processing. The storage structure, for example, can be optimized for the query patterns of the order book, the network protocol for the communication patterns of high-frequency trading, and the consensus algorithm for the rapid confirmation of trades.

The HyperBFT consensus algorithm is the core of this optimization. It draws on the design ideas of the HotStuff consensus protocol [43] and its successors LibraBFT and DiemBFT, but with several key improvements targeting the specific needs of a trading system [44]. Compared with the three-phase commit process of the base HotStuff, HyperBFT adopts the DiemBFT/Jolteon-style two-phase (two-chain) commit rule, which removes one round of inter-validator communication relative to the three-phase version and thereby lowers the confirmation latency of a single block. The two-phase commit is itself a contribution of the predecessor protocols (DiemBFT/Jolteon), not an original invention of HyperBFT relative to HotStuff. On the normal happy path, HyperBFT advances consensus through optimistic responsiveness: the rate of block production depends on the actual communication speed of a validator quorum rather than on a preset fixed timeout parameter, which means that when network conditions are good, consensus latency can be far below the protocol's theoretical upper bound. Optimistic responsiveness governs this happy path (which does not depend on a known time bound), whereas the synchrony assumption is used only in scenarios such as a view change (that is, leader replacement) to guarantee liveness: when network latency exceeds expectations, the protocol falls back to a more conservative consensus path. Whatever the state of the network, the protocol's safety (that is, not producing mutually contradictory state confirmations) is never conditioned on the synchrony assumption.

HyperBFT also introduces two optimizations: pipelined block processing and optimistic execution. Pipelining sends the quorum certificate of the previous block together with the proposal for the next block, so that multiple blocks advance in parallel through the proposal and certification phases. Optimistic execution allows a transaction to begin executing before the block is finally confirmed, further shortening the end-to-end latency the user perceives. Optimistic execution, however, introduces a theoretical risk of block rollback: in extreme cases, an optimistically executed transaction may be reversed because consensus was not reached, and users must distinguish two states—*optimistic confirmation* (low latency but not final) and *final confirmation* (verified by consensus and irreversible). The combined effect of these engineering optimizations lets HyperBFT achieve a median consensus latency of about 200 milliseconds while maintaining the safety guarantee of a BFT protocol. This performance figure, however, is measured under optimistic conditions. Under adversarial conditions—such as some validators going offline or a network partition—block-production latency may spike significantly, and consensus may even stall temporarily. While consensus is paused, the liquidation engine cannot execute protective liquidations, and risk exposure accumulates continuously; this constitutes the inherent fragility of high-performance BFT consensus under extreme conditions.

This technical choice inevitably comes at a cost, however. Building its own layer-1 network means the system must rely on its own validator set for security, rather than being backstopped by the vast computing power of the Ethereum mainnet. Under this architecture, the system's trust anchor shifts: users no longer trust the overall security of the Ethereum ecosystem but must instead trust Hyperliquid's specific validator set [45]. This shift of trust is the starting point for understanding Hyperliquid's architectural trade-offs; it reveals that in pursuing the highest performance, one must make a degree of compromise at the foundational security layer.

### 28.6.2 An analysis of the trust state at each layer

As the main instance of the *app-chain* archetype audited in Section 28.5.3, Hyperliquid's overall trustlessness at each layer is consistent with the judgments in that section; this section places it within the trust stack model and audits it, focusing on the increments specific to it. At the asset-custody layer (Layer 1), user assets are transferred from the Ethereum network to the Hyperliquid network mainly through a bridge contract. The security of this process depends entirely on the honesty of the validator set and the robustness of the bridge code [46]. At present, a deposit takes effect only after obtaining signatures from validators representing more than two-thirds of the stake weight [47]. As noted in Section 28.5.3, cross-chain bridges are the infrastructure most frequently attacked in decentralized finance—the Ronin bridge, for example, was hacked in 2022 for a loss of more than $600 million—and they therefore constitute one of the weakest links in Hyperliquid's trust stack.

Although the multi-signature mechanism requiring signatures from more than two-thirds of the validators provides some protection, the safety of user assets ultimately depends on the honesty of the validator set and remains inferior to holding assets directly on the Ethereum mainnet—the specific residual risks of the validator set and the cross-chain bridge are detailed in Section 28.6.4.

At the matching and execution layer (Layer 2), Hyperliquid places its central limit order book entirely on chain, with all orders matched within blocks and the results publicly visible [48], so that users can independently verify whether price-time priority is honored. As audited for the app-chain matching layer in Section 28.5.3, this layer is among the most trust-minimized in the entire system; although its latency of about 200 milliseconds is somewhat slower than a centralized exchange's microsecond response, it is entirely acceptable for the great majority of retail users and for some institutional traders [11].

The rules of the clearing and settlement layer (Layer 3) are likewise hard-coded in the on-chain Hypercore execution state machine: post-trade clearing of the books, continuous mark-to-market, funding payments, and unrealized-P&L updates all execute on chain according to deterministic rules and can be recomputed and checked by any node; every liquidation record of the liquidation engine can also be publicly queried; and the takeover of liquidated positions by the insurance fund and the liquidity-provider vault proceeds transparently on chain [49]. As audited in Section 28.5.3, this transparency far exceeds that of a centralized exchange. Here, however, two levels of *hard-coding* must be distinguished: the execution framework of the liquidation logic (such as the formula for computing the liquidation-triggering conditions and the execution flow) is truly immutable logic hard-coded into the protocol, whereas the specific liquidation parameters (such as the maintenance margin ratio and the maximum leverage) are variables that can be adjusted through the governance process. The rigidity of the former limits the flexibility of the rules: any framework-level modification requires a protocol upgrade, lacking the buffer that human intervention provides in a centralized system for handling extreme market conditions. During the 2008 financial crisis, the central counterparties of the traditional financial system could flexibly adjust their liquidation rules according to market conditions, and this flexibility was sometimes the key to preventing the spread of systemic risk. Although Hyperliquid's hard-coded rules are more transparent, they may lack the flexibility necessary under extreme market conditions.

At the data and oracle layer (Layer 4), the prices of crypto-native assets are generated directly by on-chain trades without an external oracle, achieving—as audited in Section 28.5.3—an extremely high degree of trust minimization. This self-referential pricing, however, carries an inherent fragility for low-liquidity assets: as the JELLY incident described in Section 28.5.3 showed, an attacker can still distort the perpetual mark price by manipulating the on-chain spot price, so this layer is not unconditionally one of *extremely high trust minimization*. At the governance layer (Layer 5), Hyperliquid is currently highly concentrated: the development team controls protocol upgrades, parameter adjustments, and the strategy of the liquidity-provider vault [50], and although it has declared a path of progressive decentralization, the current concentration of governance makes this the layer where the gap from a centralized exchange is smallest (the governance residual is detailed in Section 28.6.4).

### 28.6.3 The performance-latency trade-off

In a layered architecture, gains in performance often come at the cost of sacrificing some trustlessness. As a Byzantine fault-tolerant consensus protocol, HyperBFT follows the basic safety principle of BFT consensus by design: it prioritizes safety (that is, never producing mutually contradictory state confirmations) and, when the network partitions or inter-validator communication is severely delayed, chooses to pause block production, sacrificing liveness. This means the system would rather halt service briefly than confirm an erroneous trade result. Hyperliquid's performance optimization is achieved not by relaxing its safety guarantee but through engineering means—reducing the number of consensus communication rounds, optimizing the network topology among validators, and adopting pipelined block processing—to maximize throughput and minimize latency without impairing safety. Compared with a fully centralized matching engine, however, the communication overhead of distributed consensus still constitutes an irreducible lower bound on latency. According to official figures, for geographically close clients, Hyperliquid's median end-to-end latency is 0.2 seconds and its 99th percentile is 0.9 seconds [11]. By contrast, a centralized exchange's matching latency is typically in the microsecond range. A quantitative comparison of Hyperliquid's key performance metrics with these two benchmark architectures can pinpoint its position on the trust-performance frontier. In Table 28-7, four metrics characterize the performance differences among the three architectures from different dimensions: end-to-end latency reflects the user experience, throughput capacity reflects the system's carrying capacity, actual operating throughput reflects the match to market demand, and finality reflects the time window of trade certainty.

| Performance metric | Hyperliquid (app-chain) | Top centralized exchange | Typical Ethereum layer-1 DEX |
| :--- | :--- | :--- | :--- |
| Matching/consensus latency | ~200 ms (end-to-end, consensus confirmation) | ~5–50 microseconds (inside the matching engine; ~10–100 ms end-to-end for ordinary remote users) | ~12 seconds (block confirmation) |
| Throughput capacity | ~200,000 orders/second | Hundreds of thousands to millions/second | Tens to hundreds/second |
| Actual operating throughput | No independently verified public peak figure yet | Extremely high, depending on market volatility | Limited by block space |
| Finality | Single-block finality | Instant confirmation by the internal system | Requires waiting for multiple block confirmations |

**Table 28-7.** A comparison of performance metrics between Hyperliquid and other architectures (Data source: compiled by the author based on [10][11][12])

*Note: The "throughput capacity" in the table is measured in orders per second, encompassing all operations such as placing, canceling, and modifying orders. The official documentation states that the current mainnet supports about 200,000 orders per second, with the execution layer being the current bottleneck and the consensus and network stack theoretically scalable to millions of orders per second. As of this writing, there is no independently verified public figure for peak on-chain confirmed transactions (TPS), so the "actual operating throughput" row no longer provides a specific value.*

For high-frequency market makers, the latency gap from microseconds to 200 milliseconds is decisive. This explains why, under certain extreme market conditions, Hyperliquid's liquidity depth still struggles to fully match that of leading centralized exchanges, because high-frequency market makers cannot execute optimal market-making strategies amid millisecond-scale market swings. The profit model of high-frequency market-making relies on millisecond-scale reactions to market microstructure, and microsecond-latency arbitrage strategies are entirely infeasible on Hyperliquid. Moreover, the 200-millisecond latency also has a substantive impact on non-high-frequency traders: stop-loss orders may face slippage of several price ticks during violent volatility, market makers' delay in responding with cancellations increases the risk of adverse selection, and the execution-time difference of the liquidation engine under extreme conditions may cause the actual liquidation price to deviate significantly from the trigger price. Although these frictions are not fatal, they constitute a systemic cost that all participants must factor into their strategies.

This latency difference also affects the overall quality of market liquidity: on a centralized exchange, high-frequency market makers provide abundant liquidity, allowing traders to fill large orders near the mid-price, whereas on Hyperliquid high-frequency market-making participation is limited, liquidity comes mainly from ordinary market makers and the protocol's built-in algorithmic market-making vault (such as the HLP Vault), and the bid-ask spread may be wider.

In terms of throughput, the Hyperliquid mainnet currently supports a processing capacity of about 200,000 orders per second [11] [51]. Although the consensus algorithm and network stack can in theory scale to the order of one million orders per second, the current bottleneck lies in the execution layer [52]. This means that as the number of users and trading volume grow, the system may run up against a performance ceiling. Compared with an Ethereum layer-1 DEX, however, Hyperliquid's performance is already several orders of magnitude greater.

Yet although Hyperliquid makes the block-construction process more controllable by building its own layer-1 network, the problem of maximal extractable value does not thereby disappear. Validators still have, in theory, the ability to order and manipulate transactions. A validator could, for example, prioritize the inclusion of its own transactions or delay others' transactions for gain. This existence of maximal extractable value is an inherent problem of all blockchain systems, but on Hyperliquid the problem may be more pronounced because the validator set is small.

The Hyperliquid team has recognized this problem and is exploring various mitigations. It is considering, for example, introducing a timestamp-based order-sequencing mechanism to reduce validators' room to manipulate transaction ordering. In addition, increasing the number and geographic distribution of validators can further lower any single validator's ability to manipulate maliciously. Hyperliquid's high performance is therefore not without cost: it is a relative advantage obtained by concentrating trust in a specific validator set and optimizing the execution layer to the extreme.

### 28.6.4 Hyperliquid's residual trust

In assessing the robustness of any decentralized system, identifying its irreducible residual trust plays an important role. For Hyperliquid, the largest residual trust lies first in its validator set. In its early days, the system ran on just five validators; it then expanded to 16 genesis validators, converted to 21 permissionless nodes in April 2025, and by mid-2026 had grown to about 24 active validators (with the team announcing a further expansion to 27) [53] [54]. Although the team plans to keep enlarging the validator set, at the present stage the number and geographic distribution of validators remain relatively concentrated.

This number needs to be compared with other systems to gain a clearer picture. The Ethereum mainnet crossed the milestone of one million active validators in March 2024, with about 32 million ETH staked, accounting for 26% of total supply [55]. Even a relatively small proof-of-stake chain usually has hundreds to thousands of validators. Hyperliquid's twenty-odd validators are, by comparison, quite concentrated. More critically, the number of validators is only a surface indicator of security; the distribution of stake is the core variable that determines actual independent security. According to reports, the validators under the foundation collectively control about 81% of the staked tokens, which means that even though there are nominally twenty-odd validators, the actual concentration of power is far higher than the count suggests—this proportion exceeds both the one-third threshold needed to halt the chain and the two-thirds threshold needed to control the cross-chain bridge, and the system's number of effective independent validators may be far below its nominal validator count. If the validator set were attacked or internal collusion occurred, the security of the entire app-chain would be gravely threatened, and user assets would face direct risk. This is the core fragility of the self-built app-chain model: the system's security depends entirely on its own validators rather than on a node network as vast and dispersed as the Ethereum mainnet's.

Second, the cross-chain bridging mechanism from Ethereum to the Hyperliquid layer-1 network constitutes another significant point of centralization risk. The upgrade authority over the bridge contract, its multi-signature configuration, and the emergency-pause power all embody a high concentration of trust. Because all deposits and withdrawals of assets must pass through this bridging channel, it becomes, in substance, the critical conduit for the flow of funds through the entire system. If the bridge contract has a vulnerability or is attacked, users may be unable to withdraw funds, or funds may be stolen outright. The security problems of cross-chain bridges have already caused several major losses in the history of DeFi. The attack surface of a cross-chain bridge is not limited to smart-contract vulnerabilities: supply-chain attacks (such as the penetration of a signer's operating environment or the planting of malicious code in a dependency library) and common-mode failures (such as all validators running the same version of the software stack, so that a single vulnerability can breach all nodes at once) constitute equally serious threat vectors.

Finally, the development team's dominant position in governance is a notable compromise within the decentralized-finance narrative. According to reports, the associated foundation controls the vast majority of the staked tokens, which gives the team near-complete control over key decisions such as protocol upgrades and adjustments to the vault-strategy parameters [56]. Since HIP-3 went live on the mainnet in October 2025, qualified builders who meet the staking threshold have been able to deploy their own perpetual markets permissionlessly, so the listing of new contracts has shifted from complete team control toward partial decentralization. This concentrated governance power means that if the team makes a decision adverse to users, users have almost no way to stop it. Although Hyperliquid has proposed mitigation paths—increasing validator diversity, open-sourcing the bridge contract, and gradually transitioning governance power to the community—these remain, for now, plans on a roadmap rather than realized system features. Moreover, there is a reflexivity risk between the governance token's price and governance power: a rise in the token price increases the cost of a governance attack (raising security) but also increases the potential gain a large holder could obtain through governance manipulation (lowering security), and this positive feedback loop makes governance security hard to predict under extreme market conditions.

The problem with this governance concentration is that it leaves the system vulnerable to errors in the team's decisions. If the team decides to revise the liquidation parameters, adjust the fee structure, or change the incentive mechanism for liquidity providers, users cannot express their dissent through voting or any other democratic mechanism. This runs counter to the traditional ideal of decentralized finance but may be a necessary trade-off for achieving high performance.

### 28.6.5 The generalizability of the app-chain model

Hyperliquid's success has drawn wide industry attention, and its architectural pattern of an app-chain combined with an on-chain central limit order book seems to point to a viable path for decentralized derivatives trading. Other leading protocols have adopted similar approaches: dYdX v4 builds its app-chain on the Cosmos ecosystem, and Vertex is exploring a similar architecture. This architectural pattern is fully replicable technically. Any team with sufficient engineering capability can build an app-chain, implement an on-chain order book, and connect to Ethereum.

What is truly hard to replicate in the Hyperliquid model, however, is the specific detail of its performance optimization and its cold-start strategy for liquidity. The system's ability to process high-concurrency orders steadily at 200-millisecond latency depends on the team's deep customization and continuous optimization of the consensus algorithm and the underlying network stack [57]. This requires profound knowledge of systems programming and distributed systems. At the same time, the resilience its liquidity-provider vault displayed during a market downturn, together with the nearly $3 trillion in full-year trading volume and the fourfold user growth achieved in 2025, is owed more to the team's outstanding execution and its first-mover advantage in ecosystem-building [58] [59] [60]. These soft strengths and this accumulation of market presence cannot be obtained merely by copying the architecture's code.

A more fundamental problem is that the proliferation of the app-chain model may increase systemic risk. If hundreds of similar app-chain exchanges emerge in the future, each needing to assemble and maintain an independent validator set to secure itself, this will inevitably lead to a fragmentation of security. Each app-chain's economic bandwidth and capacity to defend against attack will be limited. Validator incentives may be insufficient to attract enough high-quality participants, causing the quality of the validator set to decline.

This problem can be understood through the economic concept of *the tragedy of the commons*. Validators are a scarce resource, all the more so high-quality validators with security expertise and infrastructure. If every app-chain must attract its own validator set, validators' compensation must be high enough to draw their participation. But this raises the app-chain's costs, which are ultimately passed on to users. At the same time, because validators are dispersed, the security of each app-chain declines, since its validator set is smaller and more easily attacked.

To alleviate this problem, introducing a shared security layer (such as restaking protocols like EigenLayer) may become a direction of future evolution. Letting multiple app-chains share underlying economic security can lower the cost of securing each independently, but it also introduces more complex cross-chain trust dependencies and potential systemic cascade risk. If the shared security layer itself is attacked, all app-chains that depend on it are affected. More seriously, in restaking the same stake secures multiple app-chains (actively validated services, AVSs) at once, so aggregate security is shared rather than simply summed, and slashing across different app-chains—together with operator failures—becomes correlated. This reintroduces precisely the common-mode failure and correlation risk warned of in Section 28.1.3 [61]. This model shifts trust from a single app-chain's validator set to the validator set of the shared security layer, but it does not fundamentally solve the problem of security fragmentation.

## 28.7 The engineering judgment of sufficient decentralization

In the architectural design of on-chain financial systems, a common misconception is to treat *decentralization* as a strict binary state or an ultimate goal to be pursued without limit. Starting from the first principles of engineering, however, the core task facing a systems architect is not to maximize decentralization at any cost but to identify precisely and minimize the unacceptable trust assumptions in the system. This paradigm shift from idealism to realism forms the basis of the engineering judgment of sufficient decentralization [62].

The concept of *sufficient decentralization* acknowledges the objective existence of the trust-performance frontier discussed above. Under given technical constraints, every additional degree of on-chain verification depth inevitably incurs a loss of performance. Good architectural design should therefore provide appropriate trust guarantees for different layers and different user groups, rather than constraining the entire system with a single rigid standard.

### 28.7.1 Defining 'sufficient'

In the context of financial infrastructure, defining *sufficient decentralization* requires returning to the bottom-line logic of protecting users' interests. A system's meeting the *sufficient* standard does not mean it achieves full peer-to-peer consensus in every technical detail; it means it has established effective safeguards at the critical risk nodes, so that the cost to any single entity of acting maliciously far exceeds the gain it could obtain. This security condition can be formalized as a cost-benefit attack model: the cost of acting maliciously includes the slashing of staked assets, the forgone future income from reputational loss (an opportunity cost), and the risk of legal prosecution; the potential gain depends on the size of the manipulable assets (such as the cross-chain bridge's total value locked, TVL, or the liquidation profit that could be triggered). The system's security condition requires that the ratio of the cost of acting maliciously to the potential gain remain above a safety threshold. When this ratio declines as the protocol's TVL grows, the system must maintain its margin of safety by raising the staking requirement or introducing additional penalty mechanisms.

Specifically, a *sufficiently decentralized* architecture must meet bottom-line requirements along three dimensions. First, at the asset-custody layer, the system must guarantee that no single entity can steal a user's assets. This is the least compromisable link in the entire trust stack. However high the system's performance requirements, control over a user's assets must, and can only, be exercised by the user's own cryptographic signature. Second, at the matching and execution and the clearing and settlement layers, the system must ensure that no entity can covertly manipulate the trading rules for private gain. Although the execution at these layers may be performed by a specific validator set or high-performance nodes, the results must be fully verifiable, and any deviation from the established rules must be detected promptly and penalized. Finally, at the governance layer, the system's rule changes must be predictable, auditable, and allow users to exit. When the protocol needs to be upgraded or key parameters adjusted, it must follow due process, granting users a full right to be informed and a time window to withdraw their assets before an adverse change takes effect.

Understanding what *sufficient* means also requires clarity about which properties are unnecessary. For example, requiring real-time whole-network consensus verification of every high-frequency order in pursuit of maximal decentralization often sacrifices the system's availability. For most trading scenarios, after-the-fact cryptographic verifiability is already *enough* to guarantee fairness. By the same token, fully decentralized permissionless governance may respond slowly to an urgent security incident, whereas a small expert committee constrained by a time lock and community veto power can often find a better balance between efficiency and security. Moreover, pursuing zero MEV may be impractical under the current public-chain architecture; as long as such value extraction is confined to a sufficiently small and controllable range, it can be regarded as an inherent friction cost of on-chain trading rather than a fundamental defect of the system.

### 28.7.2 The trust needs of different users

The participants in a financial market are not a homogeneous whole. Retail investors, institutional capital, and high-frequency market makers differ markedly in their core demands and their tolerance for various kinds of risk when participating in on-chain trading. Forcing a single unified architecture to satisfy everyone's needs therefore often yields a compromise that satisfies no one. Excellent architectural design should possess enough flexibility to respond to the specific trust needs of different user groups.

For retail investors, the core concern usually centers on the safety of assets and the fairness of the trading environment. What they least want to see is a repeat of an event like a centralized exchange misappropriating funds, or being subjected to *queue-jumping* arbitrage by an internal market maker inside an opaque matching engine. By contrast, retail investors are relatively insensitive to trading latency, and the difference between a few hundred milliseconds and a few microseconds is all but negligible in their subjective experience. At the same time, retail participants usually lack the time or expertise to engage deeply in a protocol's day-to-day governance. For this group, therefore, the optimal architectural configuration is often full trustlessness at the asset-custody layer, complemented by moderate trustlessness at the matching and clearing layers, while a relatively high degree of expert representation is acceptable at the governance layer. Yet there is a systematic gap between retail investors' revealed preference and their stated preference: in a bull market, retail investors systematically favor the platforms offering the highest leverage and the fastest speed, even when those platforms are conspicuously weak in architectural security. This means that an architectural security advantage may need to be realized through nudge mechanisms such as default-option design (for instance, enabling a self-custodial wallet connection by default), rather than relying on users' active, rational choice.

Institutional investors present a more complex map of trust needs. Beyond the non-negotiable safety of assets, institutional capital is often subject to strict compliance and regulatory constraints that require the system to be highly auditable. Institutions need to be able to demonstrate clearly to auditors and regulators the flow of their assets and the compliance of their trades. This requires the system to achieve a high degree of trustlessness and full transparency at the asset-custody, matching and execution, and clearing and settlement layers. At the same time, institutional investors usually require the protocol to have a formal and predictable governance framework in order to avoid the policy risk of frequent rule changes. As for performance, although institutional investors do not demand the lowest latency as insistently as high-frequency trading desks do, they still need the system to have the throughput capacity to handle large orders and cope with extreme market swings.

The demands of high-frequency market makers lie at the other extreme. As the primary providers of market liquidity, their strategies' profitability depends heavily on extremely low latency and a certain execution speed. In the latency-sensitive domain of high-frequency trading, any additional latency introduced by a consensus mechanism can render a strategy ineffective or expose it to serious adverse-selection risk. High-frequency market makers are therefore often willing to trade a degree of trust for performance. As long as the underlying asset custody is fully secure on chain, they may even accept the use of a centralized off-chain engine for order matching. This core demand for performance is precisely the driving force behind the market's current favor toward the *off-chain matching plus on-chain settlement* hybrid architecture.

This divergence of user needs foreshadows the future direction of on-chain financial architecture. We are unlikely to see a single unified architecture suited to every scenario; rather, we will arrive at an ecosystem in which multiple architectures coexist. In this ecosystem, different protocols serve specific target user groups precisely by choosing different landing points on the trust-performance frontier.

### 28.7.3 A gradation of trust

Building on the definition of the *sufficient decentralization* bottom line and the analysis of different user needs, we can construct a more fine-grained framework for grading trust. This framework discards the simple dichotomy of *trust* versus *trustlessness*, dividing the trust assumptions in a system into four progressive levels and matching each level with a corresponding technical implementation path.

At the very bottom, and the most solid link, is the *zero trust* level. At this level, the system's security is guaranteed entirely by code logic and cryptographic primitives, and the user need not trust any external entity, validator set, or governance committee. This level of trust usually applies only to the asset-custody layer. Through self-custodial smart contracts deployed on a decentralized underlying network, users retain complete control over their assets. As long as the underlying consensus mechanism has not been breached, no one can transfer the assets without the user's private-key signature. This is the foundation for building the entire trustless financial system.

One level up is *verifiable trust*. At this level, some of the system's computation or execution may be performed by a specific centralized entity or a few nodes in exchange for higher processing performance. This execution privilege, however, is not unconstrained. The executor must submit cryptographic proofs (such as zero-knowledge proofs) or publish the full transaction logs to the base chain, so that anyone can verify the correctness of the execution results after the fact. If the executor attempts to deviate from the established rules, a challenge mechanism allows honest nodes to submit a fraud proof, thereby overturning the erroneous state and imposing severe economic penalties on the malicious actor. This model is widely applied at the matching and clearing layers of layer-2 scaling solutions and app-chains, greatly raising the system's throughput while guaranteeing the correctness of results.

The third level is called *exitable trust*. This trust model applies mainly to the system's governance layer. In a complex financial protocol, wholly rigid rules often struggle to cope with a rapidly changing market environment, and a measure of flexibility is necessary. Adjustments to the protocol's parameters or upgrades to its code may be led by a centralized core team or by a DAO representing a small interest group. To prevent this power from being abused, the system must enforce a time-lock mechanism. After any critical rule change is proposed, it must pass through a mandatory waiting period before taking effect. This waiting period provides a window for users who disagree with the change to exit safely, allowing them to withdraw their assets under the old rules. Combined with an emergency-veto mechanism, the broad community can, in extreme cases, block a malicious upgrade proposal.

At the highest level is *replaceable trust*. At certain stages that must rely on external input—such as the oracle layer that obtains off-chain asset prices—the system inevitably needs to trust a data provider. To lower this single-point-of-failure risk, the architectural design should introduce diversified data sources and a seamlessly switchable substitution mechanism. The system should not be bound to a single oracle service but should compute the final result by aggregating data from multiple independent oracles. When a data source is detected to have an anomalous deviation or to have stopped serving, the system can automatically remove it and switch to a backup node. This mechanism, which constrains behavior through redundancy and competition, converts the dependence on a single entity into trust in an entire decentralized service market.

Cross-mapping these four trust levels onto the three-dimensional bottom-line requirements proposed in Section 28.7.1 yields more operational guidance for architectural design. The asset-custody layer, as the first-dimension bottom line ("no single entity can steal a user's assets"), must reach the *zero trust* level, which is the non-negotiable minimum standard. The matching and execution and the clearing and settlement layers correspond to the second-dimension bottom line ("no entity can covertly manipulate the trading rules"), and their minimum requirement is the *verifiable trust* level—execution may be performed by specific nodes, but the results must be endorsable by cryptographic proof. The governance layer corresponds to the third-dimension bottom line ("rule changes are predictable, auditable, and allow exit"), and its minimum requirement is the *exitable trust* level—even if governance power is concentrated in a few hands, users must have a time window to withdraw their assets before a rule change. The data and oracle layer should reach the *replaceable trust* level, using multi-source redundancy to ensure that the system does not depend on any single data provider. This mapping clarifies the minimum admission standard for each layer of the trust stack within the *sufficient decentralization* framework.

### 28.7.4 The path of progressive decentralization

Having understood the graded architecture of trust, we need to examine the dynamic process by which a system evolves from its initial state toward the ideal architecture. For the vast majority of on-chain financial projects, achieving full decentralization across all layers at the genesis stage is not only very difficult in engineering terms but often impractical. Early product iteration, bug fixing, and market expansion require the core team to have a high degree of agility and control [63]. A more pragmatic and widely adopted path is therefore progressive decentralization.

Progressive decentralization is not a vague slogan but a structured, multi-stage evolutionary strategy. In this roadmap, the core task of the first stage is to establish the basic bottom line of asset safety—that is, to achieve zero trust at the asset-custody layer. This is the minimum admission threshold for anything that calls itself a decentralized finance protocol. The team must ensure that control over the smart contracts cannot be used to misappropriate user funds at will, which usually requires multi-signature schemes, rigorous audits, and immutable custody logic. Only once asset safety is established can the system earn the initial trust of early users.

As the system enters the second stage, the focus shifts to improving the transparency and verifiability of the matching and clearing processes. At this stage, the team may still run a centralized sequencer or matching engine to ensure the user experience, but it must begin to introduce mechanisms that let these components' behavior be externally audited. This may include periodically publishing transaction logs to a data-availability layer, or beginning to develop and integrate zero-knowledge proof techniques. The goal of this stage is to eliminate the internal information black box, so that the fairness of operations no longer depends solely on the team's reputation.

Once the protocol's business model is validated and its technical architecture stabilizes, progressive decentralization enters the third stage: the devolution of governance power. This is a challenging transition period in which the core team must gradually transfer control of the protocol to a broad community of token holders. This usually begins with the adjustment of non-critical parameters, gradually extends to the allocation of treasury funds, and ultimately encompasses the upgrade authority over the core smart contracts. In this process, establishing a healthy representation system, guarding against governance attacks, and maintaining decision-making efficiency are the difficult problems the team must solve.

The final stage addresses the decentralization of external dependencies, particularly infrastructure such as oracles and cross-chain bridges. This requires the system to move from depending on a single trusted party to connecting to diversified decentralized networks—for example, replacing an internally maintained price feed with a decentralized oracle network, or upgrading a multi-signature-controlled cross-chain bridge into a trustless bridging solution based on light clients or zero-knowledge proofs.

Taking today's representative app-chain architectures as an example, many leading projects are at different stages of this progressive path. They have achieved a relatively high degree of trust minimization at the asset-custody and execution layers but still retain significant centralization residue in the allocation of governance power and the security of cross-chain bridging [45]. This state is not the architecture's endgame but a slice of the process of evolution.

The path of progressive decentralization, however, also harbors structural risks. The greatest hidden danger is that *gradual* may degenerate into a pretext for the team to retain power indefinitely. When the core team grows accustomed to the efficiency and convenience of centralized governance, or when vested-interest groups reap rich returns under the current architecture, they often lack any intrinsic motivation to truly advance the last few steps of decentralization. Empirical observation supports this concern: among major DeFi protocols, the proportion that complete the final stage of their decentralization roadmap (such as fully removing admin keys and transferring upgrade authority to permissionless governance) is extremely low, and most protocols stall once they reach the comfort zone of *sufficient decentralization*. Beyond technical feasibility, therefore, the community's continued oversight, transparent roadmap commitments, and a hard-coded timetable for the transfer of power are all key forces for ensuring that progressive decentralization does not stray from its stated goal.

## 28.8 Modularity, composability, and the trust market

Let us place the choice of a layered architecture back within the macro framework for assessing market quality: as the analytical model established in Chapter 25 holds, the architectural design of any trading system must ultimately withstand examination along five dimensions—transaction costs, price discovery, resilience, fairness, and accessibility. The following analyzes how a layered architecture systematically reshapes these five dimensions, what new forms of risk it introduces, and how architectural design can, at a deeper level, substitute for traditional regulatory intervention.

### 28.8.1 How layered architecture reshapes the five dimensions of market quality

When we turn our attention to how a layered architecture performs in actual operation, we find that it does not provide an immediate, Pareto-optimal improvement along every dimension. On the contrary, it displays a clear trade-off: it achieves structural breakthroughs along the defensive dimensions (resilience and fairness) but must pay a certain performance cost along the offensive dimensions (transaction costs and price discovery). This trade-off is, in essence, the concrete projection of the *trust-performance frontier* discussed above onto the assessment of market quality.

Along the transaction-cost dimension, a layered architecture inevitably raises explicit costs in the short term. Empirical comparative studies of centralized and decentralized exchanges show that the fixed costs of on-chain trading (mainly gas fees) significantly burden small trades and produce a persistent arbitrage deviation between centralized and decentralized exchanges [64]. Yet if we lengthen the assessment horizon and factor in implicit costs, the conclusion reverses. In the monolithic black box architecture, users have in fact been paying a steep *trust premium* for the exchange's credit risk all along—a premium that stays hidden in calm markets but manifests, when a crisis erupts, as the complete zeroing-out of assets. The persistent arbitrage deviation between centralized and decentralized exchanges recorded in the empirical study by Barbon and Ranaldo [64] provides quantitative corroboration of this cost structure, while the significant withdrawal premium that briefly appeared at major centralized exchanges after the FTX collapse reflects the existence of this implicit trust cost from another angle. By de-trusting the asset-custody layer and the clearing and settlement layer, a layered architecture fundamentally eliminates this implicit systemic-risk cost. Moreover, empirical data also show that, because fixed costs can be amortized over larger notional amounts, a decentralized architecture can often offer more competitive all-in transaction costs for large trades [64].

Along the price-discovery dimension, the impact of a layered architecture is relatively neutral but holds long-term upside. The efficiency of price discovery depends heavily on the symmetry of information and the depth of liquidity. Although the monolithic black box architecture can provide extremely high instantaneous liquidity through low-latency matching, its opacity often conceals the true dynamics of order flow. A layered architecture decouples the data layer from the matching layer, making all trade records and order-book states fully transparent and verifiable on chain. This transparency eliminates information asymmetry, enabling all market participants to price on the basis of the same genuine data and thereby promoting, over the long run, a more robust and fair process of price discovery.

Along the resilience dimension, a layered architecture brings a structural improvement. Research on systemic risk notes that the most dangerous vulnerability in a complex financial network stems from *the correlation of failures* [65]. In a centralized exchange, all functional modules share the same root of trust, which makes a local failure highly prone to cascading into a systemic collapse. A layered architecture severs this chain of failure propagation through modular design. Even if the matching engine suffers an outage or the oracle network briefly fails, as long as the underlying asset-custody smart contract remains intact, users' principal faces no risk of loss. This architectural property of downgrading *systemic destruction* to *localized functional degradation* endows a trading system with powerful resilience to survive extreme market turmoil. A layered architecture, however, does not eliminate systemic risk entirely; it changes the path of transmission. In a layered architecture, economic contagion may unfold along a specific cascade path: oracle failure → the liquidation engine cannot price correctly → large-scale erroneous liquidations or delayed liquidations → the insurance fund is rapidly exhausted → the auto-deleveraging mechanism forcibly harvests profitable positions → market confidence collapses → run-like withdrawals. The core value of a layered architecture is to downgrade this *instantaneous total collapse* to *gradual stress transmission*, in which each layer's fault-isolation mechanism provides a window of response time; but the ultimate elimination of systemic risk still depends on the adequacy of each layer's risk buffers.

Along the fairness dimension, a layered architecture systematically clears away the conflicts of interest inherent in a centralized exchange. We have diagnosed in detail above how a centralized exchange exploits its multiple roles as rule-maker, referee, and player to gain informational privilege. A layered architecture forcibly separates these functions: the matching logic is encoded as an immutable smart contract or the consensus of an independent app-chain, the liquidation parameters are determined by transparent on-chain governance, and the market-maker agreements are no longer a secret of behind-the-scenes maneuvering. This architecture-level dispersion of power deprives unfair behaviors—front-running, order queue-jumping, and selective liquidation—of their technical feasibility.

Along the accessibility dimension, a layered architecture inherits the permissionless character of blockchain technology and achieves genuine global access. The traditional trust architecture depends heavily on geographic jurisdiction and licensing barriers, which objectively exclude a large number of potential market participants. A layered architecture establishes trust through code rather than institutions, allowing any user with an internet connection to access the core financial infrastructure on equal terms. Although the current on-chain interaction interface still poses a certain threshold in user experience, in terms of the distribution of access rights a layered architecture has unquestionably expanded the boundaries of the financial market enormously.

Table 28-8 summarizes the five dimensions above, presenting the structural reshaping of market quality by a layered architecture. The *structural impact* column describes the effects already observable at the current stage, while the *long-term evolutionary trend* column makes forward-looking judgments based on the development path of the underlying technology. Reading the two columns against each other helps distinguish the efficiency costs a layered architecture must bear in the short term from the structural gains it can deliver over the long run.

| Market-quality dimension | Structural impact of layered architecture | Long-term evolutionary trend |
| :--- | :--- | :--- |
| Transaction costs | Explicit execution costs rise slightly (constrained by on-chain verification overhead), but the implicit systemic trust premium is greatly reduced | As modular blockchain scaling technology matures, all-in transaction costs will keep falling |
| Price discovery | Instantaneous pricing efficiency is slightly affected by latency, but on-chain data transparency fundamentally improves information symmetry | Trends over the long run toward more genuine, more robust price discovery, reducing the room for manipulation |
| Resilience | Markedly improved; module isolation eliminates single points of failure, downgrading the risk of total collapse to localized failure | As decentralized sequencers and fraud proofs become widespread, the system's stress resistance will strengthen further |
| Fairness | Markedly improved; the architecture level eliminates informational privilege and conflicts of interest, and the matching and clearing rules are fully transparent and verifiable | Trends markedly toward higher fairness, with any rule change required to pass through a public governance process |
| Accessibility | Markedly improved; permissionless global access breaks the geographic and licensing barriers of traditional finance | As technologies such as account abstraction mature, the interaction threshold will fall substantially, achieving financial inclusion |

**Table 28-8.** The structural impact of layered architecture on the five dimensions of market quality (Data source: compiled by the author)

A core judgment can be distilled from the horizontal comparison in Table 28-8: a layered architecture achieves structural breakthroughs along the three *defensive* dimensions of resilience, fairness, and accessibility, and these improvements stem from a fundamental restructuring of trust assumptions at the architectural level rather than marginal parameter optimization. Along the two *offensive* dimensions of transaction costs and price discovery, a layered architecture must bear the friction costs of on-chain verification in the short term, but as modular scaling technology matures, these costs keep falling. Overall, a layered architecture trades short-term explicit efficiency losses for long-term systemic robustness—a trade-off repeatedly validated in the historical experience of traditional finance's introduction of the CCP and independent custody.

### 28.8.2 New forms of risk in a layered architecture

Although a layered architecture excels at eliminating the single points of failure of a centralized entity, we must recognize clearly that this paradigm shift does not abolish risk out of thin air; rather, it transfers risk from *trust in entities* to *trust in code and protocol interfaces*. This transfer introduces three entirely new forms of systemic risk, which constitute the core problems that on-chain financial engineering must solve in the future.

Inter-module interface risk is a relatively hidden point of fragility in a layered architecture. In a monolithic architecture, the functional modules run within the same controlled memory space, and data transfer and state updates are synchronous and atomic. In a layered architecture, however, the functions of different layers are executed by independent smart contracts or app-chain networks, and communication among them must rely on asynchronous message-passing protocols. This cross-layer communication introduces the possibility of time lags and state inconsistency, thereby creating a new attack surface. For example, if the price-update interface between the oracle layer (Layer 4) and the clearing layer (Layer 3) has a latency vulnerability, an attacker can exploit this time lag to conduct a flash-loan attack, manipulating the price to trigger liquidations that should not occur. Several DeFi security incidents show that oracle manipulation has become a major cross-layer attack vector. In 2022 alone, DeFi protocols lost more than $400 million to 41 oracle-manipulation attacks [66]. This requires architects, when designing inter-layer interfaces, to introduce multi-signature verification, the time-weighted average price (TWAP), and circuit breakers to isolate the chain reactions caused by a single module's failure.

Second is cross-chain bridging risk, the core challenge that a layered architecture faces in today's multichain ecosystem. When a trading system's asset-custody layer (Layer 1) resides on the Ethereum mainnet while its matching and execution layer (Layer 2) resides on an independent rollup or app-chain, the transfer of assets between the two layers must rely on a cross-chain bridge. A cross-chain bridge is, in essence, a complex consensus converter that must lock assets on one end and mint equivalent mapped tokens on the other. If the bridging protocol's smart contract has a vulnerability, or its validator network is compromised, an attacker can drain the reserve funds inside the bridge directly without breaching the underlying asset-custody contract [67][68]. This risk shows that the security of a layered architecture is determined by its weakest connection point. Future architectural evolution must strive to minimize dependence on third-party bridges and adopt instead trustless cross-chain communication protocols based on zero-knowledge proofs, so as to converge this attack surface fundamentally.

Finally, there is the endogenous risk that system complexity brings. The essence of a layered architecture is to decompose a complex system into multiple subsystems, but this inevitably increases the overall topological complexity of the system. Every newly added module and every new communication link means an increase in potential points of failure. This practice of *introducing complexity for the sake of security* is a perennial paradox in engineering. A highly complex system is often hard to subject to exhaustive formal verification, and its emergent behavior under extreme market conditions becomes harder to predict. In pursuing layered decoupling, therefore, architects must maintain constant restraint over complexity, following the principles of *least privilege* and *minimal design* to ensure that the logic of each independent module is sufficiently clear and its boundaries sufficiently well defined.

Although a layered architecture introduces the new risks above, a simplified comparison of the net risk effect helps assess the direction in which overall security changes. The risk that a layered architecture eliminates—the systemic default of a centralized entity, epitomized by the FTX collapse (a gap of about $8 billion in customer assets at the time of collapse)—far exceeds, in the historical magnitude of losses, the new risks a layered architecture introduces. To date, although the cumulative losses from cross-chain bridge attacks and oracle-manipulation incidents have reached the level of billions of dollars, they are distributed across hundreds of independent events, and the systemic impact of any single event is far smaller than the total collapse of a monolithic black box. This shift in risk profile—from *low-frequency, catastrophic-consequence* to *higher-frequency, manageable-consequence*—is the core value proposition of a layered architecture along the dimension of risk management.

### 28.8.3 Architecture as governance

When we examine the evolutionary history of traditional finance, we find that every expansion of regulators' power was often meant to patch an inherent defect in the underlying architecture. Because the monolithic black box cannot prove its own innocence, auditors are needed; because intermediaries have an incentive to misappropriate funds, custody licenses are needed; because internal matching may involve self-dealing, compliance checks are needed. A layered architecture, however, offers an entirely new line of thinking: eliminating, through technical means, the very environment that generates the incentive to break the rules, thereby rendering part of external regulation unnecessary. This idea can be summed up as *architecture as governance*. The concept is of a piece with the idea of *code is law* proposed by Lawrence Lessig in his seminal work. Lessig argued that in digital space, software architecture, like the law of the physical world, is one of the four forces that constrain behavior [69]. De Filippi and Wright extended this idea further into the blockchain domain, proposing the concept of *lex cryptographica*—the technical embedding of legal rules through self-executing smart contracts [70]. A layered architecture advances Lessig's theory from abstract normative discussion to the concrete engineering practice of financial infrastructure: it not only uses code as a means of constraint but, through modular layered design, precisely allocates different types of constraint (cryptographic enforcement, economic incentives, and governance procedures) to different architectural layers.

With respect to asset segregation, the traditional regulatory framework treats the physical segregation of customer funds from proprietary funds as a fundamental bottom line. The FTX collapse, however, demonstrated the notable fragility of institutional segregation that relies on audit reports and executive promises. In a layered architecture, the asset-custody layer is devolved to a permissionless underlying blockchain, and open-source smart contracts enforce strict account logic. This means that, absent authorization by the user's private key, no exchange operator can physically touch these assets. This cryptography-based mandatory segregation is more resistant to attack than any legal provision. Regulators no longer need to expend vast resources verifying an exchange's bank accounts, because the architecture itself already provides sufficient proof of asset safety.

With respect to information disclosure, traditional regulation treats it as a core means of protecting investors, requiring financial institutions to publish voluminous financial statements and trading data periodically. These reports, however, are often subject to lag and easily window-dressed. A layered architecture moves all data of the matching layer and the clearing layer on chain, so that the bookkeeping of every order, the triggering conditions of every liquidation, and the flow of every cent are exposed in real time to the oversight of the whole network's nodes. This natural, irrevocable transparency turns information disclosure from *a regulatory-compliance cost* into *a fundamental property of the system's operation*. Under such an architecture, on-chain transparency gives anyone the technical prerequisite to become an auditor. Transparency, however, is a necessary but not a sufficient condition for effective oversight: interpreting raw on-chain data requires professional analytical ability, and the vast majority of users lack the technical literacy to identify anomalous patterns among massive volumes of trade records. Effective community oversight therefore also requires accompanying incentive mechanisms (such as bug-bounty programs and audit contests) to attract professional security researchers to invest their attention continuously.

*Architecture as governance* does not mean the complete demise of regulation but a fundamental shift in the regulatory paradigm. As the relevant research notes, modular architecture profoundly affects the effectiveness of regulation [71]. Future regulation should no longer fixate on layering endless rule patches on top of a bad architecture but should turn toward *requiring and verifying good architecture*. The regulator's role will shift from *behavior supervisor* to *architecture certifier*, whose core task is to ensure that a trading system follows the principle of layered decoupling from the outset, to ensure the security of the inter-layer interfaces, and to ensure the degree of decentralization of the governance mechanism. This paradigm shift, however, faces real obstacles: the current regulatory framework takes legal entities, not technical architectures, as the object of regulation; the transition to architectural regulation requires regulators to substantially update their technical-assessment capabilities and to develop new legal instruments suited to decentralized protocols, a process that may take years or longer. This deep integration of technology and regulation will pave the way for a next-generation financial system that is at once trustless and compliant.

### 28.8.4 The trust market and composability

The ultimate form of a layered architecture is not merely to decompose the monolithic black box into internal modules but to open these modules to the entire ecosystem, thereby giving rise to a highly competitive *trust market*. In this market, trust is no longer a scarce resource monopolized by some centralized institution but a standardized component that can be priced, traded, and freely combined.

Composability is the core driving force of this vision. Once functions such as asset custody, matching and execution, clearing and settlement, and data oracles are encapsulated as standardized on-chain modules, they become financial primitives that can be freely assembled like standardized components. An emerging decentralized derivatives platform no longer needs to build a complete trust stack from scratch. It can choose to plug directly into the Ethereum mainnet as its asset-custody layer to obtain the highest grade of security, adopt a dedicated app-chain as its matching and execution layer to achieve low-latency trading, and integrate a decentralized oracle network to provide price data. The vision of composability, however, faces significant limitations at the execution level. When different functional modules are distributed across different chains or protocols, cross-module atomic operations (such as simultaneously adjusting the margin of multiple related positions) lose their guarantee of transactional consistency. The complexity of cross-chain margin management (involving the confirmation times of different chains, bridging delay, and state synchronization) makes a unified risk view hard to maintain in real time. Under current technical conditions, therefore, composability is better suited to low-frequency settlement-layer operations (such as cross-chain asset transfers and final clearing) than to high-frequency trading-execution-layer operations.

This free combination of modules will drive the rapid diversification of trading-system architectures. Different project teams can seek different balance points on the trust-performance frontier according to the specific needs of their target users, thereby designing a diversity of customized architectures. More importantly, composability breaks the siloing effect of traditional financial infrastructure. An excellent clearing module can serve multiple different matching engines at once, and a deep liquidity pool can be shared by multiple front-end interfaces. These network effects will greatly lower the barrier to financial innovation and push the on-chain financial system to evolve toward greater specialization and refinement.

In the trust market, the providers of the various modules face full and open competition. The modules that offer higher security, lower latency, or superior governance mechanisms will win adoption by more protocols and higher economic returns. This market-based competition grounded in code and consensus will become the main driving force pushing the on-chain trust infrastructure to evolve continuously. In the end, we will see a global financial-infrastructure network woven from decentralized modules—one with a high degree of survivability and a capacity for self-healing.

## 28.9 Chapter summary

Starting from the systemic architectural failure of the FTX collapse, this chapter proposed the trust stack method of analysis, decomposing the implicit trust assumptions in a trading system into five layers—asset custody, matching and execution, clearing and settlement, data and oracles, and governance—and, through the trust concentration metric, turning the problem of trust into a quantifiable engineering design variable. On this basis, the characterization of the trust-performance frontier revealed a fundamental engineering constraint: trustless verification and high-performance execution cannot both be optimized within the same architectural layer. Layered architecture is precisely the engineering response to this constraint: by independently choosing the balance point between trust and performance at each layer, the system can reserve sufficient performance headroom for the matching and clearing stages while making no compromise on asset safety.

The institutional evolution of traditional finance has validated the effectiveness of functional separation, and on-chain systems are now realizing a technical upgrade of the same functions through cryptography and consensus mechanisms. The app-chain practice epitomized by Hyperliquid shows that this layered migration is engineering-feasible, but the size of the validator set, the security of cross-chain bridging, and the concentration of governance power still constitute residual trust in the current architecture that cannot be ignored. The judgment framework of *sufficient decentralization* decomposes trust needs into four progressive levels—zero trust, verifiable trust, exitable trust, and replaceable trust—and establishes a clear mapping to the layers of the trust stack, providing a structured methodology for planning the path of progressive decentralization.

The trust stack model and the layered design principles established in this chapter will serve, in the chapters that follow, as a unified analytical tool for assessing the architectures of specific protocols. The next chapter focuses on the risk-management mechanisms of perpetual futures protocols, applying this chapter's layered framework to audit, layer by layer, how key components—liquidation logic, the operation of the insurance fund, and oracle dependence—differ in their implementation and risk profile across architectures.

## References

[1] Wikipedia. (n.d.). *Bankruptcy of FTX*. Retrieved from https://en.wikipedia.org/wiki/Bankruptcy_of_FTX

[2] Investopedia. (n.d.). *FTX crypto exchange collapse: Causes, consequences, and lessons*. Retrieved from https://www.investopedia.com/what-went-wrong-with-ftx-6828447

[3] CNBC. (2022, November 13). *Sam Bankman-Fried's Alameda quietly used FTX customer funds without raising alarm bells, say sources*. https://www.cnbc.com/2022/11/13/sam-bankman-frieds-alameda-quietly-used-ftx-customer-funds-without-raising-alarm-bells-say-sources.html

[4] Commodity Futures Trading Commission. (2024, August 8). *CFTC obtains \$12.7 billion judgment against FTX and Alameda*. https://www.cftc.gov/PressRoom/PressReleases/8938-24

[5] Federal Reserve Bank of Chicago. (n.d.). *Understanding derivatives: Central counterparty clearing*. https://www.chicagofed.org/-/media/publications/understanding-derivatives/understanding-derivatives-chapter-2-central-counterparty-clearing-pdf.pdf

[6] Hyperliquid. (n.d.). *About Hyperliquid*. Hyperliquid Docs. https://hyperliquid.gitbook.io/hyperliquid-docs

[7] U.S. Securities and Exchange Commission. (2025). *Custody rule modernization: A model framework for crypto asset safeguarding*. https://www.sec.gov/files/custody-rule-modernization-model-framework-121925.pdf

[8] Roy, D., Dubey, A., & Tiwary, D. (2024). Conceptualizing an institutional framework to mitigate crypto-assets' operational risk. *Journal of Risk and Financial Management*, *17*(12), 550. https://www.mdpi.com/1911-8074/17/12/550

[9] Vidal-Tomás, D. (2025). Centralized exchanges & proof-of-solvency: The guardians of trust. *Journal of International Financial Markets, Institutions and Money*, *103*, 102183. https://doi.org/10.1016/j.intfin.2025.102183

[10] Binance. (2017). *Binance exchange whitepaper* (V1.1). https://www.scribd.com/document/369374867/Binance-WhitePaper-En

[11] Hyperliquid. (n.d.). *HyperCore overview*. Hyperliquid Docs. https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/overview

[12] Ethereum Foundation. (n.d.). *Blocks*. Ethereum.org. Retrieved March 2026, from https://ethereum.org/en/developers/docs/blocks/

[13] Daian, P., Goldfeder, S., Kell, T., Li, Y., Zhao, X., Bentov, I., Breidenbach, L., & Juels, A. (2020). Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability. In *2020 IEEE Symposium on Security and Privacy (SP)* (pp. 910–927). https://doi.org/10.1109/SP40000.2020.00040

[14] DTCC. (2023, May 9). *Celebrating our 50th anniversary*. DTCC Connection. https://www.dtcc.com/dtcc-connection/articles/2023/may/09/celebrating-dtccs-50th-anniversary

[15] Ripatti, K. (2004). *Central counterparty clearing: Constructing a framework for evaluation of risks and benefits*. Bank of Finland. https://www.econstor.eu/handle/10419/211997

[16] Intercontinental Exchange. (n.d.). *Central clearing: Reducing systemic risk*. https://www.ice.com/publicdocs/Central_Clearing_Reducing_Systemic_Risk.pdf

[17] Paddrik, M., & Young, H. P. (2020). *Central counterparty default waterfalls and systemic loss* (OFR Working Paper No. 20-04). Office of Financial Research. https://www.financialresearch.gov/working-papers/files/OFRwp-20-04_central-counterparty-default-waterfalls-and-systemic-loss.pdf

[18] Berndsen, R. (2021). Fundamental questions on central counterparties: A review of the literature. *Journal of Futures Markets*, *41*(12), 2009–2022. https://doi.org/10.1002/fut.22260

[19] Dukich, R. (2022). *Liquidity management in central clearing: How the default waterfall can be improved*. NYU Stern. https://www.stern.nyu.edu/sites/default/files/assets/documents/Dukich_Liquidity%20Management%20in%20Central%20Clearing%3B%20How%20the%20Default%20Waterfall%20Can%20Be%20Improved.pdf

[20] Heilbron, J. (2024). *Central clearing and trade cancellation: The case of LME nickel contracts on March 8, 2022* (OFR Working Paper No. 24-09). Office of Financial Research, U.S. Department of the Treasury. https://www.financialresearch.gov/working-papers/files/OFRwp-24-09_central-clearing-and-trade-cancellation.pdf

[21] SEC Historical Society. (2010). *An introduction to DTCC*. https://www.sechistorical.org/collection/papers/2010/2010_0701_DTCCServices.pdf

[22] DTCC. (2024). *2024 by the numbers: The value DTCC delivers*. DTCC Annual Report. https://www.dtcc.com/annuals/2024/value/

[23] DTCC. (n.d.). *The Depository Trust Company — DTC*. https://www.dtcc.com/about/businesses-and-subsidiaries/dtc

[24] Commodity Futures Trading Commission. (2026). *The next phase of Project Crypto: Unleashing innovation*. https://www.cftc.gov/PressRoom/SpeechesTestimony/opaselig1

[25] Bank & Finance Consulting Group. (2026). *Designing financial ecosystems: A five-layer architecture for resilience, performance, and public value*. https://bankandfinance.net/designing-financial-ecosystems-a-five-layer-architecture-for-resilience-performance-and-public-value/

[26] Parry, C. (2024). Digital asset custody deciphered: A primer to navigating the challenges of safeguarding digital assets. *Journal of Securities Operations & Custody*, *16*(2), 1–15. https://www.ingentaconnect.com/content/hsp/jsoc/2024/00000016/00000002/art00002 https://doi.org/10.69554/fekb1830

[27] Van Loon v. Department of the Treasury, No. 23-50669 (5th Cir. Nov. 26, 2024). U.S. Court of Appeals for the Fifth Circuit. https://www.ca5.uscourts.gov/opinions/pub/23/23-50669-CV0.pdf

[28] Mavroudis, V., & Melton, H. (2019). Libra: Fair order-matching for electronic financial exchanges. In *Proceedings of the 1st ACM Conference on Advances in Financial Technologies* (pp. 114–128). https://doi.org/10.1145/3318041.3355468

[29] Ram, R. (2025). *The emerging architecture of clearing and settlement in digital finance* (SSRN Working Paper No. 5378367). https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5378367 https://doi.org/10.2139/ssrn.5378367

[30] Chainlink. (2025). *The blockchain oracle problem*. Chainlink Education Hub. https://chain.link/education-hub/oracle-problem

[31] Dotan, M., Yaish, A., Yin, H. C., & Tsytkin, E. (2023). The vulnerable nature of decentralized governance in DeFi. In *Proceedings of the 2023 ACM Workshop on Decentralized Finance* (pp. 1–10). https://doi.org/10.1145/3605768.3623539

[32] Commodity Futures Trading Commission. (2022, September 22). *CFTC imposes \$250,000 penalty against bZeroX, LLC and its successor Ooki DAO*. https://www.cftc.gov/PressRoom/PressReleases/8590-22

[33] Wu, X., Deng, W., Quan, Y., & Zhang, L. (2024). Trust dynamics and market behavior in cryptocurrency: A comparative study of centralized and decentralized exchanges. *arXiv preprint arXiv:2404.17227*. https://doi.org/10.48550/arXiv.2404.17227

[34] CoinTracker. (2025). *What is proof of reserves? How crypto exchanges verify asset holdings*. https://www.cointracker.io/learn/proof-of-reserves

[35] Fidelity Digital Assets. (2026). *Navigating digital assets market structure in the UK and Europe*. https://www.fidelitydigitalassets.com/research-and-insights/navigating-digital-assets-market-structure-uk-and-europe

[36] Chainlink. (2025). *Seven key cross-chain bridge vulnerabilities explained*. Chainlink Education Hub. https://chain.link/education-hub/cross-chain-bridge-vulnerabilities

[37] Outlook India. (2026). *Hyperliquid explained: How an app-chain DEX redefines on-chain trading*. https://www.outlookindia.com/xhub/blockchain-insights/hyperliquid-explained-how-an-app-chain-dex-redefines-on-chain-trading

[38] CoinDesk. (2025, March 26). *Hyperliquid's JELLY crisis exposes risks in on-chain price oracles*. https://www.coindesk.com/markets/2025/03/26/hyperliquid-jelly-short-squeeze/

[39] ChainUp. (2026). *Crypto custody guide: MPC, multi-sig & self-custody*. https://www.chainup.com/blog/digital-asset-custody-guide-mpc-vs-multisig/

[40] Nansen. (2024). *Exploring Hyperliquid: Innovation in the perp DEX landscape*. https://research.nansen.ai/articles/exploring-hyperliquid-innovation-in-the-perp-dex-landscape

[41] Xverse. (2025). *What is Hyperliquid? A guide to the high-performance Layer 1*. https://www.xverse.app/blog/what-is-hyperliquid-blockchain

[42] Rock'n'Block. (2025). *How Hyperliquid works: Architecture, order book, HyperEVM*. https://rocknblock.io/blog/how-does-hyperliquid-work-a-technical-deep-dive

[43] Yin, M., Malkhi, D., Reiter, M. K., Gueta, G. G., & Abraham, I. (2019). HotStuff: BFT consensus with linearity and responsiveness. In *Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing (PODC '19)* (pp. 347–356). https://doi.org/10.1145/3293611.3331591

[44] Hyperliquid. (n.d.). *HyperBFT*. Hyperliquid Wiki. Retrieved March 2026, from https://hyperliquid-co.gitbook.io/wiki/architecture/hyperbft

[45] OneKey. (2026, January 26). *Hyperliquid architecture explained: Security & decentralization*. https://onekey.so/blog/ecosystem/hyperliquid-architecture-explained-security-decentralization-19137c

[46] gwrx2005. (2025). *Cross-chain transfer mechanism in Hyperliquid: Architecture and proxy design*. Medium. https://medium.com/@gwrx2005/cross-chain-transfer-mechanism-in-hyperliquid-architecture-and-proxy-design-b3179e636ec7

[47] Hyperliquid. (n.d.). *Bridge*. Hyperliquid Docs. https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/bridge

[48] ByteTree. (2025). *Hyperliquid: Driven by HYPE, backed by breakthroughs*. https://www.bytetree.com/research/2025/06/hyperliquid-driven-by-hype-backed-by-breakthroughs

[49] Dwellir. (2025). *Building a real-time Hyperliquid liquidation tracker*. https://www.dwellir.com/blog/building-real-time-hyperliquid-liquidation-tracker

[50] Phemex. (2025). *Hyperliquid faces scrutiny over centralized governance model*. https://phemex.com/news/article/hyperliquid-faces-scrutiny-over-centralized-governance-model-27774

[51] Hyperliquid Hub. (2026). *HyperCore throughput update* [Post]. X. https://x.com/Hyperliquid_Hub/status/2021514450042515459

[52] Token Terminal. (2026). *Hyperliquid transactions per second*. https://tokenterminal.com/explorer/projects/hyperliquid/metrics/transactions-per-second

[53] The Block. (2025). *Hyperliquid responds to community concerns over validator issues*. https://www.theblock.co/post/333559/hyperliquid-responds-to-community-concerns-over-validator-issues

[54] Luganodes. (2025). *Hyperliquid: Redefining decentralized trading*. https://www.luganodes.com/blog/hyperliquid-redefining-dex-trading

[55] The Block. (2024, March 28). *Ethereum's 13,900 nodes are running 1 million validators, with 26% of the supply staked*. https://www.theblock.co/post/285262/ethereum-one-million-validators

[56] Ainvest. (2025). *Hyperliquid's centralized governance: A double-edged sword*. https://www.ainvest.com/news/hyperliquid-centralized-governance-double-edged-sword-defi-scalability-2510

[57] gwrx2005. (2025). *Technical architecture comparison: Hyperliquid, dYdX, and Lighter*. Medium. https://medium.com/@gwrx2005/technical-architecture-comparison-hyperliquid-dydx-and-lighter-xyz-2fd005854a7e

[58] TradingKey. (2026). *The Hyperliquid phenomenon: HYPE ecosystem's path to growth*. https://www.tradingkey.com/analysis/cryptocurrencies/more/261633931-hyperliquid-exchange-hype-dex-price-tradingkey

[59] Yahoo Finance. (2026). *Hyperliquid celebrates 4x user growth in 2025*. https://finance.yahoo.com/news/hyperliquid-celebrates-4x-user-growth-112251312.html

[60] CoinDesk. (2026, March 2). *Inside HYPE's bear market resilience*. https://www.coindesk.com/business/2026/03/02/weekend-warriors-how-hyperliquid-became-retail-s-bear-market-playground

[61] EigenLayer Team. (2023). *EigenLayer: The restaking collective* [Whitepaper]. https://docs.eigenlayer.xyz/

[62] Ritter, V. (2022, November 13). *Minimum viable decentralization (MvD): A framework for evaluating decentralized finance (DeFi) protocols*. BICon. https://bicon.li/en/2022/11/13/minimum-viable-decentralization/

[63] Esber, J., & Kominers, S. D. (2023, January 12). *Progressive decentralization: A high-level framework*. a16z crypto. https://a16zcrypto.com/posts/article/progressive-decentralization-a-high-level-framework/

[64] Barbon, A., & Ranaldo, A. (2024). On the quality of cryptocurrency markets: Centralized versus decentralized exchanges. *arXiv preprint arXiv:2112.07386*. https://doi.org/10.48550/arXiv.2112.07386

[65] Gambhir, A. (2025). A systemic risk assessment methodological framework for interconnected infrastructure systems. *Nature Communications*. https://doi.org/10.1038/s41467-025-62029-w

[66] Chainalysis. (2023, March 7). *Oracle manipulation attacks rising: A unique concern for DeFi*. Chainalysis Blog. https://www.chainalysis.com/blog/oracle-manipulation-attacks-rising/

[67] Zhao, Q., Wang, Y., Yang, B., Shang, K., & Sun, M. (2023). A comprehensive overview of security vulnerability penetration methods in blockchain cross-chain bridges. *Authorea Preprints*. https://doi.org/10.22541/au.169760541.13864334

[68] Islam, M. J., Islam, S., Hossain, M., Noor, S., & Islam, S. M. R. (2025). Securing blockchain systems: A layer-oriented survey of threats, vulnerability taxonomy, and detection methods. *Future Internet*, *17*(5), 205. https://doi.org/10.3390/fi17050205

[69] Lessig, L. (2006). *Code: Version 2.0*. Basic Books. https://lessig.org/product/code/

[70] De Filippi, P., & Wright, A. (2018). *Blockchain and the law: The rule of code*. Harvard University Press. https://doi.org/10.4159/9780674985933

[71] Henningsson, S., & Eaton, B. D. (2023). Governmental regulation and digital infrastructure innovation: The mediating role of modular architecture. *Journal of Information Technology*. https://doi.org/10.1177/02683962221114429