NFTAMA

White Paper

Full HTML version of the NFTAMA white paper with structured sections, tokenomics, formulas, weight mechanics, minting logic, and the risk model.

White Paper: NFTAMA

1. Core Concept and Vision

NFTAMA.io is a Web3 gaming platform where users can earn and use the AMA2 (Amatu) token through a system of NFT safes.

The core concept of the project:

  • users receive NFT safes;
  • safes generate AM weight;
  • AM weight determines the share of participation in AMA2 distribution;
  • AMA2 can be spent on safe upgrades, account upgrades, minting new safes, and internal operations;
  • this creates a closed growth cycle of gameplay and economics.

NFTAMA is a gaming crypto platform in which NFT safes function as assets with parameters, history, and a yield function. A user does not simply buy an NFT image, but receives a developing digital asset that provides AM weight, affects the user’s share in the project economy, and can strengthen over time through age, upgrades, and minting of new safes.

What Problem the Project Solves

NFTAMA solves several tasks at once:

  • it turns NFTs from static images into assets with practical utility;
  • it gives the user a game-based way to participate in token economics;
  • it creates a clear reinvestment mechanism through AMA2;
  • it combines NFT ownership, upgrading, and token rewards in a single system;
  • it builds long-term motivation to hold and develop the asset rather than quickly resell it.

Target Audience

NFTAMA is aimed at:

  • investors interested in a long-term model of accumulating a position through NFTs and a scarce token;
  • users who want to participate in the platform economy through clear actions;
  • gamers who are drawn to mechanics of growth, level, rarity, and age;
  • DeFi enthusiasts using BNB Smart Chain, DEX, liquidity, and tokens;
  • NFT collectors for whom rarity, class, series, and asset history matter.

Long-Term Project Goal

The strategic goal of the project over a 1-3 year horizon is to increase the utility and circulation of AMA2 within the platform, expand the number of users, strengthen the scarce token model, and form a sustainable ecosystem of NFT safes.

The team’s target reference point for AMA2 price over a horizon of about 3 years is approximately 0.3 USD per 1 AMA2.

Note:

  • this is a strategic target, not a guaranteed return;
  • the actual AMA2 price will depend on demand, liquidity, user activity, overall market conditions, and the pace of project development.

2. How NFTAMA Differs from Regular NFTs, GameFi, and DeFi

Compared to Regular NFTs

Regular NFTs are often limited to collectible or visual value.

In NFTAMA, a safe is an asset with practical utility:

  • it provides AM weight;
  • AM weight participates in AMA2 distribution;
  • the safe can be upgraded;
  • the safe ages and can become stronger;
  • the safe can be used to mint a new NFT;
  • the safe can be sold to another user.

Compared to Typical GameFi

In many GameFi projects, game items exist only inside the game.

In NFTAMA:

  • the safe is an NFT asset;
  • the project operates on BNB Smart Chain;
  • the user can deposit and withdraw assets;
  • there is a secondary market between users;
  • there is internal financial infrastructure.

Compared to Typical DeFi

In classical DeFi, the user mainly interacts with a token, pool, or staking.

In NFTAMA, the user works not only with a token but also with a portfolio of gaming NFT assets:

  • every decision regarding safes affects AM weight;
  • AM weight affects the user’s share in AMA2;
  • AMA2 affects the speed of further portfolio growth.

3. How the Project Works as a Whole

The basic NFTAMA cycle is as follows:

  1. The user registers, passes captcha, and receives an internal IN wallet.
  2. The user confirms email to fully participate in the AMA2 economy.
  3. The user tops up the internal balance with BNB and, if needed, AMA2.
  4. The user buys a safe when opened, uses auto-buy, buys a safe from another user, or mints a new one.
  5. The user receives an NFT safe that is assigned in the system and then minted to the internal wallet.
  6. The user increases total AM weight through new safes, their age, upgrades, and minting.
  7. The user receives AMA2 proportionally to the share of weight.
  8. The user uses AMA2 for further growth, exchange, withdrawal, or sale.

This cycle is already reflected in the product structure:

  • Dashboard
  • Account
  • Wallet
  • Virtual Safes
  • AMA Tokens
  • Rules
  • Finances
  • Referral Program
  • Blog

4. NFT Safe Concept

What an NFT Safe Is

An NFT safe in NFTAMA is an NFT asset on BNB Smart Chain that participates in the internal gaming and economic logic of the project.

A safe has:

  • AM weight;
  • level;
  • age;
  • class;
  • series;
  • image;
  • value history;
  • ownership history;
  • mint participation limit.

From a practical point of view, a safe is simultaneously:

  • an asset;
  • an income tool;
  • a game object for development.

Why a Safe Has Value

A safe is valuable not as an image by itself, but because it:

  • provides AM weight;
  • increases the user’s share in the system;
  • participates in AMA2 distribution;
  • can be upgraded with AMA2;
  • becomes stronger over time due to age;
  • can participate in minting a new safe;
  • can be sold to another user.

Main Safe Parameters

1. AM Weight

AM weight is the main characteristic of a safe.

AM weight determines:

  • the user’s share among all participants;
  • the size of participation in AMA2 distributions;
  • the strategic value of the safe inside the portfolio.

2. Level

The level of a safe is increased using AMA2.

Each new level:

  • increases the safe’s weight;
  • strengthens the role of the safe in the portfolio;
  • increases the user’s future share in distributions.

In the project:

  • the starting cost of the first safe upgrade is 29 AMA2;
  • each following cost grows by 30%.

Formula for the upgrade price of safe level n:

Pricen ≈ 29 * 1.3(n-1)

In practice, the price grows sequentially, with rounding at each step.

In general form:

Un = U1 * (1 + gu)(n-1)

where:

  • U1 is the price of the first upgrade;
  • gu is the upgrade price growth rate.

Formula for weight increase on upgrade:

NewWeight = CurrentWeight + CurrentWeight * 0.08 * QualityModifier

or in compact form:

A_{n+1} = An * (1 + ga * q)

where:

  • 0.08 = base increase of 8%;
  • QualityModifier = quality modifier of the safe.

If the quality coefficient does not change, then after m consecutive upgrades:

A_{n+m} = An * (1 + ga * q)m

This means that strong high-quality safes receive a greater effective effect from upgrading.

3. Rarity, Class, and Quality

The class of a safe determines:

  • the series;
  • the class name;
  • the drop chance;
  • the range of the weight modifier.

In practice, this means:

  • two safes with the same base weight may have different final strength;
  • a rarer safe may receive a higher weight multiplier;
  • rarity affects not only perception, but also economics.

4. Safe Age

Safe age is a separate growth mechanic.

Up to the age of 720 days, the project uses a threshold-based aging model.

Base thresholds and multipliers:

  • 30 days -> x1.01
  • 60 days -> x1.02
  • 90 days -> x1.05
  • 120 days -> x1.01
  • 150 days -> x1.02
  • 180 days -> x1.05
  • 210 days -> x1.01
  • 240 days -> x1.05
  • 270 days -> x1.02
  • 300 days -> x1.01
  • 330 days -> x1.02
  • 360 days -> x1.10
  • 420 days -> x1.01
  • 480 days -> x1.01
  • 540 days -> x1.01
  • 600 days -> x1.01
  • 660 days -> x1.01

After 660 days and until the 720-day threshold, there are no new threshold bonuses. After 720 days, a separate daily weight growth model applies.

If threshold multipliers are denoted as mj, the age multiplier before 720 days can be written as:

Kstep(d) = ∏ mj, for all thresholds daysj <= d

Then the safe’s weight before 720 days is:

Astep(d) = Abase * Kstep(d)

For the thresholds above, the total multiplier by age 660 days is:

Kstep(660) ≈ 1.5074872007

This means that by the time the safe enters the 720+ phase, it already has approximately +50.75% weight purely due to threshold aging.

Daily growth coefficient after 720 days:

DailyMultiplier = 2.95(1/360) ≈ 1.0030095339437

This means:

  • every day after 720 days, weight is multiplied by approximately 1.0030095339;
  • over 360 days of this model, the final multiplier gives approximately x2.95, i.e. +195% to weight over the interval considered.

Example:

  • if the safe’s weight is 10 AM after crossing the 720-day threshold,
  • then after 360 days of daily growth it becomes approximately 29.5 AM.

In general form, the age multiplier after d days in the active growth phase:

Kage(d) = kd

where:

  • k = 1.0030095339437

Then the age-adjusted weight can be expressed as:

Aage(d) = Abase * Kage(d)

If both phases are combined into a single notation, the total age multiplier can be represented as:

Ktotal(d) = Kstep(min(d, 720)) * kmax(0, d - 720)

and the final weight:

Atotal(d) = Abase * Ktotal(d)

5. Lifetime

For demo/free safes, a limited lifetime may be set.

Such safes:

  • may be issued by the system;
  • usually have low weight;
  • stop participating in account weight calculation after expiration;
  • are used as a user onboarding tool rather than the foundation of the main economy.

What Can Be Done with a Safe

A safe can:

  • be upgraded;
  • be sold to another user;
  • participate in minting a new safe;
  • be held in the portfolio as a long-term asset.

Combining several safes into a new safe is considered as a separate future development scenario for the minting mechanic. Even now, minting a new safe for AMA2 serves as a reinvestment mechanism.

5. How Users Obtain Safes

In the current system there are several basic scenarios:

  • purchase of an opened safe on the platform;
  • auto-buy according to rules;
  • purchase of a safe from another user;
  • minting a new safe for AMA2;
  • receiving a demo/free safe in specific scenarios.

The basic mechanics of the current project economy:

  • purchase at opening;
  • purchase from another user;
  • minting a new safe for AMA2.

6. Epochs

What an Epoch Is

An epoch is a development period of the project within which the parameters of issuance and life of new safes are defined.

An epoch determines:

  • the range of total project weight;
  • the starting and final weight of a new safe;
  • the starting and final price of a new safe;
  • the lifetime of an opened safe;
  • the interval between safe openings;
  • the share of AMA2 directed to distribution;
  • the distribution fee.

An epoch is defined by the interval:

Ej = [Wj- ; Wj+)

where:

  • Ej is epoch number j;
  • Wj- is the lower bound of total system weight;
  • Wj+ is the upper bound of total system weight.

Interpretation of an Epoch

An epoch is a range of overall project development measured by total AM weight.

Simplified model:

  • 0-10000 AM -> one epoch;
  • 10001-20000 AM -> the next epoch;
  • and so on.

If the step between epochs is constant and equal to ΔW, the epoch number is determined as:

j = 1 + floor(W / ΔW)

When moving to a new epoch, the following may change:

  • frequency of appearance of new safes;
  • price parameters;
  • weight parameters of new safes;
  • conditions of part of the AMA2 economy.

Why Epochs Matter

Epochs make NFTAMA a dynamic system:

  • early participants enter earlier project phases;
  • conditions of new safes change over time;
  • development of the overall system affects new entry points;
  • this supports the scarce model and interest in early participation.

If within an epoch the starting price of a safe is P0, and the final price is P1, then:

P1 <= P(t) <= P0

And for weight:

A1 <= A(t) <= A0

An epoch defines a range of parameters within which a new safe changes.

7. Primary Safe Market

At any given moment, the system may have one opened safe available for purchase. It has a limited lifetime and is created according to the rules of the current epoch.

The user can:

  • buy a safe manually;
  • use automatic purchase rules.

After purchase:

  • the safe is assigned to the user in the database;
  • an on-chain mint queue is created;
  • the NFT is minted to the user’s internal IN wallet.

Primary Opening Formulas

If the full lifetime of an opened safe is T, and t time has passed since opening, then the price of the safe is defined by a linear function:

P(t) = P0 - (P0 - P1) * t / T

And its weight:

A(t) = A0 - (A0 - A1) * t / T

Here, not only the absolute price matters, but also the unit price per weight:

C(t) = P(t) / A(t)

where C(t) shows how much the user pays for 1 AM at a specific point in time.

Why Entry Timing Matters

Buying at opening is important because:

  • the parameters of the safe are set by the current epoch;
  • an early purchase may provide strong weight at an early stage;
  • strong early weight provides more time to accumulate AMA2;
  • as the system grows, such early entries become more limited.

The long-term effect of early entry is estimated by:

Vlong ≈ Aentry * H

where:

  • Aentry is the weight with which the user entered the system;
  • H is the length of the investment horizon.

The earlier and stronger the entry, the greater the long-term effect.

8. Auto-Buy Rules

The project implements three basic purchase strategies:

  1. Stepwise price increase purchase
  • the user defines the increase step, price limit, and number of attempts in advance.
  1. Purchase at the opening price
  • the system attempts to buy the safe immediately when it opens.
  1. Purchase after price decrease
  • the system waits until the price falls to the selected entry level.

This turns safe purchasing from a manual process into a strategic instrument. The user can build an individual entry tactic rather than simply wait for a convenient moment.

Auto-Buy Formulas

If the user chooses stepwise price increase with step s and number of steps n, the strategy’s maximum bid is:

Pmax = P0 * (1 + s)n

If a cap L is also specified, the actual upper boundary is:

Pbid = min(Pmax, L)

If the user wants to enter only after a price decrease of d, the target entry price is:

Ptarget = P0 * (1 - d)

In a linear price decrease model, the strategy trigger time is:

ttarget = T * (P0 - Ptarget) / (P0 - P1)

For comparing strategies, a useful metric is:

R = A* / P*

where:

  • A* is the expected entry weight;
  • P* is the expected entry price.

The higher R, the more weight the user receives per unit of invested capital.

9. Secondary Market

NFTAMA has a secondary market between users.

The user can:

  • sell a safe;
  • send a purchase request;
  • agree on deal terms;
  • complete the transfer of the safe to a new owner.

This means that safes receive not only initial value but also accumulated value tied to:

  • weight;
  • class;
  • age;
  • level;
  • history;
  • potential future yield.

The market value of a safe on the secondary market can be represented as:

Vsafe = f(A, q, age, lvl, y)

where value depends on:

  • weight;
  • quality;
  • age;
  • level;
  • expected future yield.

10. AMA2 Tokenomics

What AMA2 Is

AMA2 (Amatu) is the main token for development and internal settlement within NFTAMA.

It is used for:

  • safe upgrades;
  • account upgrades;
  • minting new safes;
  • internal purchases;
  • withdrawals;
  • internal exchange with BNB;
  • reward and distribution economics.

Total Supply

AMA2 token parameters:

  • total token amount: 141,000,000;
  • decimals: 18;
  • total amount in smallest units: 141,000,000 * 1018.

This means that in user-facing representation, the total project supply is:

141 000 000 AMA2

Additional token issuance is not provided for.

This means that the AMA2 model is limited in supply and has no infinite emission.

In short form:

Stotal = 141 000 000

Why AMA2 Is Needed

AMA2 performs several roles simultaneously in the ecosystem:

  • reward token;
  • reinvestment token;
  • development token;
  • token for internal settlements.

It is not an auxiliary token, but the central element of the account growth mechanic.

What AMA2 Is Spent On

1. Safe Upgrades

Starting price of the first upgrade:

29 AMA2

Subsequent levels become 30% more expensive.

General formula:

Un = U1 * (1 + gu)(n-1)

where:

  • U1 = 29
  • gu = 0.30

2. Account Upgrades

Starting price of the first account upgrade:

24 AMA2

Subsequent levels become 50% more expensive.

Formula:

AccountUpgradePricen ≈ 24 * 1.5(n-1)

In practice, the price grows stepwise, with rounding at each level.

In general form:

Bn = B1 * (1 + gb)(n-1)

where:

  • B1 = 24
  • gb = 0.50

3. Minting a New Safe

Base mint price from two safes:

320 AMA2

Formula for k safes, where k >= 2:

MintCost(k) = 320 * (k - 1) AMA2

or in short form:

M(k) = M0 * (k - 1)

where M0 = 320

Examples:

  • 2 safes -> 320 AMA2
  • 3 safes -> 640 AMA2
  • 4 safes -> 960 AMA2
  • 5 safes -> 1280 AMA2

4. Buying Safes from Users

Internal P2P deals use AMA2 as the settlement price.

5. AMA2 Withdrawal

Withdrawal requires not only an AMA2 balance, but also BNB for gas.

How AMA2 Are Distributed

The main logic of AMA2 accrual is based on the user’s share of weight.

First, the user’s share in total weight is determined:

Di = Ai / Asum

Total Pool Formula per Cycle

Q = S * r

where:

  • Q is the amount of AMA2 directed to distribution per cycle;
  • S is the amount of AMA2 available for distribution;
  • r is the share directed to distribution in one cycle.

Formula After Fee

Qnet = Q * (1 - f)

Base fee rate:

f = 0.09

User Formula

Ri = Qnet * Di

or in full form:

Ri = S * r * (1 - f) * Ai / Asum

If referral accrual is included:

Rref = α * Rchild

where α is the referral rate.

Simple Distribution Example

Assume:

  • total system weight = 10 000 AM;
  • participant weight = 1 000 AM;
  • participant share = 10%;
  • 500 AMA2 goes to the cycle after fee.

Then:

UserAMA2 = 500 * 10% = 50 AMA2

If the participant’s weight increases to 1 500 AM with the same total system weight:

UserAMA2 = 500 * 15% = 75 AMA2

Conclusion:

  • growth of weight directly increases the size of the main reward.

Ri ∝ Ai

under otherwise equal conditions.

Other Sources of AMA2

In addition to the main distribution, the project already contains additional sources:

  • receiving free AMA2 rewards;
  • bonus codes;
  • referral accruals;
  • separate internal accruals;
  • prospective LP incentives.

11. Free AMA and Account Development

The project has a separate instrument for receiving free AMA2 through the user cabinet.

Current logic:

  • confirmed email is required;
  • there is a time restriction: no more than once per hour;
  • there is a daily limit;
  • the daily limit depends on the user’s weight.

According to current default values:

  • base attempts per day: 5;
  • weight quota for an additional attempt: 10 AM;
  • maximum attempts per day: 24.

Formula for the daily limit:

Nday = min(N0 + floor(Ai / Aq), Nmax)

where by default:

  • N0 = 5
  • Aq = 10
  • Nmax = 24

This is another way to connect portfolio growth with growth of account utility.

In universal form:

Nday = min(N0 + floor(Ai / Aq), Nmax)

If the average reward from one attempt is m, then the expected daily amount is:

Fday = m * Nday

And the expected monthly amount:

Fmonth ≈ 30 * m * Nday

Account Upgrade

Account upgrades increase:

  • return percentage;
  • base free AMA2 reward.

Starting account values:

  • return percentage = 3
  • base free AMA2 reward = 0.6

Account upgrade:

  • increases return percentage by 5% of the current value;
  • increases base free AMA2 reward according to a step model:
  • levels 1-5: +20%
  • levels 6-10: +8%
  • levels 11-15: +5%
  • levels 16-20: +1.5%
  • levels 21+: +0.5%

If Bn is the return percentage value at level n, then:

B_{n+1} = Bn * 1.05

If Fn is the base free AMA2 reward at level n, then:

F_{n+1} = Fn * (1 + hn)

where hn depends on the account level range.

This makes the account a separate strategic object of development rather than simply a container for assets.

12. Minting New Safes

Minting a new safe for AMA2 is one of the key reinvestment mechanisms of NFTAMA.

Requirements

To mint, the user needs:

  • at least 2 own safes;
  • sufficient AMA2 balance;
  • sufficient BNB balance for gas.

Limitation on Source Safes

The same safe can be used in minting a limited number of times.

Mint participation limit of one safe:

Lm = 3

That is, one safe can be used no more than three times.

What Happens During Minting

  1. The user selects at least 2 own safes.
  2. The system checks balances and limits.
  3. AMA2 and BNB are deducted.
  4. A new safe is created in the system.
  5. The participation counter of the source safes is increased.
  6. The new NFT is placed in the on-chain mint queue.

How a New Safe Is Formed

The new safe:

  • receives a new class;
  • receives a new image;
  • calculates new weight probabilistically;
  • is minted within the current epoch.

This makes minting a reinvestment mechanism rather than a simple purchase of a predefined item.

Minting Formulas

If k safes participate in minting, the AMA2 cost is:

M(k) = M0 * (k - 1)

where:

  • M0 = 320

Full operation cost:

Mtotal = M(k) + G

where G is the gas cost in BNB.

If the total weight of selected safes is:

Ain = Σ Aj

then the resulting weight of the new safe can be represented as a function:

Anew = Φ(Ain, q, ξ, k)

where:

  • q is the quality coefficient;
  • ξ is the random component;
  • k is the number of safes participating in the mint.

Expected minting efficiency:

ηm = E[Anew] / M(k)

The higher ηm, the more efficient minting is as a reinvestment tool.

13. Demonstration Example for 3 Years

Below is a simple calculation example.

Conditions

Assume:

  • daily distribution: 250 AMA2;
  • horizon: 3 years = 1095 days;
  • total project weight grows linearly from 5 000 AM to 45 000 AM;
  • all 10 safes in each scenario were purchased on the same day, the first day of the experiment;
  • scenario A: the user has 10 safes of 1 AM each, total 10 AM;
  • scenario B: the user has 10 safes of 10 AM each, total 100 AM;
  • after 3 years, the AMA2 price reaches 0.3 USD.

Formula

Total system weight on day d:

W(d) = 5000 + d * (45000 - 5000) / 1094

Since all safes were purchased on the first day of the experiment, the user’s weight changes along a single age trajectory:

Ai(d) = A0 * Kstep(min(d, 720)) * kmax(0, d - 720)

where:

  • A0 is the user’s starting total weight;
  • Kstep(d) is the product of all threshold age multipliers reached by day d;
  • k = 1.0030095339437 is the daily growth multiplier after 720 days.

User daily reward:

R(d) = 250 * Ai(d) / W(d)

Total for 3 years:

Rtot = Σ R(d), d = 0..1094

If the AMA2 price at the calculation point is denoted as Pama, then the total value of the accumulated amount:

V = Rtot * Pama

Calculation Result

Scenario A: 10 Safes of 1 AM Each

Starting total user weight:

10 AM

Taking into account all age thresholds before 720 days and daily growth after 720 days, by the end of the 3-year horizon their total weight in the calculation rises to approximately 46.38 AM.

Total reward over 3 years:

≈ 219.80 AMA2

If the AMA2 price after 3 years is 0.3 USD, then the value of the accumulated amount:

219.80 * 0.3 ≈ 65.94 USD

Scenario B: 10 Safes of 10 AM Each

Starting total user weight:

100 AM

Total reward over 3 years:

≈ 2198.03 AMA2

If the AMA2 price after 3 years is 0.3 USD, then the value of the accumulated amount:

2198.03 * 0.3 ≈ 659.41 USD

Conclusion from the Example

With the same number of safes, the result is determined not by the number of items as such, but by the total AM weight.

If the portfolio weighs 10 times more:

  • the user’s share in the system on each day is approximately 10 times higher;
  • therefore the total AMA2 accumulation over the period is approximately 10 times higher;
  • and with the same purchase date, all age boosts, including threshold steps before 720 days and daily growth after 720 days, scale across the entire portfolio simultaneously.

This confirms the key idea of the project:

  • early entry into high-weight safes provides a long-term advantage;
  • the earlier a user builds quality AM weight, the longer that weight works for them;
  • over the same horizon, it is weight, not the “number of cards”, that determines the result.

Note:

  • this is a calculated scenario under specified conditions;
  • it is not a promise of profitability;
  • in reality, distributions, epochs, total system weight, AMA2 exchange rate, and user activity will differ.

14. Why the Project Stimulates Long-Term Holding

NFTAMA is built as a system that is favorable for long-term participation.

Long-term holding is driven by:

  • growth of safe age;
  • growth of weight through upgrades;
  • ability to receive AMA2 proportionally to weight;
  • use of safes for minting new ones;
  • growth of account utility;
  • long-term effect of early entry.

NFTAMA is a portfolio development system, not an NFT venue for rapid resales.

15. Liquidity and Market

Where AMA2 Is Traded

In the current project architecture, AMA2 is used in a pair with BNB on PancakeSwap.

Swap link used in the project:

https://pancakeswap.finance/swap?inputCurrency=0x126221D7635388f4aEb85c71A4701E09640EEe09&outputCurrency=BNB

Liquidity Development Strategy

Project liquidity development strategy:

  • expand liquidity in the main AMA2/BNB pair;
  • gradually increase the volume of locked liquidity;
  • stimulate organic use of AMA2 within the platform so that demand is formed not only speculatively;
  • in the future, consider adding new pools and infrastructure partners.

What TVL Is

TVL (Total Value Locked) is the total value of assets locked or used in the ecosystem or its pools.

For NFTAMA, TVL serves as a metric of:

  • user trust;
  • economic depth;
  • liquidity maturity;
  • scale of capital involvement in the ecosystem.

Project TVL is formed by:

  • liquidity in AMA2 pairs;
  • user balances;
  • expansion of the internal economy;
  • future gaming and banking mechanics.

16. Technical Architecture

Why BNB Smart Chain

The project is architecturally tied to BNB Smart Chain:

  • safes are minted in the BSC environment;
  • AMA2 is linked to a BNB pair;
  • BNB is used as gas;
  • users operate through BSC-compatible wallets and transfers.

How the Website and Blockchain Are Connected

The connection has two levels:

  1. Backend and database
  • store game state;
  • maintain internal balances;
  • calculate weight, history, rules, queues, and interface logic.
  1. Smart contracts and on-chain operations
  • mint NFTs;
  • provide on-chain storage of the token and NFT;
  • handle withdrawals and transfers of assets.

Internal Infrastructure

The project uses:

  • the user’s internal IN wallet;
  • an external OUT wallet;
  • queues for BNB, AMA2, and NFT withdrawals;
  • NFT mint queues;
  • background commands for calculations, distributions, and top-ups.

This means that part of the project logic is centralized:

  • game mechanics;
  • weight calculation;
  • distributions;
  • queues;
  • part of financial scenarios.

In NFTAMA, on-chain and off-chain components work together.

Smart Contracts

The project is based on two key smart contracts:

  • AMA2 contract;
  • NFT contract.

AMA2

Current AMA2 address:

0x126221D7635388f4aEb85c71A4701E09640EEe09

Explorer link:

https://bscscan.com/address/0x126221D7635388f4aEb85c71A4701E09640EEe09

NFT

Current NFT contract address:

0x6c476fB04Ee975Bf113dc02FDDc1ae11B3de3dbf

Explorer link:

https://bscscan.com/address/0x6c476fB04Ee975Bf113dc02FDDc1ae11B3de3dbf

External NFT Minting Limitations

Even if an NFT technically exists on-chain, this is not sufficient for participation in the NFTAMA economy.

For a safe to:

  • be counted in weight;
  • participate in age mechanics;
  • participate in minting;
  • be visible to the internal market;
  • generate AMA2,

it must be created and recorded specifically within the platform logic.

An NFT minted outside the internal project logic is not a full economic safe of NFTAMA.

17. Security and Trust

Existing Protection Measures

The project already implements:

  • registration and critical forms protected by captcha;
  • email confirmation;
  • queues and stepwise background operations instead of immediate chaotic execution;
  • balance and fee checks before withdrawals;
  • ownership checks before safe operations;
  • restrictions on receiving free AMA2 rewards;
  • restrictions on the number of mints per safe;
  • separation of the user’s internal and external wallets.

Anti-Bot Mechanics

The project already uses captcha in scenarios where automatic abuse must be limited.

  • protection from mass automated registrations;
  • protection from abuse in interactive rewards;
  • protection from scripted farming of free AMA2 rewards;
  • additional limits by time and number of attempts.

Protection Against Exploits

  • the project reduces abuse risk through server-side checks of asset ownership, balances, limits, queue statuses, and required fees;
  • critical operations are not reduced to a single button and go through validations and handlers;
  • part of the logic is moved into queues and background commands, which reduces the number of race-condition scenarios at the interface and operation-processing level.

At the same time:

  • as in any Web3 project, zero exploit risk cannot be guaranteed;
  • security is a process, not a static state.

Rug Pull and Trust

For long-term holding of assets in the project, standard trust indicators are important:

  • transparent tokenomics;
  • transparent contract addresses;
  • contract verification and openness of key infrastructure;
  • locked liquidity;
  • timelock for critical administrative actions;
  • multisig mechanism for governance.

What Multisig Is

Multisig is a scheme in which a critical action cannot be performed by one person alone. Several signatures of predefined participants are required.

This is important for the project because it:

  • reduces the risk of a single operator’s error;
  • reduces the risk of a single key compromise;
  • increases trust in contract and treasury management.

What Timelock Is

Timelock is a delay before execution of an important administrative action.

For the project, timelock is useful because it:

  • gives the community time to see a change;
  • reduces the risk of sudden unwanted changes;
  • increases transparency.

Timelock is fixed at the level of the contract, treasury, or governance procedures.

Liquidity and Locking

In the current model:

  • there is already locked liquidity of approximately 1000 USD;
  • the goal by the end of the year is to increase the lock volume to approximately 10000 USD.

Locked liquidity parameters are published together with on-chain confirmation.

Audits

  • the project relies on transparency of the contract side;
  • contract addresses, explorer links, and security materials must be publicly fixed;
  • results of completed audits are issued as a separate appendix to the white paper.

18. Contract Transparency

Project contract transparency includes:

  • AMA2 contract address;
  • NFT contract address;
  • network explorer links;
  • confirmation of token parameters;
  • information on liquidity, lock mechanisms, and governance rights.

Such transparency is especially important for a project built around long-term asset holding and reputation.

19. Roadmap

What Has Already Been Implemented

At the current stage, the following have already been implemented:

  • public landing page;
  • help section;
  • registration and authorization;
  • email confirmation;
  • internal cabinet;
  • internal wallets;
  • balance top-up and processing;
  • safe purchases;
  • automatic purchase rules;
  • secondary market between users;
  • minting of a new safe;
  • safe age mechanics;
  • weight change history;
  • free AMA2 reward mechanics;
  • withdrawal of BNB, AMA2, and NFT;
  • referral program;
  • blog.

Next 3 Months

Planned functional block: Bank

Essence:

  • users will be able to unite into groups or “banks”;
  • banks will receive common tasks and common progress;
  • bank participants will be able to receive an additional AMA2 bonus;
  • group interaction mechanics will appear inside the platform.

Practical effect:

  • retention growth;
  • team dynamics growth;
  • more reasons to hold assets in the project;
  • growth of daily activity.

6-Month Horizon

Priorities:

  • expansion of the user base;
  • strengthening of AMA2 liquidity;
  • referral and community growth mechanics;
  • strengthening of the scarce model through new internal AMA2 spending scenarios.

Suitable strategies:

  • campaigns with partners and opinion leaders in NFT/GameFi/BSC niches;
  • referral challenges and seasonal activities;
  • incentives for liquidity providers;
  • special safe releases and game seasons;
  • easier entry for new users;
  • simplification of the route buy BNB -> bring it into the platform -> buy a safe.

12-Month Horizon

Promising directions:

  • expansion of the banking mechanic;
  • growth of locked liquidity;
  • public security program;
  • governance mechanisms;
  • expansion of market integrations;
  • additional scenarios for team play, quests, and long-term seasons.

20. Team and Governance

What DAO Is

DAO is a decentralized governance model in which part of decisions is made through predefined rules and voting.

The DAO mechanic for NFTAMA belongs to a later stage of development after:

  • stabilization of the base economy;
  • accumulation of an active community;
  • appearance of clear objects for voting.

What a Governance Mechanism Is

Governance is a decision-making system:

  • who can propose changes;
  • who can vote;
  • which decisions require discussion;
  • which decisions require timelock or multisig.

For NFTAMA, governance mechanisms apply to:

  • epoch parameters;
  • banking mechanics;
  • community programs;
  • incentive models;
  • treasury decisions.

Recommended Governance Model by Stages

Stage 1. Now

Team governance:

  • decisions are made by the core project team;
  • transparency and public logic of decisions are important.

Stage 2. After Community Growth

Advisory governance model:

  • discussion of initiatives;
  • community polls;
  • test voting on non-critical parameters.

Stage 3. After Product Strengthening

Partial DAO approach:

  • voting on part of community and economy parameters;
  • treasury and critical functions under multisig and timelock;
  • part of strategic decisions remains with the core project team.

21. Marketing and Growth

How Users Learn About the Project

The NFTAMA growth model includes organic distribution:

  • if it is beneficial and interesting for a user to remain in the project, that user becomes a source of recommendations;
  • for a long-term project, reputation is more important than short-term informational noise;
  • community growth is strengthened by engaged current participants interested in the development of the ecosystem.

NFTAMA relies on long-term trust, clear mechanics, and growth through community. Project development is not based on short-term demand formed by inflated expectations. Growth of the user base is supported by the product model and long-term utility of the ecosystem.

Referral System

The project already has a referral program.

Current referral accrual size:

9%

This means that the referrer receives additional AMA2 accrual related to the invited user’s activity.

Key advantage of the model:

  • the referrer’s reward does not take AMA2 away from the referee;
  • this provides additional motivation for community growth.

How AMA2 Turnover Will Grow

AMA2 turnover will increase through:

  • new users;
  • new safes;
  • upgrades;
  • minting;
  • internal market;
  • referral activity;
  • expansion of liquidity;
  • banking and team mechanics.

Turnover growth by itself does not guarantee price growth, but it is important as a sign of a living economy: the token is used, transferred, spent, and reintroduced into the cycle.

How Scarcity Will Increase

If the project develops according to plan, AMA2 scarcity will increase through:

  • limited supply;
  • use of the token for upgrades;
  • use of the token for minting;
  • fees and internal costs;
  • growth of the user base;
  • growth of the number of scenarios where spending AMA2 inside the platform is more beneficial than holding it idle.

22. Risks and Responsibility

1. Market Risk

Market risk consists in the possibility that AMA2 may fail to reach the target rate.

Such factors include:

  • weak market cycle;
  • low demand;
  • weak community growth;
  • insufficient liquidity;
  • general market downturn.

2. Liquidity Risk

Even with a good product, the token may suffer from:

  • insufficient market depth;
  • high volatility;
  • difficult entry or exit for large volumes.

3. Infrastructure Risk

The project uses server-side game logic, databases, queues, and background commands.

This means that risks may include:

  • backend logic errors;
  • queue delays;
  • technical failures;
  • incomplete synchronization of off-chain and on-chain parts.

4. Smart Contract Risk

As in any Web3 project:

  • errors in contracts are possible;
  • technical and infrastructural risks are possible in the contract and operational parts of the project;
  • risks related to external integrations of the BSC network are possible.

5. Regulatory Risk

The legal regime of NFTs, utility tokens, and gaming token economies may change across jurisdictions.

6. User Behavioral Risk

The user independently decides:

  • when to enter;
  • which safes to buy;
  • whether to spend AMA2 on upgrades;
  • whether to withdraw tokens;
  • whether to use minting.

An incorrect strategy may worsen the result even if the project mechanics work as intended.

NFTAMA is a project with a long-term gaming and economic model, but it provides no guarantees of profitability. The price of AMA2, user activity, market depth, development stability, and practical user utility depend on ecosystem development and the quality of its implementation.

23. Conclusion

NFTAMA is built around the following basic principles:

  • an NFT safe is not an image, but an asset with parameters and function;
  • AM weight is the core of participation in the system;
  • AMA2 is the main token for settlement and ecosystem development;
  • the user path is built around the cycle weight -> AMA2 -> strengthening -> new weight.

Strengths of the model:

  • clear portfolio growth logic;
  • practical value of NFTs;
  • economic role of age, level, and rarity;
  • reinvestment cycle through AMA2;
  • combination of gaming, NFT, and token economy.

Key project task:

  • development of a sustainable ecosystem with user growth, liquidity, and trust infrastructure.

Further development of NFTAMA is determined by model transparency, AMA2 liquidity, infrastructure security, product development pace, and community resilience. These factors shape the project’s long-term position in the NFT, GameFi, and utility-driven token economy segment.

24. Variable Definitions

Below are the designations used in the formulas of the document.

  • A — safe weight or a weight quantity in the system.
  • A0 — initial weight of the safe at the moment of opening.
  • A1 — weight of the safe by the end of the primary opening cycle.
  • Ai — total weight of user i.
  • Aj — weight of one of the safes participating in minting.
  • Ain — total weight of safes participating in minting.
  • Anew — resulting weight of the new safe after minting.
  • Aq — weight quota for obtaining one additional free AMA2 reward attempt.
  • Asum — total weight of all system users.
  • Abase — base weight of the safe before applying the age multiplier.
  • Aentry — weight with which the user entered the system.
  • Bn — return percentage value of the account at level n.
  • C(t) — cost of one unit of weight at time t.
  • Di — share of user i in the total system weight.
  • E[Anew] — expected weight of a new safe.
  • Ej — epoch number j.
  • Fn — base free AMA2 reward of the account at level n.
  • Fday — expected amount of free AMA2 reward per day.
  • Fmonth — expected amount of free AMA2 reward per month.
  • G — gas or network operation cost in BNB.
  • H — investment horizon.
  • Kage(d) — age multiplier after d days of active growth.
  • L — upper price boundary in the auto-buy strategy.
  • Lm — limit of participation of one safe in minting.
  • M(k) — mint cost in AMA2 when k safes participate.
  • M0 — base mint cost from two safes.
  • Mtotal — full mint cost including gas.
  • N0 — base number of attempts to receive free AMA2 reward per day.
  • Nday — total number of attempts to receive free AMA2 reward per day.
  • Nmax — maximum number of attempts to receive free AMA2 reward per day.
  • P(t) — safe price at time t.
  • P0 — starting safe price at opening.
  • P1 — safe price by the end of the primary opening cycle.
  • P* — expected entry price for the selected strategy.
  • Pama — price of one AMA2 at the calculation point.
  • Pbid — final bid in the price-increase purchase strategy.
  • Pmax — maximum price of the auto-buy strategy.
  • Ptarget — target entry price in the wait-for-price-drop strategy.
  • Q — amount of AMA2 directed to distribution for a cycle.
  • Qnet — amount of AMA2 after fee deduction.
  • R — ratio of expected weight to expected entry price.
  • Ri — reward of user i for the distribution cycle.
  • Rref — referrer reward.
  • Rchild — base reward of the invited user.
  • S — amount of AMA2 available for distribution in the cycle.
  • Stotal — total AMA2 supply.
  • T — lifetime of an opened safe on the primary market.
  • Rtot — total user reward for the calculation period.
  • U1 — price of the first safe upgrade.
  • Un — price of the safe upgrade at level n.
  • V — value of accumulated AMA2 in monetary terms.
  • Vsafe — market value of a safe.
  • W — total weight of the entire system.
  • Wj- — lower weight boundary for epoch j.
  • Wj+ — upper weight boundary for epoch j.
  • d — either the number of days or a specified percentage of price decrease, depending on context.
  • f — AMA2 distribution fee rate.
  • ga — base growth rate of safe weight when upgrading.
  • gb — growth rate of account upgrade price.
  • gu — growth rate of safe upgrade price.
  • hn — growth rate of the base free AMA2 reward at account level n.
  • j — epoch number.
  • k — number of safes participating in minting.
  • lvl — safe level.
  • m — average AMA2 reward for one attempt to receive free reward.
  • n — level number.
  • q — safe quality coefficient.
  • r — share of AMA2 directed to distribution per cycle.
  • s — price increase step in the auto-buy strategy.
  • t — time since the safe was opened.
  • ttarget — time at which the price reaches the specified entry level.
  • y — expected future yield of the safe.
  • α — referral accrual rate.
  • ΔW — step of total weight change between adjacent epochs.
  • ηm — minting efficiency as the ratio of expected weight to cost.
  • ξ — random component affecting the resulting weight of a new safe during minting.
  • Φ — function determining the resulting weight of a new safe during minting.