How we Designed the game economy for the Telegram Mini App

Before the launch, the task was not just to implement game mechanics, but to design a stable game system that:

• keeps the user in the product
• scales to hundreds of thousands of players
• manages the economy without distortions
• eliminates the possibility of abortion
• ready for integration with Web3 (tokenization)

The key limitation is Telegram:

• short user sessions
• limited UX
• high competition for attention

Therefore, the game had to “catch” from the first seconds and hold through a system of decisions and progression.

The task was formulated not as “making a game”, but as creating a manageable system of user behavior.

What does this mean in practice?:

• The user should return 3-4 times a day.
• Every action must make sense.
• The economy must be controlled
• Progress should not break the balance

Actually:
we have designed a digital economy with predictable consequences of actions

The work was built in 3 stages:

1. Decomposition of player behavior

Decomposed the user into scenarios:

• fast player (enters for 2-3 minutes)
• engaged (20-30 minutes session)
• “abuser” (trying to farm the maximum)

1. Scenario modeling

For each type:

• how many actions per day
• how many resources does it receive
• How fast is it growing

1. Balancing

The formulas were adjusted so that:

• no one was “flying away” by progress
• There was no stagnation

interest remained

The event model. The game is built as a chain:

Event → Selection → Result → Change of state

Example:

• the player enters the location:
• Option A → +100 coins, risk of penalty
• Option B → +50 coins, no risk
• option C → boost, but at a cost

This creates:

• strategy
• variability
• engagement

An example scenario. The player chooses a risky option:

Reward = 100
PenaltyChance = 20%
Penalty = -150

Expected value:

EV = 0.8 * 100 + 0.2 * (-150) = 80 — 30 = 50

=> mathematically equal to the “safe” option,
but psychologically it is perceived as more beneficial.

The player’s progression. We control growth through a non-linear formula:

XP_required = base * level^1.6

This gives:

• quick start
• slowing down at high levels
• retention

Calculation of rewards.

Reward = Base * Difficulty * LevelModifier

Example:

• Base = 50
• Difficulty = 1.4
• LevelModifier = 1.2
• Reward = 50 * 1.4 * 1.2 = 84

Control of the economy. The main rule:

Emission ≤ Combustion + Controlled growth

Where:

• issue — all awards given
• burning — expenses (boosts, upgrades)

Balance of actions.

NetGain = Reward — Cost — Risk

If the NetGain is too high:
→ the player breaks the economy

If it is too low:
→ the player leaves

Restriction of pharma

Actions_per_hour ≤ 120
Reward_per_hour ≤ MaxLimit

When exceeding:

• reduced rewards
• soft restrictions

We’ve been checking:

Scenario 1 — “fast player”

• 10-15 actions
• Must feel the progress

Scenario 2 — “sticky”

• 100+ actions
• It should not ruin the economy

Scenario 3 — “abuser”

• trying to farm the maximum

must rest on the limitations

Let’s look at the main mistakes that could kill the game.

Error 1 — linear progression

XP = base * level

Problem:

• The player is growing too fast
• The balance is broken

Mistake 2 — Excessive rewards

If:

Reward >> Cost

→ inflation
→ depreciation

Mistake 3 — lack of restrictions

If there are no limits:

→ Players begin:

• click endlessly
• automate actions

Mistake 4 — “punishment without meaning”

Heavy fines without compensation:
→ the user leaves

Error 5 — identical scenarios

If all events are the same:
→ retention drops

Mistake 6 — lack of variability

If the player always chooses one option:
→ The system is not working

After implementing the model:

• Players return 3-4 times a day
• average session: 20-30 minutes
• there are no cases of “economic breakdown”
• there is no mass abortion
• progress is felt, but controlled

This is not a game design in the classical sense.

This:

• mathematical model of behavior
• user attention management
• designing the digital economy

Actually:
a system that controls user actions through numbers