Pinksale fair launch sets the token price from the final raise

The final raise determines the price per token

The fundraising total changes the sale price while the selling allocation stays fixed. More funds spread across that allocation mean a higher price per token.

Price and its reciprocal

The final sale price equals total funds raised divided by the tokens allocated to the fair launch. This expresses the fundraising currency paid per token. A displayed rate in tokens per unit of fundraising currency runs in the opposite direction: it equals the selling allocation divided by funds raised.

Each contributor’s share

A contributor’s allocation equals their recorded contribution divided by the final sale price. Equivalently, their share of total fundraising determines their share of sale tokens. A calculation using the running fundraising total remains provisional until contributions close. The allocation calculation describes purchased tokens before any release schedule applies.

The selling allocation excludes liquidity reserves

The selling amount covers tokens offered to contributors. With automatic listing, the creator also supplies tokens for initial liquidity. The creation interface’s total token requirement can therefore exceed the selling amount. Using that larger requirement as the price denominator would mix the sale allocation with liquidity funding. The token’s entire supply is a different quantity again, including any allocations outside this sale.

Open full-size image

Pool settings govern participation and post-sale actions

Pool settings govern participation, liquidity creation, contributor releases and buybacks. Several controls can coexist within a launch, each affecting a different component.

Service charges reduce the funds left for the project

Fair-launch service charges separate the gross raise from the creator’s remaining proceeds. The payment structure includes an upfront creation charge and a percentage charge after success.

Creation and network costs

Listed fair-launch creation charges include 1 BNB on BNB Smart Chain, 0.2 ETH on Ethereum and 4 SOL on Solana. These are network-specific service charges. Network transaction fees require an additional native-coin balance. The selected network and fee option determine the quote shown before confirmation.

Charges after a successful sale

Those listed options also charge 5% of funds raised in the fundraising currency. The platform deducts it after successful completion. Liquidity commitments and any enabled buyback or affiliate allocations also affect the funds available to the creator. The creator’s net proceeds aren’t the fundraising total used in the closing-price formula.

Listing connects the sale to a separate trading market

Auto listing makes liquidity creation part of successful finalization on the selected decentralized exchange, or DEX. The pool uses its configured router and liquidity allocation. Manual listing leaves the creator responsible for adding liquidity after finalization, so the sale’s closing time alone doesn’t establish that trading has begun. When automatic listing locks the liquidity provider tokens, commonly called LP tokens, the selected duration governs that lock. Solana creators can instead choose to burn the LP tokens at finalization. A liquidity lock restricts access to that liquidity position. Contributor vesting governs purchased project tokens separately, so an LP lock duration doesn’t describe when a contributor can claim their allocation.

Each contributor’s token allocation uses the closing sale price. Subsequent trading can move the market price away from that rate.

Buyback reserves fund later purchases and burns

An enabled buyback reserves part of raised funds for market purchases of the project token. Each triggered execution buys project tokens and sends them to a burn address. The configured amount per buyback sets how much fundraising currency each purchase uses.

When this buyback option is enabled, the liquidity percentage and buyback percentage together must reach at least 51% of raised funds. This is a combined allocation requirement; it doesn’t require the whole combined amount to enter initial DEX liquidity.

The first buyback can start one hour after finalization. Later, the owner can trigger another after the configured minimum delay. Any user can trigger it once the configured maximum delay has passed since the previous buyback.

Open full-size image

Each buyback needs someone to submit its trigger transaction and pay network fees. The contract then performs the purchase and burn. The feature doesn’t establish a fixed future trading price.

Contributor vesting schedules access to purchased tokens

Contributor vesting divides a purchased allocation into scheduled releases. Contributor vesting doesn’t support rebase tokens.

The initial release

The first-release percentage applies to each contributor’s total purchased allocation when the launchpad finalizes. An initial claimable amount can therefore be smaller than the allocation calculated from the final sale price. The pool’s chosen percentage determines that first portion.

Later release cycles

The cycle length sets the interval between later releases. Each cycle’s release percentage uses the contributor’s original purchased allocation as its base. Contributors manually claim unlocked tokens and pay the network fee for each claim. A release becoming available doesn’t automatically send tokens to the wallet.

Closing conditions determine whether claims or refunds follow

A successful fair launch requires the end time to pass and the soft cap to be met. The soft cap is the minimum raise in the pool’s fundraising currency. Once any required token-contract exemptions are in place, the pool owner can finalize the pool, enabling contributor claims under its release terms.

A pool that ends below its soft cap fails, and contributors can reclaim their contributions. That refund path differs from the penalized emergency withdrawal available during an active sale.

For EVM tokens with transfer taxes, transfer-triggered rewards or transaction limits, the token owner must exempt the specific pool address before finalization. The relevant address is the pool contract, not a contributor’s wallet. Contract-specific router or pair exemptions may also be necessary. A taxed token without suitable exemption functions can prevent correct finalization.

Open full-size image

A failed finalization transaction doesn’t settle the pool. Its failure details can identify missing exemptions, insufficient gas or other token-contract errors. The creator needs to resolve that error before successful finalization can enable contributor claims.