9lives

9lives is the most customisable and advanced prediction market in the web3 ecosystem, with a liquidity free bootstrapping model titled the DPPM, and an AMM feature. We can support teams interested in releasing prediction markets themselves using 9lives, including hosting the graph for you. If you're interested in this, contact us at this link!

9lives is an Arbitrum Stylus smart contract implemented with a simple factory/pair pattern. A factory takes a list of outcomes, and creates a variable number of contracts with a minimal viable proxy pointing to share ERC20s, and a trading contract. It either supports the Dynamic Pari-Mutuel Prediction Market (DPPM) model to solve liquidity issues in orderbooks, or a Constant Product Market Maker model hosted entirely in contract.

To get started with the contract entrypoint, src/lib.rs contains the matching of features to deploy different contract facets. Testing is done with a mixture of property and mutation testing and a bespoke testing environment for ERC20 accounting and more.

Inventors create campaigns (the prediction markets) by locking up "incentive" amounts, and by picking the type of oracle they want to use. Any fees earned in the campaign are sent to the Inventor, which provides incentive to create markets. Markets must be created with a hard deadline and a Beauty Contest or a Infrastructure Market, or with a Contract Interaction type of outcome. The Inventor must communicate to the Factory which oracle they would like to use, and provide the hash of the string that must be used to determine the outcome. This will then set the correct behaviour.

flowchart TD
    Trader --> |Locks up incentive amount, sets parameters| Factory
    Factory --> |Sets start, end, description, if infra market oracle chosen| Infra[Infra market]
    Factory --> |Deploys contract. Sets parameters| Trading
    Factory --> |Configures Longtail pool| Longtail
    Factory --> |Deploys ERC20 assets for each outcome| ERC20s
    Trading --> |Disables Longtail once trading is done| Factory
    ERC20s --> |Burns and mints supply| Trading
    Infra --> |Tells Trading who won| Trading

Infra Markets are prediction markets where Staked ARB is locked up as LARB, which is used to predict the outcome of another prediction market with a commit and reveal scheme. These markets exist in an optimistic state where anyone can "call" the outcome, before being challenged with a "whinge", which begins the process of a commit and reveal system. Following this, amounts can be claimed with a slashing process based on amounts staked.

Oracle State oracles are very simple comparatively, as presumably the associated Trading contract was configured to allow early activation, so all a caller must do is activate the associated Oracle State contract. These could communicate with LayerZero to pull information from another chain, and the contract will simply check the result of the message. If it's not activated by the date that's given, then it defaults to a "DEFAULT" clause that could be "no" if a user were to try to estimate the price of something.

Building contracts

make build

Updating docs (after editing markdown files)

forge doc -b

Testing

Testing must be done with no trading or contract feature enabled. Testing is only possible on the local environment, or with end to end tests with an Arbitrum node.

./tests.sh

Testing coverage can be measured using mutation testing and cargo-nextest. This can be quite heavy, and will take a long time to run. proptest is configured using PROPTEST_CASES to reduce the time to 10, instead of the default 256.

./mutants.sh

Interrogation of the deployment in the end to end testing library could be done using the build.rs use of environment.lst, which could be in turn read with a fresh deploy (and a clean artifacts directory):

sort $(find target -name environment.lst) | uniq

You could clear the recorded environment variables the same way with a test harness:

find target -name environment.lst -delete

You could use this to test the code by making a debug build, which includes more information about reverts, then simulate your calldata against it using stylus-interpreter, making debugging a breeze.

Errors

The error table lives in ERRORS.md.

Deployments

Superposition mainnet