Skip to content

Skinny cousin to Augur, the decentralized prediction market protocol

License

Notifications You must be signed in to change notification settings

veilco/augur-lite

Repository files navigation

Welcome to AugurLite! AugurLite is a decentralized prediction market protocol, built on Ethereum. The protocol is a fork of Augur v1, whose code is available here. AugurLite shares much of the same functionality as Augur but is designed to be more modularβ€”supporting multiple denomination tokens and oracle systems.

Introduction

AugurLite is a protocol for creating and resolving prediction market contracts on Ethereum. Each prediction market is a smart contract with a chosen denomination token, such as Dai. Denomination tokens can be escrowed in a market in exchange for a set of outcome tokens, each of which is an ERC-20 token. The outcome tokens can be traded or exchanged on platforms like Veil, and ultimately redeemed for a portion of the escrowed denomination tokens once the chosen oracle resolves the market.

Overview

To explain AugurLite concepts, we will discuss each smart contract that makes up the protocol. Here is the breakdown.

AugurLite Go to code

This is the protocol's master contract. It is responsible for logging protocol-wide events, controlling transfers of denomination tokens, and creating the genesis universe using the UniverseFactory. This contract is a fork of Augur's main contract.

Universe Go to code

Conceptually, a universe is a container for markets that use the same denomination token. Each universe is created by the AugurLite contract. New markets (scalar, yesno, categorical) are created by calling this contract that in turn uses MarketFactory contracts. The Universe contract stores the denomination token that is used for all markets created in the universe. Unlike Augur's equivalent, this contract doesn't have any concept of forking, fee windows, reporting fees, open interest, or REP, because AugurLite does not come with an oracle out-of-the-box.

Market Go to code

A market is effectively a question about the future. Examples might be "Will Kamala Harris win the 2020 Democratic presidential nomination?" or "What will be the price of Bitcoin (BTC) in USD at 5pm PDT on Friday, May 17, 2019?" Markets come in three types: yes/no, categorical, and scalar.

AugurLite markets have an oracle field which specifies which Ethereum address can resolve the market, meaning specify how much each outcome is actually worth on expiration. All markets in Augur by default use the Augur oracle for resolution, and therefore users are required to deposit ETH and REP when creating a market. AugurLite is oracle-agnostic, so markets could be resolved by referencing the result of an Augur market or some other piece of Ethereum state. Therefore, users do not have to pay additional ETH, REP, or any other currency when creating markets.

This contract shares many of the same fields as Augur's Market contract. It's worth noting that the initial reporter and reporting participants concepts have been removed because they relate to the Augur oracle, which is irrelevant here. Markets are resolved by calling one resolve method. There is no finalization process as there is on Augur.

Upon market creation, a market creator mailbox is created through the MailboxFactory, and share tokens are created through the ShareTokenFactory. We'll talk more about those in their own sections below. Markets also have a market creator fee that is charged when shares are redeemed.

ShareToken Go to code

These are mintable, burnable ERC-20 tokens that represent outcomes in markets. They are created by ShareTokenFactory. A share token should be valued between 0 and 1 of the relevant denomination token. For instance, if you own a "YES" share token in a market denominated in Dai about an event that ends up happening, that share token will be worth 1 DAI upon resolution. Similarly, the "NO" share token in that market will be worth 0 DAI. There is an equivalent ShareToken contract in Augur.

CompleteSets Go to code

A complete set is a basket of all share tokens in a market. For instance, 1 complete set in a yes/no market would be 1 "YES" share token and 1 "NO" share token. Complete sets have the property of always being worth denomination token, because regardless of the outcome of the market, the sum of the values of the share tokens will be 1. This contract lets users buy and sell complete sets in a given market. A user can buy a complete set by escrowing 1 denomination token in the market in exchange for 1 complete set. And a user can sell a complete set by exchanging the set for 1 denomination token (minus the market creator fee) that had been escrowed in the market. There is an equivalent CompleteSets contract in Augur.

ClaimTradingProceeds Go to code

This contract lets users exchange their share tokens for denomination tokens once a market resolves. It is equivalent to the ClaimTradingProceeds contract in Augur.

You will notice that all other trading-related contracts from Augur do not exist in AugurLite. That is because AugurLite defers trading to other off-chain exchange protocols (like 0x or Hydro) and encourages users to trade through off-chain relayers (like Veil, BlitzPredict, or Flux) for better performance.

Mailbox Go to code

This contract is deployed per market and is owned by the market creator. It collects the market creator fees, and it's ownership can be transferred. There is an equivalent Mailbox contract in Augur.

Factory Contracts Go to code

AugurLite uses the UniverseFactory contract to create universes, including the genesis universe. Universe contracts uses MarketFactory to create new markets. Upon deployment, market contracts use MailboxFactory to create mailboxes for the market creators and ShareTokenFactory to create outcome tokens (i.e. share tokens).

Comparison

Here is a table that highlights the main differences between Augur and AugurLite.

Market creation βœ… Anyone can create a market, but they must deposit ETH and REP to do so. βœ… Anyone can create a market, and there is no fee or deposit for doing so.
Denomination tokens 🚫 Markets are only collateralized in ETH. βœ… Markets are collateralized in any arbitrary ERC-20 token.
Complete sets βœ… Complete sets of ERC20 outcome tokens can be created by escrowing ETH. Complete sets can also be settled at any time. βœ… Complete sets of ERC20 outcome tokens can be created by escrowing whatever the denomination token of the universe is (default Dai). Complete sets can also be settled at any time.
Trading and liquidity βœ… Orders are created and maintained on-chain. A custom order matching engine matches and executes trades. 🚫 No trading happens through the protocol. The ERC20 outcome tokens should be traded on other protocols like 0x or Hydro. Relayers like Veil, BlitzPredict, or Flux can provide UX.
Oracle βœ… Users stake REP tokens on a weekly cadence to determine the outcome of markets. 🚫 No oracle is built into the protocol. Instead, markets have a resolver which can reference any oracleβ€”an Augur market, Chainlink feed, or any arbitrary smart contract state.
Settlement βœ… Once the oracle report is finalized, users can redeem their outcome tokens for their portion of the escrowed ETH. βœ… Once the market is resolved, users can redeem their outcome tokens for their portion of the escrowed currency.

If you're looking for a more in-depth list of changes, please review the CHANGELOG file.

Current addresses of relevant contracts

Contract Commit Ethereum Address
AugurLite c9c0817cd1 0x5c025873f7aee04719b6c13fe453b5e446c7ed05
ClaimTradingProceeds c9c0817cd1 0x32cfb05a69328ac6a2944fc35c48ecb9a448c31d
CompleteSets c9c0817cd1 0x92e320330007aa538b0315297c2299fd746d6d8d
Controller c9c0817cd1 0x23d27cc545503a6a1b7127c1a1a2777a38a2aa17
DAIUniverse c9c0817cd1 0xba38540b0f2e11b3ac839b65756bcd8501ded215
MailboxFactory c9c0817cd1 0x1e86d8a1c4287e4ea8566e42e02375b5a4caac44
MarketFactory c9c0817cd1 0x2f5ef0fa22a008b1054a9a7f9b2c6e545ccf3873
ShareTokenFactory c9c0817cd1 0x739b21035799702474da538c3ed22c72415e5f5e
UniverseFactory c9c0817cd1 0xb08ff5e8484c96d5db9b5fb157bcd3df81501ebb
Time c9c0817cd1 0x8bc8a395671c1c200a56e4a7fd3fc74ee2620522

Installation

You need system-wide installations of Python 3.7.3, Node.js 10.12, and Solidity 0.4.26. On MacOS, you also need to use venv for package management.

Setting up a specific solc version could get tricky. We recommend using Homebrew, and following this guide to help install the latest 0.4.xx version of Solidity.

To setup venv:

python3 -m venv venv # Creates venv directory to install Python packages
source venv/bin/activate # Activates the virtual environment

You can switch away from your environment with:

deactivate

Once your Python setup is complete, install JS dependencies with yarn:

yarn add npx
yarn

Deployment

To deploy the contracts, you need to create an .env in the base directory. The specification for the .env file will depend on which Ethereum network you are deploying to. Review the NetworkConfiguration file to see all options. Or copy one of the examples below for common networks.

Sample .env file for Kovan:

KOVAN_ETHEREUM_HTTP=https://eth-kovan.alchemyapi.io/jsonrpc/<INSERT API KEY>
KOVAN_PRIVATE_KEY=<INSERT PRIVATE KEY OF ADDRESS DEPLOYING CONTRACTS>

Sample .env file for Mainnet:

MAINNET_ETHEREUM_HTTP=https://eth-mainnet.alchemyapi.io/jsonrpc/<INSERT API KEY>
MAINNET_PRIVATE_KEY=<INSERT PRIVATE KEY OF ADDRESS DEPLOYING CONTRACTS>

Now you should be able to compile contracts, build contract interfaces, and deploy contracts.

yarn run build              # Compiles contracts and builds contract interfaces
yarn run deploy:kovan       # Deploys contracts to Kovan
yarn run deploy:mainnet     # Deploys contracts to Mainnet

You can see a full list of helper functions to run with yarn in package.json.

Solidity contract deployment is handled by ContractDeployer.ts and the wrapper programs located in source/deployment. This deployment framework allows for incremental deploys of contracts to a given controller (specified via a configuration option). This allows us to deploy new contracts without touching the controller, effectively upgrading the deployed system in-place.

Main Code

Configuration

Smart contract organization

Solidity smart contracts reside in source/contracts. There are two additional folders:

Oracles and custom resolvers

By design, AugurLite does not come packaged with an oracle system. An oracle is some sort of mechanism for bringing information from the real-world onto a blockchain, enabling smart contracts to respond to it. Here are some popular oracle systems:

One goal of AugurLite is to decouple markets from their oracles. Not every market needs to be reviewed by the Augur reporting community. And an oracle for data feeds should be designed differently from an oracle for one-off events. Therefore, markets in AugurLite simply designate an Ethereum address that has the power to resolve them. That oracle address could be a trusted third-party, a smart contract that can observe state from an oracle and pass it along to AugurLite, or something else entirely.

Example: OracleBridge

As an example, Veil uses a smart contract called OracleBridge to observe the result of Augur markets and resolve AugurLite markets accordingly. The OracleBridge address is set as the oracle for Veil's 2020 US Presidential Election markets in order to abstract away various oracle systems. Read more in Veil's smart contracts repository.

Additional resources

Here is a short collection of resources and guides to better understand the Augur ecosystem:

Questions and support

If you have questions, comments, or ideas, we recommend pursuing one of these channels:

License

AugurLite is released under the GNU General Public License v3.0. See License.

About

Skinny cousin to Augur, the decentralized prediction market protocol

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published