What Is A Trade?¶
Introduction¶
What is a trade?¶
Traditional Representation¶
In traditional on-chain prediction markets, a trade is defined as an exchange of tokens. One participant sends cash, the other sends specific outcome tokens. Execution depends on both parties holding the correct inventory in the correct representation.
Under that definition, many economically valid trades fail. Not because they are unsound, but because one side does not hold the required tokens, or because the trade would require intermediate transformations or flash loans to complete.
Valid trades are defined by representation.
PredictionSwap Representation¶
PredictionSwap adopts a different definition.
A trade is not an asset swap. A trade is a pair of equal and opposite exposure transformations applied to two accounts.
Execution depends only on the resulting economic state. If both participants remain solvent in every possible outcome, the trade is valid and executes.
The examples below illustrate the difference between defining a trade as a token exchange and defining a trade as a state transition.
A Simple Structural Example¶
Consider a mutually exclusive outcome market:
Example 1¶
Traditional Systems¶
Alice holds:
- $10 only
Bob holds:
- \(5\,\text{YES–R}\) tokens
Alice wants to buy \(2\,\text{YES–R}\) at price \(0.6\).
- Alice sends $1.2
- Bob sends \(2\,\text{YES–R}\)
After Trade¶
Alice:
- $8.8
- \(2\,\text{YES–R}\)
Bob:
- $1.2
- \(3\,\text{YES–R}\)
Execution succeeds, both participants have the correct tokens for the trade.
Exposure Accounting¶
Step 1 — Translate Holdings to Exposure Vectors¶
Initial:
We translate all holdings Alice and Bob have into exposure vectors.
\(e_k\) tells us how much money the user has if outcome \(k\) happens.
Alice has $10:
Bob has \(5\,\text{YES–R}\) tokens:
Step 2 — Translate the Trade into Exposure \(\Delta\)¶
Alice wants to buy \(2\,\text{YES–R}\) at price \(0.6\).
Translation:
Combined exposure change:
Bob agrees to take the opposite exposure:
Step 3 — Apply Equal and Opposite Updates¶
Alice:
Bob:
The trade executes because both accounts still have positive exposures in every possible world.
No token inventory is required.
Example 2 — Trade That Fails Under Traditional Token Holdings¶
Traditional Model¶
Now suppose:
Alice holds: - $10
Bob holds: - \(5\,\text{NO–G}\) tokens
Alice wants to buy \(2\,\text{YES–R}\) from Bob for $0.6.
Bob has no \(\text{YES–R}\) to sell.
Therefore the trade fails.
Exposure-Based Model¶
Alice holds: - $10
Bob holds: - \(5\,\text{NO–G}\) tokens
(Bob has $5 if either \(R\) or \(B\) happens.)
Step 1 — Translate the Trade into Exposure \(\Delta\)¶
As before Alice wants to buy \(2\,\text{YES–R}\) for $0.6.
Recap:
Combined exposure change:
Bob agrees to take the opposite exposure:
Step 2 — Apply Equal and Opposite Updates¶
Alice:
Bob:
The trade executes because both accounts still have positive exposures in every possible world.
No token inventory is required.
Structural Difference¶
Traditional model¶
- Requires specific asset inventory
- Trades may fail due to token representation
Exposure model¶
- Updates payoff vectors directly
- Trades depend only on economic capacity
- Representation does not constrain execution
Significance¶
Liquidity without inventory¶
Because trades are expressed directly as exposure deltas, execution updates payoff vectors symmetrically:
Trading is a redistribution of exposure between participants.
The trade executes if and only if the resulting exposure vectors remain solvent:
Liquidity therefore becomes a rule over admissible exposure changes, rather than a pool of pre-allocated tokens.
Intents simplify¶
An intent specifies:
- A desired exposure change \(\Delta e\)
Matching simply requires pairing with
- A corresponding exposure change \( - \Delta e\)
New Automatic Market Makers¶
A new powerful class of Zero Sum Automatic Market Makers becomes possible as liquidity providers no longer manage pools of YES and NO tokens.
ZAMMs simply decide whether to accept a proposed exposure change \(\Delta e\).