Build the mini app that sells your token and feeds its pool

Why a sale beats a giveaway for a new token

A token given away arrives in a wallet with nothing behind it. The holder did not pay, so the pool did not grow, and the only thing they can do with it is sell — which the pool has to absorb. That is why campaigns built entirely on free distribution tend to watch their own price fall as the rewards land.

A token sold at a discount arrives with its GRAM inside. The buyer pays, the payment enters the pool, and the liquidity behind every token in circulation gets deeper rather than thinner. The discount is what makes the purchase attractive; the pool routing is what makes it sustainable.

How the discount defends itself

The discount is not a fixed number of tokens. It is a percentage off the current pool price, which means the app recalculates what a buyer receives every time the price moves. When the token rises, the same GRAM buys fewer tokens, and the reserve you set aside lasts longer without you touching a setting.

This is the part that usually needs a person watching a spreadsheet. Tying the discount to the pool price instead of to a token count removes the dial entirely: there is nothing to adjust when the market moves, because the rule already refers to the market.

Why the tokens arrive second by second

Delivering a whole purchase at once creates a moment where a large balance lands in a wallet with nothing stopping it from being sold immediately. Spreading delivery over the days you choose turns that moment into a slope, and it gives the buyer a reason to open the app again tomorrow.

It also changes what the app is. A page where you pay and leave is a checkout; a place where something accrues while you are away is a product people come back to. The return visit is not a growth trick here — it is the mechanic.

What the owner can and cannot touch

The GRAM paid for tokens never reaches the owner's balance. It is claimed, simulated against the pool and sent into the liquidity — and every step of that is recorded, with the state visible in the app's Proof screen. An owner who wanted to take that money would have to not build this, rather than turn something off.

What the owner does control is the reserve: how many tokens are set aside for the sale, how long delivery takes, and where the discount tiers sit. Every order is set aside from that reserve the moment it is placed, so the same token is never promised twice.

Decide the buckets before you announce anything

A distribution plan is three numbers and their rules: what sits in the pool, what the app hands out, and what the owner keeps. Publish them before the campaign starts. Every credible launch can answer "how much did you keep?" instantly, and every failed one answers it after the fact, differently each time.

The pool bucket is locked by the LP. The app bucket is restricted by purpose — it leaves through rewards and purchases, never to a market. The owner bucket is the one that needs an explicit rule, because it is the only one that can be dumped. Vesting it, capping it, or setting it to zero are all defensible; leaving it undefined is not.

Giving tokens away, and why the sale comes first

The app can also hand tokens out — for joining a channel it verifies by membership, for completing a task, for inviting someone who themselves did something real. That is distribution, and a token needs it: a coin with no holders is not a market. But pay for verified actions, never for pressing Start, or the campaign becomes a faucet for bots.

Every token handed out for free is future selling pressure the pool pays for. Every token sold at a discount arrives with its GRAM inside. Sizing those two against each other is the whole question, and it is why the sale is set up before the giveaway rather than after.

1. Define the qualifying action

   The first event that represents real value — not the click that precedes it.

2. Verify it server-side

   Channel membership rechecked on use, not only at start.

3. Credit once, idempotently

   A retried callback must not pay twice.

4. Show the state honestly

   Pending, qualified and rejected are three different messages.

5. Cap the campaign

   A distribution with no ceiling is a liability with no ceiling.

Common ways this goes wrong

• Reusing the token's signing wallet as the app's wallet, which puts the whole supply behind the same seed phrase as your users' deposits.
• Pasting the jetton address by hand instead of picking your own token from the starred suggestions, and connecting a contract that is not yours.
• Leaving the app's wallet with no GRAM, so token withdrawals fail on gas even though the token balance is fine.
• Applying the skin before the token has a pool, so the app has a price of zero to discount from.
• Giving tokens away faster than the sale funds the pool, which produces a chart that only goes one way.
• Promising a return rather than a product. A discount on a token is defensible; a promised profit is not.