This section is not necessarily accurate. The technical architecture has changed, and is now more modular.
[Improve to discuss both the protocol-owned liquidity, and the “automatic” concentrated liquidity]
The Futarchy Protocol allows organizations adopting futarchy governnace to allocate some of its protocol-owned liquidity to provide liquidity for conditional pools. We assume the protocol liquidity in the form of LP tokens for a TOKEN/CURRENCY pair.
The first step for market evaluation of a proposal, is to withdraw liquidity from these LP tokens, getting back the separate TOKEN and CURRENCY tokens. These will be further split into conditional tokens as explained below.
The Futarchy Protocol uses the Gnosis Conditional Token Framework (CTF). Today, these are currently used mostly for prediction market applications, but are much more general, and allow the implementation of conditional markets.
The first step is preparing a condition, alongside a definition of the oracle, called the Approval Oracle, responsible for determining within the system whether the proposal was ultimately accepted or not by the resulting organization. In the simplest implementation, this will be a simple (YES, NO) decision; in the context of proposals, we also call these respectively the (p=pass, f=fail) outcomes.
After a condition is prepared, based on the designated oracle, we can then proceed to splitting collateral. We’ll split both collateral assets:
TOKEN → pTOKEN + fTOKEN
CURRENCY → pCURRENCY + fCURRENCY.
These are called conditional tokens. If the proposal ultimately passes, pCURRENCY and pTOKEN will be redeemable back to CURRENCY and TOKEN, respectively, otherwise the fail tokens will be redeemable.
In a regular prediction market implementation, we’d be interested in the prices between pass tokens and the regular underlying collateral, such as the pTOKEN/TOKEN ratio, which can represent the probability of the proposal passing.
In the futarchy protocol, however, this is not done. None of the protocol-owned liquidity is used to create or subsidize such prediction markets.
Instead, we create two conditional token pools:
The “pass” pool — pTOKEN/pCURRENCY — which represents the price if the proposal passes.
The “fail” pool — fTOKEN/fCURRENCY — which represensts the price if the proposal fails.