# ZIP-12: Futarchy-xcm

## 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

The sender is used to aggregate or collect market data. A _signal_ consists of the following information: _pool ID_, _type_ and _state_. The pool ID determines which pool/space the data is drawn from. The type determines how the data is recorded and holds the recorded data. To give you an idea what the type could be:

- `SignalType::Block(BlockNumber)`: Signals market data at that particular block.
- `SignalType::Candle(BlockNumber, BlockNumber)`: Signals market data at a random point between the specified block numbers.
- `SignalType::Average(BlockNumber, BlockNumber)`: Signals market data between the specified blocks and averages it.

`SignalType` takes the entire pool structure to record data. In particular, it can measure liquidity as well. While the candle auction is probably a good starting point, as it incentivizes informants to stay in the market until the end specified by the signal type, averaging over the market data and weighing by liquidity might be a good second option. We should be open to experimentation here.

The state field stores information about the state of the recording. It can be _active_ (waiting for recording or currently recording), successful or failed. There shouldn't be too many expected reasons for a recording to fail (in fact, recordings should be designed in a way that ensures that they cannot fail unless something odd happens like the pool disappearing).

Signals have a limited lifetime, before they're cleared from storage.

A successful recording can be _sent_, which means that it's XCM'ed over to the target chain.

It's worthwhile to note that signals are not owned by anyone and is immutable once created. This is important to ensure that futarchy is not vulnerable to manipulation of the signal.

Creating a new signal costs ZTG relative to the amount of compute required to make the recording.

### Receiver

The receiver is used to manage and execute proposals. A _proposal_ consists of the following information:

- A call to execute as root (similar to pallet-democracy).
- The XCM path to the parachain sending the signal used to decide the proposal and the index of the signal.
- A condition on the market data that must be fulfilled in order for the proposal to pass.

Once the specified signal has been sent to the proposal, it can be executed using the `execute` extrinsic. The pallet can be configured to restrict access to the `execute` call. This essentially means that decisions made by futarchy also need to be whilelisted. A canonical choice is the council. The point of the feature is that parachains that are suspicious of futarchy, lack of liquidity on Zeitgeist, etc. can continue to execise control in case something on our side goes wrong or seems shady. Full-blown futarchy would require anyone to be able to run `execute`, though.

Bells and whistles like an enactment period, etc. can be implemented at a later time.

## Workflow for Parachains Using Futarchy As A Service

The following is a rough outline of the full workflow of a parachain using Futarchy As A Service. We assume that the parachain was to decide if they should execute a certain root action.

- Create a space whose condition is whether or not the root call is executed and use the parachain's welfare measure of choice.
- Register a signal on Zeitgeist using zrml-futarchy-aggregator which records the information that the parachain wants to aggregate and base their decision on.
- Create a new proposal on the parachain using zrml-futarchy-gov and choose as source a signal which records the information the parachains wants to aggregate and base their decision on. Ensure that the lifetime of the signal is ample enough to allow successful transmission via XCM.
- Wait for the signal to finish recording.
- Send the signal to the parachain.
- Execute the proposal if the signal is positive.

- Submit a proposal comprised of the following data:
- Call
- Oracle-Key (Specify two outcome tokens and compare the price
- Execution time
- Ensure that execution time is sufficiently for away from right now
- Wait until execution time is reached