---
# System prepended metadata

title: (outdated) Squad Protocol

---

# (outdated) Squad Protocol

## Definitions

The squad protocol defines a structure for metadata-driven games that
allows them and the metadata driving them to be curated by a
decentralized market.

```
Game <- Format -> Component
 ^____________________|
```

### Games

A Game definition is a set of instructions to run the game on a
particular platform. It might be a link to the game on the web, or an
install and run command on a desktop platform.

It's not necessary to include the code of the game in the definition
but in order to run on the squad platform a game software must be
configurable by the Formats and Components discussed below. The game
must also respect the licenses selected by format and component
contributors discussed below though the Squad software development
kits (SDKs) will make this easy to do.

### Components

A Component definition is interpreted by a game. It's up to the game
to expose an interface to Component designers and could treat
Components as a number of things like a unit of configuration, a
module, an image, an animation, or any other bit of data the game
might need.

If a card game exposed a schema for how it interprets cards, Component
contributors would create Components whose data followed that schema
to make cards available to Format contributors.

### Formats

A Format is a set of Components and configuration that together meet
the configuration requirements for a particular Game (or Games).
Formats specify a universe of Components and a way to play with
them---one of the possible complete experiences made possible by the
Game---for players to gather around.

## Curation

Each definitions is entered into the curation market which is
implemented as a curved bond token per definition. Market activity in
the market correlates to the value of the definition when purchases of
those bonds are correlated to their value. For instance, if a user is
required to buy a Format's bond before the game allows them to play or
if there is a micro-transaction market for cosmetics that change the
look of a component if the player has some of the relevant token.

In order to support a broad range of revenue models and revenue
sharing models built on top of this curation market, the protocol
supports revenue sharing between contributors, system enforceable
sharing requirements between contributions and legal licenses between
contributors and game developers.


```
Player -> Game -> Definition <- Contributor
  \        |         |   _______/
   \       |         |  /
    --- Proof of -- Bond ---- Curator
        purchase     |
                     |
                    Curve
```

* Players buy proofs of purchase and play Games
* Games check proofs of purchase and follow definition license rules as
  implemented by the Squad SDK
* Contributors create definitions (Games, Formats, Components)
  * Optionally buy first block of bond tokens
  * Optionally select licensing rules implemented by the Squad SDK
  * Optionally select revenue sharing requirements
* Curators buy bond tokens

## Value flow between contributors

Contributors choose licenses, revenue share offers, and revenue share
requirements as part of submitting definitions. Licenses are
agreements between players and contributors (and between multiple
contributors) enforced by the live courts and requirements are
constraints on revenue share offers enforced by the smart contracts.

## Licenses

### End User License Agreements (EULA)

Definitions may specify EULA clauses that players must agree to before
using them.

### Proof of purchase license

Definitions may specify a contract address that implements the Proof
of Purchase interface. Game contributors agree to check the contract
for proof of purchase before allowing players to use the definition.

#### Proof of purchase Interface

For games (though games can do what they want)
`validGamePurchase(userAddress, gameAddress)`

For Formats
`validFormatPurchase(userAddress, gameAddress, formatAddress)`

Format contributors may want the ability to charge for each game they
are played with, and perhaps charge different amounts.

For Components
`validComponentPurchase(userAddress, gameAddress, formatAddress, componentAddress)`

Component contributors may want to charge differently for different
games or formats

## Revenue Sharing Offers and Requirements

Each definition type has different options for sharing revenue and
requiring shared revenue.

### Component Revenue Share Options

Component authors may share N% of their revenue with formats that
include them, weighted by format market cap, and subject to a
deny-list.

### Component Requirement Options

Component authors may require formats to share greater than N% of
their revenue evenly with components in order to include the component
in the format.

### Format Revenue Share Options

Format authors may share N% of Format revenue evenly with its
components

Format authors may share N% of Format revenue with a game. This may be
specified multiple with different percentages for different games.

### Game Rev Share Options

Game authors may share N% of Game revenue with Formats for that game,
weighted by market cap, and subject to a deny-list. Revenue that would
have been sent to a format on a deny list is burned instead to keep
game authors from being able to add all formats not authored by them
to a deny list once the game becomes popular.

Game authors may share N% of Game revenue with Components in Formats
for the game weighted by either the component market cap or their
formats market caps or some combination.

### Game Requirement Options

Game authors may require that Formats for the game share greater than
N% revenue with either the game or their components.

Game authors may require that Formats for the game not include
components that don't share greater than N% with the game or the
format.

# Protocol Governance

The Squad Games DAO governs the protocol by setting the parameters and
funding new development.

## Token Economy

* In general I think we should start with as few options as we can and add them as needed
  rather than start by 

### Definition Curation Market Tokens

Each Game, Format, and Component definition is associated with a curved bond token
which is offered in exchange for assets the DAO has approved. Curves are S curves with
a limit set by the DAO and 

* What options should contributors have for their definition curve?
    * Should they be able to take ANY% after tax as revenue?
    * Should they be able to distribute ANY% after tax to token holders?
    * Should they be able to use any curve contract?

* What options should contributors have for their proof of purchase contracts?
    * Free (always return true)
    * Stable price
    * Should they be required to forward the purchase to the curve?
        * This would be a way around tax, in exchange for not being curated

### Squad Games Reputation

### Squad Games Dividend Token

## Responsibilities

* Maintain the software and documents
    * Smart Contracts
    * Software Development Kit
    * Back-end services
    * Website
    * Handbook
    * Documentation
    * Technical papers
* Set the governance tax rate
* Distribute dividends
* Token Economy Parameters
    * Curation Market Tax Rate
    * Curve parameters 
        * sigmoid function?
            * [bonding curves in depth](https://blog.relevant.community/bonding-curves-in-depth-intuition-parametrization-d3905a681e0a)
            * [bonding curves in practice](https://tokeneconomy.co/token-bonding-curves-in-practice-3eb904720cb8)
* Distribute reputation
    * Reputation distribution schedule (how much, how often)
    * Stakeholder category definition
    * Stakeholder category reputation portions
    * Stakeholder category distribution functions (how to distribute a categories rep to its members)
    * Voting schemes
    * Rage quit option?
    * Who gets rep and how?
        * Rep is minted on a regular schedule
        * DAO determines what portion of new rep is distributed to each
          stakeholder category
    * Investors
        * Gain rep weighted by investment token owned 
    * Contributors
        * Gain rep weighted by contribution market success
    * DAO Agents and Developers
        * Create and distribute rep in exchange for work and general
          participation according to precedent
    * Players
        * Probably need to implement "game results" system for this.