Comment on page



The platform enables a virtual world where users can buy, sell, rent, collect, and curate pieces of virtual land in the form of non-fungible tokens. The platform will collect fees for all those actions, which will be converted to $CITY tokens.
CITY is the core utility token of the platform. The fixed-supply token will operate on the BSC network, compliant with the BEP20 token standard.
The platform will enable several functionalities, including a maker/taker model for fees, lending and borrowing with land/storefront NFTs as collateral, and decentralized fair price discovery. Users will be able to upgrade their land on multiple levels by staking CITY tokens. will distribute incentives to liquidity providers, Governance and platform participants. The platform’s Reserve will reward users, contributing by building on public land.


Non-fungible tokens, or NFTs, are blockchain-based digital assets with unique characteristics used to represent items such as photos, videos, audio, and other types of digital files. The difference between conventional cryptocurrency tokens non-fungible digital assets is that the latter cannot be changed for another.
Since 2020, the market value of NFTs has grown more than three times. CoinMarketCap shows that the combined market cap of major NFT projects, including Decentraland, Enjin, Theta, Chiliz, reached almost $28 billion in September 2021.
The platform enables a virtual world where users can buy, sell, rent, collect, and curate pieces of virtual land in the form of non-fungible tokens.
The platform utilizes its native token, CITY, to facilitate users to perform the following actions:
  • Purchasing of goods and services on the platform
  • Staking for additional discounts
  • Participating in the system’s Governance
  • Rewards for liquidity providers, Governance and platform participants
The document that follows outlines the mechanics behind the CITY token’s utility and outlines the CITY token’s sale details.

Economy setup

Token functions

CITY is the core utility token of the platform. The token is structured as a fixed supply token with core functions being:
  • Purchase of goods, avatars, build armies, and avail services on the platform
  • Staking for additional discounts and land and kingdom upgrading
  • Rewards distribution for liquidity providers, users participating in system governance, users making purchases on the platform, and contributors, building on public virtual land
  • Governance of the platform

Conversion to CITY token will enable users to pay fees on the platform with any cryptocurrency and potentially fiat but will convert those to CITY tokens on the back end. The two possible use cases are:
  1. 1.
    The user pays transaction fees in CITY tokens.
  2. 2.
    The user pays with Fiat, BSC or any from the list of supported cryptocurrencies. The platform payment middleware will then swap these tokens to CITY tokens.


Users will be able to stake their CITY tokens, which will provide the following advantages, both dependent on the amount of CITY tokens staked:
  • Access Legendary Avatars
  • Discount on platform fees
  • Land upgrade on different levels
  • Access to different partner metaverse land sales and allocations

Access Omni Avatars

Staking the CITY token will grant users the ability to upgrade their avatars and get them closer to gold NFTs like Washington, Hitler, Gandhi, or legendary NFTs like Shiva, Jesus the Saviour, or Buddha.

Fee discount

Staking the CITY token will grant users additional discounts on fees collected by the platform. The discount will be based on the amount of CITY token staked, as shown in the table below.
Minimum amount of CITY staked
Fee reduction factor
Level of upgrade

Land upgrade

Landowners will also be able to use their staked tokens to upgrade their virtual land. Depending on the number of CITY tokens staked, there will be multiple upgrade levels, as displayed above. Users will be provided with a list of possible amenities for each level, depending on what piece of land they wish to upgrade.

Access to partner metaverses

CITY tokens would be used to strategically launch and fund partner metaverses. All RoI from this larger Satoshi fund would be used to buy back and lock CITY tokens for deepening liquidity.

Platform functionalities

The platform is a virtual world, enabling users to perform the following actions:
  • Purchase pieces of virtual land in the form of NFTs
  • Sell pieces of virtual land
  • Rent virtual land
  • Curate NFTs
  • Build new features on the public virtual land
  • Participate in virtual events
The platform will collect fees for all those actions.
A portion of the land will be reserved for the city itself. The platform will offer grants to independent 3D artists (collaborators/builders) for building amenities on the platform-owned land. will also allow users to pay a single fee and participate in virtual events held by the platform.

Platform participants

At its core, will enable the following platform participants:
  • Investors/landowners - Users who invested in virtual land. They could become sellers and rent their NFTs at any point.
  • Lenders/borrowers - Landowners can also use their NFTs as collateral for borrowing money.
  • Buyers - Users opting to buy virtual land from landowners.
  • Renters - Users renting virtual land from landowners.
  • Curators - Users curating pieces of virtual land.
  • Contributors/Builders - Independent 3D artists, building amenities on the platform-owned land.
  • Independent users - Users coming to the platform to participate in virtual events by paying a single fee.

Maker-taker model for fees

For years, cryptocurrency exchanges have been helping users by creating liquidity on the market. This is achieved through a maker-taker fee model, where market makers are paying a very small or no transaction fee at all, as opposed to market takers.
Some crypto exchanges, such as Bitfinex, have implemented a maker-taker model with very small or negative fees for market makers. For standard trading (crypto to crypto, stablecoins, and FIAT), Bitfinex is using the following fees:
  • Maker fees - 0.100%
  • Taker fees - 0.200%
When trading with derivatives, the exchange offers a -0.0200% transaction rebate to market makers.
Taking these examples into account, is introducing a maker-taker model for fees, where:
  • Makers (users buying virtual land) will not be required to pay any transaction fees.
  • Takers (users selling their virtual land) will have to pay a fixed marketplace listing fee.

Lending and borrowing

The platform will also offer lending and borrowing with land/storefront NFTs as collateral. The lending solution follows industry-standard functionalities of pooled lending and a dynamic, curve-based interest rate based on the lending pool’s current utilization.
Users who already purchased virtual land on the platform (borrowers) can deposit their NFTs in a lending pool. On the flip side, lenders deposit stablecoins in the lending pool. Initially, only loans in stablecoins will be made available. However, other currencies can be added later on. Lenders receive interest rate on their deposits as per the utilization curve (and formula) below:
Lender effective APY as a function of the utilization rate
APYL=min(2UR×525×Max,PM+LM)APY_{L} = min(\frac{2^{UR \times 5}}{2^{5}} \times Max, PM + LM)
    is the lender APY is the pool utilization rate is the profit margin is the minimum lender margin (default 3%).
  • URUR
    is the pool utilization rate
  • PMPM
    is the profit margin
  • LMLM
    is the minimum lender margin (default 3%)
As an example of the above:
  • While the utilization rate of the pool is around 50%, any lenders would receive an effective APY of 2.9%
  • When the pool utilization reaches 70%, the effective APY becomes 10.3%
When a borrower wants to receive a loan versus the pool, they need to post collateral in NFTs. The loan will be based on the fair price discovery mechanism of the platform, as described in the section below.

Fair price discovery

The platform will enable a decentralized Oracle service, providing a consistent fair value estimate of the pieces of land.
The estimation will be based on recent sales in the same district and other auxiliary data.

Rewards will incentivize platform participants via its reward pool. The exact actions which will be incentivized and the exact incentive amounts will be up for governance, however, the initial set of rewarded actions is:
  • Liquidity providers on Pancake for the CITY/BNB pair (0.04%)
  • Users participating in system governance (0.04%)
  • Users of the platform making purchases (0.02%)
  • Contributors, building on platform-owned virtual land. These rewards will come from the platform’s Reserve.
The rewards will be distributed from a fixed supply reward pool. The rewards will be distributed on a daily basis and will be based on the outstanding tokens in the pool. For example, 0.10% of the outstanding tokens in the pool would be distributed daily between all groups of people eligible for rewards. The above setup means that:
  • The reward pool can never be depleted since the rewards are always distributed as a percentage of the outstanding tokens in the pool.
  • The rewards get less and less over time (Bitcoin style), but the net USD value of the rewards might increase in case the price of the CITY token increases.
  • This rewards mechanism provides capped inflation and is compatible with fixed supply tokens (as opposed to perpetual inflation)
The rewards distribution will be as follows (as cumulative % of all tokens in the reward pool):
Token distribution schedules and takeover time
Token inflation YoY and cumulative

LP rewards will offer incentives to liquidity providers on Pancake for the CITY/BNB pair. 0.04% of all CITY minted will be locked in a pool and awarded to liquidity providers. According to their LP amount, the pool will distribute 0.05% of its outstanding supply on a daily basis to liquidity providers who have locked their LP tokens. Similar to the Governance staking, locking the LP tokens for a longer duration will provide a multiplier for the rewards (M), utilizing the same formula based on duration (D):
M=0.75+0.1×D0.67M=0.75+0.1 \times D^{0.67}

Governance rewards

Governance participants will also receive 0.04% of all fees collected by the platform. The reward will be based on the participants’ Voting power, as described in the Governance section below.


In order to promote decentralized community governance for the network, CITY would allow holders to propose and vote on governance proposals to determine future features and/or parameters of the platform, with voting weight calculated in proportion to the tokens staked. For the avoidance of doubt, the right to vote is restricted solely to voting on features of the platform; the right to vote does not entitle CITY holders to vote on the operation and management of the Company, its affiliates, or their assets or the disposition of such assets to token holders, and does not constitute any equity interest in any of these entities. The arrangement is not intended to be any form of joint venture or partnership.
The decentralization of the project will be structured in 3 stages as follows:
  1. 1.
    Early days - during this period, the team is in full control of the project, and no voting is done. This is because there will be bugs and events which require immediate hotfixes, and this cannot be done really democratically.
  2. 2.
    Semi-decentralisation - during this period, the team is still in complete control of the project and can deploy hotfixes same as above, but for the non-urgent decision, it can take community input via a forum or even via off-chain voting like a snapshot -
  3. 3.
    Full decentralization - where the project will implement a process following industry best practices, as defined further below.
It is the community members which would drive development of the platform, so CITY token incentives would need to be distributed to compensate them for their time, expertise, and effort. Only users who have staked tokens to participate in submission of proposals, commenting, reviewing and/or voting will be entitled to receive CITY token governance rewards.
During phases 2 and 3, voting will be done via Voting power. Voting power is obtained by staking the project's token in the Governance module for a certain duration. More formally:
VP=Ts×MVP = T_{s} \times M
  • VPVP
    is voting power
  • TsT_{s}
    is the number of staked tokens
  • MM
    is a multiplier based on staking duration
We can then define
as follows:
M=1+0.3×D0.4M=1+0.3 \times D^{0.4}
Where (
) is the duration of the stake in weeks, this gives us the following multiplier curve based on duration.
During Phase 3, suggesting and implementing a proposal will closely follow UniSwap’s governance process, with tweaked parameters and an additional Tender step.
Phase 1: Temperature Check — Discourse/Snapshot
The purpose of the Temperature Check is to determine if there is sufficient will to make changes to the status quo.
To create a Temperature Check:
  1. 1.
    Ask a general, non-biased question to the community on the community forum about a potential change (example: “Should the project governance add rewards for action CITY?”). Forum posts should be labeled as follows: “Temperature Check - [Your Title Here]”. The forum post should include a link to the associated Snapshot poll.
  2. 2.
    Voters use Snapshot to indicate their interest in bringing it forward to the next stage. Snapshot poll lengths should be set to 3 days.
If the proposal gains 5% of the pool backing, it moves to the next stage - consensus check.
If the Temperature check does not suggest a change from the status quo, the topic will be closed on the governance site. If the Temperature Check does suggest a change, proceed to Stage 2: Consensus Check.
Phase 2: Consensus Check — Discourse/Snapshot
The purpose of the Consensus Check is to establish formal discussion around a potential proposal.
To create a Consensus Check:
  1. 1.
    Use feedback from the Temperature Check post and create a new Snapshot poll that covers the options which have gained support. This poll can either be binary or multiple-choice but should include the option “Make no change” or its equivalent. Set the poll duration to 5 days.
  2. 2.
    Create a new topic in the Proposal Discussion category on the community forum titled “Consensus Check — [Your Title Here]”. This will alert the community that this topic has already passed Temperature Check. Any topics beginning with Consensus Check that have not passed Temperature Check should be immediately be removed by community moderators. Make sure that the discussion thread links to the new Snapshot poll and the Temperature Check thread.
  3. 3.
    Reach out to your network to build support for the proposal. Discuss the proposal and solicit delegates to vote on it. Be willing to respond to questions on the Consensus Check topic. Share your viewpoint, although try to remain as impartial as possible.
Voting lasts five days. Whichever option has the majority of votes wins and can be included in a Tender for Stage 3. A 67% pool quorum of the voting pool is required for the vote to be considered valid.
If the option “Make no change” wins, the Consensus Check topic should be closed by community moderators.
Phase 3: Governance Proposal — Governance Portal
Phase 3 — Governance Proposal — is the final step of the governance process. The proposal should be based on the winning outcome from the Consensus Check and can consist of one or multiple actions, up to a maximum of 10 actions per proposal.
To create a Governance Proposal:
  1. 1.
    Write the code for your proposal, which can be voted on through any Governance Portal. All proposed codes should be audited by a professional auditor. This auditing process could be paid or reimbursed by the community treasury.
  2. 2.
    Create a topic in the Proposal Discussion category on the community forum titled “Governance Proposal [Proposal Number] — [Your Title Here]” and link to any relevant Snapshot polls/discussion threads as well as the code audit report.
  3. 3.
    Call the propose() function of the Governance Contract to deploy your proposal.
Once the propose() function has been called, a seven-day voting period is started. Ongoing discussions can take place on the community forum. If the proposal passes successfully, a two-day timelock will follow before the proposed code is executed.
During the early stages of the Governance module implementation, the project team will have the power to veto any proposal in the Timelock which could significantly hurt the protocol. At a later stage, the team will renounce this power.
Soft governance:
The process described above lays out a structure for those wishing to host a formal vote on a particular issue.
However, governance systems also require a degree of “meta governance” discussions that inform the direction of and the implementation processes behind the policy, but which don’t qualify as policy themselves.
The community may discuss new ideas and strategies for governance — including changes to the process outlined above — in the “Governance-Meta” category. On-chain voting is not necessary to make updates to off-chain processes.
Governance Glossary:
Governance token: An BEP-20 token that designates the weight of a user’s voting rights. The more Governance tokens a user has in their wallet, the more weight their delegation or vote on a proposal holds.
Delegation: Governance tokens holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s address. Note that delegation does not lock tokens; it merely adds votes to the chosen delegation address.
Governance Proposal: A proposal is a code that is executed by the governance contract through timelock. It can replace the governance contract, transfer tokens. Proposals are stored in the “proposals” mapping of the Governor smart contract. All proposals are subject to a 5-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, the proposal may be canceled by anyone.
Quorum: For a vote to pass, at least 67% of all delegated tokens must vote in the affirmative. The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.
Voting: Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the “Active” state. If the majority of voters vote for a proposal, the proposal may be queued in the Timelock.
Timelock: All governance actions are delayed for a minimum of 2 days by the timelock contract before they can be executed.
Last modified 2yr ago