# Yellowpaper

April 5, 2022 · 73 minute read

## Staking & Unstaking​

Staking and unstaking are the basic mechanisms that allow ships to enter and exit gameplay. While ship traits are preserved across stakes and unstakes, unstaking a ship erases its internal travel and banking state. As such, ships may only unstake when they have arrived at The Citadel.

To stake a ship $s$, a pilot sends a transaction including its unique identifier. After verifying that the pilot owns $s$, we map $s$'s unique identifier to the pilot's address, initialize its travel state, and transfer ownership of $s$ to the game contract, following the checks-effects-interactions pattern. This is standard practice, and ensures that we know which pilot owns $s$, that $s$'s state is correct from the beginning, and that the pilot may not trade $s$ while playing. Unless stated otherwise, every action dependent on a ship $s$ is only allowed for its staking pilot.

To unstake $s$, a pilot sends a similar transaction including $s$'s unique identifier. After verifying that the ship is staked, that it belongs to the pilot, and that it is targeting and has arrived at The Citadel, we delete its internal travel and staking state, then transfer it back to the pilot.

## Ship Reveals​

When a pilot mints a ship, it has no data associated with it. To ensure that ship traits are distributed fairly, each pilot must initiate a reveal for their ship, which pulls a random from Chainlink VRF and uses it as a seed for trait generation. Because all reveals happen on Layer 2, per-request randoms are viable, and each pilot can choose to reveal their ship at any time after mint, instead of having to wait for a batch of seeds.

To accommodate the push-based nature of VRF, ship reveals happen in three stages. First, a pilot sends a transaction to initiate the reveal. During this stage, we check that the ship has not already been revealed, that the pilot owns their ship, and that no other reveals are in progress for it. Once the checks are complete, we mark that a reveal is pending for the ship and request a random from Chainlink VRF, which will function as the seed for the ship's traits.

After 10 blocks, the random oracle calls back into the ship traits contract, providing the random number and the ship id for which it is relevant. In response, we record the random, and note that the ship is ready for reveal.

Once the pilot is notified that their ship is ready for reveal, they may send a final transaction to complete the reveal and assign their ship its traits. During the reveal transaction, we check that the seed exists and that the ship hasn't already been revealed, mark it as revealed, then select and assign its traits.

For genesis ships, we use A. J. Walker's alias method to select each ship's independent traits (size, class, designation, hull) according to the proper probability distribution. From those traits, we are able to fill in the ship's dependent traits(speed, fuel efficiency, reactor, power) without pulling additional randoms. For more information on the distribution of genesis ship traits, see the ship traits section.

For ships introduced through the construction bay, we modulate the random seed to select each ship from a predefined list. Once a ship is selected, it is deleted from the list, so that no ship is selected more than once. For more details on the construction bay, see the construction bay section.

## Ship Traits​

Each ship has four traits that correspond to gameplay mechanics: speed, fuel efficiency, reactor cost, and power.

Speed is the number of units that a ship can travel per second. Fuel efficiency and reactor cost determine the travel cost that a ship's pilot pays to seek new opportunities. Fuel efficiency is measured in units per full ore, and reactor cost is a flat fee per travel, measured in ore. Speed, fuel efficiency, and reactor cost are especially relevant to travel, and are covered in depth in the travel section.

In rough terms, a ship's power determines its ore gathering capability. For miners, this is the ship's drill rate, which measures the drill that they accumulate per second during their mining operations. For a fixed ore type and mining duration, this is directly proportional to the ore that they gain. For marauders, this is the ship's attack power, which dictates the percentage of stolen ore it receives, relative to other marauders at its belt. The impact of power is covered in depth for miners in the mining section and for marauders in the roaming section.

tl;dr: For power, travel speed, and fuel efficiency, higher numbers mean that the ship is better suited for the corresponding mechanic. For reactor cost, lower is better, especially for short-distance travel.

For simplicity, classes are referenced by their sizes. Small ships correspond to frigates and interceptors, medium ships correspond to barges and cruisers, and large ships correspond to command ships and battleships.

Each of the tables below corresponds to a ship designation. Ship stats increase based on their designation, and to balance this, the likelihood of ships being these designations varies. Upon reveal, a ship has a 60% chance of being standard, a 30% chance of being noble, and a 9% chance of being exodus.

### Standard​

ClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)
Small6508002400,000
Medium8256006275,000
Large100050010200,000

### Noble​

ClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)
Small85012002400,000
Medium115010006275,000
Large140070010200,000

### Exodus​

ClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)
Small145016002400,000
Medium165014006275,000
Large1800120010200,000

While noble and exodus class ships have better traits by default, standard ships have a small chance to get upgraded stats upon initial mint. Out of all standard ships minted, 2% will have tier 1 systems, 1% will have tier 2 systems, and 0.5% will have tier 3 systems. More information on upgrades and the meaning of tiers will be outlined in the upgrades section.

TierClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)
T1Small682.5008801.66420,000
Medium886.8756455.5288,750
Large1100.0005259.25210,000
T2Small715.0009601.33440,000
Medium948.7506905302,500
Large1200.0005508.5220,000
T3Small747.50010401460,000
Medium1010.6257354.5316,250
Large1300.0005757.75230,000

## Ship Naming​

When a pilot has accumulated enough ore, they can choose to spend 1000 ore to give their ship a name. After accumulating sufficient ore, pilots may choose to name their ships for vanity purposes. These names are permanent, unique, and displayed prominently in token metadata. To prevent abuse, ships may consist only of alphanumeric characters and spaces. To ensure that existing names stay in sync for the uniqueness check, ships may only be named from Layer 2.

When a pilot submits a transaction to name their ship, we check that the ship has not yet been named and that no other ship's name has the same hash. We then set the ship's name, mark the name's hash as used, and burn 1000 ore from the pilot's account. When pilots move their ships between networks, the ships' names are sent and applied through the dock.

Each ship can be upgraded to increase its power, speed, and fuel efficiency stats, and upgrades are organized by tiers from one to five. Each of the upgrade tiers takes a different amount of time and ore to complete, where time is measured in days. Independent of its tier, every upgrade's time and ore cost differs depending on the ship's class and designation. As in ship traits, classes are written as their sizes: small, medium, and large.

TierClassOre Cost (Miner)Ore Cost (Marauder)Upgrade Time (Days)Stat Bonus
T1Small2505000.25105%
Medium2505000.25107.5%
Large2505000.25110%
T2Small50010000.5110%
Medium50010000.5115%
Large50010000.5120%
T3Small100020001115%
Medium100020001122.5%
Large100020001130%
T4Small200040002120%
Medium200040002130%
Large200040002140%
T5Small300080003125%
Medium300080003137.5%
Large300080003150%

TierClassOre Cost (Miner)Ore Cost (Marauder)Upgrade Time (Days)Speed BonusFuel Efficiency BonusUpdated Reactor Cost (ORE)
T1Small1252000.125110%105%1.66
Medium1252000.125107.5%105%5.5
Large1252000.125105%105%9.25
T2Small2504000.25120%110%1.33
Medium2504000.25115%110%5
Large2504000.25110%110%8.5
T3Small50010000.5130%115%1
Medium50010000.5122.5%115%4.5
Large50010000.5115%115%7.75
T4Small100020001140%120%0.75
Medium100020001130%120%4
Large100020001120%120%7
T5Small150040002150%125%0.5
Medium150040002137.5%125%3.5
Large150040002125%125%6.25

### Cost Modifiers​

SmallNoblePower115%110%
Propulsion130%110%
ExodusPower160%150%
Propulsion140%130%
MediumNoblePower130%120%
Propulsion130%110%
ExodusPower180%150%
Propulsion160%130%
LargeNoblePower145%120%
Propulsion130%115%
ExodusPower200%150%
Propulsion180%140%

### Calculator​

Disclaimer: this calculator uses JavaScript floating point math, instead of the fixed-point representation that we use in Solidity. As such, the results may be ever so slightly different in-game. Please use this calculator to get a feel for the mechanic, then consult the game UI to finalize your decisions.

## Travel​

### Definitions​

• $v_s$ - The speed of ship $s$ (in units per second)
• $r_s$ - The reactor cost of ship $s$ (in ore wei)
• $f_s$ - The fuel efficiency of ship $s$ (in units travelable per ore)
• $(x_s, y_s)$ - The current coordinates of ship $s$
• $\operatorname{dist}((x_1, x_2), (y_1, y_2)) = \sqrt{{(x_1-x_2)}^2 + {(y_1 - y_2)}^2}$ - The Euclidean distance function

### Overview​

The Citadel's map is a 16:9 rectangle, and points are represented with standard cartesian coordinates. To keep manipulation straightforward from Solidity, coordinates start at $(0, 0)$ and increase from the top left corner of the map, meaning that $x$ and $y$ for any point are always zero or positive. Aside from the ships docked there, The Citadel is the unique game element with coordinates $(0, 0)$.

### Ship Positions​

During gameplay, ships may travel between locations on the map. Because it is impossible to trigger transactions directly from within a contract, we cannot update ships' positions periodically. Instead, we store a ship $s$'s intent to travel as $(x_c, y_c)$, the coordinates of $s$ when the intent was signaled, $(x_t, y_t)$, the coordinates that $s$ is targeting, and $t_s$, the epoch time at which the $s$ signaled its intent.

Logically, we assume that ships travel in a straight line from their last committed coordinates $(x_c, y_c)$ to their target $(x_t, y_t)$. To compute the position of $s$ at epoch time $e$, we first compute the distance it has traveled, $l_s(e) = \operatorname{min}(\operatorname{dist}((x_c, y_c), (x_t, y_t)), (e - t_s)v_s)$. If $l_s(e) \geq \operatorname{dist}((x_c, y_c), (x_t, y_t))$, we know that the ship has arrived, and that its coordinates are $(x_t, y_t)$. This technique also serves as a $\operatorname{min}$ function, preventing overshoots. Otherwise, we know that the ship has not arrived. In this case, because the ship is travelling in a straight line, we can compute its coordinates as $(x_c, y_c) + \frac{l_s(e)}{\operatorname{dist}((x_c, y_c), (x_t, y_t))}(x_t - x_c, y_t - y_c)$. To prevent underflow, each component becomes $x_s = x_c - \frac{l_s(e)}{\operatorname{dist}((x_c, y_c), (x_t, y_t))}(x_c - x_t)$, and $y_s = y_c - \frac{l_s(e)}{\operatorname{dist}((x_c, y_c), (x_t, y_t))}(y_c - y_t)$ when $x_t < x_c$ and $y_t < y_c$, respectively.

### Travel Transactions​

When initiating a travel transaction for a ship, a pilot includes the ship's identifier and the identifier of the point that they're targeting. After verifying that the pilot has the correct permissions and that the target exists, we can look up $(x_{\operatorname{tnew}}, y_{\operatorname{tnew}})$ and compute $(x_s, y_s)$. We then commit the ship's current position $(x_c, y_c) := (x_s, y_s)$, note the time $t_s := \operatorname{now}$, and update the ship's target $(x_t, y_t) := (x_{\operatorname{tnew}}, y_{\operatorname{tnew}})$. Note that because we've placed The Citadel at $(0, 0)$, each of the values assigned here is automatically correct before initialization (i.e., the first travel transaction), due to the EVM's zero defaults.

After we've updated the ship's travel state to reflect its intent, we compute and transfer the ore necessary to get there. Fuel cost in ore for each trip is simply the distance the ship will travel, divided by the ship's fuel efficiency, plus the ship's reactor cost, given as $\frac{r_s}{10^{18}} + \frac{\operatorname{dist}((x_s, y_s), (x_t, y_t))}{f_s}$. Because native fixed-point math isn't available in Solidity yet, we adapt the formula for ore wei within the contract $r_s + \frac{\operatorname{dist}((x_s, y_s), (x_t, y_t))(10^{18})}{f_s}$. For ships that have not traveled before, the fuel cost for any trip is defined to be $0$ ore, for any target. Of the ore proceeds from travel, $\frac{2}{3}$ are burned and $\frac{1}{3}$ are added to the DAO's balance.

### Calculator​

Disclaimer: this calculator uses JavaScript floating point math, instead of the fixed-point representation that we use in Solidity. As such, the results may be ever so slightly different in-game. Please use this calculator to get a feel for the mechanic, then consult the game UI to finalize your decisions.

Try $(0, 0)$ for The Citadel, $(10000000, 7000000)$ for Frontier, $(15000000, 40000000)$ for Providence, $(40000000, 30000000)$ for Ouroboros, $(80000000, 5000000)$ for Outer Ring, and $(70000000, 35000000)$ for Abyss. For reference, the maximum map coordinates are $(86400000, 48600000)$.

## Belts​

While belts are not a mechanic themselves, they are directly involved in almost every part of the game. As such, they have many associated values, and it is very important that they are defined concretely. Instead of describing the procedure for a mechanic, this section will give a high-level view of the properties of belts and how they are applied.

As game elements, belts have standard $(x, y)$ coordinates. From here on, $(x_b, y_b)$ will mean the coordinates of belt $b$, or casually, the belt being referenced.

For their limited-resource mechanic, belts have a capacity. This is measured in drill, and is depleted with the sum of the drill of the ships mining there. From here, it will be written as $c_b$. Internally, a belt's remaining capacity is computed from $r_b$, the current rate of depletion (in drill per second), $t_b$, the epoch time of the last change in depletion rate, and $g_b$, the total capacity depleted prior to the last rate change.

To simulate multiple ores with varying densities, each belt has an optional ore breakdown. This breakdown is not present when the belt is initially added, and is published after the fact by the game developers. An ore breakdown, if present consists of a list of ore multipliers $\mu_i$ and probabilities $\rho_i$ for breakdown items $1, 2, ..., n$. Each $\mu_i$ controls how much ore a miner receives per second of their operation and the corresponding $\rho_i$ determines the probability that a miner receives the multiplier $\mu_i$ when completing their operation. For extra precision, $\mu_i$ are stored in ore wei and $\rho_i = 10^{18}$ represents a probability of 100%.

The power balance of miners and marauders for each belt is dictated by its transport ship tax $\tau_b$ and its crime breakdown. Like the ore breakdown, these are both optional and filled upon publication. The transport ship tax $\tau_b$ dictates the percentage of ore that it siphoned when a miner calls a transport ship to belt $b$. Values range from $\tau_b = 0$ for zero percent, and $\tau_b = 10^{18}$ for one hundred percent. A crime breakdown consists of a list of theft percentages $\sigma_i$ and probabilities $\psi_i$ for breakdown items $1, 2, ..., n$. Each $\sigma_i$ controls what percentage of ore is stolen from a miner's gross claim and the corresponding $\psi_i$ determines the probability that the theft percentage $\sigma_i$ occurs, should a miner not call a transport ship from $b$. For extra precision, $\tau_b, \sigma_i, \psi_i$ are stored on the same $[0, 10^{4}]$ scale as $\rho_i$.

To ensure that the developers are unable to manipulate belt publications, each belt is initialized with a provenance value $\operatorname{provenance}_b = \operatorname{keccak256}(\tau_b, (\sigma_i, \psi_i), (\mu_i, \rho_i))$. When the developers send a transaction to publish the belt, the contract verifies that $\operatorname{keccak256}(\tau_b, (\sigma_i, \psi_i), (\mu_i, \rho_i)) = \operatorname{provenance}_b$, the value that they submitted when adding the belt. If the hash does not match the provenance, the transaction reverts. This property means that it is impossible for the developers to change the ore breakdown for a belt after adding it, preventing them from manipulating the game based on the interaction that the belt receives.

## Regions​

### Overview​

As a way to organize belts with similar crime and transport ship tax rates, the map is separated into regions. From Frontier through Abyss, regions get more distant from The Citadel and present increased risks and rewards. The transport ship tax controls the percentage of ore that is deducted from miners who opt to claim without returning to an outpost. The crime outcomes control the likelihood that 0%, 15%, 30%, 45%, 70%, or 100% of a miner's ore claim is stolen, should they opt to return to an outpost to deposit it. In the case that 100% of a claim is stolen, the claiming ship is also destroyed (burned) permanently. In all regions except for the Abyss, transport ships are considered to be the safe option, as the percentage of ore deducted is always known in advance. However, at distant belts, the increased transport ship taxes and the relatively low chance of destruction may encourage miners to take a risk. In the Abyss, high-value ores are abundant and transport ships are not available at all, meaning that all miners must embrace the odds.

### Example Belts​

Shown AsRegionCoordinates
Frontier$(10 \cdot 10^6, 7 \cdot 10^6)$
Providence$(15 \cdot 10^6, 40 \cdot 10^6)$
Abyss$(40 \cdot 10^6, 30 \cdot 10^6)$
Ouroboros$(80 \cdot 10^6, 5 \cdot 10^6)$
Outer Ring$(70 \cdot 10^6, 35 \cdot 10^6)$

### Theft Probabilities​

Region0% Theft15% Theft30% Theft45% Theft70% Theft100% Theft
Frontier55%15%15%10%3.5%1.5%
Providence65%15%10%6%3%1%
Ouroboros70%12.5%7.5%5%4.2%0.8%
Outer Ring75%10%5%5%4.6%0.4%
Abyss77.5%5%5%2.5%5%5%

RegionTax
Frontier25%
Providence30%
Ouroboros35%
Outer Ring40%
AbyssN/A

## Outposts​

Outposts are travel targets in the game where returning mining ships can claim their rewards without a transport ship. More on this can be found in the mining rewards section. The Citadel is a special outpost where ships can be staked and unstaked, but other outposts are planned. Information regarding staking is in the staking section.

## Mining​

### Definitions​

• $d_s$ - The drill trait of ship $s$ (in drill per second)
• $c_b$ - The capacity of belt $b$ (in total drill)
• $\mu_i$ - The $i$th drill multiplier within the ore breakdown of the referenced belt (in ore wei)
• $\rho_i$ - The density of the $i$th ore within the ore breakdown of the referenced belt (in $[0, 10^{4}] \rightarrow [0\%, 100\%]$ representation)
• $\tau_b$ - The transport ship tax for belt $b$ (in $[0, 10^{4}] \rightarrow [0\%, 100\%]$ representation)
• $\sigma_i$ - The theft percentage of the $i$th crime outcome within the crime breakdown of the referenced belt (in $[0, 10^{4}] \rightarrow [0\%, 100\%]$ representation)
• $\psi_i$ - The probability of the $i$th crime outcome occurring for non-transport ship claims at the referenced belt (in $[0, 10^{4}] \rightarrow [0\%, 100\%]$ representation)

### Depletion​

Each belt's resources deplete with the sum of the drill of its active mining operations. Concretely, each second, a belt $b$'s capacity depletes by $\sum_{s} d_s$ for each ship $s$ mining at $b$. As ships begin and complete their mining operations, this rate changes. Because it is infeasible gas-wise to store and loop through each rate on every mining transaction, we have to compute depletion a little differently.

Internally, we keep track of belt depletion as $r_b$, the current rate of depletion (in drill per second), $t_b$, the epoch time of the last drill rate change, and $g_b$, the total capacity depleted from $b$ prior to the last rate change.

This makes it straightforward to compute the depleted capacity of $b$ (in drill) as $p_b(e) = g_b + (e - t_b)r_b$, for epoch time $e$ after $t_b$. The remaining capacity for $b$ is then $m_b(e) = c_b - p_b(e)$. The downside is that we lose on-chain access to the remaining capacity for times before $t_b$, but because it is simple to compute from logs and timestamps only move forward on the blockchain, it is no big deal.

When a transaction is sent to start a mining operation for some ship $s$ at $b$, we first check $m_b(\operatorname{now})$. To prevent overdrilling, we compute the belt's hypothetical drilled capacity after a second of drilling at the new rate, $h_b = p_b(\operatorname{now}) + (r_b + d_s)$. If $h_b > c_b$, it's clear that the belt doesn't have the capacity to support this ship, and we revert the transaction. Otherwise, we commit the depletion at the rate excluding $s$, $g_b := p_b(\operatorname{now})$, note the time of commit $t_b := \operatorname{now}$, and update the current drill rate $r_b := r_b + d_s$ to account for the drill of the new ship.

Things get a little more complicated when a stop mining transaction is submitted for a ship $s$ at $b$. To start, we check $p_b(\operatorname{now})$. If $p_b(\operatorname{now}) \leq c_b$, we know that the belt has had the capacity to support $s$'s drill for its entire operation, from its start time to now. In this case, all we have to do is commit the depletion at the rate including $s$, $g_b := p_b(\operatorname{now})$, note the time of commit $t_b := \operatorname{now}$, and update the current drill rate $r_b := r_b - d_s$ to account for the removal of $s$'s drill. If $p_b(\operatorname{now}) > c_b$, the belt's capacity was depleted somewhere between the start mining transaction for $s$ and now. Assuming that $g_b \leq c_b$, we can compute when by computing how long it took to reach capacity from the last commit, $\frac{c_b - g_b}{r_b}$ and then adding it to the time of the last commit $t_b$. This gives us the epoch time of the belt's depletion, $f_b = \frac{c_b - g_b}{r_b} + t_b$.

To ensure that our $g_b \leq c_b$ assumption holds for future exits, we update the rate as normal $r_b := r_b - d_s$, but commit the depletion as only the belt's capacity $g_b := c_b$, and set the commit time to the second that the belt was depleted, $t_b = f_b$, instead of the current epoch time. To avoid division by zero when all ships have exited, we use $0$ for $\frac{c_b - g_b}{r_b}$ when $g_b = c_b$.

### Rewards​

When mining a belt, a miner accumulates rewards in the form of total drill, up until the belt's capacity is depleted. Upon completion of their mining operation, an ore wei per drill value is selected from the belt's ore breakdown, and multiplied by the total drill the miner has accumulated to determine their gross ore owed.

Suppose that a ship $s$ has been mining at belt $b$ since epoch time $\epsilon$. At epoch time $e$, $s$ stops mining and requests to claim its rewards. To compute their rewards in ore, we must first compute their operation's total drill. To do this, we first check the drilled capacity of $b$ at $e$, $p_b(e)$. If $p_b(e) \leq c_b$, the belt hasn't yet been depleted, meaning that the miner's is simply $(e - \epsilon)d_s$. Of course, if $p_b(e) > c_b$, the belt was depleted sometime before $e$. In this case, we can use $f_b$, as computed in the depletion section. Thus, we have $\omega_s = d_s(\operatorname{min}(e, f_b) - \epsilon)$ for the $s$'s total drill.

Aside from the mining operation's total drill, the net ore that $s$ receives is dependent on whether its pilot opts to call a transport ship or return to an outpost themselves. To reduce branch count, the $\omega_s$ and a boolean indicating whether the pilot is returning are stored in each case. A random request is then sent through Chainlink's VRF, the result of which will determine the pilot's fate. If $s$ will be returning to an outpost to claim its ore, its travel state is updated and ore is burnt for fuel according to distance, as usual. It is also marked as Returning at this point, and forbidden from traveling until it arrives at the outpost.

When the random request is fulfilled with random $\gamma$, it is modulated by our precision basis, $10^{4}$. We then select the first $\mu_k$ such that $\sum_{i = 1}^{k} \rho_i < \gamma \operatorname{mod} 10^{4}$. This multiplier allows us to find the gross ore of the claim, $\mu_k\omega_s$. If there are no marauders roaming at $b$, this is equivalent to the net ore owed to the pilot, and no further computation is necessary. Otherwise, the remaining process for determining the net ore for $s$'s claim is dependent on whether its pilot has opted to call a transport ship.

If $s$'s pilot has opted to perform the claim by transport ship, the net ore for the claim is calculated as the percentage of the gross ore claim in wei that is not lost to the transport ship tax, $\mu_k\omega_s\ - \frac{\mu_k\omega_s\tau_b}{10^{4}}$. In whole ore, this is $\frac{10^{4}\mu_k\omega_s - \mu_k\omega_s\tau_b}{10^{22}}$.

Otherwise, the crime outcome affecting $s$ return is selected through a process similar to that used for the ore wei per drill. We select pick the lowest $j$ for which $\sum_{i = 1}^{j} \psi_i < \operatorname{keccak256}(\gamma, 1) \operatorname{mod} 10^{4}$. We then compute the net ore wei owed to the miner, $\mu_k\omega_s\ - \frac{\mu_k\omega_s\sigma_j}{10^{4}}$. In whole ore, this is $\frac{10^{4}\mu_k\omega_s - \mu_k\omega_s\sigma_j}{10^{22}}$. In the case that $\sigma_j = 10^{4}$, the entire gross ore reward is stolen and $s$ is burned.

In reality, this process has to occur in three transactions in order to accommodate per-request randoms. The miner initiates the process by submitting a transaction to commit their claim. In this step, we store the operation's total drill, $s$'s id, and whether $s$ will be returning. If $s$ is returning, we also initiate the travel process, burning the necessary fuel and marking it as Returning. We then send a random request to Chainlink VRF. When the request fulfills, Chainlink calls into the game contract, allowing it to store $\gamma$. Once $\gamma$ has been stored, the pilot may submit a transaction to reveal the outcome of their operation, computing and accounting for their net ore.

### Calculator​

Disclaimer: this calculator uses JavaScript floating point math, instead of the fixed-point representation that we use in Solidity. As such, the results may be ever so slightly different in-game. Please use this calculator to get a feel for the mechanic, then consult the game UI to finalize your decisions.

## Roaming​

### Definitions​

• $a_s$ - The attack power of ship $s$ (in gun units)

### Rewards​

Once a marauder ship $s$ has arrived at a belt $b$, it may begin roaming there. Roaming grants $s$ a portion of the ore siphoned through transport ship taxes and crime outcomes, proportional to the percentage of the belt's attack power that it contributes. In concrete terms, for a claim where $o$ ore is stolen, $s$ will receive $o(\frac{a_s}{\sum_{z} a_z})$, where $z$ is any ship at $b$ (including $s$).

Because it is impractical to compute and update $\frac{a_s}{\sum_{z} a_z}$ for each marauder each time it changes, we have to store the rewards in a form that allows a single storage update to apply to all marauders. To achieve this, we store $\alpha_b$, the total attack power at $b$, $\omega_b$, the total ore wei to be issued per gun at $b$, and $\eta_s$ the annulled ore per gun for each marauder ship $s$ at $b$. This allows us to keep track of how much ore each marauder is owed, without having to keep track of the rate. We can then compute the ore wei owed to a marauder ship $s$ as $(\omega_b - \eta_s)a_s$.

When a marauder ship $s$ arrives at $b$ and begins roaming, we set $\eta_s := \omega_b$ and $\alpha_b := \alpha_b + a_s$. This correctly starts $s$ with zero ore wei owed, and allows us to account for the extra attack power at the belt moving forward. Because $\omega_b$ only increases throughout the life of the belt, the computation is safe from underflow.

When $o$ ore wei are siphoned, it is straightforward to divide it by the total attack power to figure out the increase in ore wei owed per gun $\omega_b := \omega_b + \frac{o}{\alpha_b}$. Because ore owed per ship is computed directly from $\omega_b$, no additional writes are necessary.

When a marauder ship $s$ leaves $b$, note the decrease in total attack power at $b$, $\alpha_b := \alpha_b - a_s$, find the ore wei that are owed, $(\omega_b - \eta_s)a_s$, and issue it to $s$'s pilot. For the sake of the gas refund, we also set $\eta_s = 0$. Because the $s$ has left the belt, $\eta_s$ will be set properly if it enters again and begins roaming, making the operation safe.

## Claiming Ore​

All ore gains from ships' mining and roaming operations are mapped to their stakers' addresses and may be claimed at any time through a separate transaction, in compliance with the pull-payment pattern. Because banking state is tied to addresses and not ships, pilots do not lose their pending ore when their ships are unstaked, transferred, or destroyed. When a pilot claims their pending ore, a 2.5% tax is levied and added to the DAO balance, and their remaining ore is transferred to their address.

## Construction Bay​

New ships are brought into the game through the ship construction bay, a periodic sealed-bid (blind) dutch auction system. Weekly, all addresses will have one day to bid on a number of ships, with unknown traits. Each individual address may bid on up to 3 ships. Once the auction has completed, all bids will be released, and the winning bidders will be able to claim their ships. Each winning bidder will pay the price of the lowest winning bid.

Because all transactions are publicly visible on the blockchain, sealed-bid auctions are not straightforward to implement. Originally, the bidding system was to be based on a modified version of Anonymous Sealed-Bid Auction on Ethereum, which presents a cryptographic model for keeping bids private and auctioneers honest in an on-chain system. However, the number of transactions required from each bidder, as well as the timing required for them to be valid, would have significantly decreased accessibility.

As a compromise between accessibility and trustlessness, the bid collection system will be hosted off-chain, but the deposit collection, bid reveal, and ship reveal systems will be implemented on-chain, through a smart contract.

### Definitions​

• $e$ - The time in epoch seconds, in each example

### The On-chain Process​

#### Auctions​

Auctions may only be added by construction bay admins. When a construction bay admin submits a transaction to add an auction, they include the following parameters:

• $\iota$ - The ID of the auction
• $\epsilon_s$ - The start time for the auction, in seconds since the epoch
• $\epsilon_e$ - The end time for the auction, in seconds since the epoch
• $\delta_w$ - The winning submission delay for the auction, in seconds
• $\delta_f$ - The finality delay for the auction, in seconds
• $\tau_f$ - The flat tax rate for the auction (in $[0, 10^4] \rightarrow [0\%, 100\%]$ representation)
• $\tau_n$ - The no-show tax addition for the auction (in $[0, 10^4] \rightarrow [0\%, 100\%]$ representation)
• $\sigma$ - The id of the first token issuable from the auction
• $\nu_t$ - The total number of ships allocated to the auction
• $\alpha$ - The address of the ERC20 token contract that will process deposits for the auction
• $\psi$ - The address of the system signer for the auction
• $\xi$ - The address of the contract that will assign traits for the auction's ships

For convenience, let these same definitions apply to the referenced auction for each example in the following sections.

After checking that no auction already exists with the ID $\iota$, we associate all of the passed parameters with the auction $\iota$. Beyond the parameters that are used to initialize it, auctions are defined by the following (mutable) state variables, each of which is zero-initialized:

• $\Rho$ - The total depositor rewards for the auction, in $\alpha$ wei
• $\Omega$ - The winning bid for the auction, in $\alpha$ wei
• $\Beta_d$ - The balance of depositor $d$ for the auction
• $\Delta_d$ - The total $\alpha$ wei deposited by depositor $d$ for the auction
• $\Chi_d$ - The total $\alpha$ wei claimed by depositor $d$, as depositor rewards for the auction
• $\Nu_c$ - The total number of ships claimed from the auction
• $\Tau_d$ - 1 if depositor $d$ has revealed on time
• $\Pi_d$ - 1 if depositor $d$ has been punished

For convenience, let these same definitions apply to the referenced auction for each example in the following sections.

The construction bay can support multiple active auctions at the same time, but, for the sake of simplicity, we will assume that there is only one active auction ("the auction") while describing the process.

#### Standard Parameters​

Although the construction bay has been designed to accept auctions with varying tax rates, payment tokens, winning submission delays, and finality delays, these parameters will be constant for the foreseeable future. For the standard auction, we expect the following definitions to hold:

• $\delta_w = 3600$, 1 hour
• $\delta_f = 86400$, 24 hours
• $\tau_f = 500$, 5%
• $\tau_n = 5000$, 50%
• $\alpha = \text{ore token address}$

#### States​

After it has been added, an auction may be in one of four states at any time: Bidding, AwaitingWinningBid, Revealing, Punishing, or, in rare cases, Neglected. All auctions move through these states in order, and there is no return to a state once it is complete. In the usual case, an auction will move from Bidding to AwaitingWinningBid, then to Revealing, and finally to Punishing. In the case that The Citadel Team fails to publish the winning bid within $\delta_w$ seconds of the end of the auction, the state will instead progress from AwaitingWinningBid to Neglected, at which point all depositors will be able to recover their funds.

#### Bidding​

When $\epsilon_s \leq e \lt \epsilon_e$, the auction is considered to be in the Bidding state. During this time, bidders and stakers may deposit any amount of the auction's native token. When a depositor $d$ sends a deposit transaction for an amount $a$, the construction bay stores its token balance $b_0$, attempts to transfer $a$ from the depositor's token balance, and then records its updated token balance $b_1$. It then computes the net deposit increase and sets the depositor's balance to reflect it: $\Delta_d := \Delta_d + (b_1 - b_0)$, $\Beta_d := \Beta_d + (b_1 - b_0)$. If the depositor intends to use their deposit as backing for a bid, they may then send a request to the bid signing system to create a bid ticket for any amount $m$, so long as their bid plus the flat tax, $(1 + \frac{\tau_f}{10^4})m \leq \Beta_d$.

The point of allowing everyone to deposit into the contract is similar to bluffing in a game of poker: people reading the deposit transactions have to guess whether the depositor is transferring more than their bid into the contract. This ensures that they can't reliably outbid others by reading transaction data. Distributing bid taxes based on deposits, instead of bids, ensures that depositors have economic incentive to bluff, thus securing the privacy of bids.

#### Awaiting the Winning Bid​

When $\epsilon_e \lt e \leq (\epsilon_e + \delta_w)$ and $\Omega = 0$, the auction is considered to be in the AwaitingWinningBid state. During this state, deposits are disabled and reveals are disallowed. The only action that may occur for the auction is the submission of $\Omega$ by the construction admin.

This phase of the auction is designed to be short, and will likely not be noticeable for most auctions, as the winning bid submission is triggered automatically once $\epsilon_e$ passes. In the case that that automatic submission fails, the submission delay $\delta_w$ serves as an incentive for the team to rectify the issue, given that the auction will enter the Neglected state for $e \gt (\epsilon_e + \delta_w)$ where $\Omega = 0$.

#### Revealing​

When $\epsilon_e \lt e \leq \epsilon_e + \delta_f$, and $\Omega \neq 0$, the auction is considered to be in the Revealing state. During this time, bidders may reveal the bids that they placed during the auction. Bids are represented internally as "bid tickets", Solidity structures with the following fields:

• $n$ - The number of ships the bidder hopes to win
• $a$ - What the bidder is willing to pay for each ship, in wei for the auction's native token
• $t$ - The time that the bidder created the bid ticket, in epoch seconds
• $i$ - The id of the auction that the bidder is targeting
• $d$ - The address of the depositor

For convenience, let these same definitions apply to the bid ticket for each example in the following sections.

In order for a bid to be accepting during the Revealing phase, it must be accompanied by signatures from both the depositor $d$ and the system signer. The depositor's signature serves to verify that the consented to the bid, and that The Citadel's systems did not manipulate it in any way. The system signature requirement allows the off-chain logic to verify that the bidder's deposit is sufficient to cover their bid and any taxes. The doubly-signed bid tickets are a compromise between privacy and trustlessness. The depositor's signature ensures that bids cannot be faked by the system, and the system's signature ensures that depositors cannot overbid their deposits.

If both signatures are valid, we map the depositor's address to their bid amount, and mark that they revealed their ticket on time, $\Tau_d := 1$.

Once the bid has been stored and the bidder has been marked, we check whether the bid is a winner.

In the case that $a \geq \Omega$, the bid is a winner, and may claim $w =\operatorname{min}(o, \nu_t - \Nu_c)$ ships. In order to process the claim, we first compute what the depositor owes for their claimed ships, $w * \Omega$. Next, we compute the total taxes that they owe for their bid. Because taxes are based directly on submitted bids and not winning bids, this is $\frac{an\tau_f}{10^4}$ $\alpha$ wei, or $\frac{an\tau_f}{10^{22}}$ full $\alpha$ tokens. To distribute this amount among all of the auction's depositors, we update the total depositor rewards, $\Rho := \frac{an\tau_f}{10^4}$. We can then deduct the sum of these amounts from the depositor's balance, $\Beta_d := \Beta_d - ((w * \Omega) + \frac{an\tau_f}{10^4})$, to charge the depositor for the ships that they won, in addition to the standard bid taxes. Finally, we increment the claimed ships count, $\Nu_c := \Nu_c + w$, copy and zero the depositor's balance, return the depositor's remaining funds, and issue the depositor their $w$ ships, unrevealed. In order to reveal their ships' traits, the depositor may call the reveal function from $xi$.

If $l \lt \omega_s$, the bid is not a winner, and the depositor may reclaim their deposit, minus the flat tax on their bid. We compute, deduct, and distribute the flat tax using the same process as for winning bids, $\Beta_d = \Beta_d - (\frac{an\tau_f}{10^4})$. We then copy and zero the user's balance, and send them their remaining funds.

#### Punishing​

When $e \geq (\epsilon_e + \delta_f)$ and $\Omega \neq 0$, the auction is considered to be in the Punishing state. During this time, all doubly-signed bid tickets will be released off-chain, and all addresses will be allowed to call the punish function. To use punish, the caller supplies a valid doubly-signed bid ticket that was not revealed on time and hasn't yet been punished.

To perform a punishment, we first verify that the bid ticket is valid, that both of its signatures are valid, that its depositor did not reveal on time ($\Tau_d = 0$), and that its depositor has not yet been punished ($\Pi_d = 0$). Next, we check to see if the bid ticket was a winner and the bidder abandoned their ships. In either case, we mark that the depositor has been punished, $\Pi_d := 1$.

If $a \lt \Omega$ or $\Nu_c = \nu_t$, the bid was either not a winner, or the depositor lost the race to reveal winning tickets. In this case, we follow the exact same process as we do for losing bids in the Revealing phase, charging the depositor the standard flat tax and returning the rest of their deposit.

If $a \geq \Omega$ and $\Nu_c \lt \nu_t$, then we know that the bid was a winner, and that the depositor intentionally failed to reveal on time. Because this damages the integrity of the auction, we assess an additional no-show tax on winning depositors that abandon their ships, $\frac{an\tau_n}{10^4}$ $\alpha$ wei. Including the flat tax, we deduct a total of $\frac{(\tau_f + \tau_n)an}{10^4}$ $\alpha$ wei from the punished bidder's balance, $\Beta_d := \Beta_d - \frac{(\tau_f + \tau_n)an}{10^4}$ before copying, zeroing, and transferring it. It is our expectation that the sum of the these taxes, along with the lack of ship transfers for late reveals, will prevent pilots from abandoning their ship.

Beyond this, we believe that distributing these taxed funds proportional to deposits will encourage pilots to deposit ore even if they do not intend to bid (i.e, to submit bid tickets with $a$ = 0), thus securing the privacy of unrevealed bids.

#### Claiming Rewards​

At any time after the punishing state has begun, depositors who revealed on time are eligible to claim their portion of the tax revenue for the auction. When a depositor $d$ submits a claim transaction, we first compute their portion of the total rewards according to their deposit $r = \frac{\Rho\Delta_d}{\sum_{o}{\Delta_{o}}}$, where o is any depositor in the auction (including $d$). Next, we subtract the rewards that $d$ has already claimed to get the rewards that they are owed, $c = r - \Chi_d$. Finally, we note the additional rewards that they have claimed, $\Chi_d := \Chi_d + c$, and send them what they are owed.

It's important to note that, because the total taxed funds for an auction cannot be known until all bids are revealed, $\Rho$ will continue to grow during the punishment state, up until all bidders have either revealed on time or been punished. This is intentional and harmless, because anyone may submit valid punishments, and all doubly-signed tickets will be released at the end of each auction. It is likely that the biggest depositors will submit the most punishments, and that most depositors will wait until all punishments have been submitted to claim their rewards.

In the same way that depositor rewards are claimed, anybody can transfer the DAO balance from the construction bay to the DAO. This simply transfers the DAO's portion of the auction revenue and zeroes its balance.

#### Neglected Auctions​

Because an auction cannot move into the Revealing state without the submission of a winning bid, the fact that only a construction bay admin may submit winning bids creates a problem of forced participation. If all states beyond AwaitingWinningBid required participation from a construction bay admin, and there were no way to withdraw funds until one of those states was reached, lack of participation from the construction bay admin could result in a massive loss of funds.

To avoid this scenario, auctions enter the emergency Neglected state when $e > (\epsilon_e + \delta_w)$ and $\Omega = 0$. That is, when the winning bid submission delay has elapsed, and no winning bid has submitted. During the Neglected state, all depositors may collect refunds, tax-free.

When a depositor $d$ requests a neglected auction refund, we copy their balance, $p = \Beta_d$, zero it, $\Beta_d := 0$, and then send them their funds. Because all other actions are disallowed for neglected auctions, there is no need to update the depositor rewards or the DAO's balance.

### The Off-chain Process​

To ensure that bids are not made public on the blockchain before auctions are complete, the bid submission stage of each auction happens off-chain. This section details the logic of the system signer, and the constraints that it must meet so that the on-chain portion behaves properly.

#### Assumptions​

In order for the on-chain logic to behave correctly, the off-chain system must meet a set of constraints:

• The system must only sign one bid per bidder per auction. This allows the reveal system to work based on a single boolean per address. Without this constraint, it would be impractical to check for on-time reveals, because the on-chain logic could not verify the number of bids that any address placed.
• The system must only sign a bid if the requester has sufficient balance to cover the total and tax. This prevents underflow during the taxation portion of reveal transactions, which would cause reverts, and thus loss of funds. Because taxes are applied based on bids and not deposits, it is not possible to perform this verification on-chain at deposit time.
• The system must only sign bids during the Bidding phase of an auction. This prevents bidders from depositing excess, gaining information from other bidders' reveals, and submitting their own bid. This requirement could be replaced with timestamp verification, but this would only result in an equivalent condition about accurate timestamps.
• The system must submit winning bids honestly. For obvious reasons, this condition is necessary for the integrity of the auction. However, we've taken care to reduce the amount of damage that a malicious system can do. If the system were to submit an inaccurately low winning bid, the revealing phase would simply become a first-come, first-served release. If the system were to submit an excessively high bid, the would-be winners would only lose their flat taxes, and pilots may elect to pursue further punishment through the DAO.

#### Signing Bids​

Because bid tickets require both the depositor's and the system signer's signature, each depositor $d$ must make a request to the off-chain system in order to place a bid. Before signing the ticket, the system will check that:

• The targeted auction is in the Bidding state, $\epsilon_s \leq e \lt \epsilon_e$
• The timestamp of the bid ticket has passed and is recent $e \gt t$, $e - t \leq 10$
• The depositor is not attempting to bid on more than three ships, $n \leq 3$
• The depositor has not successfully placed any bids

Through a database transaction, the system will then record the depositor's bid. After the bid is recorded, the system will send back its signature for the bid ticket.

#### Winning Bid Submissions​

When the auction is in the AwaitingWinningBid state, any caller may prompt the off-chain system to submit the winning bid. Before continuing, the system will check that:

• The auction is truly in the AwaitingWinningBid state, $e \geq (\epsilon_e + \delta_f)$, $\Omega \neq 0$
• No winning bid submissions are pending

The system will then mark the winning bid submission as pending, let $b_i$ be all bids with $n, a \neq 0$, sorted in descending order, and initiate a transaction to set $b_{\nu_t}$ as the winning bid. Intentionally, this creates a race to reveal if any winning depositors have bids with $n \gt 1$.

#### Ticket Reveals​

When the auction is in the Punishing state, any caller may request the full list of bid tickets, including signatures, from the off-chain system. After checking that the auction is truly in the Punishing state, the system will return the full list of doubly-signed bid tickets. The caller may then filter for any winners that have failed to reveal on time, and submit punishments, increasing $\Rho$.

tl;dr: A number of ships will be auctioned each week. Each auction will last for 24 hours. Each wallet may bid on up to 3 ships. All winning bidders will pay the price of the lowest winning bid. All bids incur a 5% tax, and winning bidders who no-show will be charged an additional 50% tax. Taxes are redistributed to depositors according to their deposit amounts. You can deposit without bidding, and you will receive a portion of the bid taxes for securing the auction.

## Economic Balance​

### Overview​

Our approach to economic balance with The Citadel is focused on maintaining a sustainable ecosystem value by promoting equilibrium between generation and burn of the supply of both ships and ore.

As with any game, there are numerous variables and a large degree of randomness that make it impractical to approach economic calculations directly. We instead took a more objective approach, starting from a point where all players have acted rationally and worked backwards to observe the economic effects. By adjusting the costs and benefits of each game action accordingly, we have established an economic atmosphere in which equilibrium is achieved naturally as the game is played.

After an initial phase of in-house balancing and due diligence, we wanted to go a step further by hiring a third party consulting firm to model and verify our economy. We were the first on-chain game to partner with the team at Machinations in comprehensively modeling our economy with their cutting edge technology and professional economic expertise. Machinations utilizes a powerful software tool designed from the ground up to prototype, model, and test game mechanics. Since its inception, Machinations has earned a reputation for massively reducing the time needed to bring new titles and gameplay features to market.

The power of Machinations' software lies in its Monte Carlo simulations. These simulations predict the probability of different outcomes depending on the interaction of random variables, such as player action or skill. The resulting data can be used to assess the impact of risk and uncertainty in prediction and forecasting models for finance, engineering, and supply chain operations.

As of March 16, 2022, The Citadel game has passed the Machinations game economy health verification program.

As former EVE Online players, we take great inspiration from EVE's economy which likely represents the most sophisticated and longest running virtual economy in existence. EVE's Chief Economist Eyjolfur Gudmundsson took a hands-off approach and let the community decide the value of commodities and goods. The EVE team only intervened when serious exploits or issues posed major threats to the game economy. Taking this a step further, The Citadel places economic control partly in the hands of the community. The team will fully release in-game auction house governance to the DAO once an appropriate equilibrium is met. We intend to provide adequate economic reports on the state of the game, just as Eyjolfur Gudmundsson's team did for EVE. Our goal is to empower the community to make informed decisions for the future of the game.

### Preserving and Growing Value​

Many nascent P2E game economies suffer from a symptom we think of as "value leakage". If at some point confidence in a P2E game economy is shaken, it can lead to value leaving the ecosystem at an accelerating rate. Once this negative spiral begins it can be difficult to reverse and we see far too many games end up in a graveyard littered with short-lived P2E projects as a consequence.

Our solution for insulating our economy from value leakage is to anchor the economy to a robust storehouse of value via the DAO treasury. In theory, by creating a treasury centered project we are able to implement a lower bound value for a governance token that is equal to its proportionate percentage ownership over the treasury. John Patten of TreasureDAO calls the treasury the "flywheel" of their economy and we take the same view in our approach.

With a treasury as the centerpiece of the economy, we can develop flows of value that perpetually increase the backing of the ecosystem. Value is accumulated frictionlessly via in-game taxes on ore transactions as well as fees from out of game exchanges and marketplaces such as OpenSea. As the game progresses, the value of the treasury steadily increases which permits sustainable inflation of the token supply and NFT game assets. The value of new token supply is at least partially backed by the commensurate growth in treasury value.

Demand for ships is supported by the fractional ownership of the treasury entailed by the voting rights of each ship. Each ship receives an equal vote in governance and therefore an equal share of ownership in the DAO treasury. If we look at this as a value equation and compare it to other on-chain games, we can begin to see why this should support the stability of the ecosystem.

On-chain Game Without a Treasury-linked NFT

NFT Value = Speculation + Utility + Community

NFT Value = Speculation + Utility + Community + Treasury Value

Speculation is commonly viewed in a negative light in the NFT space for good reason, but we should also recognize that speculation is a fundamental part of the valuation model for conventional technology companies. Azuki, for example, is priced at such a high multiple because of the potential future value they could bring to holders. As a decentralized game project, we are building a product and ecosystem that will only deliver more value to the players over time and this should be reflected in the NFT value.

#### Work, Weight and Multiplayer Effects​

In our effort to create a robust economy it was important to design the game such that each decision carried real weight. With this in mind, the team developed a fully on-chain real time player positioning system based on a 2D star map. There is a cost in both ore and time to travel across the map and earn resources. Consequently, each decision requires meaningful strategic consideration in order to optimally decide where to mine or roam. An economy where tokens are gained without effort or possibility for failure cannot be sustained. Without losers, there can be no winners.

The star map allows for multiplayer decision making. A real game economy cannot be created from intertwining a grouping of single player instances. In order for a market economy to flow there must be real competition between players in the same ecosystem. Each ship position may be viewed via the in-game interface and decisions will be based on the distribution of miners and marauders across different asteroid belts in your region. Miners will look for belts that have the best multipliers and fewest miners. Marauders will look for belts with numerous miners and few marauders. In the weekly auctions, you will be bidding against other players rather than minting at a linear cost. This inherent multiplayer competition is at the heart of what drives a real living, breathing economy.

### DAO Treasury Funds​

It is the community that will ultimately decide how treasury funds are utilized. As the founding team, we can only provide guidelines on best practice use cases for the treasury. As we can see from the NounsDAO example, we want to underscore the importance of keeping a minimum ratio of funds in the treasury in order to back the ecosystem and ensure that value is retained in the ships. This ratio should be established at launch and maintained carefully as ship supply increases every week. We will likely create a tool to track this value so that it is apparent and visible to the community.

Even if the majority of funds should stay in the treasury post launch, that doesn't mean those funds can't be productive in the meantime.

One approach that could be utilized with treasury funds is something akin to a Sovereign Wealth Fund (SWF). A SWF is a state-owned investment fund that invests in real and financial assets such as stocks, bonds, real estate, precious metals, or alternative investments such as private equity funds or hedge funds. The fund can then issue a dividend to the government in order to run essential processes or to be utilized as the benefactory constituents choose. In our case this investment will initially be held purely as Ether.

The specific type of SWF that is most relevant to our use case is called a "stabilization fund". A stabilization fund is maintained by a government to control the foreign exchange rate of its currency. This holds great promise for stabilizing a game asset ecosystem in terms of Ether. As Ethereum grows in value so too will the ecosystem, thereby creating a strong foundational value in the NFTs.

A great example of a SWF is the Government Pension fund of Norway.

The Norwegian fund has amassed 1.35 trillion in assets over its 30 years in existence. By the power of compound interest and excess funding it has built a valuation of around $250,000 per Norwegian citizen. Norway could pay out$50 billion in dividends to citizens per year and still have the treasury increase in value.

In a similar vein, we can begin to create a compounding treasury by first staking it into Ethereum 2.0 when it launches. The staking contract of Ethereum 2.0 is likely to pay 10%+ in annual percentage yield and this is not taking into account the appreciation of Ethereum itself. As ETH 2.0 is released new supply emissions will be reduced by 90%, making the token deflationary on account of the additional token burn associated with transactions. As the game is played the treasury will accrue royalties from exchanges that can be used to further compound our ETH 2.0 staking yield. This would allow the value of our NFT game ecosystem to track with Ethereum rather than against it, providing some level of hedging against the normal tendency of NFTs to weaken against Ethereum.

Following the SWF example is purely a suggestion and it will be the community DAO that will decide how these funds are utilized in the end. Treasury management is a deep topic to explore and there are many opportunities to safeguard as well as grow the community's wealth over time.

### In Summary​

We have taken great care and utilized every resource at our disposal in designing a state of the art, robust and sustainable on-chain game economy. Throughout this process we were guided by the holistic philosophy that for an on-chain game economy to work it had to be founded on the same core principles as any real economy. The aim was to lay a sturdy foundation for a long lived game world we co-create along with the community.

## Bridging​

### Overview​

In The Citadel, gameplay and governance happen strictly from layer 2, and yet we expect most item trading to happen on layer 1. In order to make ships and ore natively accessible from both networks, we've instituted a bridging system to connect state on both layers, inspired by EtherOrcs' portal and castle system, and written over FxPortal.

At a high level, this system involves two tunneling contracts. Each tunnel exposes a send function to set of privileged contracts (i.e., parts of the game). When a contract on layer 2 needs to make a call to one on layer one, or vice versa, it encodes the function call data, along with the address of the target on the receiving network, and sends it to the tunnel.

Through Polygon's StateSync mechanism and FxPortal, the tunnel on the sending layer sends the encoded call data to the receiving network. Once the tunnel on the receiving network receives the message, it executes each call, as was desired by the sending contract on the sending network.

The receipt process happens automatically and quickly (usually within 10 to 15 minutes) from layer 1 to layer 2, where each state sync is pushed individually by network miners. From layer 2 to layer 1, transfers are slower due to an extra verification period, but usually process within 30 minutes to 3 hours. Because transactions into layer 1 must use constant data, a cryptographic representation of the set of transactions is pushed, and users must prove inclusion and push their transactions through themselves. Fortunately, The Citadel automates the proof process, and pilots will receive notifications in their hangars once their ships have been processed.

In order to maintain security while keeping simplicity, security is handled directly by each network's tunnel, which verifies that the message was sent by tunnel on the opposing network. It is then guaranteed that any calls from the tunnel on each network were originally dispatched by a valid sender from the opposing network. For additional assurance, privileged governance calls coming from layer 2 to layer 1 are passed through a separate tunnel. This allows the standard tunnels to maintain minimal privileges, while still allowing governance complete control over the project.

Though it may sound complicated, this system of bridging has a major benefit: aside from the tunnels and their privileges, all contracts can remain identical across networks. This allows for faster development with fewer footguns, reduces the amount of code that must be tested and audited, keeps our surface area for attacks smaller, and, most importantly, allows community builders to gain an understanding of the system with less effort.

### Docking​

Docking is the process by which ships are transferred between networks. As is standard with bridging ERC-X tokens, the goal is to burn the token on the sending network and reissue an identical one on the receiving network. In order to keep gas usage low, we simulate this by transferring the ship to the contract and either issue or update it on the receiving network, depending on whether it already exists there. This maintains the condition of keeping the token inaccessible on the sending network, without incurring the gas fees associated with ERC721 mints on the receiving network.

When a pilot docks a ship on the sending network, the dock/bank contract simply transfers the ship to itself then requests a call to its own undock function, which issues or updates the token on the receiving network, transferring it to the pilot.

### Banking​

Banking is the process by which ore is transferred between networks. Like docking, it works by rendering the banked tokens inaccessible from the sending network, then issuing them on the receiving network. Because balance tracking is made simple by ERC20, tokens are always burnt on the sending network and minted on the receiving network.

When a pilot banks ore on the sending network, the dock/bank contract simply burns the ore being sent, then requests a call to its own unbank function, which mints ore to the pilot on the receiving network.

## Governance​

To put the game in the hands of the community, The Citadel will be controlled through an on-chain governance system, built over OpenZeppelin's Governor, Timelock, and ERC20Votes bases. These expose a set of functions for submitting proposals, allowing pilots to vote on them, and automatically executing the effects of the proposals that pass.

For each ship staked, a pilot may claim one pilot's badge. For each ship unstaked, one of the unstaking pilot's badges will be burnt. Each pilot may cast one vote per pilot's badge per proposal, and pilots with 5 or more pilot's badges will automatically be granted proposing privileges. To prevent manipulation of the badge supply during voting periods, each pilot's badge holdings, as well as the total badge supply, are checkpointed at each change and each proposal uses the last snapshot before the vote is initiated.

Pilot's badges are ERC20Votes tokens, modified to prevent transfers and approvals, except by authorized contracts. This ensures that pilot's badges are locked to staked ships, and that governance shares will not be treated as a commodity to be bought and sold on their own.

### Emergency Multisig​

While it is extremely important that the governance system retain ownership of all of the contracts, its voting period and execution delay make it impractical for emergency updates. To avoid this problem in the case that there is an emergency, we have created a multisig, and given it the necessary privileges to upgrade non-governance contracts without the need for a DAO vote.

Although the governance system can revoke these privileges permanently through a vote, this is still a point of centralization. In order to ensure that these privileges are used only when necessary, we have included the entire core team, select community members, and the Machinations team (a third party) in the multisig, with 100% participation required for transactions. This means that, if the emergency multisig were to be used, the entire core team, the additional community members, and Machinations as a company would all have to back it, with their reputations as collateral.

It is our belief that these consequences are severe enough to prevent abuse. If the community believes otherwise, we will gladly hear a well-considered proposal to remove the emergency multisig.

### Handoff​

After all contracts are deployed, but prior to launch, The Citadel team will relinquish control over upgrade permissions, as well as all contracts' admin roles, giving full control to the community through the governance system. Practically, this means that The Citadel team will retain only the roles necessary to add belts, publish belts, and improve gameplay, while still allowing the governance system to revoke each of these permissions (and not vice versa).

In more technical terms, this means that the governance authority for on network will be the sole admin owner of its ProxyAdmin, but that The Citadel team will retain proxy admin permissions for the Game, Ore, and Ships contracts. Similarly, the one and only address with DEFAULT_ADMIN_ROLE and TIMELOCK_ADMIN_ROLE will be the governance authority, but The Citadel team will retain ADDER_ROLE, PUBLISHER_ROLE, and REPLAYER_ROLE.

This system works analogously to a token approval, allowing The Citadel team to upgrade Game, Ore, and Ships, but preventing it from giving itself extra permissions and allowing the existing permissions to be revoked at any time. If the community so chose, The Citadel team could have its upgrade permissions removed immediately, and any upgrades it made could be reverted.

### Proposing​

Proposals consist of a unique identifier, a human-readable description, and a set of encoded function calls to execute if the proposal is executed. The unique identifier is used for vote tracking, the description serves as an on-chain record of the pitch to voters, and the function calls determine the concrete effects of executing the proposal.

Pilots may cast votes for each proposal, either in favor of the proposal, against the proposal, or abstaining from the proposal altogether. While the first two stances are self-explanatory, abstaining is also significant, in that it helps a proposal reach quorum, while signaling stakeholder has no opinion on it.

When casting a vote, it is extremely important that pilots ensure that id of the proposal that they are voting on matches the id of the proposal that they read. We will do our best to suppress spam, but, by design, it is impossible for us to censor proposals coming from the community.

### Executing Proposals​

In order to execute a proposal, two things are required: quorum must be reached, and the majority of votes on the proposal are in favor. If quorum is reached, but the majority of votes are not in favor, the proposal is rejected and will not be allowed to execute. However, if both requirements are met, the proposal is set to be available for execution after a set delay.

This delay is set initially by the project owners and adjustable by the governance system itself. It is enforced by the timelock, which serves to allow stakeholders who voted against the proposal a chance to exit the project before the proposal's execution. Once the delay period has passed, anyone can execute the passed proposal.

### Executing Proposals That Require Bridging​

Executing passing proposals on layer 1 from layer 2 requires use of the governance tunnel, the behavior of which is outlined in the bridging section. These types of proposal executions are almost exactly the same as normal executions, and the only difference is the required interaction with the layer 1 pull system for execution to complete. Concretely, once the timelock period has passed, the proposal has been executed on layer 2, and governance calls have reached layer 1, an account must prove their inclusion to finalize their execution on layer 1. Because each pilot who voted affirmatively had an interest in seeing the proposal executed, and because any address may complete the execution, it is expected that all valid layer 1 effects will be executed. This assumption is equivalent to that of the propose-execute cycle that has been battle-tested through other DAOs, such as COMP and AAVE.

### Veto Power​

In order to ensure that proposers have done their due diligence, and that passing proposals will not cause damage to the economic balance or security of The Citadel, the core team will retain a relinquishable veto power at launch. In order for a proposal to be vetoed, its vote must have passed, and it must be queued for execution. Further, the veto must be submitted by the core team's multisig, with 51% required participation.

In order to prevent abuse of the veto power, there is a single proposal for which the veto function is disabled: the pre-written proposal that removes the team's veto power. In the case that the community believes that the team has incorrectly vetoed a proposal, they may vote to remove the team's veto power, then resubmit the original proposal.

We will release the full transaction data for the veto removal proposal within our community resources on the DAO.

tl;dr: The team has reserved the right to veto a proposal considered substandard or harmful to the game or community. The majority of the team must vote in favor for it to take effect. The community can submit a pre-written proposal to remove the team's veto power any time, and this special proposal is immune from the team veto power.