UNITE/documentation

UNITE docs.

One tradeable coin. One liquidity pool.
Every representation accounted for.

Solana launch flowCurve + vault / proposed design

On this page

Overview

One coin gets traction. Copycats launch. Buyers split between contracts, and every chart competes for the same liquidity. UNITE’s goal is to keep the community around one tradeable coin rather than a collection of competing representations.

This document describes two distinct things: the Solana launch flow available on this site, and a proposed Unified Coin model with a bonding curve and 1:1 vault conversions. The model is not a deployed bridge, exchange or pool-fusion protocol.

Available launch flow

Connect a wallet, prepare a Pump.fun coin, review and sign a mainnet transaction. Listings require finalized chain verification. Existing IPFS metadata is required; picture publishing is not connected.

Community voting / fusion not live

Holder-verified voting requires more than 80% YES and each selected coin above $10,000 USD market cap. Votes run for 24 hours, one wallet per vote. Pool fusion, holder migrations, custom curves, cross-chain vaults and fee claims are not deployed.

The problem with split liquidity

The same idea can attract many tokens, each with its own contract, holders and pool. Liquidity in one pool cannot automatically fill an order in another. A shared name or ticker does not make those assets interchangeable.

UNITE’s original fusion concept is holder-approved consolidation: one market, combined liquidity and holders carried over under an agreed allocation. Community votes are available on the voting page. Only verified UNITE launches with market caps strictly above $10,000 USD qualify; unavailable data blocks participation. Exactly 80% YES does not pass: approval must exceed 80% of ballots cast. Holders of at least one selected coin may propose or vote, once per wallet. These votes do not execute fusion or migration. The vault design below tackles a narrower issue: preventing representations of the same coin from becoming separate tradeable markets.

fragmented marketsone tradeable coinshared liquidity

Core design

Unified Coin

The trading-chain token is the only form that can be bought and sold. Its supply is S. Moving to another chain does not authorize a second independent supply.

Vaulted forms

The proposed second-chain form is non-tradeable and convertible 1:1 only. Every issued vaulted unit must correspond to one Unified Coin unit locked in the vault. Conversion is not a buy or a sell.

Supply rule

Let L be locked trading-chain units and V the outstanding vaulted units. The design requires V = L, so unlocked trading supply plus vaulted supply remains S. A real implementation would also need enforceable transfer restrictions and bridge settlement rules.

unlocked Unified Coin + vaulted units = total supply
(S_total_on_trading_chain − L) + V = S

Coin lifecycle

01
Launch
Current flow
Choose ticker, name, description, optional social links and an optional first buy in SOL. Select a picture for preview or use existing IPFS metadata. Publishing pictures is not connected, so the launch currently needs existing metadata. Your wallet signs; UNITE never takes your private key.
02
Trade
Provider rules today
Current coins trade through Pump.fun and its applicable markets. The custom constant-product curve in this document is a separate proposed model, not a live UNITE trading engine.
03
Convert out
Proposed
Lock n Unified Coin units and issue n non-tradeable vaulted units. Increase both L and V by n. Do not issue before the lock is verified.
04
Convert in
Proposed
Retire n vaulted units and release n locked Unified Coin units. Decrease both V and L by n. Failed conversions must not unlock units while claims remain outstanding.
05
Graduate
Model only
The proposed curve finishes when its real token allocation is exhausted. Show the final price and collected quote, then model the reserved-token pool. A displayed “Graduated” or “liquidity locked” label is not an on-chain guarantee.

Curve math

Reference defaults are editable per coin in the proposed model. They do not configure today’s Pump.fun launches. Quote quantities would use integer base units (lamports for SOL), and token quantities use consistent integer token units.

Proposed per-coin defaults
Parameter	Default
X₀ · virtual quote reserve	30 SOL
Tv₀ · virtual token reserve	1,073,000,000
S · total supply	1,000,000,000
T_curve · sold on curve	793,100,000
T_reserve · pool allocation	206,900,000
f · total trade fee	1%
r_c · creator share of trade value	0.25%

Xv and Tv are current virtual reserves; K starts at X₀ × Tv₀. Virtual reserves are pricing inputs, not proof of deposited assets. With consistent display units:

K = X₀ × Tv₀
spot price p = Xv / Tv
market cap = p × S

Buy · gross quote payment x

Subtract the fee before moving the curve. Reject if tokens_out is below the buyer’s minimum output, or the buy would exceed the real curve inventory.

fee = floor(x × f)
net = x − fee
Tv′ = ceil(K / (Xv + net))
tokens_out = Tv − Tv′
Xv′ = Xv + net

Buy exactly n tokens

Solve for the quote needed, then gross it up for fees. Require a positive remaining virtual reserve and sufficient real curve inventory.

net = ceil(K / (Tv − n)) − Xv
x = ceil(net / (1 − f))

Sell · u tokens

Return quote from the curve, then deduct the fee. Reject if payout is below min_out or exceeds available real quote.

Xv′ = ceil(K / (Tv + u))
gross = Xv − Xv′
fee = floor(gross × f)
payout = gross − fee
Tv′ = Tv + u

Fee split

For buys, the fee basis is the gross payment x. For sells, it is gross quote returned before fees. The creator’s 0.25% is part of the total 1%, not an additional fee.

fee_total = floor(gross × f)
fee_creator = floor(gross × r_c)
fee_protocol = fee_total − fee_creator

The protocol receives the rounding remainder. The reference proposes tracking creator fees per coin with a simulated Claim action; no live UNITE fee-claim contract is specified.

Integer arithmetic & rounding

Use BigInt for all curve calculations. Express fee rates as integer ratios, use floor or ceiling division explicitly, and only convert to decimals for display. Rounding favors the curve; minimum-output checks happen before applying an action.

Graduation condition

The real curve allocation reaches zero at Tv = Tv₀ − T_curve = 279,900,000 tokens. Record the final spot price and net collected quote, excluding fees.

The reference proposes seeding a simulated pool with 206,900,000 reserved tokens and collected quote at the curve’s end price. These fixed allocations do not automatically guarantee an exact price match: a deployment must reconcile pool reserves, rounding and any leftover amounts. A display-only lock must never be presented as enforceable liquidity protection.

Vault invariant

The accounting rule is simple: vaulted claims must equal locked backing after each completed action. The trading-chain total in this expression includes the locked units.

V = L
(S_total_on_trading_chain − L) + V = S

convert out n: L′ = L + n; V′ = V + n
convert in n:  L′ = L − n; V′ = V − n

For example, locking 100 units means L = 100 and V = 100. Converting 40 back leaves L = 60 and V = 60. The sum of unlocked units and vaulted units is unchanged; conversion does not create new economic supply.

The proposed system must reject insufficient balances, negative amounts, over-redemption and any action that breaks the invariant. A vault status badge would report the check, not certify bridge security. No vault panel or conversion system is live today.

Verification

What current launch listings show

Only coins actually launched through UNITE and verified against a finalized Solana transaction are eligible for listing. Published details include name, ticker, picture, mint address, creator, metadata URI, launch signature and creation time. A finalized launch is not a safety endorsement or proof of future liquidity.

What the vault model should publish

A public conversion log: time, direction, amount, resulting L and V. Also publish supply totals, locked backing, relevant chain transaction references, contract addresses and the current invariant result. These are requirements of the proposed design, not existing live logs.

What needs to be tested

Before a custom curve or vault goes live, test that K never decreases, real curve inventory never becomes negative, a buy-then-sell cannot return more than was paid, and vault invariants hold across random sequences of trades and conversions. Include slippage, integer rounding and failed-settlement cases. The custom engine and these behavioral tests are not implemented by this docs page.

Risks

Vault / bridge risk

Bugs, compromised signers, chain reorganizations or unavailable backing can leave vaulted units unredeemable. A 1:1 accounting equation does not eliminate custody risk.

Operator trust

Permissions, upgrade rights, key custody and recovery processes must be disclosed and independently checked. No decentralized or trustless bridge is demonstrated here.

Failed conversions

Settlement across chains is not automatically atomic. Pending or failed actions need explicit recovery rules that prevent duplicate issuance and premature unlocking.

Market risk

Prices can fall to zero. Thin liquidity, slippage, fees and manipulative trading can cause losses. Graduation, unified liquidity and verified launches do not guarantee returns.

Model / implementation risk

Reference formulas and simulated labels are not deployed guarantees. Current launches depend on Pump.fun, PumpPortal, wallet approval, metadata availability and network conditions. Never sign a transaction you have not reviewed.

UNITE is experimental. These docs are a design reference, not financial advice, an audit or a promise of redemption.

FAQ

one coin. not fifteen copies.go to launch