Costs

In a flow trading market, bidders create submissions out of various bid primitives. There are only two such primitives: an auth and a cost. This guide provides an explanation for the latter.

What is a Cost?

A cost is an explicit definition of a group of auths alongside a demand curve. Collectively, the costs measure the utility for any potential trade outcome. Thus, costs permit the core optimization to find an outcome that maximizes social welfare (gains from trade) within the set of feasible trades.

What is a Group?

The flow trading paper pairs a demand curve directly to a portfolio (the pairing of which we call an auth). A cost can either be thought of as a generalization of an auth, or as an additional bid primitive to allow for richer preference expression.

This bid primitive defines a linear combination of portfolios (the group) and associates an additional demand curve to this group.

When a group consists of a single auth with weight 1, a cost works similarly to an auth, with the caveat that costs are additive. (So if we were to define an auth with a particular demand curve, and additionally define a cost associated exclusively to the same portfolio, the effective demand curve would be the sum of the two).

If the group instead consists of two auths each with weight 1, then the optimization gains a degree of freedom to mix-and-match the two auths in a way that maximizes gains from trade: 1 unit of the first portfolio is equivalent to 1 unit of the second, so the optimizer is free to meet an overall total in whichever way it determines is best. If the two auths are not perfect substitutes, they can have different coefficients (even potentially of mixed signs).

Superficially (but not semantically), groups look a lot like portfolios, but with auth ids keyed to weights instead of product ids.

Note

Mathematically, it is accurate to think of a portfolio as a direction vector in product space and a group as defining an inner product of a potential trade outcome with the weight vector.

For example, supposing the bidder has defined auths A1 and A2, the following are all valid groups:

// A "singleton" group that directly prices A1
G1 = { A1: 1.0 }
// A "substitution" group that treats A1 and A2 as perfect substitutes
G2 = { A1: 1.0, A2: 1.0 }
// An otherwise perfectly valid group
G3 = { A1: 0.5, A2: -0.75 }

How is Utility Specified?

Utility is specified via a demand curve, with the usual convention of positive and negative rates corresponding to buying and selling. Demand curves must be non-increasing and must have a domain permitting zero trade.

The reference implementation accepts two ways to specify a demand curve.

Option 1: Piecewise-Linear Demand Curve

The first and primary way to specify a demand curve is via a list of points, which are interpreted to correspond to a piecewise linear curve. This specification takes the form of:

type PWLDemandCurve = { "rate": number, "price": number }[]

This list may contain arbitrarily many elements; as mentioned, the only restrictions are

1. FirstPoint.rate <= 0 <= LastPoint.rate
2. For each point P[i], P[i].rate <= P[i+1].rate and P[i].price >= P[i+1].price.

Note that this permits “flat” segments on the demand curve. While this is permissable as far as the optimization is concerned, there may be a desire for a market operator to impose a validity requirement of having a minimum slope. The reference flow trading server does not impose such a requirement, but a market operator is encouraged to enforce such a restriction on their systems before forwarding a submission to the server.

Option 2: Constant Demand Curve

The second approach to specifying a demand curve assumes a constant price, allowing for a potentially infinite domain. As before, the market operator might wish to restrict this type of specification in order to enforce a minimum slope, but the reference server does not require this. The constant demand curve is specified as a triplet of (min_rate, max_rate, price):

type ConstantDemandCurve = {
  // negative infinity if omitted or null
  min_rate?: number | null,
  // positive infinity if omitted or null
  max_rate?: number | null,
  // the constant price to extend across the domain
  price: number
}

Summary

Costs assign utility to groups of auths, allowing for optimization to select an outcome that maximizes gains from trade and social welfare. This outcome will be constrained by the feasible trade regions defined by the auths and costs.