Futari: Make Decisions Using Prediction Markets

Abstract

Futari (a wordplay on “Futarchy”) applies decision market technologies to address challenges faced by blockchain middleware services (oracles, bridges, public goods, staking, identity etc.). ETH validators elect trustworthy delegates to adjudicate misbehaving middleware services. The adjudication efficiency of delegates is enhanced with decision markets so that hundreds of middleware may be serviced with the same set of delegates, scaling those with the highest reputation.

Overview

The problem of present-day blockchain middleware, such as oracles, public goods funding, bridges, staking services, is that they become unsafe if the economic values guarded by these services exceed the staked value of their owned governance or rented re-staked tokens.

A possible solution is to enshrine middleware into the base consensus itself, giving it the same security model as the blockchain operating system. However, for various reasons, one of which is that some middleware involves a subtle element of subjectivity (e.g. ETH-USD price oracle), this threatens to overload the base consensus.

Another possible solution is re-staking where Ethereum stakers can simultaneously use their stake as a deposit in another protocol. However, because of the risk of being slashed if middleware services misbehave, the stake behind any specific middleware service is expected to be a small fraction of the total sum, circling us back to the present-day challenge of separate gov tokens securing separate middleware services.

Our solution derives its security model from a committee of elected delegates (a generalized version of Vitalik’s design here), and derives its efficiency from decision markets.

To address the common failure mode of middleware (e.g. oracle gov token takeover), we set up a contract where there are 13 delegates. Every week, there is a vote, where ETH validators can replace one of the delegates.

• There is no slashing, so participation could be universal instead of fragmented.

• The security model is simple: If you trust the current set of delegates, you can trust their decisions for at least the next six weeks, even if you believe ETH validator collusion has taken place, which is enough time for an orderly exit. There’s definitely an assumption that there exist some intrinsically trustworthy actors in the world and that these actors can be discovered. But this is still a much weaker criterion than an assumption that protocol designers can enshrine a set of such actors that everyone will be ok with.

We can then use the decisions of these delegates to detect and backstop middleware failure modes.

Then of course is the matter of efficiency: we want to discover and pool the most trustworthy actors discoverable into one pool and use it to safeguard hundreds of middleware services. This means that the 13 human delegates must make decisions with in-human efficiency.

To solve this, we use a fraud-proof mechanism resolved with decision markets. Applications post a bond to assert correctness optimistically. Anyone can post a counter-bond and challenge the output. The bond and counter-bond are then used to seed a prediction market that gets bettors involved. The prediction market can resolve the dispute by settling to the majority side unless it is escalated to the delegates for adjudication. If escalated, the delegates will vote and settle the prediction markets.

• We expect that challenges would be infrequent because of the bonding mechanism, and escalations would be very rare because of default settlements through prediction markets. As a result, human intervention would be very rarely needed.

Delegates Election

ETH validators opt in (e.g. through Eigenlayer) to elect delegates. By doing so, they receive protocol token $FUT as voting rewards. These voting validators are called ETH re-stakers. $FUT has a fixed supply S0 and is emitted according to a 4-year halving schedule like Bitcoin. Out of these, a portion p1(e.g. p1=60%) is distributed to ETH re-stakers that opt in to vote, a portion p2(e.g. p2=10%) is distributed to delegates, a portion p3(e.g p3=30%) is distributed to protocol developers, such that p1+p2+p3=100%.

ETH re-stakers elect delegates according to the procedure proposed by VB. The number of delegates is N=13, and every period T=1week, a vote will take place to replace 1 delegate. The governance procedure shall follow a standard Compound-like Propose-Vote-Execute procedure, under a TimeLock contract. The TimeLock contract is the only privileged actor that can add/remove delegates. $FUT holders are responsible for voting upon which particular middleware to be serviced by delegates.

Optimistic Fraud Proof

The delegates are responsible for judging correctness of a result from a higher level layer (in particular, it is not expected that the delegates will provide a correct alternative; it only provides a yes/no answer). In general, the workflow is as follows: a middleware program subscribes to use the delegates for adjudication.

Each time the middleware program has a value update (framed generically), say at time T0, it calls the “update” method in a Verifier contract to store the signature of current update (the signature could be the raw value, hashed value, or Merkle root, or an address to be whitelisted, depending on the particular application), along with the current timestamp and index (increment by 1 upon each update), and set the current status to be “pending”. For each channel (a channel corresponds to a particular service such as a ETH-USD feed), index must be monotonically increasing by 1 (such that if index=i has not been finalized, index=i+1 cannot be processed). Different channels have different authenticated user sets that can call the “update” method.

This signature is ready for anyone to challenge, within a challenge period between T0 and T1 (e.g. T1 = T0+4hour). At the same time, the middleware program also stakes a bond B, which is ready to be forfeited by the Verifier contract in the case of a successful challenge (in the case of no challenge or unsuccessful challenge, the bond will be returned). By default, the signature is optimistically considered as valid, if no one challenges within the challenge period. Once the challenge period has elapsed, anyone can call the Verifier contract to change the status to be “confirmed” and no further challenge is allowed.

Within the challenge period, anyone that thinks the signature is incorrect can call the “challenge” method in the Verifier contract by posting a bond of value C (C >= 2B) and submitting an alternative signature. At the end of the challenge period, if there is at least one challenge submitted, then all challenges are ranked according to the bond value and time priority, such that the highest-ranked (lexicographical sorting on bond value descending and submission time ascending) challenge is escalated to be adjudicated (and all other challenges are ignored).

Resolution through Decision Markets

To make the adjudication process more efficient, a prediction market is spun up (prediction of the delegates council final adjudication) at time T1 (i.e. at the end of the challenge period).

The specific prediction market works as follows: the two outcomes of the prediction market are “yes” and “no”, with “yes” corresponding to challenge unsuccessful (i.e. original update is correct) and “no” corresponding to challenge successful (i.e. original update is incorrect). Between T1 and T2 (e.g. T2 = T1+1day), the prediction market is active. For every dollar deposited into the prediction market contract, 1 “yes” token and 1 “no” token is minted to the depositor simultaneously (so that every V dollars deposit mints V “yes” tokens and V “no” tokens). “yes” and “no” tokens can be traded freely in a secondary market, in particular against a uniswapV2-style AMM that is spun up. (For instance, a user that believes in the outcome to be yes can first deposit V dollars and sell all the minted “no” tokens against the AMM for “yes” tokens.) Holders of both “yes” and “no” tokens can also LP in this AMM.

At time T2, the prediction market transits into a settlement phase during which time no more deposit or trading is allowed. Suppose at T2, 1 “yes” token is worth $p while 1 “no” token is worth $q as implied by the AMM. [The specific math is follows: Suppose at T2 the balance of “yes” tokens in the AMM is x, the balance of “no” tokens in the AMM is y, then the price of “yes” in terms of “no” is y/x, i.e. p/q=y/x; along with the invariant that p+q=1, (p,q) can be solved to be (y/(x+y), x/(x+y))]. To minimize the adjudication work of the delegates, the prediction market settles as follows: instead of invoking the delegates to manually settle in every case, the settlement by default settles to the majority opinion as implied by the prediction market, i.e. it settles to “yes” if p > q and settles to “no” if p < q.

Escalation

Settlement is escalated to the delegates only if at least one of the following conditions hold: (1) if any delegate appeals for manual settlement; or (2) if a random sample occurs with probability u=smin(p,q) where s >=1 is a protocol parameter such as s=1.1 [e.g. p=0.3, q=0.7, u=smin(p,q)=0.33, a random sample from Uniform(0,1) turns out to be < 0.3 0.33, in this case adjudication is called for. The reason is that suppose the actual truth is “yes”; under this probabilistic mechanism, with probability 0.33 adjudication is called for and “yes” token is determined to be worth $1, and with probability 0.67 adjudication is not called for and “yes” is worth $0, therefore the expected value of “yes” token is 0.33*$1+0.67*$0=$0.33=$u=s*$p>=$p. This implies that even under the adversarial condition that majority opinion would settle to a false outcome, it would still be profitable in expectation for an honest risk neutral user to hold on to the minority truth, i.e. this mechanism induces “truth-telling” behavior instead of subordination to majority]; or (3) if min(p,q) >= t (e.g. t=0.48) [this is saying that if yes/no is too close to be a tie, adjudication is called for]. In most cases where settlement answer is obvious, none of the 3 conditions shall trigger, and thus prediction market by defaults settles to majority opinion.

Outcomes

Regardless whether the prediction market settles by default or escalates to the delegates, there are 3 possible settlements: (1) challenge unsuccessful: in this case, 1 “yes” token is worth $1 while 1 “no” token is worth $0, and the status of the current update is set to “challenge unsuccessful”; (2) challenge successful: in this case, 1 “yes” token is worth $0 while 1 “no” token is worth $1, and the status of the current update is set to “challenge successful”, and the signature is replaced by the challenger’s submitted signature; (3) challenge escalates to delegates but quorum is not reached within a voting window (e.g. not enough committee members voted) to determine validity of the challenge: in this case, prediction market settles to majority opinion (and signature is replaced correspondingly), the status of the current update is set to “challenge undetermined”.

There is a special treatment to the 2 initial parties that launch the prediction market (i.e. the original updater and the challenger). The original updater’s bond B is deposited into the prediction market to mint out B “yes” tokens and B “no” tokens. The challenger’s bond C is deposited into the prediction market to mint out C “yes” tokens and C “no” tokens. Then a portion r (e.g. r=50%) of “no” tokens from original updater is deposited into the AMM, and the same portion r of “yes” tokens from the challenger is deposited into the AMM, to form the initial two-sided market. The rest of (1-r)*B of “no” tokens from the original updater is transferred to the challenger, while the rest of (1-r)*C of “yes” tokens from the challenger is transferred to the original updater. This is because by construction, the original updater must be defending his update (i.e. holding onto “yes” tokens) while the challenger must be defending his challenge (i.e. holding onto “no” tokens). Note that this implies the initial price of “yes” token in terms of “no” token is B/C [this can be seen in 2 ways: (1) the initial swap of (1-r)B “no” from updater to challenger and (1-r)C “yes” from challenger to updater implies that (1-r)B “no” and (1-r)C “yes” are equal in value, implying price ratio “yes”:“no” = B:C; (2) the initial balance of the AMM is (“yes”, “no”) = (rC, rB), which implies that pool price of “yes”:“no” = B:C]. The initial LP token (with underlying being rC “yes” tokens + rB “no” tokens) is permanently locked, and will be burnt upon prediction market settlement. [This is the extension of the simpler case that in absence of a prediction market, a portion of the updater/challenger’s bond is slashed while the remaining is rewarded to the winning party.] It can be verified that if market settles to “yes”, original updater makes a profit of (1-r)*C while the challenger loses C; if market settles to “no”, the challenger makes a profit of (1-r)*B while the original updater loses B.

It will be up to the higher level program how to use the current update along with the status (pending/confirmed/under challenge/challenge successful/challenge unsuccessful/undetermined); however it is advised that higher level program shall wait until status becomes finalized before making further progress.

Example Applications

Oracle Aggregator

An oracle aggregator decides to maintain a whitelist of oracle providers (e.g. existing oracles such Chainlink/Pyth/Tellor plus new reputable entrants that want to provide oracle services such as exchanges). The aggregator aggregates each update value from the individual providers (e.g. by taking the median, or with some weighted average) and outputs the final value for dapps to use.

The aggregator uses the delegates for security through the following mechanism: the aggregator subscribes to the Verifier contract. Each time the aggregator decides to add or remove a particular oracle provider, it sends a signature update to the Verifier contract through a specific channel (which is authenticated and only callable by the aggregator) to indicate such intent. The aggregator also needs to post a bond to uphold its intent. Anyone can post at least a double bond to challenge such action, and if there is at least 1 challenge submitted within the challenge period, it escalates to adjudication (through a prediction market).

The oracle aggregator could adopt the following node inclusion/exclusion procedure: suppose the aggregator has n (e.g. n=13) oracle providers. Once a week, the oracle aggregator submits a proposal to exclude one of its existing nodes and include one new node, effective starting from the beginning of next week, along with a bond to uphold the claim. Anyone could post at least a double bond to challenge. Settlement should arrive (either no challenge or challenge settled to majority opinion or by delegates) by the beginning of next week. Before the change becomes effective, the old node continues to operate. At the beginning of next week, either new node will replace old node (if no challenge or challenge unsuccessful) or old node continues to operate (if challenge successful). The security model is as described here.

Although much more unlikely that using a single oracle provider, this design still has a weak trust point, that more than n/2 oracle nodes get corrupted at the same time even though they all have been validated by the delegates previously. To prevent this case, the dapps that use this oracle could add a delay mechanism for oracle updates (for example, the MakerDAO uses their oracle for liquidation with a 1 hour delay). In the extreme case, where half of the existing oracles in the whitelist is believed to have been compromised, the dapps could, as a last resort, exit the oracle before the delay window is up.

Bridge between Turing-complete blockchains

For a bridge between two Turing-complete blockchains with smart contract systems, a different mechanism could be adopted. Suppose the base chain is A (e.g. Ethereum) and the bridged chain is B (e.g. Polygon). The cross-bridge deposit and withdraw can work as follows: suppose a user wants to deposit token X (e.g. USDC) on chain A and mint out the corresponding token bX on chain B. The chain B DAO can deploy a smart contract on chain A to hold token X deposits from users, and mint token bX to the address on chain B that is specified by the user. To prevent the default scenario that the chain B DAO takes away user funds in custody on chain A (especially when the locked funds exceed the market cap of the chain B DAO so that it is incentive compatible for the DAO to default), the withdraw method defined in the smart contract on chain A can include a delay condition. Whenever a withdraw request is submitted on chain A, the request is put into a queue that is asynchronously processed. The withdraw initiator also posts a bond that would be forfeited if the request is later on denied (e.g. if it is an attack that is attempting to drain funds). Within the challenge period, anyone can challenge the validity of such withdraw request by posting at least a double bond. If there is no challenge or the settlement turns out to yes (i.e. valid withdraw), the status flag can be set accordingly (“confirmed” or “challenge unsuccessful”) and withdraw can be processed (anyone can finalize the withdrawal) and the challenger (if any) loses his bond, otherwise if a challenge is successful, withdraw is denied and the withdrawal initiator loses his bond.

Venture & Public Goods Funding

A funding vehicle (such as a Venture DAO or a Ecosystem Foundation) needs to evaluate whether to fund a particular project (either retrospectively or ex-ante). A funding mandate, or request-for-proposals (RFP), which specifies the criteria for funding is drawn up and committed before proposals come in. The funding vehicle also pre-screens the deals and perhaps only retain K finalists. Each of the K finalists projects then submitted as signature to the Verifier contract, along with a bond vouching that the project does indeed meet the RFP. Within a challenge period, anyone can post at least a double bond to challenge, i.e. saying that such project should not be funded. If there is any challenge, it escalates to adjudication (through a prediction market). Ultimately the funding vehicle bootstraps decision from the delegates whether a project should be funded. The proposer could be an authenticated user, e.g. a TimeLock contract of the DAO Governance under the condition that a proposal is called for.

Staking

A staking service needs to maintain a whitelist of node operators to run the staking program and distribute returns to LPs. Similar to the case of oracle whitelisting and bridge node operator whitelisting, each time the staking service decides to add or remove a staking node, it sends a corresponding signature to the Verifier contract. It also posts a bond to support its intent. Anyone can post at least a double bond to challenge. If there is at least 1 challenge submitted within the challenge period, it escalates to adjudication (through a prediction market). Through this process, the staking service derives its security model from the protocol.

BTC Bridge

A L1 bridge (e.g. BTC-ETH bridge) needs to maintain a whitelist of node operators to facilitate cross chain transactions. Similar to the case of oracle provider whitelisting, each time the bridge DAO decides to add or remove a node operator, it sends a corresponding signature to the Verifier contract. The DAO also posts a bond to support its intent. Anyone can post at least a double bond to challenge. If there is at least 1 challenge submitted within the challenge period, it escalates to adjudication (through a prediction market). Through this process, the bridge derives security from the protocol.

Key Ceremonies

Many advanced encryption techniques such as fully homomorphic encryption or witness encryption involve either a genesis or ongoing ceremony where a private key is split between N holders. It is natural to choose Futari because of its ease of use and high reputation.

Within and Beyond Crypto

Our goal is to take root in crypto, and then grow beyond it to upgrade critical real-world governance processes.

Decision market is a generic governance technology that can scale beyond crypto. Imagine in the next decades, when the first colony forms on Mars, would they still be relying on simple voting (democratic elections) and expert panels (Congress) and a gigantic opaque bureaucracy (agencies) to make and enforce policy? Or can we do better? Technologies such as liquid democracy, quadratic voting and decision markets are viable candidates.

There are also immediate real-world applications that make sense. One example is a small-claims court, where the economic value of at stake is perhaps less than $2000. The opposing parties can post bonds and spin up a prediction market for quick settlements. All of it could be resolved within a single day, which is an order of magnitude improvement over existing legal processes.