💎
GemWorks
  • 👋gm, anon
  • 🚀Get Started
  • 🏦Gem Bank
    • Overview
    • Architecture
    • Video Walkthrough
  • 🧑‍🌾Gem Farm
    • Overview
    • Variable Rate Rewards
    • Fixed Rate Rewards
    • Architecture
    • Video Walkthrough
    • ⁉️Frequent Issues
  • ⚗️Transmuter
    • Overview
    • In-depth
    • Use-case Ideas
Powered by GitBook
On this page
  1. Gem Farm

Frequent Issues

PreviousVideo WalkthroughNextOverview

Last updated 3 years ago

U64::max

Currently most variables are stored inside the program as .

This means the larger the numbers you use for your farm, the higher the chance you'll hit the and cause an overflow. This in turn will cause your transaction to fail, typically with code 0x1770.

In simple terms what I'm saying is - if at any point in your program's math journey there is a number bigger than 18,446,744,073,709,551,615 (1.8 * 10^19) - you'll get an error.

So what are the numbers that matter?

  • Decimals for your token - if you have 9 decimals, you should add * 10^9 to all math operations.

  • Rarity points assigned to each NFT (remember default is 1, but you can assign up to 65,535 per item)

  • Number of NFTs staked

  • Duration the reward is funded for

  • Amount of promised reward per unit of time

Let's go through an example

  • You have a collection of 10,000 NFTs and you suspect the max a single user might want to stake is 100

  • You've added rarities and the most rare one has a rarity of 5,000

  • You want to let your users stake NFTs on a fixed schedule, promising them 1,000 tokens per day

  • You've funded your reward for 365 days

  • Your token has 9 decimals

  • Let's see what we get:

    • Number of NFTs staked * Max rarity * Rewards/day promised * Days promised * Token decimals

    • 100 * 5000 * 1000 * 365 * 10^9 = 1.82 * 10^20

    • Uh oh! That's about 10 times bigger than u64::max. You'll get an error.

🧑‍🌾
⁉️
U64s
U64::max limit