-
Notifications
You must be signed in to change notification settings - Fork 0
Specification
- Event: A future event with outcomes to (optionally) be predicted.
- Market: A grouping of events that are typically mutually exclusive. Most markets will have a single event, but a multidimensional election market might have events "Hillary Clinton wins the 2016 Presidential Election" and "Unemployment by the end of 2016 will be below 5%." This would allow users to see the correlation between unemployment rates if Hillary were or weren't elected.
- Branch: Each "branch" in Augur has its own markets, events and reputation balances. If someone creates a Football branch, reporters who don't report on the outcomes of its events will only lose reputation in the Football branch, not in the General or any other branch. This allows the system to scale without requiring reporters to verify every single event.
- Period: The amount of time between votes on a given branch.
- Ballot: Each voting period, reporters are presented with a ballot of matured decisions to vote on.
Traders want to purchase outcomes in markets that are currently active.
Market Authors want to create new markets and events to make a profit from trading fees.
Reporters want to cast their ballot on outcomes of closed markets to make a profit from their trading fees.
All views should are responsive and mobile-friendly.
While branches are the parent of markets, there will only be one branch in the initial implementations of this PM. The UI excludes branches in the interim.
The market list view lists the markets in the current branch, displaying their volumes and maturation date. We use the latest maturation date of the events in a market to display.
Above the list is a button to add a new market.
The first version of the client handles the common case of a single-dimensional (i.e. one event), binary event market. The add market screen displays the fields needed to create a market and an event. A single field is used for the event name and market title. Submitting creates the event, creates the market, then adds the event to the market. The fees for the whole process are displayed up front.
The highest priority event type to add next is categorical events. For example, the 2016 Presidential election could be represented as a categorical market where the four categories are Hillary Clinton, Jeb Bush, Rand Paul, or someone else.
The market detail view is the heart of this app and contains components like current percentage, price history graph, current price and volume, holdings and user commenting. Price information is charted for each event in the market, and the events are listed with their price of the "yes" outcome, volume and respective color in the charts. The events link to their detail pages.
This display handles binary events, but categorical events are also high priority. The UI for categorical, scalar, and multidimensional markets needs more thought.
The markets the client creates will only have one event at first, so the market detail is the event detail. Even in future multidimensional markets, it's unclear whether viewing a single event in isolation will be useful.
It's rare to need a listing of events in a branch. Most events will be in markets. However, events can be created and reported on even if they aren't added to markets, which is useful for third-party contracts that want to use reporters' decisions to get information about the outside world.
The holdings page displays a list of event outcomes with the number of outcome tokens held, their current price, and the current total value of the user's holdings of a given outcome. It also displays the total value of all held event outcomes. Each outcome links to its corresponding event detail page, where the user can buy and sell shares.
Users can send reputation to other accounts from the holdings page.
Ballots show, at a glance, all the events a reporter needs to vote on. It shows the most useful information for reporters (particularly the highest priced outcome), and should link to the market detail page for the given event. Reporters indicate their vote for each event, then click a "cast ballot" button. The client generates a salted hash of the ballot, stores the ballot and salt locally, and broadcasts the hash to the network. The user is informed that they still need to run the client again to finish casting their ballot between the appropriate deadlines.
In the second half of the reporting period, the client automatically broadcasts the users ballot and salt. When there's a use case for making that process manual, we'll add a way to disable automatic ballot broadcasting.
Voting deadlines are always clearly displayed. Reporters have half a period to submit their ballot hash. The ballot and salt must be submitted in the second half of the reporting period.
(See also: issue 23.)
On first launch, Augur explains itself to users. This is either a guided tour with tooltips that explain parts of the app, or a mobile-style app slideshow that explains the app with text and images. After the tour, users are prompted to enable demo mode if they don't have an Ethereum daemon running. Demo mode is also available from a menu so users can toggle over if the live data is too boring.
Key points:
- Augur is a decentralized prediction market platform that forecasts future events by letting people like you trade shares of future outcomes.
- Augur runs on a token called Reputation. The system figures out which outcomes actually happened by letting reporters—people who own Reputation tokens—vote on what happened. The more Reputation you have, the more your vote counts. Half of the trading fees are allocated to reporters who vote accurately. The fees are split based on the amount of Reputation tokens reporters own.
- Market authors create new events to trade, and keep the markets trading smoothly by providing a deposit to smooth out unbalanced trades in a market. They are rewarded with the other half of the trading fees.
- Start trading, reporting, and making markets today! Let's forecast the future together.