Introduction

Fuel is the first blockchain network that enables the use of functors (objects that can be used as functions) called Predicates. They’ll have major implications on transaction validation and execution, and DEX architecture design. At Composability Labs, we’re using Predicates to develop a fully on-chain central limit order book (CLOB) called Spark. In this article, we want to introduce you to the concept of Predicates within the FuelVM ecosystem, explore the working principles of Predicates, and dive into how Predicates are used in Spark.

Predicates in the FuelVM Ecosystem

To understand Predicates in regards to their use in Fuel (and other blockchain networks), we recommend that you first become familiar with the unspent-transaction-output (UTXO) accounting model used by FuelVM. To provide new readers with an introduction to the UTXO accounting concept, we’ve included Appendix A: The UTXO Accounting Model.

Simply stated, a Predicate is a delegate function that returns either True or False based on transaction input and output metadata. On the Fuel network, Predicates are represented as an address. Each address is a hash of a specific Predicate function’s bytecode. Similar to Ethereum addresses, Predicate addresses can receive tokens and send tokens. Unlike Ethereum addresses, the conditions to spend tokens belonging to a Predicate address are defined by the Predicate’s function. Any user or client can spend tokens behind a Predicate address, so long as the function’s conditions are satisfied.

Working Principles of Predicates

There are three primary working principles of Predicates.

First, a Predicate is not a smart contract, it is a pre-defined function that returns a boolean. Tokens behind a Predicate address can be spent without a private key as long as the Predicate function returns true. The flexibility in how functions can be constructed allow for fully permissionless transactions. To enable this mechanism, the conditions for transactions involving a Predicate must be defined upfront. These conditions are used as inputs when a script is run to evaluate a Predicate’s boolean result.

Second, a Predicate is never “deployed” onto the Fuel Network. On-chain, the Predicate code is only represented in its hashed form as an address. This trait requires that users provide the bytecode for a Predicate function as a transaction condition, along with the defined inputs and outputs.

Third, a Predicate is stateless. Due to their stateless nature, Predicates are deterministic and can only access data available in the transaction conditions. They don’t rely on on-chain data or store data on-chain. Predicates can also be “pruned” when they are no longer needed.

The working principles of Predicate result in the following benefits:

Transaction Flexibility: Predicates allow for the creation of highly customizable transaction conditions. Users can define specific rules and requirements that must be met for a transaction to be valid, enabling more complex and tailored transactions. Recently, Predicates have become gas-metered and they’ve started allowing backward jumps, this lifts the restriction on the usage of loops.
Improved Efficiency: Predicates enable faster and more efficient transaction processing. By defining conditions upfront, the validity and execution of transactions can be determined prior to execution, reducing the need for arbitrary ordering and gas estimation. Additionally, the use of the UTXO model allows transactions to occur in parallel by avoiding account state conflicts. This leads to lower transaction costs and faster transaction confirmation times.
Scalability and State Reduction: Predicates contribute to improved scalability by minimizing state growth. Unlike traditional smart contracts, predicate code does not contribute to the blockchain’s state, reducing the strain on the network and the requirements for running nodes. This helps maintain network performance and mitigate the risk of centralization.
Enhanced Security: Predicates provide an additional layer of security by allowing transactions to be locked behind specific conditions. This ensures that transactions can only be executed when the predefined conditions are met, preventing unauthorized access and potential attacks.

Implications of Predicates on DEX architecture

There are two dominant DEX architectures employed today:

The first dominant architecture design utilizes an automated-market-maker (AMM) implemented via a smart contract. The AMM architecture operates entirely on-chain but is generally burdened by capital inefficiencies. A great example of an AMM-based DEX is Uniswap.
The second dominant architecture design utilizes an off-chain order-book and on-chain settlement. This architecture is more capital efficient than AMM-based DEXes and optimizes on reducing gas fees, but has a reliance on off-chain components. The downside of off-chain components are regulatory, censorship, and liveliness risks. Some examples of DEXes that use this type of architecture are DyDx, 0x, and OpenSea. Both architectures require a temporary escrow party or contract.

Predicates, uniquely enabled by Fuel, open the doors for an entirely new DEX architecture. In a Predicate-based DEX architecture, an order maker defines a Predicate function with conditions that allow order takers to spend tokens at the Predicate address. As an example, a Predicate function could allow an order taker to assume ownership of tokens if the output of the taker’s transaction sends tokens (of a specific asset type) to the maker’s desired address. To publish their order, a maker would hash their Predicate function to produce an address, then send tokens they want to trade to the address. Orders created using Predicates are fully permissionless and can be executed atomically without needing an escrow.

An order book built with this model, such as Spark, is cheaper than an AMM because there is no need to spend gas on saving state or order data onto the blockchain. Additionally, there are no risks brought on by the presence of off-chain components.

Lastly, due to the flexibility of Predicate functions, orders built with Predicates can include “escape-hatches” and other complex logic, such as enforcing smart contract state changes, or receiving approval from a third party fraud auditor.

Predicates in the Spark Limit Order Book

Spark uses the Predicate-based DEX architecture to implement a fully on-chain central limit order book (CLOB). Each order, consolidated and tracked centrally by Spark, is a simple Predicate authorized asset transfer that doesn’t require costly state writing. With a data availability layer enabling public order visibility, on-chain verification is achieved by checking the Predicate address balance. This approach provides the capital efficiency advantages of centralized limit order books while preserving decentralization. Traders gain enhanced order control while benefiting from the inherent advantages of blockchain technology.

An illustration of a simple trade on Spark:

Conclusion

FuelVM’s Predicate construct introduces a new approach to transaction authorization, opening the doors for DEX architectures that solve for the challenges faced by AMMs and off-chain order books. Already, Composability Lab’s Spark CLOB uses Predicates to achieve trustless swaps, censorship resistance, regulatory resistance, and capital efficiencies. Critically, Predicates also further FuelVM’s mission of improving the scalability of Ethereum by providing a means to avoid state-bloat on the network.

Appendix A: The UTXO Accounting Model

The UTXO accounting model, popularized by Bitcoin, is an alternative to the account-based model commonly used in blockchain networks like Ethereum and Solana. In the UTXO model, assets are represented as transaction outputs (called tokens) with a specific value and ownership. tokens aren’t held in a central account, rather they can be thought of as disparate fixed-value coupons with defined spending conditions. In contrast, transactions in account-based models deduct or add assets to specific accounts, resulting in changes to the account balances stored in the network’s ledger. This video provides a deeper overview of UTXO based accounting if you’re interested.