Overview

DFlow is a protocol that constructs order flow markets
Suggest Edits
DFlow is a Solana protocol that constructs order flow markets, in which arbitrary, off-chain entities are empowered to sell signals to on-chain programs. A specialized and primary use-case of the DFlow protocol is selling flow toxicity signals to decentralized liquidity-bearing venues, such as AMMs and CLOBs that are then able to specialize their behavior based on the toxicity of order flow.
Off-chain parties, known as "endorsers", who are typically part of the order flow origination process, such as wallet providers, attach signed blobs of information known as "signals" to swap transactions through a set of plug-in protocols known as signal adapter protocols (SAPs).
Decentralized venues specialize the cost of using their protocol using modular fee curve programs (FCPs). FCPs are small, pure functions that execute custom order flow pricing logic at various points of execution in a SAP.
The DFlow protocol modernizes the liquidity layer of Solana, by enabling greater expressiveness: decentralized venues are able to express preference for certain types of order flow through modular FCPs.

Problem Statement

Decentralized markets enable price discovery through different market structure than centralized markets. Thus, decentralized market structure poses a different set of problems for market makers, who provide liquidity and profit through spread capture, namely that they must price the probability of toxic flow differently. Validators on the Solana network are responsible for constructing and propagating new blocks, and therefore hold a privileged position in that they are able to order transactions in ways that can be trivially beneficial for certain parties at the economic expense of other parties. Namely, this privilege can be exercised at the expense of liquidity providers, who provide a valuable service through posting resting quotes to the network. Furthermore, validators are often amenable to handshake deals with non-validating third parties who wish to express their opinion on the ordering of transactions inside of a block at the further expense of resting liquidity.
DFlow's order flow markets aim to solve this problem by allowing front-ends and wallets to annotate order flow with toxicity signals. Toxicity signals are signed blobs of information containing information endorsers provide about the origination of the order flow. Solana programs which enable liquidity provision can parse these toxicity signals on-chain, and branch on the information in ways that maximize that Solana program’s individual utility curve.

Solana Transaction Annotations

The Solana transaction annotation is a technique which describes how arbitrary signed blobs of information can be attached to transactions. Annotations are built with a lightweight wrapper around instruction introspection enabled by the SVM. Solana transactions are composed of individual instructions, and a transaction annotation is an Ed25519 program instruction that is added to the transaction at a specified index. Instruction introspection allows Solana programs to view the signed data annotating the transaction on-chain.
Transaction annotations are one of the building blocks of the DFlow protocol, and are used to annotate order flow with toxicity signals.

Toxicity Signal Standard

The toxicity signal standard describes a specific type of transaction annotation attached specifically to order flow transactions, and the data format expected by consumer Solana programs of this annotation. The toxicity signal is an eight byte buffer interpreted on-chain as a f64, whose value should lie between 0 and 1. A value of 0 confers non-toxicity to the fullest extent, while a value of 1 confers toxicity to the same extent.

Endorsers

Endorsers are off-chain parties that are typically, but not necessarily, involved in the order flow origination process such as wallets. Endorsers, through privileged positions, are able to observe information about the order flow origination, are able to translate these observations into toxicity signals that are then sold on-chain to Solana programs. The sale of these signals can be viewed as a form of bartering, as Solana programs will pay for these toxicity signals in-kind, typically through swap fee discounts.
Endorsers each carry an Ed25519 private key for signing, and hold an endorsement algorithm that outputs toxicity signals, which are signed, during the order flow origination process.

Endorser Registry

The endorser registry is a decentralized, permission-less, global bulletin board of endorsers posted on-chain to the Solana network. Endorsers must add themselves to the endorser registry before they are able to begin selling toxicity signals to decentralized venues.
The modular fee curve programs (FCPs) lookup into the endorser registry to ensure that the endorser is allowed to sell toxicity signals. The endorser registry is convenient state which provides to FCPs a single referential bulletin board that aids in defining the logic of a fee curve.

Fee Curve Programs (FCPs)

Fee curve programs are functors which map the product category of signals and endorser identity into an arbitrary third category. These fee curve programs can be invoked by any arbitrary Solana program, but are typically invoked by signal adapter protocols which are individually deployed on a per-DEX basis. FCPs can encode arbitrary logic so long as they don't emit side effects.
FCPs return an arbitrary type, defined by the signal adapter protocol (SAP), as a function of the signal information and the signal endorser.

Piecewise

FCPs will generally follow the pattern of segmenting signal transformations based on the endorser identity.
FCPs can encode arbitrary piecewise functions.

Signal Adapter Protocols

Signal adapter protocols are Solana programs that parse inbound signals and invoke one or more FCPs, and invoke other arbitrary Solana programs, such as AMMs, CLOBs, lending protocols, NFT mints. They specify the return type of the FCP, and any FCP which adheres to the interface can be modularly dropped into the SAP.

Segmenter Signal Adapter Protocol

The Segmenter SAP is the first and primary use-case of signal markets. The Segmenter SAP will receive toxicity signals and invoke modular FCPs prior to invoking swap instructions on various AMMs and CLOBs. The modular FCPs in this case return information on the cost of accessing liquidity.
For the Segmenter SAP, a specialization which allows DEXs to branch on toxicity information, the signal adapter protocol requires a return type of a 64-bit floating point number as specified by IEEE standard 754.
The FCPs expected by the Segmenter SAP returns a 64-bit floating point number.

Bartering & Signal Markets

Endorsers, signals, SAPs, and FCPs are all specified on a per-application basis. Consequently, the method by which the endorser is paid for their signal is also on a per-application basis. In the Segmenter SAP, the method by which the endorser is paid is through fee discounts to its users. This is a form of in-kind payment given to the endorser by the AMM or CLOB.

Signal Lifecycle and Program Interaction

Putting it all together, the lifecycle of a signal is straightforward. Endorsers create and endorse the signal, and include it in a Solana transaction through Solana Transaction Annotations. On-chain, signal adapter protocols (SAPs) which are defined per-application class, will invoke fee curve programs (FCPs) based on its own business logic.