Skip to main content


April 5, 2022 · 73 minute read

Technicians working on a ship

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

To unstake ss, a pilot sends a similar transaction including ss'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.


ClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)


ClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)


ClassPowerTravel Speed (un/s)Reactor Cost (ORE)Fuel Efficiency (un/ORE)

Standard Upgrades

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)

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.

Power Upgrades

TierClassOre Cost (Miner)Ore Cost (Marauder)Upgrade Time (Days)Stat Bonus

Propulsion Upgrades

TierClassOre Cost (Miner)Ore Cost (Marauder)Upgrade Time (Days)Speed BonusFuel Efficiency BonusUpdated Reactor Cost (ORE)

Cost Modifiers

ClassDesignationUpgradeOre Cost ModifierUpgrade Time Modifier


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.




  • vsv_s - The speed of ship ss (in units per second)
  • rsr_s - The reactor cost of ship ss (in ore wei)
  • fsf_s - The fuel efficiency of ship ss (in units travelable per ore)
  • (xs,ys)(x_s, y_s) - The current coordinates of ship ss
  • dist((x1,x2),(y1,y2))=(x1x2)2+(y1y2)2\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


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)(0, 0) and increase from the top left corner of the map, meaning that xx and yy 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)(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 ss's intent to travel as (xc,yc)(x_c, y_c), the coordinates of ss when the intent was signaled, (xt,yt)(x_t, y_t), the coordinates that ss is targeting, and tst_s, the epoch time at which the ss signaled its intent.

Logically, we assume that ships travel in a straight line from their last committed coordinates (xc,yc)(x_c, y_c) to their target (xt,yt)(x_t, y_t). To compute the position of ss at epoch time ee, we first compute the distance it has traveled, ls(e)=min(dist((xc,yc),(xt,yt)),(ets)vs)l_s(e) = \operatorname{min}(\operatorname{dist}((x_c, y_c), (x_t, y_t)), (e - t_s)v_s). If ls(e)dist((xc,yc),(xt,yt))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 (xt,yt)(x_t, y_t). This technique also serves as a min\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 (xc,yc)+ls(e)dist((xc,yc),(xt,yt))(xtxc,ytyc)(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 xs=xcls(e)dist((xc,yc),(xt,yt))(xcxt)x_s = x_c - \frac{l_s(e)}{\operatorname{dist}((x_c, y_c), (x_t, y_t))}(x_c - x_t), and ys=ycls(e)dist((xc,yc),(xt,yt))(ycyt)y_s = y_c - \frac{l_s(e)}{\operatorname{dist}((x_c, y_c), (x_t, y_t))}(y_c - y_t) when xt<xcx_t < x_c and yt<ycy_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 (xtnew,ytnew)(x_{\operatorname{tnew}}, y_{\operatorname{tnew}}) and compute (xs,ys)(x_s, y_s). We then commit the ship's current position (xc,yc):=(xs,ys)(x_c, y_c) := (x_s, y_s), note the time ts:=nowt_s := \operatorname{now}, and update the ship's target (xt,yt):=(xtnew,ytnew)(x_t, y_t) := (x_{\operatorname{tnew}}, y_{\operatorname{tnew}}). Note that because we've placed The Citadel at (0,0)(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 rs1018+dist((xs,ys),(xt,yt))fs\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 rs+dist((xs,ys),(xt,yt))(1018)fsr_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 00 ore, for any target. Of the ore proceeds from travel, 23\frac{2}{3} are burned and 13\frac{1}{3} are added to the DAO's balance.


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)(0, 0) for The Citadel, (10000000,7000000)(10000000, 7000000) for Frontier, (15000000,40000000)(15000000, 40000000) for Providence, (40000000,30000000)(40000000, 30000000) for Ouroboros, (80000000,5000000)(80000000, 5000000) for Outer Ring, and (70000000,35000000)(70000000, 35000000) for Abyss. For reference, the maximum map coordinates are (86400000,48600000)(86400000, 48600000).



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)(x, y) coordinates. From here on, (xb,yb)(x_b, y_b) will mean the coordinates of belt bb, 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 cbc_b. Internally, a belt's remaining capacity is computed from rbr_b, the current rate of depletion (in drill per second), tbt_b, the epoch time of the last change in depletion rate, and gbg_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 μi\mu_i and probabilities ρi\rho_i for breakdown items 1,2,...,n1, 2, ..., n. Each μi\mu_i controls how much ore a miner receives per second of their operation and the corresponding ρi\rho_i determines the probability that a miner receives the multiplier μi\mu_i when completing their operation. For extra precision, μi\mu_i are stored in ore wei and ρi=1018\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 τb\tau_b and its crime breakdown. Like the ore breakdown, these are both optional and filled upon publication. The transport ship tax τb\tau_b dictates the percentage of ore that it siphoned when a miner calls a transport ship to belt bb. Values range from τb=0\tau_b = 0 for zero percent, and τb=1018\tau_b = 10^{18} for one hundred percent. A crime breakdown consists of a list of theft percentages σi\sigma_i and probabilities ψi\psi_i for breakdown items 1,2,...,n1, 2, ..., n. Each σi\sigma_i controls what percentage of ore is stolen from a miner's gross claim and the corresponding ψi\psi_i determines the probability that the theft percentage σi\sigma_i occurs, should a miner not call a transport ship from bb. For extra precision, τb,σi,ψi\tau_b, \sigma_i, \psi_i are stored on the same [0,104][0, 10^{4}] scale as ρi\rho_i.

To ensure that the developers are unable to manipulate belt publications, each belt is initialized with a provenance value provenanceb=keccak256(τb,(σi,ψi),(μi,ρi))\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 keccak256(τb,(σi,ψi),(μi,ρi))=provenanceb\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.



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

example belt for each region
Shown AsRegionCoordinates
Frontier(10106,7106)(10 \cdot 10^6, 7 \cdot 10^6)
Providence(15106,40106)(15 \cdot 10^6, 40 \cdot 10^6)
Abyss(40106,30106)(40 \cdot 10^6, 30 \cdot 10^6)
Ouroboros(80106,5106)(80 \cdot 10^6, 5 \cdot 10^6)
Outer Ring(70106,35106)(70 \cdot 10^6, 35 \cdot 10^6)

Theft Probabilities

Region0% Theft15% Theft30% Theft45% Theft70% Theft100% Theft
Outer Ring75%10%5%5%4.6%0.4%

Transport Tax

Outer Ring40%


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.



  • dsd_s - The drill trait of ship ss (in drill per second)
  • cbc_b - The capacity of belt bb (in total drill)
  • μi\mu_i - The iith drill multiplier within the ore breakdown of the referenced belt (in ore wei)
  • ρi\rho_i - The density of the iith ore within the ore breakdown of the referenced belt (in [0,104][0%,100%][0, 10^{4}] \rightarrow [0\%, 100\%] representation)
  • τb\tau_b - The transport ship tax for belt bb (in [0,104][0%,100%][0, 10^{4}] \rightarrow [0\%, 100\%] representation)
  • σi\sigma_i - The theft percentage of the iith crime outcome within the crime breakdown of the referenced belt (in [0,104][0%,100%][0, 10^{4}] \rightarrow [0\%, 100\%] representation)
  • ψi\psi_i - The probability of the iith crime outcome occurring for non-transport ship claims at the referenced belt (in [0,104][0%,100%][0, 10^{4}] \rightarrow [0\%, 100\%] representation)


Each belt's resources deplete with the sum of the drill of its active mining operations. Concretely, each second, a belt bb's capacity depletes by sds\sum_{s} d_s for each ship ss mining at bb. 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 rbr_b, the current rate of depletion (in drill per second), tbt_b, the epoch time of the last drill rate change, and gbg_b, the total capacity depleted from bb prior to the last rate change.

This makes it straightforward to compute the depleted capacity of bb (in drill) as pb(e)=gb+(etb)rbp_b(e) = g_b + (e - t_b)r_b, for epoch time ee after tbt_b. The remaining capacity for bb is then mb(e)=cbpb(e)m_b(e) = c_b - p_b(e). The downside is that we lose on-chain access to the remaining capacity for times before tbt_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 ss at bb, we first check mb(now)m_b(\operatorname{now}). To prevent overdrilling, we compute the belt's hypothetical drilled capacity after a second of drilling at the new rate, hb=pb(now)+(rb+ds)h_b = p_b(\operatorname{now}) + (r_b + d_s). If hb>cbh_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 ss, gb:=pb(now)g_b := p_b(\operatorname{now}), note the time of commit tb:=nowt_b := \operatorname{now}, and update the current drill rate rb:=rb+dsr_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 ss at bb. To start, we check pb(now)p_b(\operatorname{now}). If pb(now)cbp_b(\operatorname{now}) \leq c_b, we know that the belt has had the capacity to support ss'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 ss, gb:=pb(now)g_b := p_b(\operatorname{now}), note the time of commit tb:=nowt_b := \operatorname{now}, and update the current drill rate rb:=rbdsr_b := r_b - d_s to account for the removal of ss's drill. If pb(now)>cbp_b(\operatorname{now}) > c_b, the belt's capacity was depleted somewhere between the start mining transaction for ss and now. Assuming that gbcbg_b \leq c_b, we can compute when by computing how long it took to reach capacity from the last commit, cbgbrb\frac{c_b - g_b}{r_b} and then adding it to the time of the last commit tbt_b. This gives us the epoch time of the belt's depletion, fb=cbgbrb+tbf_b = \frac{c_b - g_b}{r_b} + t_b.

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


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 ss has been mining at belt bb since epoch time ϵ\epsilon. At epoch time ee, ss 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 bb at ee, pb(e)p_b(e). If pb(e)cbp_b(e) \leq c_b, the belt hasn't yet been depleted, meaning that the miner's is simply (eϵ)ds(e - \epsilon)d_s. Of course, if pb(e)>cbp_b(e) > c_b, the belt was depleted sometime before ee. In this case, we can use fbf_b, as computed in the depletion section. Thus, we have ωs=ds(min(e,fb)ϵ)\omega_s = d_s(\operatorname{min}(e, f_b) - \epsilon) for the ss's total drill.

Aside from the mining operation's total drill, the net ore that ss receives is dependent on whether its pilot opts to call a transport ship or return to an outpost themselves. To reduce branch count, the ωs\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 ss 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, 10410^{4}. We then select the first μk\mu_k such that i=1kρi<γmod104\sum_{i = 1}^{k} \rho_i < \gamma \operatorname{mod} 10^{4}. This multiplier allows us to find the gross ore of the claim, μkωs\mu_k\omega_s. If there are no marauders roaming at bb, 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 ss's claim is dependent on whether its pilot has opted to call a transport ship.

If ss'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, μkωs μkωsτb104\mu_k\omega_s\ - \frac{\mu_k\omega_s\tau_b}{10^{4}}. In whole ore, this is 104μkωsμkωsτb1022\frac{10^{4}\mu_k\omega_s - \mu_k\omega_s\tau_b}{10^{22}}.

Otherwise, the crime outcome affecting ss return is selected through a process similar to that used for the ore wei per drill. We select pick the lowest jj for which i=1jψi<keccak256(γ,1)mod104\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, μkωs μkωsσj104\mu_k\omega_s\ - \frac{\mu_k\omega_s\sigma_j}{10^{4}}. In whole ore, this is 104μkωsμkωsσj1022\frac{10^{4}\mu_k\omega_s - \mu_k\omega_s\sigma_j}{10^{22}}. In the case that σj=104\sigma_j = 10^{4}, the entire gross ore reward is stolen and ss 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, ss's id, and whether ss will be returning. If ss 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.


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.




  • asa_s - The attack power of ship ss (in gun units)


Once a marauder ship ss has arrived at a belt bb, it may begin roaming there. Roaming grants ss 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 oo ore is stolen, ss will receive o(aszaz)o(\frac{a_s}{\sum_{z} a_z}), where zz is any ship at bb (including ss).

Because it is impractical to compute and update aszaz\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 αb\alpha_b, the total attack power at bb, ωb\omega_b, the total ore wei to be issued per gun at bb, and ηs\eta_s the annulled ore per gun for each marauder ship ss at bb. 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 ss as (ωbηs)as(\omega_b - \eta_s)a_s.

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

When oo 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 ωb:=ωb+oαb\omega_b := \omega_b + \frac{o}{\alpha_b}. Because ore owed per ship is computed directly from ωb\omega_b, no additional writes are necessary.

When a marauder ship ss leaves bb, note the decrease in total attack power at bb, αb:=αbas\alpha_b := \alpha_b - a_s, find the ore wei that are owed, (ωbηs)as(\omega_b - \eta_s)a_s, and issue it to ss's pilot. For the sake of the gas refund, we also set ηs=0\eta_s = 0. Because the ss has left the belt, ηs\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.


  • ee - The time in epoch seconds, in each example

The On-chain Process


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
  • ϵs\epsilon_s - The start time for the auction, in seconds since the epoch
  • ϵe\epsilon_e - The end time for the auction, in seconds since the epoch
  • δw\delta_w - The winning submission delay for the auction, in seconds
  • δf\delta_f - The finality delay for the auction, in seconds
  • τf\tau_f - The flat tax rate for the auction (in [0,104][0%,100%][0, 10^4] \rightarrow [0\%, 100\%] representation)
  • τn\tau_n - The no-show tax addition for the auction (in [0,104][0%,100%][0, 10^4] \rightarrow [0\%, 100\%] representation)
  • σ\sigma - The id of the first token issuable from the auction
  • νt\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:

  • P\Rho - The total depositor rewards for the auction, in α\alpha wei
  • Ω\Omega - The winning bid for the auction, in α\alpha wei
  • Bd\Beta_d - The balance of depositor dd for the auction
  • Δd\Delta_d - The total α\alpha wei deposited by depositor dd for the auction
  • Xd\Chi_d - The total α\alpha wei claimed by depositor dd, as depositor rewards for the auction
  • Nc\Nu_c - The total number of ships claimed from the auction
  • Td\Tau_d - 1 if depositor dd has revealed on time
  • Πd\Pi_d - 1 if depositor dd 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:

  • δw=3600\delta_w = 3600, 1 hour
  • δf=86400\delta_f = 86400, 24 hours
  • τf=500\tau_f = 500, 5%
  • τn=5000\tau_n = 5000, 50%
  • α=ore token address\alpha = \text{ore token address}


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 δw\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.


When ϵse<ϵe\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 dd sends a deposit transaction for an amount aa, the construction bay stores its token balance b0b_0, attempts to transfer aa from the depositor's token balance, and then records its updated token balance b1b_1. It then computes the net deposit increase and sets the depositor's balance to reflect it: Δd:=Δd+(b1b0)\Delta_d := \Delta_d + (b_1 - b_0), Bd:=Bd+(b1b0)\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 mm, so long as their bid plus the flat tax, (1+τf104)mBd(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 ϵe<e(ϵe+δw)\epsilon_e \lt e \leq (\epsilon_e + \delta_w) and Ω=0\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 ϵe\epsilon_e passes. In the case that that automatic submission fails, the submission delay δw\delta_w serves as an incentive for the team to rectify the issue, given that the auction will enter the Neglected state for e>(ϵe+δw)e \gt (\epsilon_e + \delta_w) where Ω=0\Omega = 0.


When ϵe<eϵe+δf\epsilon_e \lt e \leq \epsilon_e + \delta_f, and Ω0\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:

  • nn - The number of ships the bidder hopes to win
  • aa - What the bidder is willing to pay for each ship, in wei for the auction's native token
  • tt - The time that the bidder created the bid ticket, in epoch seconds
  • ii - The id of the auction that the bidder is targeting
  • dd - 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 dd 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, Td:=1\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Ωa \geq \Omega, the bid is a winner, and may claim w=min(o,νtNc)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Ω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 anτf104\frac{an\tau_f}{10^4} α\alpha wei, or anτf1022\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, P:=anτf104\Rho := \frac{an\tau_f}{10^4}. We can then deduct the sum of these amounts from the depositor's balance, Bd:=Bd((wΩ)+anτf104)\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, Nc:=Nc+w\Nu_c := \Nu_c + w, copy and zero the depositor's balance, return the depositor's remaining funds, and issue the depositor their ww ships, unrevealed. In order to reveal their ships' traits, the depositor may call the reveal function from xixi.

If l<ωsl \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, Bd=Bd(anτf104)\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.


When e(ϵe+δf)e \geq (\epsilon_e + \delta_f) and Ω0\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 (Td=0\Tau_d = 0), and that its depositor has not yet been punished (Πd=0\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, Πd:=1\Pi_d := 1.

If a<Ωa \lt \Omega or Nc=νt\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Ωa \geq \Omega and Nc<νt\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, anτn104\frac{an\tau_n}{10^4} α\alpha wei. Including the flat tax, we deduct a total of (τf+τn)an104\frac{(\tau_f + \tau_n)an}{10^4} α\alpha wei from the punished bidder's balance, Bd:=Bd(τf+τn)an104\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 aa = 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 dd submits a claim transaction, we first compute their portion of the total rewards according to their deposit r=PΔdoΔor = \frac{\Rho\Delta_d}{\sum_{o}{\Delta_{o}}}, where o is any depositor in the auction (including dd). Next, we subtract the rewards that dd has already claimed to get the rewards that they are owed, c=rXdc = r - \Chi_d. Finally, we note the additional rewards that they have claimed, Xd:=Xd+c\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, P\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>(ϵe+δw)e > (\epsilon_e + \delta_w) and Ω=0\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 dd requests a neglected auction refund, we copy their balance, p=Bdp = \Beta_d, zero it, Bd:=0\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.


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 dd 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, ϵse<ϵe\epsilon_s \leq e \lt \epsilon_e
  • The timestamp of the bid ticket has passed and is recent e>te \gt t, et10e - t \leq 10
  • The depositor's signing address matches the ticket's depositor address
  • The depositor is not attempting to bid on more than three ships, n3n \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(ϵe+δf)e \geq (\epsilon_e + \delta_f), Ω0\Omega \neq 0
  • No winning bid submissions are pending

The system will then mark the winning bid submission as pending, let bib_i be all bids with n,a0n, a \neq 0, sorted in descending order, and initiate a transaction to set bνtb_{\nu_t} as the winning bid. Intentionally, this creates a race to reveal if any winning depositors have bids with n>1n \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 P\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


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.

Machinations seal of approval

You can read more about the Machinations partnership here.

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.

accelerating flywheel

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

The Citadel Game

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.

Utility is the focus of many conversations around how NFTs become useful and relevant, but we rarely see utility that promotes real retention of value. All too often, utility in many NFT games directly causes value leakage rather than value retention. Our approach to utility enables us to partake in our own type of "Nouns auction" via the Construction Bay. Demand is then captured dynamically in $ORE and stored frictionlessly in our treasury.

Community is possibly the most neglected piece of this equation. It is the most powerful example of a whole that is greater than the sum of its parts. Many projects seek to create a false sense of community through inflating Discord and Twitter numbers with promotion antics that amount to multi-level marketing schemes. This results in fake, hollow communities where the "community value" does not hold up after the initial mint as most "community members" reveal their true interest in the project was short term profiteering. A valuable community must be developed organically over time with intention and a set of core ideas, usually inspired and aligned by the founding team. Great examples of projects with principled founders who co-created amazing communities are Etherorcs and TreasureDAO. It has been a guiding principle from day one to follow in their footsteps and prioritize genuine community building at every opportunity.

A proportion of the treasury should define the lower bound value of a ship. To make this connection a bit clearer, let's consider an example where the members of the DAO decide to pass a proposal to disperse the treasury fund evenly amongst themselves with a proportional share for each ship. While this is unlikely to occur and would represent the gutting of the project, it serves to illustrate the true value of owning what is effectively a share of the treasury.

An existing example of fractional ownership of a robust treasury setting a lower bound NFT value can be observed in action with the NounsDAO project. NounsDAO is an on-chain avatar project that auctions off one Noun per day in perpetuity and 100% of the proceeds of those auctions go directly to their community treasury. Each Noun has equal governance rights and access to making proposals in the DAO.

264 Nouns have been auctioned off thus far, accumulating 22,200Ξ for their treasury in the process. If we divide 22,200 by 264 we get an estimated lower bound value of 84Ξ, while floor currently sits at 67Ξ. While this isn't exactly one-to-one, the daily auctions still take in bids of 80Ξ+. This demonstrates the level of confidence that the treasury value instills in the Nouns ecosystem as well as the sustainable demand that is created for new supply entering the ecosystem. We might also argue that the value would be closer to the fractional ownership value or higher if Nouns capitalized on the other three parts of the NFT value equation: speculation, utility, and community.


The Auction House and Percentage Based Burn

Refer to Construction Bay for a more comprehensive explanation of the auction house, this section focuses on the overall effect it will have on the game economy.

The weekly auction will contribute the largest ore burn in the ecosystem and does the heavy lifting in curbing inflation. Many on-chain game projects set a constant mint value for creating new NFTs, and this linear cost cannot keep up with token inflation. The problem is that it's not possible to burn all ore that is generated without reducing the circulating supply to zero. However, by consistently burning a percentage of tokens generated we see an inflation curve that slopes towards equilibrium. Ore mint value will adjust to the upside naturally over time as more supply is generated and demand increases.

Chart 1

chart 1

In the above chart, we can see that the auction house is what creates this zig-zag effect on the trend lines. It is a weekly event that causes large fluctuations in the circulating ore supply.

Price Cliffs vs. Dynamic Pricing

The fixed price minting approach in many on-chain games employs what is commonly called a "price cliff" method to determine the mint price of new NFTs. After a predefined quantity of NFTs are minted, the mint price denominated in the native token is increased to a new level which essentially devalues the token. Spending power falls off a cliff at regular intervals by design in a misguided effort to combat runaway inflation.

The Citadel Game does not use the price cliff method and new ships cannot be minted at will. Instead, new ships are minted in our weekly auction from the Construction Bay. The price in ore of the ship NFTs will be set by the community via the auctions which results in all "new mints" being priced dynamically. This allows the value to fluctuate as needed to meet market demand and is part of what allows equilibrium to be reached naturally. Due to the limited supply of 3,333 ships at launch, the auction method will likely create a healthy demand for ore as well as an incentive for those outside the ecosystem to enter the game through this avenue.

Chart 2

chart 2

Here we can see the general trend of ship prices over time. Notice that the cost naturally tends to increase as more tokens enter the circulating supply. Keep in mind, these values are simulated and are based on assumptions about demand and that no new game mechanics are introduced. In reality, we will see highly variable market dynamics.

Capturing demand dynamically in the auction house allows the circulating supply of tokens to expand and contract as needed. When ore supply is high then it follows that more auction bids will increase and more ore will be burned. When ore supply is low then we should see lower bid values, resulting in less ore getting burned. As the community creates new gameplay and utility for the ore token, the team expects to see the auction house ore bids shrink to compensate and allow for ecosystem growth.

Chart 3

chart 3

As we mentioned above, ore spent at auctions can increase or decrease as necessary and will depend on a number of variables. This is a healthy relationship because it essentially allows for the circulating supply of ore to be soft capped by player decisions. Beyond the Construction Bay auctions, there are three additional main ore sinks which remain relatively static during gameplay: ore fuel, ore upgrades, and ore taxes.

Ship Destruction

While the dynamic pricing model of the Construction Bay effectively throttles inflation for ore tokens, we also needed to address the reckless inflation of token generating NFTs that plagued many other on-chain games. Our first order of business was to find a mechanic that would act as a pseudo-limit on ship inflation. We came up with a novel approach: allow the primary game NFT to be vulnerable to the risk of destruction under certain conditions. Not only does this reduce inflation of the circulating supply of token generating NFTs, it also makes ownership of the NFTs more meaningful in the context of the game world on the premise that we tend to value things more when there's a chance we could lose them.

While it was essential to build this burn into the gameplay, it was also important to the team that the burn risk be optional but well incentivized. With these constraints in mind, we developed the theft and transport ship mechanics as described in the sections on Mining Rewards and Regions. With this approach, players have the option to claim ore safely through transport ships but can also opt for greater rewards by risking a crime outcome. While many crime outcomes involve ore taxes, the greatest risk factor is ship destruction where the claiming ship is burned.

Table 1
Region NameRegion #Transport TaxChance no TaxChance ship destruction
Outer Ring440%75%0.40%

(Truncated from theft probabilities)

As shown in Table 1, the chances of both ship destruction and 0% taxes increase along with the transport ship tax as regions become more distant. This combination incentivizes choosing the risky option in more dangerous regions where rare ore types are available and ore generation potential is greater overall.

This ship inflation control method acts as a stimulus to the entire ecosystem by increasing ship scarcity, decreasing token generation, and burning ore dynamically based on current demand for ships. We've seen mechanics such as stealing NFTs in many on-chain games. However, having an NFT stolen ultimately feels just as bad as having it burnt. Meanwhile, transferring an NFT from one player to another doesn't contribute to inflation control since the NFT that generates tokens still exists. We believe our approach is significantly healthier for the economy and will eventually contribute to reaching an equilibrium supply of ships.

Chart 4

chart 4

The above chart is based on the simulated results of 500 days of gameplay, where the red line denotes total ship supply and the purple line represents burned ships. The most important takeaway we gleaned from simulating these results is that new ship supply introduced each week will eventually be equal to the amount of ships burned each week. This will likely fluctuate and would take years to occur, but it is important to demonstrate that the tendency towards equilibrium is built into the mechanics of the game. The important thing is that these two lines slope toward one another and will eventually converge in equilibrium.

The reason that these two lines converge is because ship supply increases are semi-linear and will predictably fall within a narrow range of new ship quantities offered at auction. Meanwhile, ship destruction will tend to be a percentage based burn of the total supply. As total supply increases, total ship burns will increase until they are relatively equal to the number of new ships introduced at auction.

Disclaimer: Any charts inserted into this document are from the Machinations model. It's important to note that these simulations are based on imperfect information as there is no direct statistics to input into the models. The trends in the simulations inform us that the mechanics and overall economic design should be sustainable. These models will be updated with inputs from the blockchain once the game goes live so that we can more accurately monitor the game economy health.

Upgrade Balance

In the short to medium term, ship upgrades are intentionally cost-inefficient in terms of the immediate increase in ore generation for miners. Because marauder yield is balanced against that of other marauders, ship upgrades will be necessary in order for marauders to maintain sufficient attack power to compete with their peers. We've attempted to balance the increased stats of more powerful ships by increasing their upgrade costs proportionally. This way, the immediate benefit of generating more ore is balanced by the increased cost of upgrades. As equipment is introduced to the game, upgrade tiers will become very important. Although initial upgrades for miners may be cost-inefficient, they will gain access to higher-powered equipment in the future.

That upgrades are inefficient for miners and necessary for marauders is itself a form of balance. Inefficiency for miners means that the cost of upgrading a ship's power to the maximum is great enough that the corresponding gain in yield will take over 60 days* on average to pay for itself. In this way, miner upgrades decrease the available supply of ore in the short and medium term. Meanwhile, marauder upgrades do not increase the ore supply and have an overall deflationary effect since the ore cost is burned.

In most on-chain games, the standard effect of upgrades is a linear boost to utility token generation which can inadvertently cause more inflation. To avoid this, we've designed the system to be nonlinear as described above. Overall, we consider the upgrade utility for The Citadel to be a deflationary mechanic.

*Upgrade costs in $ORE for miners have been reduced across the board. Training time costs have been greatly reduced for both Miners/ Marauders.

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.

sovereign wealth fund

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.



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 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 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.


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.


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.


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.

Casting Votes

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.