Author: Dr. Malte Kliemann Revision: 2 Introduction The following architecture design allows users of the Zeitgeist runtime to use the DLMSR AMM and CDA in parallel on the markets they create by splitting and routing trades to achieve the best execution price. The design requires an off-chain matcher to provide a list of order IDs which should be used to fill the users order. Using the on-chain router in combination with an off-chain matcher has one crushing advantage over just using an off-chain matcher: If multiple trades come in on the same block, collisions can be avoided. Blockchain Architecture Changes Scoring Rules

Author: Dr. Malte Kliemann Proposal version: 1.0 Protocol version: 0.3.6 Introduction When a liquidity pool is deployed in the current iteration of the Zeitgeist app, the prices of all outcome assets are even. For example, when creating a market for a sports event with the typical four outcomes A (A wins), B (B wins), TIE, NONE (no clear result, game/fight cancelled, unforeseen events), all outcomes start at a value of 0.25 ZTG (representing a prediction of 25%). But clearly, 25% of all football games are not cancelled, which means that NONE is heavily overpriced. By buying full sets of outcome tokens, then selling the NONE tokens and keeping the other three, traders can short NONE to correct the mispricing (in terms of predictions, this means they bet that NONE will not occur). A similar scenario is an A/B market with a clear favorite A and underdog B. The favorite and underdog will be priced at 0.50 ZTG. If the typical prediction is that the favorite has a 90% chance of winning, this will allow traders to acquire A tokens at a very cheap price to correct the value of A to 0.90 ZTG. This "price discovery" comes at the cost of the liquidity providers, who bet against the market but are forced to initially sell their tokens at these sometimes completely inappropriate prices. This makes providing liquidity unnecessarily unappealing.

Author: Dr. Malte Kliemann Introduction Zeitgeist's dispute system allows users to dispute the report made by a market's oracle. The dispute system is modular and delegates the responsibility of resolving a dispute to the market's dispute mechanism (MDM). The system is modular in the sense that all MDMs implement the same specification. Currently, three dispute mechanisms are available (although two of them are disabled): authorized, which allow an authority (on-chain address) specified by the market creator to force set the outcome in case of a dispute. simple-disputes, which simply assumes that the last dispute is correct when the dispute period ends (disabled and deprecated). court, a jury-based court system similar to Kleros. Currently, only a proof-of-concept implementation is available, and it currently differs from Kleros in some key points. The court is planned to be the primary market dispute mechanism (MDM) of Zeitgeist. This proposal is a specification for the first production version of the court. We will frequently refer to the Kleros [Yellow Paper], which details the court's behavior.

Author: Dr. Malte Kliemann Version: 1.3 (Oct-15-2022). Changelog 1.3 Fixed maximum iterations estimate. Introduction Zeitgeist currently uses the Balancer AMM design, a variant of the classical constant product market maker (CPMM), to facilitate trading of outcome tokens. The liquidity pool for a market contains outcome tokens as well as the base asset (currently ZTG), and the Balancer AMM calculates prices of tokens as functions of these balances and the weights of these assets. As early as the Kusama Derby, a design problem in our AMM has become apparent: The sum of the spot prices of the outcome tokens (the total spot price) is not always equal to $1$ ZTG. Instead, it will usually be higher than $1$ as a result of users buying the outcome tokens from the pool. This yields an arbitrage opportunity for traders. They can mint complete sets of outcome tokens for the price of $1$ ZTG per set and then sell these sets to the market at a price higher than $1$ ZTG per set until the balances of the pool have evened out and the total spot price has returned to $1$.

We present an architecture design for a watered-down version of the original AMM 2.0 design. We call this AMM 2.0-alpha. What's AMM 2.0-alpha? AMM 2.0-alpha implements all features defined by the AMM 2.0 proposal, except for the following: LMSR pools can only be deployed for markets with two outcomes (binary and scalar). If the price of an outcome reaches $.99$, then buying is prohibited; if the price of an outcome reaches $.01$, then selling is prohibited. LMSR pools must be manually deployed and AMM 1.0 pools are not automatically disabled; LMSR pools can be deployed even if there is already an AMM 1.0 pool. The liquidity tree is not implemented; instead, only the market creator can deploy liquidity to a pool.

Author: Dr. Malte Kliemann Version: 1.0 (Sep-19-2022) Based on discussions with several other members of Zeitgeist. Special thanks to the Node Team for some very helpful discussions. Introduction Zeitgeist's dispute system allows users to dispute a market's report or previous disputes. This report will summarize the weak points of this system and present a plan for an overhaul. We begin by describing how the dispute system works in the current version of the protocol. When a market's oracle submits a report, a window opens during which every user may dispute the reported outcome. This is called the dispute period. When the dispute period ends without any user submitting a dispute, the market resolves to the outcome reported by the oracle. When submitting a dispute, the user specifies the outcome that they think is correct (the suggestion), and they reserve a bond (more on incentivization later). If a dispute is submitted, a new dispute period is started, during which users can challenge the previous dispute. If no dispute is opened within the dispute period, the dispute is resolved by the market's dispute mechanism (MDM). The dispute system is modular in the sense that all MDMs implement the same specification. Currently, three dispute mechanisms are available (although two of them are disabled):

Introduction Zeitgeist's futarchy module is designed to offer Futarchy As A Service to other parachains using prediction markets that run on Zeitgeist's parachain. Terminology A space is a combinatorial pool created by combining a binary market (the condition) and a scalar market (the welfare measure). Structure The module is split into two pallets, the sender (futarchy-aggregator) and the receiver (futarchy-gov). Sender

This ZIP outlines the design and implementation of zrml-futarchy. Futarchy in Theory Futarchy is a mode of governance defined by R. Hanson in [RH03]. An organization (nation, city, corporation, DAO, etc.) governed by futarchy selects its values (how is welfare measured?) using some form of a democratic vote, but uses prediction markets in which informants bet on their beliefs to aggregate information on which policies will improve the organization's welfare and which policies won't. In futarchy, decisions about policy are delegated to prediction markets. In these markets, the efficacy of the policies is estimated in terms of a pre-defined welfare measure, a scalar measure of how well things are going for the organization. Depending on the measurements made using the prediction markets, the policy is either adopted or not. By proceeding in this fashion,

This bulletin details the theory and design behind Forecasting Technologies' implementation of Referendum #502. Most of this research is based on Gnosis' documentation and implementation. Our implementation will closely follow theirs to ensure testability. All files will therefore include a Gnosis copyright notice and LGPL license note. ZIP-10.1: Theory of Combinatorial Pools and Betting Payout Vectors As of version <0.6.0, when a market resolves, it resolves to a particular outcome (in case of categorical markets) or a number (in case of scalar markets). For various reasons, it's easier to think of a resolved market having a payout vector though. The payout vector of a resolved market with outcomes $x_1, \ldots, x_k$ is a vector $p = p(x_1, \ldots, x_k)$ of $k$ non-negative numbers with $\sum_{i=1}^k p_i = 1$. Redeeming one unit of the $i^{\mathrm{th}}$ outcome token yields $p_i$ units of collateral.