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 , a pilot sends a transaction including its unique identifier. After verifying that the pilot owns , we map 's unique identifier to the pilot's address, initialize its travel state, and transfer ownership of to the game contract, following the checks-effects-interactions pattern. This is standard practice, and ensures that we know which pilot owns , that 's state is correct from the beginning, and that the pilot may not trade while playing. Unless stated otherwise, every action dependent on a ship is only allowed for its staking pilot.
To unstake , a pilot sends a similar transaction including '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.
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.
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.
|Class||Power||Travel Speed (un/s)||Reactor Cost (ORE)||Fuel Efficiency (un/ORE)|
|Class||Power||Travel Speed (un/s)||Reactor Cost (ORE)||Fuel Efficiency (un/ORE)|
|Class||Power||Travel Speed (un/s)||Reactor Cost (ORE)||Fuel Efficiency (un/ORE)|
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.
|Tier||Class||Power||Travel Speed (un/s)||Reactor Cost (ORE)||Fuel Efficiency (un/ORE)|
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.
|Tier||Class||Ore Cost (Miner)||Ore Cost (Marauder)||Upgrade Time (Days)||Stat Bonus|
|Tier||Class||Ore Cost (Miner)||Ore Cost (Marauder)||Upgrade Time (Days)||Speed Bonus||Fuel Efficiency Bonus||Updated Reactor Cost (ORE)|
|Class||Designation||Upgrade||Ore Cost Modifier||Upgrade Time Modifier|
- - The speed of ship (in units per second)
- - The reactor cost of ship (in ore wei)
- - The fuel efficiency of ship (in units travelable per ore)
- - The current coordinates of ship
- - 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 and increase from the top left corner of the map, meaning that and for any point are always zero or positive. Aside from the ships docked there, The Citadel is the unique game element with coordinates .
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 intent to travel as , the coordinates of when the intent was signaled, , the coordinates that is targeting, and , the epoch time at which the signaled its intent.
Logically, we assume that ships travel in a straight line from their last committed coordinates to their target . To compute the position of at epoch time , we first compute the distance it has traveled, . If , we know that the ship has arrived, and that its coordinates are . This technique also serves as a 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 . To prevent underflow, each component becomes , and when and , respectively.
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 and compute . We then commit the ship's current position , note the time , and update the ship's target . Note that because we've placed The Citadel at , 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 . Because native fixed-point math isn't available in Solidity yet, we adapt the formula for ore wei within the contract . For ships that have not traveled before, the fuel cost for any trip is defined to be ore, for any target. Of the ore proceeds from travel, are burned and are added to the DAO's balance.
Try for The Citadel, for Frontier, for Providence, for Ouroboros, for Outer Ring, and for Abyss. For reference, the maximum map coordinates are .
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 coordinates. From here on, will mean the coordinates of belt , 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 . Internally, a belt's remaining capacity is computed from , the current rate of depletion (in drill per second), , the epoch time of the last change in depletion rate, and , 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 and probabilities for breakdown items . Each controls how much ore a miner receives per second of their operation and the corresponding determines the probability that a miner receives the multiplier when completing their operation. For extra precision, are stored in ore wei and represents a probability of 100%.
The power balance of miners and marauders for each belt is dictated by its transport ship tax and its crime breakdown. Like the ore breakdown, these are both optional and filled upon publication. The transport ship tax dictates the percentage of ore that it siphoned when a miner calls a transport ship to belt . Values range from for zero percent, and for one hundred percent. A crime breakdown consists of a list of theft percentages and probabilities for breakdown items . Each controls what percentage of ore is stolen from a miner's gross claim and the corresponding determines the probability that the theft percentage occurs, should a miner not call a transport ship from . For extra precision, are stored on the same scale as .
To ensure that the developers are unable to manipulate belt publications, each belt is initialized with a provenance value . When the developers send a transaction to publish the belt, the contract verifies that , 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.
|Region||0% Theft||15% Theft||30% Theft||45% Theft||70% Theft||100% Theft|
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.
- - The drill trait of ship (in drill per second)
- - The capacity of belt (in total drill)
- - The th drill multiplier within the ore breakdown of the referenced belt (in ore wei)
- - The density of the th ore within the ore breakdown of the referenced belt (in representation)
- - The transport ship tax for belt (in representation)
- - The theft percentage of the th crime outcome within the crime breakdown of the referenced belt (in representation)
- - The probability of the th crime outcome occurring for non-transport ship claims at the referenced belt (in representation)
Each belt's resources deplete with the sum of the drill of its active mining operations. Concretely, each second, a belt 's capacity depletes by for each ship mining at . 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 , the current rate of depletion (in drill per second), , the epoch time of the last drill rate change, and , the total capacity depleted from prior to the last rate change.
This makes it straightforward to compute the depleted capacity of (in drill) as , for epoch time after . The remaining capacity for is then . The downside is that we lose on-chain access to the remaining capacity for times before , 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 at , we first check . To prevent overdrilling, we compute the belt's hypothetical drilled capacity after a second of drilling at the new rate, . If , 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 , , note the time of commit , and update the current drill rate 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 at . To start, we check . If , we know that the belt has had the capacity to support '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 , , note the time of commit , and update the current drill rate to account for the removal of 's drill. If , the belt's capacity was depleted somewhere between the start mining transaction for and now. Assuming that , we can compute when by computing how long it took to reach capacity from the last commit, and then adding it to the time of the last commit . This gives us the epoch time of the belt's depletion, .
To ensure that our assumption holds for future exits, we update the rate as normal , but commit the depletion as only the belt's capacity , and set the commit time to the second that the belt was depleted, , instead of the current epoch time. To avoid division by zero when all ships have exited, we use for when .
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 has been mining at belt since epoch time . At epoch time , 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 at , . If , the belt hasn't yet been depleted, meaning that the miner's is simply . Of course, if , the belt was depleted sometime before . In this case, we can use , as computed in the depletion section. Thus, we have for the 's total drill.
Aside from the mining operation's total drill, the net ore that receives is dependent on whether its pilot opts to
call a transport ship or return to an outpost themselves. To reduce branch count, the 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 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 , it is modulated by our precision basis, . We then select the first such that . This multiplier allows us to find the gross ore of the claim, . If there are no marauders roaming at , 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 claim is dependent on whether its pilot has opted to call a transport ship.
If '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, . In whole ore, this is .
Otherwise, the crime outcome affecting return is selected through a process similar to that used for the ore wei per drill. We select pick the lowest for which . We then compute the net ore wei owed to the miner, . In whole ore, this is . In the case that , the entire gross ore reward is stolen and 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 id,
and whether will be returning. If 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 . Once has been stored, the pilot may submit a transaction to
reveal the outcome of their operation, computing and accounting for their net ore.
- - The attack power of ship (in gun units)
Once a marauder ship has arrived at a belt , it may begin roaming there. Roaming grants 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 ore is stolen, will receive , where is any ship at (including ).
Because it is impractical to compute and update 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 , the total attack power at , , the total ore wei to be issued per gun at , and the annulled ore per gun for each marauder ship at . 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 as .
When a marauder ship arrives at and begins roaming, we set and . This correctly starts with zero ore wei owed, and allows us to account for the extra attack power at the belt moving forward. Because only increases throughout the life of the belt, the computation is safe from underflow.
When 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 . Because ore owed per ship is computed directly from , no additional writes are necessary.
When a marauder ship leaves , note the decrease in total attack power at , , find the ore wei that are owed, , and issue it to 's pilot. For the sake of the gas refund, we also set . Because the has left the belt, will be set properly if it enters again and begins roaming, making the operation safe.
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.
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.
- - 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:
- - The ID of the auction
- - The start time for the auction, in seconds since the epoch
- - The end time for the auction, in seconds since the epoch
- - The winning submission delay for the auction, in seconds
- - The finality delay for the auction, in seconds
- - The flat tax rate for the auction (in representation)
- - The no-show tax addition for the auction (in representation)
- - The id of the first token issuable from the auction
- - The total number of ships allocated to the auction
- - The address of the ERC20 token contract that will process deposits for the auction
- - The address of the system signer for the auction
- - 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 , we associate all of the passed parameters with the auction . Beyond the parameters that are used to initialize it, auctions are defined by the following (mutable) state variables, each of which is zero-initialized:
- - The total depositor rewards for the auction, in wei
- - The winning bid for the auction, in wei
- - The balance of depositor for the auction
- - The total wei deposited by depositor for the auction
- - The total wei claimed by depositor , as depositor rewards for the auction
- - The total number of ships claimed from the auction
- - 1 if depositor has revealed on time
- - 1 if depositor 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.
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:
- , 1 hour
- , 24 hours
- , 5%
- , 50%
After it has been added, an auction may be in one of four states at any time:
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
Revealing, and finally to
Punishing. In the case that The Citadel Team fails to publish the winning bid within
seconds of the end of the auction, the state will instead progress from
Neglected, at which
point all depositors will be able to recover their funds.
When , 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 sends a deposit transaction for an amount
, the construction bay stores its token balance , attempts to transfer from the depositor's token balance,
and then records its updated token balance . It then computes the net deposit increase and sets the depositor's balance
to reflect it: , . 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 , so long as their bid
plus the flat tax, .
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 and , 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 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 passes. In the case that that automatic submission fails,
the submission delay serves as an incentive for the team to rectify the issue, given that the auction will enter
Neglected state for where .
When , and , the auction is considered to be in the
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:
- - The number of ships the bidder hopes to win
- - What the bidder is willing to pay for each ship, in wei for the auction's native token
- - The time that the bidder created the bid ticket, in epoch seconds
- - The id of the auction that the bidder is targeting
- - 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
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, .
Once the bid has been stored and the bidder has been marked, we check whether the bid is a winner.
In the case that , the bid is a winner, and may claim ships.
In order to process the claim, we first compute what the depositor owes for their claimed ships, . 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 wei, or full tokens. To distribute
this amount among all of the auction's depositors, we update the total depositor rewards, . We can then deduct
the sum of these amounts from the depositor's balance, , to charge the depositor
for the ships that they won, in addition to the standard bid taxes. Finally, we increment the claimed ships count,
, copy and zero the depositor's balance, return the depositor's remaining funds, and issue the depositor their
ships, unrevealed. In order to reveal their ships' traits, the depositor may call the
reveal function from .
If , 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, . We then copy and zero the user's balance, and send them their remaining funds.
When and , the auction is considered to be in the
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 (), and that its depositor has not yet been punished (). 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, .
If or , 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
charging the depositor the standard flat tax and returning the rest of their deposit.
If and , 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, wei. Including the flat tax, we deduct a total of wei from the punished bidder's balance, 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 = 0), thus securing the privacy of unrevealed bids.
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 submits a claim transaction, we first compute their portion of the total rewards according to their deposit , where o is any depositor in the auction (including ). Next, we subtract the rewards that has already claimed to get the rewards that they are owed, . Finally, we note the additional rewards that they have claimed, , 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, 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.
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 and .
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 requests a neglected auction refund, we copy their balance, , zero it, , 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
Biddingphase 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.
Because bid tickets require both the depositor's and the system signer's signature, each depositor 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
- The timestamp of the bid ticket has passed and is recent ,
- The depositor's signing address matches the ticket's depositor address
- The depositor is not attempting to bid on more than three ships,
- 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
- No winning bid submissions are pending
The system will then mark the winning bid submission as pending, let be all bids with , sorted in descending order, and initiate a transaction to set as the winning bid. Intentionally, this creates a race to reveal if any winning depositors have bids with .
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 .
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.
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.
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.
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.
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.
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.
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.
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.
|Region Name||Region #||Transport Tax||Chance no Tax||Chance ship destruction|
(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.
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.
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.
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.
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
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.
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
Similarly, the one and only address with
TIMELOCK_ADMIN_ROLE will be the
governance authority, but The Citadel team will retain
This system works analogously to a token approval, allowing The Citadel team to upgrade
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.
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.
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.
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.