<aside> 📢 Each Gem NFT has a corresponding staked TON (L2 representation of staked TON on L1: WSWTON, wrapped staked WTON). This is specific to the specific L2.

</aside>

Some strict requirements for overall system:

Overall, there are no requirements that cannot be changed → but you have to explain why you are bringing in the change. In this section, I will describe minimum requirements that need to be followed when considering making the system for GEM NFT

  1. Reliance on existing contract on L1: (W)TON staking is on L1. This is already deployed contract on L1 and it contains minting logic for WTON per block; WTON is wrapped version of TON. Please check
    1. original git repository related staked WTON
    2. upgraded git repository
  2. This is an L2 application: GEM NFT dapp application must exist on L2
    1. however, minting & burning can be done on L1 if there are is a good reason to implement it that way, I would recommend minting and burning on L2 due to sheer gas issue and UX issue for forging (because forging always mints new NFT).
  3. All offered functions and related economy must be solvent: System must be solvent at any point (solvency can be delayed, but needs to be solvent without new users)
    1. Any outflow must be matched with inflow
  4. Must utilize randomness from existing project: Randomness should be from project DRB
    1. They will provide API / contract call similar to chainlink VRF API for randomness
      1. The exact specification will be provided later. For now, no need to finalize the interface for the randomness