# Contracts {% hint style="info" %} This page summarizes Conditional Funding Markets v1 (CFMs) contracts and their resolution and redemption flow. {% endhint %} ### Contracts description Butter's first iteration of Conditional Funding Markets (CFMs) contracts is available at [github.com/butterygg/cfm-v1](https://github.com/butterygg/cfm-v1). The main contract, `FlatCFM` represents a CFM with a flat outcomes structure: each outcome represents the condition that a proposal gets funded. These outcomes are also called *decision outcomes*. `InvalidlessConditionalScalarMarket` represents the scalar prediction market which is conditional on the parent outcome being selected. It contains outcomes `Short` (also called DOWN), `Long` (also called UP) and `Invalid`. The `InvalidlessFlatCFMFactory` contract enables the creation of a `FlatCFM` and its related `InvalidlessConditionalScalarMarkets`. For a given CFM, it helps creating one `FlatCFM` instance per candidate project, one `InvalidlessConditionalScalarMarket` instance per decision outcome (Funded or Not Funded), asks the associated oracle questions and prepares the associated Conditional Scalar Tokens. `FlatCFMRealityAdapter` implements an adapter pattern to access RealityETH from our contracts, with a normalized interface. ### General flow The system follows these general steps: 1. The `InvalidlessFlatCFMFactory` creates one `FlatCFM` per candidate project, with specific parameters. This enables the creation of `InvalidlessConditionalScalarMarket`s for each decision outcome. This submits the decision question to the oracle via `FlatCFMRealityAdapter` and prepares the decision condition through `ConditionalTokens`. 2. The `InvalidlessFlatCFMFactory` creates new `InvalidlessConditionalScalarMarket`s for an existing `FlatCFM`. This submits the scalar question to the oracle via `FlatCFMRealityAdapter` and prepares the scalar conditions through `ConditionalTokens`. This relies on a Reality template with a placeholder for the decision outcome name. 3. Users split their collateral into decision conditional tokens, then split again into scalar conditional tokens. These tokens are ERC20s and can be traded on AMMs. 4. When the oracle provides an answer to the decision question, the `FlatCFM` can be resolved and calculates payouts. 5. When the oracle provides an answer to the conditional scalar questions (all together), all `InvalidlessConditionalScalarMarket`s can be resolved and calculate payouts. 6. Users can redeem their positions for payouts. ### Invalid decision question In case the decision question posted to [Reality.eth](/technical-docs/v1-dependencies.md) fails to be processed correctly (either due to ambiguity or a technical error), it can return an `Invalid` response. In such a case, the `FlatCFM` decision question and its related condition will be marked invalid. In this case, the related `ConditionalTokens` condition will be marked invalid, and *both the Funded and Not Funded markets will be voided.* In such a case, the INVALID decision outcome token will be worth 1 unit of collateral (1 USDC), and **traders will return their original deposits.** **CFM Reality.eth questions have been carefully reviewed by a panel of experts, including Kleros and Reality.eth. Previous CFM questions have never resulted in Invalid outcomes.** ### Invalid metric question In case the metric question fails to be processed correctly, it can return an `Invalid` response. In such a case, the processing is different than the one reserved to decision questions: A set of parameters `defaultPayouts` has been passed by the factory contract to initialize `InvalidlessConditionalScalarMarkets` . This parameter represents the proportion that is allocated to UP and DOWN tokens in case the question returns `Invalid`. By default, a ratio of 50%/50% is used. In the unlikely case that the metric question returns Invalid, all traders will be rewarded *as if the market closed at 0.5 USDC*. We expect this outcome to be extremely improbable, based on our deep understanding of how Reality.eth and Kleros courts' cryptoeconomics and their previous rulings. The [CFM Kleros policy](/technical-docs/v1-dependencies.md) has been carefully crafted to prevent ambiguity even in the most adverse conditions (e.g., if DefiLlama is hacked). **CFM Reality.eth questions have been carefully reviewed by a panel of experts, including Kleros and Reality.eth. Previous CFM questions have never resulted in Invalid outcomes.** ### Audits The `cfm-v1` codebase has been audited by leading auditors, including Trust and a $30k Immunefi competition. See [here](https://github.com/butterygg/cfm-v1/tree/main/audits) for audit reports. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.butter.markets/technical-docs/v1-contracts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.