Fate-Constrained Ordering (FCO)

The key change we made by switching from a Chain-Centric to a Service-Centric design, compared to all other platforms, is to flip around two fundamental assumptions of blockchain architecture.

Top-Down vs. Bottom-Up

Most blockchain platforms today adopt a bottom-up approach to scalability. They establish local sequences (ledgers, chains, or state machines) within groups (committees) of nodes, followed by a global stage that settles interactions across these groups. This pattern is common in systems like Avalanche's subnets, the Cosmos Network, Polkadot parachains, Near's sharded execution, and Ethereum Layer-2 platforms such as Optimism and Arbitrum.

The rationale of partitioning nodes into several groups stems from the nature that many contracts are irrelevant or only need inter-operations occasionally. The contracts can be categorized into these groups so they get more dedicated handling for better performance and waste fewer resources. This resembles a bank having branches in different cities as an amenity to the locals and offload the processing burden by geographic distribution of their customers.

This approach enables scalability through validator specialization but introduces several architectural problems:

Ordering Uncertainty Because each group has its own local consensus, the order of transactions is only finalized within that group. Interactions that span multiple groups are not globally ordered at the time they occur. The global settlement layer must reconcile these interactions after the fact, which opens the door to race conditions and unpredictable outcomes.

Loss of Atomicity Unlike centralized, monolithic systems like banks, in a decentralized deployment, once transactions cross group boundaries, it becomes difficult to guarantee all-or-nothing behavior across multiple contracts. The lack of a shared execution context breaks end-to-end transactional guarantees.

Some platforms attempt to avoid fragmentation altogether. Solana, for example, uses a monolithic architecture where all contracts are executed by a single global validator set. While this preserves composability, it requires full-state replication and limits scalability through specialization. Others, like Sui, adopt an object-centric model that allows parallel execution when dependencies are absent, but still requires a second coordination phase when causal relationships arise. This effectively results in a two-stage composability model, which behaves similarly to bottom-up systems under contention.

In Lyquor, we address these challenges by flipping the model around. Instead of scaling from local ordering upward, we start with a global sequence:

1. We first decouple sequencing (consensus) from execution (VM), enabling a lightweight consensus layer to determine the global, total order of all contract interactions. This ordering is established efficiently, without requiring any node to interpret or execute the transactions during consensus.

2. Lyquor moves from a Chain-Centric architecture to Service-Centric. Execution happens per service by a contract-like unit named Lyquid. Each Lyquid can be hosted by a group of nodes. This means nodes are no longer grouped by chains anymore like the bottom-up approach, but through the hosting of Lyquids. This offers way more flexibility that nodes can then organically select Lyquids to host, and can freely participate in multiple groups simultaneously to max out their computation capabilities with specialization for their best profits.

3. As the sequence is finalized, each node independently follows the global order and executes the subsequence for each Lyquid it has chosen to host. A node can host all Lyquids and execute the full sequence, or it can selectively run only the Lyquids that balance its incentives or capabilities.

4. Importantly, executing Lyquids does not require the node to participate in consensus. While a node may be configured to handle both roles, Lyquor treats consensus voting and execution as distinct responsibilities, and expects them to be carried out by separate networks.

5. Even if a node executes only a subsequence corresponding to a specific Lyquid (or a set of Lyquids), it is still aware of the effects by the total order of Lyquids it did not run. The fate of the system is fixed through the global order, and each node simply unravels the portion it touches, preserving composability without requiring full execution.

This notion of fate sharply contrasts with the behavior of bottom-up systems. In those architectures, global outcomes emerge only after separate node groups finalize their local results and attempt to reconcile them. The actual order of effects across contracts in different groups is not known until global settlement, and after other factors like bridge logic, or external relayers. In Lyquor, the fate of the system (the timeline of all Lyquid calls) is determined at the global sequencing stage, before any execution begins, and must be respected by all nodes.

This is similar to a play script that has already been written. Each node picks up the script and performs only the scenes relevant to its role. The storyline is not improvised or invented during performance. It is already there, waiting to be revealed. Execution does not define what happens; it discovers what was already determined. This is the essence of Fate-Constrained Ordering (FCO): a global ordering that allows every node to reason about Lyquid interactions reliably, even while executing only a small slice of the system.

This design principle coincides with the ideas explored in Corfu, a foundational system for cloud-scale replication. Lyquor, like Corfu, separates the act of ordering operations from the act of executing state, using a shared log to impose a total order while allowing each replica to materialize state on demand. Drawing from the world of distributed systems, Lyquor carries forward the philosophy behind large-scale, efficient infrastructure and applies it to decentralized environments.

Full Nodes vs. Light Nodes

Traditional L1 platforms distinguish sharply between full and light nodes. Full nodes are responsible for both participating in consensus and executing every transaction and maintain hosting capabilities for all contracts. They are expected to act as consistent replicas of the system, maintaining identical state transitions and outputs.

Over time, the entry barrier to becoming a full node has grown significantly. This is a natural consequence of expecting every node to replicate all contracts, both in computation and storage. As the diversity and complexity of deployed applications increases, so does the cost of replication. In response, many platforms introduced the notion of light nodes, which do not vote in consensus or replicate contract state locally. They instead keep proofs or query full nodes to track specific states, but do not add to the security of the core network.

In Lyquor, we flip the assumptions around in three changes:

Lightweight, Independent Nodes We enrich the capabilities of a light node, so it effectively becomes a validator that locally replicates the selected contracts' state by following the sequencing result. Each Lyquid may contain both network state, shared by hosting group of nodes, driven by sequencing; and instance state, local to each node in the group, driven by off-sequence events. Nodes participate directly in service provisioning as a server or get embedded directly into wallets or other user-end apps as a client.

Slim, Global Composability Archive We trim down what full nodes should do in the networks and refer to them as Archival Nodes in Lyquor. They are not required to render services to users, but to execute the globally ordered sequence of all Lyquids, for two main purposes:

1. Supplying side effects and output data for contracts not hosted by a given node, and
2. Ensuring baseline availability for any Lyquid, especially during its onboarding phase.

Although archival nodes may still behave like regular nodes if desired, their essential role lies in composability and availability, not service rendering.

Service-First Scalability The majority of the network is made of lightweight regular nodes, not the archival nodes. Once quickly bootstrapped, a regular node can just use its local information for all services.

Additionally, archival nodes can offer hints for performance optimization. When a regular node executes the subsequences, archival nodes may help the regular node skip redundant work or understand runtime dependencies better. These hints do not affect correctness or determinism. They are simply early exposures of an already-fixed ordering, revealed for efficiency.

This model requires no separate software stacks. Archival and regular nodes run the same protocol but follow different strategies. Archival nodes are general-purpose: they require no specialized hardware and earn stable, universal staking rewards for maintaining full availability. Regular nodes, in contrast, curate a portfolio of profitable staking of contracts. They can earn more, but their returns depend on demand and may require specialized resources, driven by the services they choose to host.

To summarize, partial execution is the new norm, and full-state retention is secondary. Rather than layering light nodes as an afterthought with centralized API which undermines security, Lyquor makes decentralization and specialization a coherent starting point. Scalability emerges naturally from a model where nodes are free to choose their scope of execution, without sacrificing global composability.

Example: Two DEX Contracts

To better understand how Fate-Constrained Ordering (FCO) works in practice, let’s consider an example involving two DEX contracts, A and B. For simplicity, we'll focus on a shared liquidity token C, which both DEXes use for asset exchange.

Assume there is a node X that is only interested in DEX A. It does not wish to host DEX B. However, since both A and B involve contract C to move tokens, any side effect B causes to C, such as modifying a user's balance, must still be visible from A’s point of view, even though X does not care about B directly.

In this example, FCO guarantees composability while allowing partial execution. Let’s walk through the key steps:

1. Node X hosts A and C, since C is invoked by A. While it is possible to skip executing C and retrieve all A-to-C call results from archival nodes, executing C locally is often preferred for efficiency and trust minimization, especially when C is a widely used token like USDC.
2. Meanwhile, another node Y is only interested in DEX B, so it hosts B and C. Since C is a shared liquidity contract, its state must remain consistent across both A and B. For example, a user's balance in C must reflect all relevant transactions, regardless of which contract caused the change. This ensures no double spend or state inconsistency.
3. When node X executes transaction 3, which calls a function in contract A, that function may internally invoke a function in C. To preserve global consistency, node X must schedule transaction 6, which modifies C, after transaction 3 according to the global sequence. For example, transaction 3 may already drain the user's remaining balance in C. If transaction 6 then attempts to transfer additional tokens, it should fail. If C were to process its transactions independently without respecting this order, the resulting state would be incorrect.
4. Similarly, when node Y executes transaction 7, which invokes C from contract B, the effects of A's earlier execution (up to transaction 7) must already be visible. Even though node Y did not run A, the changes made to C are part of the global fate and must be respected. These external effects can be learned from archival nodes.

If there is no causal interaction at a given point in the sequence, for example when A and B are not currently calling the shared contract C, they can still be executed in parallel. This holds even if both contracts depend on C elsewhere in the sequence. FCO enables this fine-grained concurrency by enforcing only the ordering constraints that actually exist at each step, allowing unrelated parts of the execution to proceed independently while preserving global consistency.

It is also worth noting that even though node X must observe all B-to-C interactions to ensure consistency, it does not need to understand how B arrived at those calls. X only needs to observe the terminating effects on C, not the internal execution path inside B or any of B’s interactions with other tokens like D. This property allows nodes to remain lightweight and focused, even when composability spans across multiple contracts.

This example illustrates how FCO enables seamless composability across selectively hosted contracts. Nodes can independently execute only what they care about, while still respecting the global ordering of the system.