Crate fts_solver

Flow Trading Service (FTS)

This crate is part of a collection of crates that together implement flow trading as proposed by Budish, Cramton, et al, in which trade occurs continuously over time via regularly-scheduled batch auctions.

The different crates in this workspace are as follows:

• fts_core: Defines a set of data primitives and operations but defers the implementations of these operations, consistent with a so-called “hexagonal architecture” approach to separating responsibilities.
• fts_solver: Provides a reference solver for the flow trading quadratic program.
• fts_server: A REST API HTTP server for interacting with the solver and persisting state across auctions.
• fts_sqlite: An implementation of the core data operations using SQLite, suitable for exploration of flow trading-based marketplaces such as a forward market.

FTS Solver

This package defines a few basic types and a solver interface to operate over these types. Presently, the following solvers are provided:

• feature = ["clarabel"] – Uses the Clarabel interior point solver for the quadratic program
• feature = ["osqp"] – Uses the OSQP ADMM solver for the quadratic program

Additional solvers will be developed as needed. The present implementations are intended as “reference” for future work.

There are a few additional features exposed by this crate. If an application intends to (de)serialize the primitive data types directly, enabling feature = ["serde"] will provide Serde bindings.

Primitive Types

There are two externally-defined types ProductId and AuthId, which allow the application host to provide their own implementations. These are black-boxes as far as the solver is concerned – they just need to implement Clone + Eq + Hash + Ord.

This crate defines a Submission<AuthId, ProductId> type, which is intended to encapsulate a single bidder’s submission. A submission is a combination of auths and costs: an auth defines a portfolio (a sparse vector over product space) and the minimum and maximum allowable trade of this portfolio. Costs define a linear combination of auths (a group) and a utility function, whose domain additionally constrains the space of feasible outcomes. It is assumed by the solver that auth ids are globally unique; that is, the auth ids should be disjointly partitioned amongst the submissions. (It does not otherwise cause an error, but will likely yield unexpected results.) Refer to the implementations of src/types/auth.rs and src/types/cost.rs for more details on these types. Refer to tests/simple_solve.rs for an example assembling two submissions and solving them.

TODO

• Warm-start interface
• Large-scale tests
• Enhanced dual reporting
• Automatic determination of error tolerances based on input
• Bespoke ADMM implementation

Modules

clarabel

Implementation using the Clarabel interior point solver

export

Utilities for converting the derived QP to standard file formats

Structs

Auction

A simple wrapper around the auction input so we do not leak implementation details

AuctionOutcome

The outcome of an auction

DemandCurve

A demand curve represents utility via a piecewise linear function

Point

A demand curve is defined by its points, which in turn have an associated quantity and price

PortfolioOutcome

Solution data for an individual authorization, containing the trade quantity and effective price.

ProductOutcome

Solution data for an individual product, containing the market-clearing price and total volume traded.

Segment

A single line segment satisfying q0 ≤ 0 ≤ q1 and p1 ≤ p0

Submission

The fundamental input to a Solver implementation, containing an independent collection of portfolios and demand curves.

Enums

SubmissionError

The error type for when preparing a submission fails

Traits

Solver

The Solver trait defines the interface for market-clearing solvers.

Functions

disaggregate

If a demand curve is an aggregation of individual demand segments, then we can disaggregate a demand curve into these segments. This is useful for constructing the optimization program.