Staking Position Minting

This page demonstrates the minting process of "GEM NFTs" by burning a matured staking position.

Process Overview:

1. Selection of Matured Non-Minted Staking Positions:

• Query Staking Data: Use database and blockchain queries to identify all staking positions that:

  • Have reached or passed their maturity date without having been minted into NFTs.

  • Are in a valid state for minting (e.g., not previously failed or revoked).

• Epoch Determination: Establish the latest epoch whichconcluded. Each epoch is based on predefined 24hr time interval.

• Epoch Tagging: Assign an epoch to each matured staking position that has not yet been minted.

1. Calculation of the Merkle Tree:

• Data Gathering: Collect the unique identifiers of all matured staking positions. These include user addresses, pool IDs, pool Indices and epoch IDs that define each position.

• Merkle Tree Construction:

  • Implement a Merkle Tree algorithm to hash these identifiers. Each leaf node of the tree represents one staking position.

  • Hash the leaves upwards to create branches and finally the Merkle Root, ensuring each step is cryptographically secure.

• Store Merkle Root:

  • Once calculated, the Merkle Root for the current epoch is stored in the Minting smart contract. This serves as a compact proof of all valid minting positions for this epoch.

1. Storage of Merkle Proofs:

• Generate Individual Proofs: For each staking position included in the Merkle Tree, generate its Merkle proof. This proof consists of all the sibling nodes needed to reconstruct the Merkle Root from the leaf node.

• Database Storage: Store these proofs in a database associated with each staking position's identifier. This allows for quick access during the minting process without requiring recalculation of the entire tree.

1. Claiming Process by Users:

• User Connection: When a user connects their wallet to the UI:

  • The UI queries the backend for any staking positions associated with the user's address that is eligible for minting.

• Verification:

  • The UI and backend checks the database for the Merkle Proof associated with the user's staking position.

  • This proof along with the pool ID, the epoch ID and the index is then presented to the smart contract to verify the user's right to mint an NFT.

• Minting Execution:

  • The user interface facilitates an interaction where the user can execute a transaction to:

    • Burn their staking position (which could mean transferring the staked tokens back to the user or marking the position as spent).

    • Mint a GEM NFT, where the smart contract uses the Merkle Root stored within it to validate the proof.

This detailed process not only secures the minting of NFTs but also ensures efficiency and user trust in the system's integrity.

Minting Function Overview:

• Parameters:

  • _id: A string identifier for the NFT type or category.

  • _receiver: The Ethereum address where the NFT will be minted.

  • _poolID: An identifier for a discount pool, used for offering discounts on Gold.

  • _epoch: A number for time-based validations.

  • _index: An index related to staking position.

  • merkleProof: An array of bytes32, used for proving membership in a Merkle Tree, which is part of a whitelist mechanism.

• Process:

  1. Check Fee: The function ensures that the transaction includes the exact fee required for minting, preventing over or underpayment.

  2. Blacklist Check: It verifies that the sender's address isn't blacklisted using an external stakingAddress contract.

  3. Contract Status: It checks if the contract is currently active to allow minting.

  4. Category Status: Ensures that the NFT category (_id) exists and is active.

  5. Supply Limit: Confirms that the number of NFTs minted doesn't exceed the supply limit for that category.

  6. Discount Validation: Calls an internal function validateDiscount() to check if the sender qualifies for any discounts based on the provided Merkle proof and other parameters.

  7. Minting: If all checks pass, the NFT is minted to the _receiver address by calling an authorized mint function mintGEMNFTAUTH() on the GEM NFT contract.

Test Example:

The example below demonstrates the effectiveness of the mintGEMNFT() function.

• Data:

  • _id = GEM1

  • _receiver = 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

  • _poolID = 1

  • _epoch = 0

  • _index = 3

  • merkleProof = ["0x92b4dc55abf502327566e9a49dae3fa4e8a402e67498d02c82053c9f27d9192e"]

• Test Case:

  • The test simulates the minting of an NFT by burning a staking position indexed at position 3 on poolID 1 using the GPRO and Gold 90-days moving average prices of epoch 0.

  • In order for the minting to be successful the Merkle Proofs of all staking positions during epoch 0 need to be calculated and the Merkle Root needs to be stored on the GEM Minting contract.

  • Once the GEM NFT is minted the amount staked minus the discount is burnt and the discount amount is returned back to the caller.

    • ex. If the address staked 1 GRPO on a GEM1 pool and is eligible for 11% discount, 0.89 GRPO will be burnt and the rest 0.11 GPRO will be returned to the address.

This setup ensures that only valid, authorized, and compliant transactions result in new GEM NFTs being minted, showcasing how GEM smart contracts can manage complex logic for NFT creation with built-in security measures, supply control, and staking mechanisms.