# Protocol Overview Mimicry is a decentralized prediction game that helps anyone discover the odds of any market. {% hint style="info" %} **Mimicry's mission is to accelerate universal adoption of free markets.** **We believe this protocol needs to exist so people have a safer alternative to buying and holding illiquid assets like NFTs.** This protocol operates as a [hyperstructure](https://jacob.energy/hyperstructures.html) and aims to solve common problems within illiquid and inefficient asset classes such as NFTs, distilled spirits, trading cards, and more. For example, we address the following desires: * I want liquid exposure to \[NFTs, distilled spirits, etc.] as an asset class * I want an index-like product that lets me short NFT collections, or the entire NFT market * I want exposure to my favorite NFT collections without having to buy-and-hold any of their NFTs * I want a simple way to long or short every ERC-20/721/1155 ever created by a specific creator * I want to better understand the odds of an NFT collection’s market cap going up or down {% endhint %} ## ✏️ Introduction Every market on earth has two sides; bulls who think the price of something is going up, and bears who think the price is going down. Very often those two sides disagree about which outcome is more likely and this can lead to inefficient and illiquid markets. We’ve developed a novel system that leverages game theory and economic incentives to solve this difficult problem. ### 🎭 Positions and 🎪 Markets Players in our game can use ERC-20 tokens to open perpetual positions, called `Mimes`, that represent their exposure to one or both sides of a market, which we sometimes call a `Pantomime`. > **A concrete example of a Mime is:** *a perpetual long position opened on 12/15/2022 at 12:01 p.m. GMT within a given Pantomime market, using 1,000 DAI tokens.* Mimes gain or lose value as the [reference price](#user-content-fn-1)[^1] for a Pantomime changes relative to the skew of at-risk capital provided by bulls and bears, within their respective long and short positions. All reference prices are known using deterministic on-chain oracle feeds that update when new transaction data is available within a market. Players may choose to have their deposited capital, plus or minus any profits/losses, returned at any time by destroying their Mime and paying a small exit fee to the protocol. > **A concrete example of a Pantomime Market is:** *the market capitalization of the World of Women NFT collection, updated whenever the market capitalization for the entire World of Women collection changes by 0.5%, or once per 60 minutes, whichever comes first.* {% hint style="info" %} Note that most Chainlink price-feeds on the Ethereum Mainnet update whenever there is a 0.5% deviation in the reference price, or once per 60 minutes, whichever comes first. Hence the reference used here. {% endhint %}

Mime minting and burning process

{% hint style="info" %} Although Mimes are delivered to player wallets as ERC-721 tokens, they are not the NFTs that were minted as part of a collection like *World of Women* or *Bored Ape Yacht Club*. A Mime is simply a perpetual position within a market. {% endhint %} [^1]: For example, the total market capitalization of the Bored Ape Yacht Club NFT collection. # Core Mechanics The Mimicry Protocol consists of a series of open-source smart contracts and a GUI web application.

Illustration of Mimicry GUI with description of each component

## **🔎 Overview** Each Pantomime is a smart contract that manages a pool of tokenized collateral supplied by liquidity providers ([Producers](/whitepaper/players-and-participants/producers-liquidity-providers)) and traders ([Actors](/whitepaper/players-and-participants/actors-traders)) based on the price movement of an on-chain reference-price feed. Theoretically, the skew of collateral deposited into a Pantomime at a given time could be exactly split, 50/50, between bulls and bears. However, in practice this will be rare. More commonly there will be an asymmetric skew of capital, because a group of bullish or bearish Actors will collectively predict that the reference price of a Pantomime will be more likely to go up or down. This creates a situation where the “underdog” side of a pool has less capital at risk than the “favorite” side, and thus each side will have unique odds. We call the unique odds of each side of the market the [True Odds](/whitepaper/core-mechanics/true-odds). # True Odds True Odds describe how likely "the street" thinks it is for a market's reference price to move up or down in the future. The True Odds for each side of a Pantomime functions as a multiplier, where, all things being equal, a player's deposited collateral will grow by a rate equal to the True Odds every time the reference price for the Pantomime in question doubles. > **For example:** Let's assume there is a market with $1M long and $2M short. The Short Side's True Odds would be 0.5x, and the Long Side's True Odds would be 2.0x. So, all other things being equal, a long position would double in value if the reference price for this fictional market were to increase by 50%. ### Calculating True Odds Within a Pantomime, the long side's True Odds `Lto`, is equal to capital in the short pool `sp`, divided by the capital in the long pool `lp`. $$ Lto = sp / lp $$ Within a Pantomime, the short side's True Odds `Sto`, is equal to capital in the long pool `lp`, divided by the capital in the short pool `sp`. $$ Sto = lp/sp $$ # Value Transfer Events Value Transfer Events are the smart contract functions that move ownership rights of deposited collateral between players. Capital within existing positions are redistributed as part of a Value Transfer Event whenever players add or remove capital from a pool, where the winner’s profits `p`, is equal to the True Odds of their side of the pool `o`, multiplied by the percentage shift in the reference price since the last Value Transfer Event `s`, multiplied by their Mime’s position size `m`. $$ p = o*s*m $$ Conversely, a loser’s losses `l`, is equal to the percentage shift in the reference price since the last Value Transfer Event, multiplied by their Mime’s position size, without factoring True Odds at all. $$ l = s \* m $$ ### Token Flow Illustration The following chart illustrates how tokens might flow between two sides of a Pantomime at different Value Transfer Events. > **In this example:** Let’s assume for a given Pantomime that Alice represents all bulls who believe the reference price will rise, and Bob represents all bears who think the price will fall. And they are both using USDT. As you can see below, losers always lose at a 1:1 ratio of reference price movement, while winners earn at the rate of reference price movement relative to their True Odds.

Reference Price % Change True OddsAlice (Long)Bob (Short)Value Transfer Event
Time 0n/an/a1000Alice opens a position
Time 1n/a0.5x vs. 2x10050Bob opens a position
Time 250%0.16x vs. 6.25x12520Bob withdraws 5 USDT
Time 3-50%n/a62.500Bob withdraws 82.50 USDT
{% hint style="success" %} **Related:** [Skew Change Risk](/whitepaper/risks-and-mitigations/skew-change-risk) {% endhint %} # Advanced Features The Mimicry Protocol supports a number of advanced features to help Traders that wish to seek more alpha. `Leverage` allows players to open larger positions with levered capital. `Automations` help traders reduce risk by automatically managing their positions as market conditions change. # Leverage Leverage in Mimicry is unique, in that, players can never go into debt and there is never any need for the system to manage liquidations. When Actors open positions with leverage `L`, their Mime’s position size `s`, will equal their deposited capital `c`, multiplied by their selected leverage between an integer range of 1-30. $$ s = c \* L $$ Levered positions respond to Pantomime reference-price changes in accordance with their leverage. > **For example:** Let’s assume the True Odds within a hypothetical market are 1:1. A bullish Mime with a $1,000 worth of tokens, previously opened by Alice using 5x leverage, will impact the skew as if $5,000 worth of collateral was deposited on the bullish side of the market. Accordingly, a 10% change in the reference price in this hypothetical example would yield a gain of $500. {% hint style="info" %} The leveraged size of a position will be used when calculating [exit fees](/whitepaper/fees#exit-fees). So assuming a 0.5% exit fee for the hypothetical Pantomime above, Alice would pay the protocol $27.50 worth of tokens to close her position. The value returned to Alice would be her original deposit of $1,000, plus $472.50 in profits. {% endhint %} {% hint style="success" %} **Related:** [Leverage Risk](/whitepaper/risks-and-mitigations/leverage-risk) and [Liquidation Risk](/whitepaper/risks-and-mitigations/liquidation-risk) {% endhint %} # Automations Actors and Producers will have the opportunity to define a series of automated position management settings that work in concert with each other, and with leverage. Automations will be maintained by Balancers and paid for by tips specified by players. Players offering the highest tips will have their positions automated before other players offering lower tips. `Stop Loss` protects players from suddenly unfavorable price swings. `Take Profit` helps players harvest profits during upward price swings. `Swap Sides` protects players from unexpected shifts in overall market sentiment. # Automated Stop-Loss Mime’s that have a stop-loss set will automatically close when a certain amount of deposited capital is lost due to changes in the reference-price of a Pantomime. > **For example:** If Bob opens a bullish long position with $100 worth of collateral, and he sets a stop-loss of 20%, then his position will close automatically whenever the Pantomime reference-price moves down such that his losses, including his exit fee and Balancer tip, are equal to $20. # Automated Take-Profit Mime’s that have a take-profit set will harvest profits when a certain amount of profits are earned due to changes in the reference-price of a Pantomime. > **For example:** If Charlie sets a take-profit of 15% for his bullish Mime, then his position’s at-risk liquidity will automatically be reduced to its original value whenever the Pantomime reference-price moves up by 15%. Simultaneously his 15% profits will be safely harvested and available to him when he closes his position—regardless of what may have happened to the reference price after that point. # Automated Swap-Sides We hope all Actors will do their own research to determine what [True Odds](/whitepaper/core-mechanics/true-odds) they believe are most favorable to their situation. Accordingly, some Actors may decide that they want to be long if the True Odds of the bullish side of a market are below `x`, and short if the True Odds of the bullish side are above `x`. > **For example:** Suppose that Debbie fundamentally believes that the market capitalization of the World of Women NFT collection is twice as likely to go down in value than go up in value, and the current skew within that Pantomime is $20k long and $100k short. Here the bulls have 5x True Odds, and the bears have 0.2x True Odds. In this case Debbie would want to have her capital working on the long side of this Pantomime until the bearish True Odds shifted to be above 0.5x, simply because she would believe that 0.2x odds are not favorable based on her fundamental research. To accomplish this she can open her Mime with the automatic swap-side feature set to 2x bullish and 0.5x bearish. When enough capital is added to the bullish side, such that the bearish odds would move above 0.5x if her capital was swapped from the bullish side to the bearish side of the Pantomime, her position would automatically shift from bullish to bearish. {% hint style="success" %} **Related:** [Skew Change Risk](/whitepaper/risks-and-mitigations/skew-change-risk) {% endhint %} # Players & Participants Mimicry functions as a decentralized autonomous organization with five core network participants. [`Directors`](/whitepaper/players-and-participants/directors-market-sponsors) manage each market. [`Actors`](/whitepaper/players-and-participants/actors-traders) open directional positions. [`Producers`](/whitepaper/players-and-participants/producers-liquidity-providers) provide liquidity to markets. [`Balancers`](/whitepaper/players-and-participants/balancers-keepers) keep the network healthy. [`Crew`](/whitepaper/players-and-participants/crew-team) builds the protocol. # Directors (Market Sponsors) Directors create, maintain, and promote Pantomime markets. The first subset of players in our game are Directors and their role is to create, maintain, and advertise Pantomime markets. Directors receive exit fees within their Pantomimes, at a rate which they set, in exchange for sponsoring the gas costs of maintaining reference-price oracle feeds for their Pantomimes. Additionally, because more players within a given Pantomime means more revenue, Directors are also incentivized to spend their own resources marketing their Pantomimes to other players throughout the world. Game theory will prevent Directors from charging unfair exit fees because another Director can create a similar Pantomime with lower exit fees at any time. Game theory also incentivizes oracle price feeds to be well funded because competing Directors can overtake control of an abandoned Pantomime whenever a Pantomime’s escrow-fund for gas falls below an unsafe threshold, such as $250 USD. Simultaneously there is an economic incentive for a Director to abandon a Pantomime that has low liquidity due to a lack of overall demand from players in the community. {% hint style="warning" %} Note that Directors bear legal responsibility for the markets they create, and that the Mimicry Protocol simply provides the smart contract infrastructure that enables anyone to create new Pantomime markets. We encourage Directors to seek the advice of independent council prior to promoting or advertising any markets they have created. {% endhint %} # Actors (Traders) Actors open directional long & short positions within markets. The next subset of players in our game are the bulls and bears, or a group we call Actors. Actors are motivated by a desire for profits, and they hope to earn profits based on their fundamental belief that a Pantomime’s reference price will be higher or lower in the future. Actors will deposit capital to open Mimes in Pantomimes where they have emotional affinity, or where they believe the current skew of capital spread between the bulls and the bears presents favorable odds on one side. Accordingly, as Actors open positions, they help to discover the True Odds for each side of a given market. # Producers (Liquidity Providers) Producers provide low-risk liquidity to Pantomime markets in exchange for protocol fees and token rewards. The third subset of players in our game are Producers and their role is to provide liquidity to Pantomimes. Some Directors may choose to also play our game as a Producer in order to ensure their Pantomime reaches key adoption levels. Producers have a lower risk-tolerance than Actors and they are motivated by their desire to receive an economic reward for providing liquidity to both sides of a Pantomime at a ratio nearly-equal to the True Odds. Game theory will drive Producers to provide liquidity to the Pantomimes which they feel will be most used by the bulls and bears, because those markets will generate the most exit fees. Conversely, Pantomimes that have low demand from players in the community will lack Producer liquidity. {% hint style="success" %} **Related:** [Market Abandonment Risk](/whitepaper/risks-and-mitigations/market-abandonment-risk) {% endhint %} # Balancers (Keepers) Balancers call public smart contract functions to rebalance two-sided Producer positions and help automate advanced trading features for Actors. The second-to-last subset of players in our game are Balancers. Balancers serve a critical role, which is to rebalance the Producers’ positions to match the True Odds of a Pantomime anytime the Pantomime bull vs bear skew changes beyond a threshold perviously set by a Producer at the time that the Producer opened their Mime position. Skew changes can happen anytime (a) Actors add or remove capital, (b) the value of the ERC-20 tokens deposited within a Pantomime change in USD terms, or (c) a Pantomime’s reference price deviates. This mechanic causes Producers’ positions to remain as close to delta-neutral as possible by continuously moving part of their deposited collateral from long to short, or short to long, as appropriate based on the True Odds in a pool. A detailed illustration of this rebalancing mechanism is as follow… {% embed url="" %} Detailed illustration of Producer rebalancing {% endembed %} Producers pay Balancers a [tip](/whitepaper/fees#balancer-fees) in exchange for Balancers hosting and maintaining servers that automate the process of monitoring Pantomime health and paying gas costs to call a smart contract function which rebalances a Producer’s assets, where Producers may specify that the more time a Producer’s position spends out of balance, the greater the tip. An economic disincentive will prevent Balancers from rebalancing Pantomime liquidity when their tip will not exceed their gas and operational costs, and at the same time game theory will also prevent greedy Balancers from waiting to rebalance a Pantomime until it is far out of balance because Balancers effectively race each other to win tips. Balancers may also [earn fees](/whitepaper/fees#balancer-fees) by triggering [automated events](/whitepaper/advanced-features/automations) for the benefit of Actors. {% hint style="success" %} **Related:** [Balancer Shortage Risk](/whitepaper/risks-and-mitigations/balancer-shortage-risk) {% endhint %} # Crew (Team) The Mimicry Crew consists of all people and organizations who contribute time, knowledge, and/or capital towards our mission. The last but not least group of players in our game are the creators of the game itself. Crew is motivated to build an unstoppable game that helps anyone discover the odds of any market, safely and privately. Crew exchanges time, knowhow, and capital for the prospect of spiritual, legacy, and economic reward. Crew collaborate as members of a decentralized autonomous organization and are appointed by the community of players via token-holder voting mechanics. > **Crew have a concrete directive to:** create open-source smart contracts and player-friendly interfaces that allow anyone to easily and safely interact with Pantomimes and Mimes for countless years to come. # Fees Mimicry charges traders an exit fee, and 100% of these fees are redistributed to liquidity providers and market sponsors. ### **Exit Fees** Players may mint Mimes to open positions without any fees. However, players who open one-sided positions will be charged a small exit fee whenever they remove liquidity from their positions. Liquidity providers who open two-sided positions will not be charged fees. Exit fees are set by each market's sponsor will vary from market to market, but generally they will fall between 0.0% – 1.0%. {% hint style="info" %} Initially, 100% of exit fees will be subsidized by the Mimicry Protocol. {% endhint %} #### Revenue Split Once exit fees are activated, Directors will retain some portion of revenue generated by Pantomimes, and the remaining portion of fees will be paid to Producers who provide liquidity. Similar to [Uniswap](https://gov.uniswap.org/t/fee-switch-pilot-update-vote/19514), we anticipate that at some point in the future our DAO community may vote to send a portion of exit fee revenue to the Mimicry Foundation’s treasury in an effort to support ongoing software development grants, bug bounties, charitable grants, and the general health of the ecosystem. ### **Advertising** Fees A second stream of potential protocol revenue is from Pantomime advertising. Directors may compete using an auction model for promotional advertising space within the Mimicry Marketplace GUI. Initially 100% of this revenue will be used for community rewards and, similar to exit fee revenue, someday a portion may instead be routed to the Mimicry Foundation treasury. ### Balancer Fees All tips Producers and Actors pay for balancing and automation efforts will be retained by Balancers with no revenue share to the protocol. # Tokenomics $MIMIC is an ERC-20 utility token that is required in order for the Mimicry Protocol to function in the most healthy way possible. ## **Overview of $MIMIC** `$MIMIC` is the native utility token used within the Mimicry Protocol to ensure a healthy ecosystem. The token will be used to pay all fees to the network, tip Balancers, unlock features, and facilitate DAO governance. $MIMIC has a max supply of 1B tokens. All $MIMIC distributed for community rewards as part of our initial token supply will be minted at the time they are claimed. [`In-App Use Cases`](/whitepaper/tokenomics/in-app-use-cases) describes how Mimes interact with $MIMIC. [`Rewards`](/whitepaper/tokenomics/rewards) describes how players can earn rewards for providing liquidity to the protocol. [`Governance`](/whitepaper/tokenomics/governance) describes how players may impact the mechanics of the protocol. [`Distribution`](/whitepaper/tokenomics/distribution) describes how the 1B $MIMIC tokens will be allocated. [`Vesting`](/whitepaper/tokenomics/vesting) describes how tokens will be locked when distributed to various recipients. # In-App Use Cases ### **Fee Settlement** Players may use a wide array of ERC-20 tokens to [open positions](/whitepaper/core-mechanics), pay [exit fees](/whitepaper/fees#exit-fees), and [tip](/whitepaper/fees#balancer-fees) Balancers. And Directors may use whatever token they like to pay for [advertising](/whitepaper/fees#advertising-fees). However, all exit fees, advertising fees, and tips must ultimately be paid using $MIMIC. Accordingly, when a player does not pay fees with $MIMIC, their payment token will be immediately converted to a *MARKET BUY* order for $MIMIC tokens across supported exchanges and they will be responsible for slippage. Therefore every action in the protocol represents demand for $MIMIC. For the sake of clarity, only fees—not deposits locked in the smart contract—will be converted to $MIMIC. ### **Feature Gates** Players who use $MIMIC to open positions, or auto-swap to $MIMIC within our UI, will have access to advanced features that will not be available to players who use other tokens. For example, [automations](/whitepaper/advanced-features/automations) will all be restricted to players who mint Mimes using $MIMIC. Community rewards will also be restricted to players who use $MIMIC to open their positions. This will serve to increase demand for the token while also effectively removing $MIMIC tokens from circulation when they are locked in positions. # Rewards ### **Overview** In addition to unlocking special features, Actors and Producers who use $MIMIC to open positions will also be eligible to earn rewards in the form of additional $MIMIC tokens. Rewards will be paid using Pantomime revenue, and using [an allocation](/whitepaper/tokenomics/distribution) of the initial token supply. ### **Time-Weighted & Size-Weighted Earning** It is in the best interest of the protocol to incentivize players to open large positions for long periods of time. This is especially true for Producers who want to maximize reward earnings while providing liquidity. Accordingly $MIMIC token yield will be determined based on a weight assigned to each Mime. Players may lock their Mimes when opening their position, or after their position is open, for a selectable time-lock `tl` in one-week increments, where `tl` ≥ one week, `tl` < max time-lock `m`, and `m` = 4 years. After locking, the weeks left to unlock is `t` ≤ `tl`, and `t` will be rounded to the nearest whole week. Reward earning weight decreases linearly from the moment of locking. The amount of $MIMIC in their Mime `a`, may change with market dynamics. Additionally, there is a second reward multiplier `b`, applied from the moment a position is opened with a time-lock, where `b` = 1 + 100% annually, calculated weekly. The earning weight is equal to: $$ w = a \* b \* (t / m) $$ > **For example context using this formula:** A two-year-old Mime that extends its time-lock to four years using $1,600 worth of $MIMIC will have the same reward-earning weight during the first week of its time-lock as a newly minted Mime with $998,400 worth of $MIMIC and a one week time-lock, or a newly minted Mime with $4,800 worth of $MIMIC and a four-year time-lock. > > **Because:** > > `998,400 * 1 * (1/208) === 4,800 * 1 * (208/208) === 1,600 * 3 * (208/208)` In other words, the reward-earning weight is both amount- and time-weighted, where the time counted is how long the tokens cannot be moved in the future and how long ago the Mime was first minted. {% hint style="info" %} The size of a [leveraged](/whitepaper/advanced-features/leverage) position will not be used when calculating reward-earning power. {% endhint %} We imagine this approach will also create a secondary market for Mimes, where Mimes that have been open for a long time will be more valuable than newly minted Mimes. The time-lock for a Mime can be extended at any time, up to the max time-lock, and the amount of $MIMIC within a time-locked Mime can also be increased at any time. Further, all features available to $MIMIC-backed Mimes, other than reducing position sizes and automated stop-loss, will be available to all time-locked Mimes. Concretely this means that a time-locked Mime can earn a cash flow of profits using the automated take-profit feature or by manually harvesting profits earned. Deposited $MIMIC may be withdrawn from a Mime after the time-lock expires. ### Reward Distribution Rewards are distributed pro-rata based on Mime weight. Accordingly, the amount of revenue-based rewards earned during a two-week earning-epoch within each Pantomime will be equal to the sum of a Mime’s reward-earning weight `w`, on each day of the earning-epoch, divided by the sum of reward-earning weight from all Mime’s in the Pantomime on all days of the an earning-epoch `W`, multiplied by the total Pantomime exit fee and advertising revenue earned during the earning-epoch that is earmarked for community rewards `r`. ![{( sum w)/( sum W), r}](https://lh4.googleusercontent.com/qglvGVzSfYW2mcSszJE4E4PCuA7Zgi5gLfOsFG3YhQ3Z5QIhIlKcyJdmc4JLQdODz1uWEuru-nw_AIIGZkkaq5knhSbX2lZdV50OokI5WKXqFUOrx2GlIi_DP1OtWE3W0V_XB-3SHsoZqclhA3-EdqM) $MIMIC distributed for community rewards as part of our initial token supply will be distributed using a similar function, except where `W` represents the sum of reward-earning weight from all Mime’s in all Pantomimes on all days of an earning-epoch. {% hint style="info" %} Note that this design is based heavily on the Curve governance model. See the [Curve DAO white paper](https://classic.curve.fi/files/CurveDAO.pdf) for additional implementation details. {% endhint %} ### **Claiming Rewards** $MIMIC community and revenue rewards earned by Actors, Producers, and Directors may be claimed weekly. All claimed tokens will vest linearly for 12 months using a constant linear stream. This claiming and vesting mechanism will help to prevent players from receiving rewards and immediately selling them on the open market. # Governance ### **Overview** $MIMIC will be used to facilitate voting on token grants and other operational aspects of the protocol, such as smart contract development and new feature development for the Mimicry Markets GUI. Eventually smart contract upgradability will be removed to protect all players. After that event, token holders will still be able to vote to modify exit and advertising fees earned by the protocol, other key earning ratios, allowed settlement tokens, treasury grants, gated features, and more. In order to disincentivize someone forking Mimicry, upon eventual protocol maturity, all efforts should be made by the community to optimize key ratios and the use of treasury funds in favor of a profit-neutral balance sheet. Concretely this means that the community may vote to allow treasury surpluses to be used for airdrops or deflationary mechanisms. Further, if revenue to the foundation is ever activated, it may later be removed entirely in favor of maximizing economic incentives for Actors, Directors, and Producers. ### **Voter Escrow Model** We strive to reach a truly decentralized and unstoppable network so we will be leveraging our amount- and time-weighted reward-earning design for governance as well, where Mime holders may vote on proposals in accordance with their pro-rata share of reward-earning weight at the time of their vote. Accordingly, the longer Mimes are time-locked (from 1 week up to 4 years), the more voting power they hold. This will reward the players who most adamantly believe in the future of this protocol with greater governance control, while also effectively removing $MIMIC from the circulating supply to increase demand pressure on the token itself. Concretely this means that only those players who risk $MIMIC within time-lock positions will have the ability to participate in protocol governance. ### **Delegation** Mime holders may choose to assign the voting power of their Mime to any other player whom they trust to make decisions in the best interest of the protocol. The original holder will still retain their Mime and all rights associated with it other than governance, regardless of which player they may have assigned their votes to. Furthermore, they may choose to revoke voting delegation rights at any time. ### **Anticipated Behavior** We expect Producers to use $MIMIC to keep large positions open for long periods of time on the markets they believe will have the most activity so they can maximize their reward-earning yield. Additionally, we also expect Producers to be the most active participants in governance proposals for the protocol. Actors are less likely to time-lock their positions because they may want to reduce their position sizes from time to time. Some players may also choose to deposit $MIMIC within LP pools on decentralized exchanges in order to capture trading fees. # Distribution ### **Overview** The supply of $MIMIC will be reserved as follows: 40% for community rewards, 22.5% for existing and future investors, 20% for existing and future Crew, 14% for the Mimicry Foundation’s treasury and exchange listings, 2% for strategic market makers, and 1.5% for an airdrop sometime in the future. This distribution will be programmed into the $MIMIC smart contract and may not be changed in the future.
The community rewards tokens will be distributed using a decay curve that operates as an approximately-having schedule annually, calculated weekly, where \~48.54% of the community rewards will be distributed during the first year, \~24.98% during the second year, and so on. A detailed code example that illustrates the exact number of weekly rewards for the 30 years following the TGE is available below. {% @runkit/embed content="// CONSTANTS WE CAN CHANGE TO MODEL DIFFERENT CURVES const startingTokenSupply = 400000000; const periodsPerYear = 52; const years = 30; let totalTokens = 0; const totalPeriods = periodsPerYear \* years; const decayMeasure = 1 / startingTokenSupply; // I ASSUME WE WILL SET THE DECAY RATE AS A // CONSTANT IN THE SMART CONTRACT TO SAVE ON GAS const decayRate = 1 - (-Math.log(decayMeasure) / totalPeriods); // console.log(decayRate); // e.g. 0.9873032210864922 // OUTPUT THE MAX NUMBER OF CLAIMABLE TOKENS DURING THIS PERIOD function getClaimableTokenAmount( period, decay = decayRate, startingSupply = startingTokenSupply ) { const previousSupply = startingSupply \* (decay \*\* (period - 1)) const currentSupply = startingSupply \* (decay \*\* period); return previousSupply - currentSupply; } // LOGGING FOR CONVENIENCE for (let i = 1; i <= totalPeriods; i++) { const claimableTokens = getClaimableTokenAmount(i); totalTokens += claimableTokens; console.log("Claimable tokens for period " + i + ": " + claimableTokens); if (i % periodsPerYear === 0) { console.log(" End of Year " + (i / periodsPerYear) + ". Total tokens distributed: " \+ totalTokens + " ( " + ((totalTokens / startingTokenSupply) \* 100) + "%" + " )."); } } " nodeVersion="14.x.x" %} Using this curve, 92.99% of the 400,000,000 $MIMIC tokens allocated to community rewards will be available to Producers and Actors who time-lock their $MIMIC-funded Mimes at any point over the first four (4) years following the token generation event (TGE), and the remaining 7.01% of community reward tokens will be distributed during the next 26 years after that. The nature of this design provides economic incentive for the earliest adopters of the protocol to earn the greatest share of token rewards.
# Vesting ### **Investors and Crew** Pre-Product Investors will receive 10% of their $MIMIC tokens at the TGE, and their remaining tokens will be streamed linearly over the next 24 months. Post-Product Investors have notably less risk than Pre-Product Investors, so they will receive 10% of their $MIMIC tokens at the TGE, and the remaining tokens will be streamed linearly over the next 36 months. Post-Product Investors will also have a contractual mandate to only use their vested tokens during the first 12 months following the TGE for providing liquidity to the protocol within Mimes. Crew will receive 0% of their tokens at the TGE, and their remaining tokens will be streamed linearly over the next 36 months. ### **Community** The Mimicry Foundation will receive their tokens via a linear stream over the 60 months following the TGE. Tokens granted to market makers will be fully-vested at the time of the grant in exchange for long-term contractual agreements for market-making services. Claimed community rewards and airdrop tokens will vest linearly over the 12 months following their minting by members of the community.
In no particular order or ratio, we anticipate that the majority of the earliest recipients of vested $MIMIC will operate as Producers to provide liquidity to the protocol and earn rewards, or (b) deposit their $MIMIC within LP pools on decentralized exchanges to earn trading fees. # Contract Architecture Eventually our contracts will be open-sourced and upgradability will be removed. For now we're publishing notes here. ### How Data Flows Players may take positions by selecting a number of variables and depositing ERC-20 collateral. New positions are represented as ERC-721 tokens (Mimes). ![Mimicry data flow diagram](/files/lgTmmRhSVb07boJ3cvwJ) ### Mimics as NFTs Each minted Mimic will contain specialized metadata written to the blockchain. When rendered within a wallet, that data, along with real-time performance information, will be visible in the NFT itself. Some of the data recorded may include: * The NFT collection to peg value against * The direction of the collection's price prediction (long or short) * The USD liquidation value of the position, after fees * The amount of profit, expressed as a percentage * The amount of rewards earned | ![](/files/6MunsdguA2cLgkzw5H43) | ![](/files/9EmKD0yuMXEM1qOtvVlH) | | -------------------------------- | -------------------------------- | # Risks & Mitigations Mimicry is a complex codebase and certain risks exist within the system. {% hint style="danger" %} There are a number of risks in the current architecture, as Mimicry is still an experimental system and complex systems require both empirical observations and theoretical analysis. Empirical observation and theoretical analysis ensure the mechanism design aligns incentives for all players. {% endhint %} We have attempted to describe an exhaustive list of risks related to the use of our protocol, along with an equally exhaustive list of mitigation strategies each each. [`Price Manipulation Risk`](/whitepaper/risks-and-mitigations/price-manipulation-risk) [`Data Feed Downtime Risk`](/whitepaper/risks-and-mitigations/data-feed-downtime-risk) [`Centralization Risk`](/whitepaper/risks-and-mitigations/centralization-risk) [`Smart Contract Risks`](/whitepaper/risks-and-mitigations/smart-contract-risks) [`Macroeconomic Risk`](/whitepaper/risks-and-mitigations/macroeconomic-risk) [`Leverage Risk`](/whitepaper/risks-and-mitigations/leverage-risk) [`Skew-Change Risk`](/whitepaper/risks-and-mitigations/skew-change-risk) [`Liquidation Risk`](/whitepaper/risks-and-mitigations/liquidation-risk) [`Arbitrage Risk`](/whitepaper/risks-and-mitigations/arbitrage-risk) [`Market Abandonment Risk`](/whitepaper/risks-and-mitigations/market-abandonment-risk) [`Balancer Shortage Risk`](/whitepaper/risks-and-mitigations/balancer-shortage-risk) # Price Manipulation Risk Perhaps the most notable risk is reference-price manipulation. This may occur if a nefarious Director creates a new Pantomime using a reference-price oracle that they can easily manipulate. For example, this could happen if the Director creates a Pantomime for an NFT collection where they control most or all of the NFTs in that collection, or if they control the price oracle they use to launch the Pantomime, or if they solely control a centralized API endpoint that an is using for its price feed. These risks are chiefly mitigated by utilizing oracles that have battle-tested smart contracts, well-designed economic incentives for disputes, and game theory that incentivize reporters to write accurate price information on-chain. Additionally, we believe our community of Actors will avoid Pantomimes that use reference-price calculations that are easy to manipulate with wash-trading, such as NFT Collection Floor Price, in favor of more fraud-resistant measures such as the [NFTGo Market Cap](https://docs.nftgo.io/docs/collection-metrics) or the [Time-Adjusted Market Index](https://github.com/Mimicry-Protocol/TAMI) of an NFT collection. Further, there is a 60-minute cooling period whenever someone attempts to remove liquidity from their positions. This delay is specifically designed to allow oracles enough time to begin the dispute process on a price feed, thus locking the retrieval of funds by a potentially nefarious player until the dispute is resolved within the underlying oracle protocol. Then, in practice, a community vote will be needed to unlock funds that were previously locked. # Data Feed Downtime Risk Reference-prices must be reliable in order for the protocol to be able to function properly. This risk can be mitigated when Directors use price oracles that aim to source identical price information from multiple data providers. For example, any oracle reporter can deterministically calculate the market capitalization of an NFT collection’s OpeaSea sales using that collection’s sales history sourced from Dune Analytics, Reservoir Protocol, the OpenSea API, or a custom Subgraph that monitors OpenSea’s smart contract events. Conveniently, when different oracle reporters send deterministic data to the blockchain using different technology stacks, they are also reducing price manipulation risk. # Centralization Risk At launch there will be the risk that a government or corporate actor may disrupt services by disabling services that Mimicry depends on for hosting front-end web assets and blockchain relayer nodes. In time this risk will eventually be mitigated with the use of private relayer nodes, decentralized file storage, an unstoppable domain, and censorship-resistant oracles. # Smart Contract Risks Our smart contract code has been written by a team of senior software engineers and will not launch on mainnet until we complete two comprehensive audits with reputable independent firms. Nonetheless, the larger our codebase, the more attack vectors. To mitigate this risk we will maintain a healthy bug bounty and require at least two new, independent, and publicly-published contract audits prior to upgrading any of our contracts. Eventually upgradability will be removed entirely. # Macroeconomic Risk Participants who deposit non-stable collateral, including $MIMIC, are at risk of having their position sizes reduced due to changes in the value of their underlying collateralized assets. This risk will remain present in perpetuity as we believe that it benefits Actors and Producers who are bullish on certain non-stable assets—including $MIMIC. Additionally, by not forcing players to use stable assets we remove unwanted slippage or impermanent losses that they may have otherwise incurred. # Skew-Change Risk As illustrated within our [Token Flow Illustration](/whitepaper/core-mechanics/value-transfer-events#token-flow-illustration), the earning potential within each side of a Pantomime shifts anytime collateral is added or removed from the pool, while the risk exposure remains constant at 1:1. Bullish and bearish Pantomime skew will also change when there are fluctuations in the price of some, or all, of the collateralized tokens in the pool. This means that an Actor may open a bullish position when they fundamentally believe the odds of a Pantomime’s reference price increasing happens to be greater than the odds represented in a pool, and they might become surprised when the odds in the pool suddenly change. In practice skew-change risk is mitigated in two ways. First, the function of [Balancers](/whitepaper/players-and-participants/balancers-keepers) in our system will incentivize many rebalancing events following small movements in a Pantomime’s reference price, and thus preventing significant un-hedged exposure for Producer positions. However, there still may be times where a player removes a large amount of capital from one side of a Pantomime, inadvertently changing the earning odds of the opposite side quite significantly. Our second mitigation strategy is our [automated position management tools](/whitepaper/advanced-features/automations), which will allow Mimes [swap-sides](/whitepaper/advanced-features/automations/automated-swap-sides) whenever certain skew changes occur. # Leverage Risk Actors are given the privilege of optionally using leverage to increase their position’s earning power. Conversely, positions that use leverage may also be liquidated more quickly during periods of increased market volatility. Each player is responsible to only open positions using tokens that they can afford to lose. # Liquidation Risk A situation may occur where a player’s position is worth less than zero. For example, this may be the case for bearish Mime when the reference-price of a Pantomime more than doubles. In these cases the winning side will have rights to all tokens held by the losing position, but no more than that ceiling. The losing Actor will not owe the winners any additional funds and their Mime will effectively be worthless. # Arbitrage Risk A sophisticated Actor may run their own infrastructure to calculate a Pantomime’s reference-price feed, such as the market capitalization of Bored Ape Yacht Club, and modify their positions when they believe there is extractable value available between the last on-chain reference price and the current reference-price. We believe arbitrage of this nature is a healthy and efficient market dynamic, and one that will be mitigated organically as more and more players race against each other to capture alpha. We will further mitigate this risk by publishing robust Node and Python developer SDKs and well-documented code examples that teach novice software engineers how to easily interact with the Mimicry smart contracts. # Market Abandonment Risk We recognize that Producers may be reluctant to lock their capital into an unproven market with low activity from Actors. Further, some markets may lose community interest over time. Accordingly, we will implement mechanisms that will allow players to easily move their Mimes, whether time-locked or not, between Pantomime markets as they see fit. # Balancer Shortage Risk Early in the life of the protocol there may be a shortage of Balancers who compete to earn tips. To offset this risk, the Mimicry Foundation and several key partners will run Balancer nodes. Dockerized source code for running a balancer node will be open source and made available to anyone who wishes to compete for tips. # Notable Vocabulary We sometimes use novel vocabulary to describe certain aspects of our system.
TermDescription
Mimicry ProtocolA collection of smart contracts that govern the mechanics of a decentralized prediction game.
$MIMICThe native utility token for the Mimicry Protocol.
PlayersThe core participants in the Mimicry ecosystem; Directors, Actors, Producers, Balancers, and Crew.
DirectorsThe players who create and maintain Pantomime markets.
ActorsThe traders who open long and short positions within Pantomime markets.
ProducersThe players who provide liquidity to both sides of Pantomime markets.
BalancersThe players who maintain software that automatically calls smart contract functions to keep the system healthy.
CrewThe contributors who are building Mimicry.
Mimicry MarketplaceThe GUI where players interact with the Mimicry Protocol.
PantomimeA synthetic prediction market that uses on-chain oracle price feeds to mimic external price movement of other markets; also refers to a theatrical story told by a silent mime.
MimeAn NFT that represents right to a portion of the collateral locked into a Pantomime; a position; also refers to the word that describes an actor in a pantomime.
BullsActors who think the reference price of a Pantomime is going up in the future; bulls take long positions.
BearsActors who think the reference price of a Pantomime is going down in the future; bears take short positions.
SkewThe difference in the amount of deposited capital, in USD terms, between bullish and bearish Actors within a Pantomime market.
True OddsA measure that predicts how much a deposit will grow each time a Pantomime’s reference-price doubles.
Rebalancing EventA smart contract function call that Balancers use to rebalance a Producer’s capital between two sides of a Pantomime in order to match the True Odds of that market.
Value Transfer EventA smart contract function call that captures losses and distributes profits within a Pantomime.
# Partner Integrations Mimicry leverages countless hours of development effort from other teams. Here's a few of the players in our stack. ## Re: Oracles * [Tellor](https://tellor.io/) - Tellor is the only truly permissionless and censorship resistant oracle we know of in the magical land of DeFi. Naturally we support their feeds for anyone who wishes to use them to create a market. * [Chainlink](https://chain.link/) - We leverage Chainlink as the gold standard for all things USD price lookups. * [Gelato](https://www.gelato.network/) - Web3 Functions are quite the tool. If you haven't yet, please give them a spin. ## Re: Data Providers * [NFTGo](https://nftgo.io/) - These guys have fantastic APIs and greatly simplify market caps. * [CoinGecko](https://coingecko.com) - Leaders in web2 price lookups, and super flexible for floors as well. * [HelloMoon](https://www.hellomoon.io/) - Solana beasts when it comes to NFT data. * [Reservoir](https://www.reservoir.tools/) - Nuf' said * [DIA](https://www.diadata.org/) - DIA has the easiest endpoints around when it comes to floor price lookups. ## Re: UI * [RainbowKit](https://www.rainbowkit.com/) - These folks have made connecting wallets easy breezy lemon squeezy. * [TradingView](https://www.tradingview.com/) - Our charts are provided by TradingView, a social platform for traders and investors with versatile analytical tools. TradingView lets you track particular symbols, e.g. [BTC USD](https://www.tradingview.com/symbols/BTCUSD/), as well as dive into a more advanced market analysis with sophisticated data like crypto market cap. # Roadmap We maintain a detailed [public roadmap](https://trello.com/b/BkZ5fSI8/mimicry-public-roadmap) on Trello. # Contracts & Wallets This section is an active work in progress. At the same time, you can safely expect posted contract addresses to never change. # Contracts Overview The Mimicry contracts are modular, and together comprise the core functionality of the network. ## Mimicry Protocol ### Mimicry A contract which keeps track of the markets that have been created, and is responsible for facilitating communication between the markets and the PositionToken contract explained below. ### Market A contract that defines a market. Primarily used to keep track of positions, as well as acting as the interface between users and markets. ### Accountant A contract that lives alongside a Market contract and is used to do the math necessary to run value transfer events; as well as other math heavy operations. ### Value Providers Each Value Provider contract tells the market what the latest value of an asset is. The value provider is used by the market to determine how the value of an asset moved, and to calculate how to transfer funds between the long and short positions. ### Position Token The ERC721 contract that creates and burns position tokens when positions are opened and closed. ## Off-Chain Reporting Oracle ### Open Markets Oracle This contract is a catch-all data repository for Mimicry Market data feeds. Our community can use this contract to write new data feeds on chain from secure sources, such as Gelato's web3 functions. # Contracts Reference With the exception of the OpenMarkets Oracle, we often redeploy contracts on testnet. Accordingly, we are intentionally omitting old and/or WIP addresses. ## Off-Chain Reporting Oracle #### Mumbai * OpenMarketsOracle: [0x0aC47a0aBf3f96df1E5A3F31Ea475ad99f2D9A31](https://mumbai.polygonscan.com/address/0x0aC47a0aBf3f96df1E5A3F31Ea475ad99f2D9A31) # Wallets Reference Mimicry leverages a series of wallets to facilitate transparent and simplified on-chain bookkeeping. ### Foundation Treasury * Historic Treasury: [mimicry.eth](https://app.safe.global/home?safe=eth:0x7fC31aD2662b7A62004d8029956aC6d56D71858a) * Reserved for Future Use: treasury.mimicry.eth ### Token Vesting Escrow Accounts All vested tokens will be streamed from these wallets. * Reserved for Future Airdrop: airdrop.tokenvesting.mimicry.eth * Escrow for Investors: investors.tokenvesting.mimicry.eth * Escrow for DAO: dao.tokenvesting.mimicry.eth * Escrow for Community Rewards: community.tokenvesting.mimicry.eth * Escrow for Team: crew\.tokenvesting.mimicry.eth ### Contract Manager Smart contracts will be owned by the following account until we close our public beta and remove contract upgradability. * contractmanager.mimicry.eth ### Insurance We may opt to capture a portion of revenue into an insurance fund to further protect the protocol. All insurance-related expenses and claims will be paid from this account. * contractmanager.mimicry.eth ### Gas Tank We will persistently fund a gas tank to support gasless transactions. * gastank.mimicry.eth ### Revenue Various revenue streams will be separated to help ensure the most transparent bookkeeping possible. * Reserved for revenue from trading fees: tradingfees.revenue.mimicry.eth * Reserved for revenue from yield farming: farming.revenue.mimicry.eth * Reserved for revenue from promoted markets: ads.revenue.mimicry.eth # SDK Please visit # Official Links Website: Docs: Roadmap: Testnet Dapp: Discord: Twitter: Telegram: SDK: # Brand Assets Please [visit our Github](https://github.com/Mimicry-Protocol/brand-assets) to gain access to our public brand assets. # Markets Anyone can launch Mimicry Markets using this simple guide. ## 1. Request Access At this time your wallet must be approved in order to launch a new market on Mimicry. Please apply for approval [here](https://v593x222y0p.typeform.com/to/q76aaHsv?utm_source=docs.mimicry.org) and then ping the team on Discord in the [mimicry-markets channel](https://discord.com/channels/931357054218666005/1100530833074438244). ## 2. Create a New Data Feed **a)** Refer to the [contracts reference](/for-devs/contracts-and-wallets/contracts-reference#off-chain-reporting-oracle) for the address of the OpenMarketsOracle contract on Polygon Mumbai. **b)** From there you'll need to call the `createDataFeed()` function the contract, passing the data feed *nickname* and a list of one or more *allowed scribes*. > **Pro Tip:** The most secure data feeds will only authorize a single scribe and that will be the [dedicated msg.sender](https://aslanas.gitbook.io/mudita-white-paper/disclaimer) associated with your Gelato Web3 Functions (W3F) account. **c)** Inspect the logs after the `createDataFeed()` transaction is successful in order to find the `dataFeedId`. The ID will be used later when setting up the W3F.
## 3. Create an Automated Task in Gelato **a)** Visit [this page](https://beta.app.gelato.network/new-task) in the Gelato W3F application and connect your wallet. You can also reach this page by clicking the New Task button on the dapp homepage.
**b)** You'll need to start off by pasting the IPFS CID of your W3F. We recommend using the *Mashup* function that we've officially published and maintain. Please see the [Contracts Reference](/for-devs/contracts-and-wallets/contracts-reference#gelato-web3-functions) for the latest CID of the function you'd like to use. **c)** Each W3F schema is different, but assuming you're using one of our officially supported functions, you'll need to add the following parameters: > **Pro Tips:** See the enums in the [Off-Chain Reporting Oracle repository](https://github.com/Mimicry-Protocol/off-chain-reporting-oracle/blob/master/src/web3-functions/libs/enums.ts) for a complete list of supported *chainIds*, *consensus methods*, *currencies*, *metrics*, and *providers*. > > And all arrays of strings must be formatted as follows: `["value","value"]` * `oracleAddress` See the [contracts reference](/for-devs/contracts-and-wallets/contracts-reference#off-chain-reporting-oracle) for the appropriate OpenMarketsOracle contract. * `dataFeedId` Paste the *dataFeedId* that you previously created in step 2.c. above. * `nftCollections` This field accepts a comma-separated array of one or more NFT collections pointers, in the following format: `["chainId:contractAddress","chainId:contractAddress"]` * `tokens` This field operates the same way as `nftCollections`, expect that it expects contract address of ERC-20 tokens. * `currency` Expects a currency string, like *usd.* * `metric` Expects a metric string, like *market-cap.* * `providers` Expects an array of strings, where each provider is used to query market data about NFTs, tokens, etc. * `consenusMethod` Expects string that includes a filter and a methodology, formatted as *filter:methodology.* Ultimately this defines how to distill down to a single number when various providers disagree on the metric related to an NFT collection, token, etc. In nearly all cases we recommend using `meanAverageDeviation:mean`. * `deviation` Expects a number between 0 – 10,000, where 10,000 equals 100%. This parameter instructs the data feed to write a tick on-chain anytime the new value returned by the provider APIs changes by more than the deviation threshold. We generally recommend using a value of 25 to represent a deviation threshold of 0.25%. * `heartbeat` Expects a number greater than 0, where the number is the amount of seconds to wait between on-chain ticks before writing a new value. Generally we recommend setting this value to *3600* to represent one hour. ## 4. Set Environment Variables API keys must be set for each provider. The easiest way to do this is to clone the Mimicry Off-Chain Reporting Oracle repository, setup your local .env file, and run the command , as described in the [Secrets section of the repository README](https://github.com/Mimicry-Protocol/off-chain-reporting-oracle/tree/master#re-secrets). ## 5. Fund Your Task The last step is to fund your Gelato W3F account so there is ample money available for gas. We generally recommend funding approximately $1,000 per task per year, which assumes an average of $0.078 per transaction, and 35 transactions per day.