# A Protocol for Competitve Mobile Games
We will start to talk about the protocol directly from a concrete example. In the conclusion, we will extend the idea to a protocol level overview. Assume that this pitch is given by a new project called `Arena Grinders`.

Arena Grinders is a mobile game that is going to provide players a place where they can play to earn. The project's vision aims to build a place in the game industry such that participants can achieve financial income by active or passive participation to the game.

## Introduction
The mobile gaming industry is a huge market. With the rapid improvements in mobile hardware technology and software development, everyone can build or play a mobile game. An [article](https://www.protocol.com/bulletins/mobile-gaming-100-billion) mentions that the revenue in 2022 will exceed \$200 billion this year. This information begs the question: How much of the revenue is actually transferred to the players? The answer is unfortunately about \$3 billion, as it's mentioned in this [article.](https://www.marketwatch.com/press-release/play-to-earn-nft-games-market-trends-2022-demand-cagr-value-growth-business-strategy-future-trends-competitive-landscape-industry-share-size-and-forecast-to-2028-2022-04-27) However, with the *Web3* movement, we want to change that to an amount that is significant. We believe that we are going towards a future where the consumer and producer are actually a whole, where one uses a service also is a participant of the value produced, thus there should be a fair cut to the consumer. With that in mind, we would like to build a protocol that$$ will give the participants what they actually deserve. The main idea is simple. If you are starting something new, if there is no capital infusion from outside, you are simply valued by the work/participation performed by your users. In the beginning, your sole aim is to gain a traction as soon as possible. If you can incentivize people to take a part of the interaction with your protocol in the beginning very fast, you can grow faster and stabler, thus the protocol can have a long term success. If someone participates in our game, their participation will be the main force helping us to make our product valuable. If there is a financial gain created by their work, they should have a piece of the financial gain they have created. We will solidify the protocol by giving an example and extend it to a protocol level abstraction.

## Components and Actors
In the game, there are two main actors. The participants and the protocol. Protocol will be an autonomous part, a smart contract. The participants are actual humans. They can perform two actions.
- **Protocol**: It will be the autonomous system that will manage pools, participant entries and revenue distribution.
- **Participants**: They can perform three operations:
- Manage a *pool* : They can be the manager of a pool where the participants play for the pool reward.
- Participate in a *pool*: They can play in the arenas of a pool to win rewards.

Here is a visualization for clearance, which should be viewed as an extreme simplification:

The components of the game are protocol manager, pools, arenas, entrance cards and characters. Arenas are the fields where character matches happen, pools consists of several arenas where after structured matching ,the pools reward will be distributed by the protocol manager to the players. Protocol manager also controls pool deployments and specifications such as participant size, arena structure and entrance requirements.

## Mechanics
Mechanics are heavily important in a protocol where captured value should be highly utilized and fairly distributed. We will start by example flows for participants and protocols then build up the solid theory that lies under the hood.

First of all, here is an example generalized flow for revenue generation and user participation:

A participant can enter free pools and play the game as they wish without requiring any sort of financial commitment such as entrance cards. They can play the game in order to achieve skins, characters and entrance cards. The participants in free pools will be automatically matched by an off-chain engine in real time. It's worth to mention that the possibility of rewarding an entrance card should be low. The skins and characters should represent some financial value on the open market. The entrance cards will have tiers and the entrance card mined from free pools can't be registered to enter _treasured pools_ above _Tier 1_.

The treasured pools will have several tiers, which represent the maximum value they can hold in the pool. The matching structure will be determined after locks of entrance cards by an on-chain tree builder. The pool tier will be determined by the statistics of the participants to that pool and the manager of the pool. The cost of the participant that are entering a pool via free pool mint will be covered by fees collected by the protocol.

The managers of the treasured pools can claim fees which they have deployed. The fees will be claimable after the pool is completed. The managers of the free pools will have royalties for the skins and characters that are minted in that pool.
Recall that these characters and skins will obey the _ERC-721 Non-fungible Token Standard_ with royalty mechanisms and they will be exchangeable on secondary marketplaces.

The protocol will sell first-tier **magic boxes** before the launch of the game, which the generated revenue will be injected entirely to the game to bootstrap the progress. The magic boxes might contain one or several of:
- Limited skins that will be only available in these boxes. There will be no other minted in the game.
- A special card that will allow owner of the card to claim fees from skin and character card sales. For every entrance card sale and skin/character exchange, holder of this card will be able to claim fees.
- Entrance cards to pools. These cards will have access up and including to the _Tier 3_ pools.

For a participant, there are two operations they can perform.
- A participant can join a pool if it's in the building stage. The building stage is where participants collect entrance cards and pool builds up a reward reserve from the fees collected by the sales of entrance cards.
- This mechanism works as the same for free pools, there will be no need for entrance cards. The reward cards (skins, characters, entrance cards etc.) will be assigned to pools automatically.
- A participant can be a manager of a pool. Being a manager of a pool is only allowed if the participant holds a special pool-winner card. Participant can collect fees aside from the protocol and manage pool specification.

The protocol can deploy pools and collect fees from their revenue if the deployed pools are treasured. As platform, protocol will collect a fee from every treasured pool, no matter whether the pool is deployed solely by protocol or other participants. The rate might change by the deployer set but the rate is not going to be significant. There are two types of pools:

A free pool consists of:
- The real time arena matchings will be assigned by an off-chain engine, the players will be independent of pools but tied to matching structures.
- Several arenas that is compatible with matching structure.
- Matching structure:
- Level count, arena matching type, character thresholds etc.
- Participants
- Management structure:
- Manager
- Royalty address: By default the managers address.
- Participant count
A treasured pool consists of:
- The arena matchings will be assigned by an on-chain tree builder. This stage will be executed after locking stage.
- Several arenas that is compatible with matching structure.
- Matching structure:
- Level count, arena matching type, character thresholds etc.
- Participants
- Reward Pool
- Management structure:
- Manager
- Protocol fee ratio
- Manager fee ratio
- Participant count

The workflow in a pool can be described as:
- Setup Phase:
- Mint of the entrance cards.*
- Sale of the entrance cards.*
- Character Card - Entrance Card bindings.*(1)
- Fee collection by the protocol.*
- Setting up genesis matchings.
- Game Phase:
- Starting from genesis matchings, an `n-tree` will be structured and will be obeyed by the pool specification.
- After every arena is completed on the level, the matchings will iterate to the upper level.
- After every arena is completed, the history and ranking of the game will be set to final.
- Reward/Distribution Phase:
- Pool history is final.
- By the initial pool and matching structure, the rewards will be distributed accordingly to the winners. Also, if there was an external pool manager, they will claim their fee specified in the pool specification.*
- Matching structure of the pool will determine several aspects of the pool:
- The deadline function per level: This function will determine the deadline for the arena execution. If participant of an arena do not attend to the match before the deadline, they will be kicked and **their character that is binded to the card or pool will be burned**. If other participants sent a match request before the deadline but remained unresponded, they will be bumped up to the upper level.
- Arena configuration: Determining the criteria for bumping up to an upper level. By default, single arena win is sufficient. By configuration, several structures can be imposed such as:
- 3-2-1: Three arenas, winner of all arenas bumped up to the next level etc.

*: These steps will not be performed for free pools.
*(1): Pool-character binding will be performed for this step.

An arena consists of:
- Several sides.
- Sides will be determined by the matching structure of the pool that the arena belonged to. By default, there will be two sides with two participants. We will maximize to **six** sides for better UX, also in an arena there will be a maximum of **six** participants.
- The arena execution will be off-chain. The state before the arena execution and after execution will be written on-chain. The protocol manager will have a submodule called arena manager, which will be responsible for the state updates and data integrity.
- The winner of the arena will be matched to another participant that is advanced to the upper level. The defeated participants will be:
- Their characters will be detached from their entrance card.
- They will be removed from the pool as a player, but they will remain in the history of the chain.
- Due to the lack of speed on EVM-based chains, the arena execution will be off-chain and the global state of the game will be updated by the protocol manager, it will be located at the in-house protocol signer machine.

An entrance card consists of:
- The bounded character
- The issued pool
- The ranking and current level of the card:
- This means that whether the bounded character is at level `k` for some pool by the matching structure.

An entrance card holds:
- The right to claim the reward, if permitted so.
- The reward that is permitted to card will be sent to the owner of the entrance card.
- The right to transfer ownership of the entrance card:
- If there is a permitted character card to the entrance card, the ownership of the character card also moves to the new owner.
An entrance card can:
- It can be destroyed after the pool is completed. However, pool configuration is the decider of that. Some pools might let the winners hold their entrance cards as souvenirs. Be aware that the entrance cards and pool-deployable cards will be different. Even if the pool selects an entrance card as the winner, the pool-deployable card will be minted to the owner of the entrance card.

A pool-deployable card consists of:
- Lifetime: The protocol sets the lifetime of the pool-deployable card.
- Calculation method:
- $BN_{i} - BN_{o} \leq Lifetime$ where
- $BN_{i}$: Current block number.
- $BN_{o}$: Origin number of the mint, at block.
- Pool count: In it's lifetime, it can deploy at most `k` pools.
- Revenue Cap: This pool can set at most `v` revenue pools.
- Skins: This pool can reward only the skins in this array.
- Characters: This pool can reward only the characters in this array.
A pool-deployable card has the same rights as the entrance card type.

A character-card consists of:
- Character metadata: The graphics etc. since it's very expensive to store on-chain data, a service like [IPFS](ipfs.io) will be used.
- Damage
- Shield
- Level
- Arena Count
- The remaining part will be discussed in further mechanics.

Overall, the components and their interactions can be summarized in this way.

_NOTE_:This is the litepaper. Mechanics will be described in a more detailed and formalized way.

## Architecture
The game architecture will be the software representation and visualization of the actors and components.


We will have four main actors in the architecture:
- **Protocol**: It's responsible for:
- Card management: Responsible for minting cards, assigning them to the pool, minting to the owners and querying them.
- Pool deployment: Deploying new pools with specified schemes.
- Treasury management: Manages protocol assets.
- Pool management module: Manages pool assets, lifetimes of the pools.
- **Data Sentry** :It's responsible for providing correct data that will be supplied by an off-chain database and captured/indexed on-chain data.
- **Sentries**: The completed pool contracts and cards should be `SELFDESTRUCT`ed. We need off-chain sentries that will trigger those operations. Think as liquidator bots in [dydx](www.dydx.exchange).
- **Game**: This is where the participants will be interacting with. It's responsible for:
- A fun game. It's a must.
- Arena execution.
- Free pool matchings.
- User deposits and withdrawals.
- Data sentry communication for write and reads.

## Economics
We have designed several mechanisms for the integrity and sustainability of the project. Firstly, the integrity and sybil protection mechanisms will be explained. After that, how the system can actually stay alive with the economic model we build.

Entire protocol revenue will be generated by the participants. The participants drive the revenue by playing in pools. So, the main entry point will be the treasured pools, thus we should build mechanisms that ensure that no sybillers can exploit these pools. For pool schemes, we will use `n-ary` trees. For simplicity, we will bound our case to `binary` tree scheme.

Assume that there are $2^n$ participants in a pool. The pool is structured to have an entrance card pricing of value $k$. After selling all the entrance cards, the pool will have $V=2^nk$ value locked in the pool. Protocol takes $V.p_{rate}$ of the pool immediately and the locked value in the pool updates to $V' = V.(1-p_{rate})$. Also assume that this pool is deployed by an another participant, thus they will also take $p_{manager}$ fee. Now, the pool has $V_{net} = V'.(1-p_{manager})$.

The one possible method can be thought of a $\%51$ percent attack. The sybiller enters the pool with $2^{n-1} + 1$ characters and remaining participants are honest. The best case for the sybiller is that our off-chain matching engine will pair every $2^{n-1} + 1$ cards owned by the attacker will be matched with each other and $1$ of the cards will be matched with a regular participant. The probability of this situation happening is:$$\Pi_{i=0}^{k}\frac{k+1 -i}{2k-i}$$ where $2k = 2^n$. The dominating term will determine the upper bound probability, so extraction of terms yield $\Pi_{i=0}^{k} \frac{k}{2k} = \Pi_{i=0}^k \frac{1}{2} = \frac{1}{2}^k$. Now the problem is for every level, this should happen repeatedly for full execution of the attack . But the game enforces a strict minimum pool size of $64$ participants, which is sufficient enough to drive the possibility to some $\epsilon = (\frac{1}{2})^{32}= 2.328\times10^{-10}$ on the first round, a value that is small enough to neglect. If you extend it to all rounds at worst case, you have $\epsilon' = \Pi_{i=0}^{5}(\frac{1}{2})^{32/{2^i}}$ as the probability, is amazingly small.

The mystery box sale will be the initial source of capital to the game. Even though the exact numbers are not set yet, the details will be provided in the whitepaper. For a glimpse, the protocol will use a diminishing returns per incremented stake that will follow a logarithmic behavior, after the staking stage there will be mystery boxes claimable by the participants with assigned rewards. The rewards are mentioned in the _mechanics section_ of the paper.

## Extending the Idea to a Protocol Level Abstraction

When we showed the concrete example of the protocol above, it's possible to observe that the protocol can be extended to any game that involves competition, namely zero-sum games. The participants will be the competitors, and the game designers can instatiate the protocol by binding the rules of the game to the protocol triggers. And when we think the protocol as an abstraction, we can observe that some designers might want to have more control on the data and the execution. Since all systems have different needs, a customizable chain is a must. Also, EVM is proven to be not an efficient virtual machine for all needs. Thus, we are keen to build the abstract template by using [Substrate](https://substrate.io/) as a customizable chain. By using `Substrate`, the protocol and designers can tweak the chain aligned with their needs, without thinking too much about the data efficiency and the costs of operations in chains such as Ethereum. On the other hand, we don't want other games to congest the singular chain by dominating capacity. A multi-chain network is a must, and when we think in terms of independent systems, using multiple chains that interoperate is the future of scaling. In conclusion, a framework for the protocol is suited to be built with custom network, and `Substrate` seems to be the right tool for this. We have extended it in a another litepaper [here](https://hackmd.io/@denizsurmeli/rJKGeph1s).

## Conclusion
Why do we believe that this model is sustainable ? Because of another successful project with the similar idea: [Uniswap](www.uniswap.org). They have shown that if incentives provided to the users, the participants will drive the protocol as much as they could to profit more, since they are the ones that generate the value. We believe that we are advancing this idea by adding a gamification concept with highly emotional attachment to the game. The real simulation of hunting and fighting for a reward is absent in real life today, but in a metaverse that you fight in a arena for financial value is one of the closest experiences you can have.

We also think that the GameFi concept is a concept that is highly new and there is a crypto-native community who wants to participate in the sector. In a game where you can both produce and capture value without permission , also attaching emotional components to it, the protocols key alignments and the community values meet perfectly. Since being accepted by the community is the core requirement of any successful protocol, we believe that we will be loved by them.