Kosmo Protocol

Why Kosmo?

The name Kosmo comes from the ancient Greek kosmos (κόσμος), meaning order out of chaos, and by extension the universe as an ordered whole. Token launches have long been chaotic, with snipers, shifting fees and rules that change after the fact. Kosmo Protocol is built on the opposite idea. Every launch follows rules its creator chooses, written into the contracts and fixed from the first block, across every chain it runs on. Your token, your rules.

1. Introduction

Kosmo Protocol lets anyone create a token that trades on Uniswap v4 immediately, on the chain of their choice. A creator picks a name, a symbol, a supply and a fee configuration, signs one transaction, and the token is live: its liquidity is in a public pool, it is locked, and it can be bought and sold by anyone.

The protocol has three goals.

• Fair opening. The creator's first buy is part of the launch transaction and happens at the opening price. Nobody can buy before the creator, and optional limits slow the first minutes for everyone else.
• No capital to start. The creator does not seed liquidity. The pool holds the token side only and is filled by buyers.
• Locked liquidity. The pool position is held by a locker contract for the life of the token.

This paper explains how those properties are built, what they cost, and what they do not guarantee.

2. Background

Launchpads for new tokens have mostly used bonding curves. A curve sells tokens from a contract along a fixed price function until a target is reached, then moves the proceeds into a normal liquidity pool. The design is simple, but it has three well-known weaknesses.

1. Two markets. Before the target is reached the token trades on the launchpad's own contract, not on an open exchange. Aggregators, wallets and analytics tools see it late or not at all.
2. A migration event. When a curve fills, liquidity is moved to a pool in a separate transaction. The move is a moment of risk and a moment of advantage for whoever acts first.
3. Opening advantage. Whoever is first in line when trading starts buys the cheapest tokens. Creators who want a first position must race the market for it.

Uniswap v4 [1] makes a different design possible. Pools can carry a hook, a contract that runs on every swap and can change the fee or reject the trade. Positions can also be placed on one side of the price, so a pool can hold only the new token and sell it as the price rises [2]. Kosmo uses both.

3. Launch mechanism

One call to a chain's launch factory does everything. It deploys the token, opens the pool, places the liquidity and, if the creator sent value, performs the creator's first buy, all in a single transaction.

3.1 The single-sided pool

The creator chooses a supply S between 1,000,000 and 1,000,000,000,000 whole tokens. The factory mints all S tokens and puts every one of them into one Uniswap v4 position. No tokens go to the creator, the team or any treasury. The position holds only the new token, so the pool starts with no quote asset in it. Buyers pay in the quote asset and receive the token. Their payments become the pool's quote-side balance, and the position sells further tokens as the price moves up.

The pool uses a tick spacing of 60. The position starts 60 ticks below the opening price and runs about 600,000 ticks upward, which is effectively unbounded. The first buy crosses the small empty gap and is the first trade that fills the position.

3.2 Opening price

The pool opens at a fixed nominal market cap, set per chain so that it is roughly the same in dollars everywhere. For a quote asset with starting reserve R and a supply S, the opening tick follows from the ratio of the two amounts. Uniswap v4 orders a pool's two currencies by address, so the ratio is inverted when the quote asset sorts above the token.

Opening tick = floor( ln(ratio) ÷ ln(1.0001) )

The factory floors the result to a multiple of 60. Because the token's address decides the ordering, a caller must compute the tick for the exact address the launch will create. The vanity-address service returns that address before the launch is sent.

3.3 The creator's first buy

If the creator attaches value to the launch, the factory swaps it into the pool inside the same transaction, before the transaction ends and before any other account can trade. The creator receives the tokens at the opening price. The launch reverts if the first buy returns fewer tokens than the creator's stated minimum. The creator's first buy is the only purchase exempt from the opening limits in section 4.

3.4 Locked liquidity

The pool position is held by a locker contract for the life of the token. The liquidity is also not a pot of idle capital: it is the supply itself, so the only way it leaves the pool is by being sold to buyers.

3.5 Address customisation

A creator can choose a suffix of three to five hexadecimal characters for the token address. A service mines a CREATE2 salt that produces an address ending in that suffix, and the factory deploys the token at exactly that address.

4. Opening protections

The first minutes of a token's life are when one wallet can take a large share of the supply. A creator can switch on opening protections at launch. They are optional, they are fixed once the launch is mined, and the fee hook enforces them on every swap.

The creator's first buy is exempt, because it is part of the launch transaction. Sells are never limited, so a buyer can always exit. A swap that breaks a cap is rejected by the hook and the transaction reverts. When the window ends, the caps stop applying and the pool trades with no limits.

The caps do not make a launch safe. They raise the cost of dominating the opening and give other buyers time to arrive. A creator who sets no protections gets a fully open market from the first block.

5. Fee model

Every swap pays one fee, taken by the hook and split between the protocol, the creator and, optionally, holders and a buy-and-burn.

5.1 Protocol fee

The protocol fee depends on the token's fully diluted market cap, measured in the chain's native coin. It steps down as the token grows. The hook reads the pool's price on every swap, so the tier changes automatically, without any action from the creator or from Kosmo.

If the hook cannot read a price for a token's quote asset, the 1% tier applies. Creator fees do not depend on the tier.

5.2 Creator fee

The creator sets a fee from 0% to 10%, separately for buys and for sells, at launch. It cannot be changed afterwards. The default in the launch form is 1%.

5.3 Holder share and buy-and-burn

The creator also decides how the creator fee is shared. Two percentages, set at launch, apply in order:

1. Holder share. This percentage of the creator fee is paid to token holders.
2. Burn share. This percentage of what is left after the holder share is used to buy the token from its own pool and burn it.

The creator keeps the remainder. With a holder share of 50% and a burn share of 50%, half the creator fee goes to holders, a quarter is burned and a quarter stays with the creator. A fee splitter contract on each chain does this accounting, and each amount is readable on-chain.

6. Multi-chain deployment

Kosmo is deployed as five independent stacks. Each chain has its own factory, executor, fee hook, fee splitter and locker, and nothing is shared between chains. A token lives on the chain it was launched on.

The opening market caps are chosen so that they are worth about the same in dollars on every chain. Contract addresses for each chain are published in the documentation and are generated from the same configuration the application uses.

Robinhood Chain also carries tokens created earlier on bonding curves. They continue to trade and are labelled as curve tokens. New launches on every chain are Instant launches.

6.1 Quote assets

A token can be paired with the chain's native coin or with another asset that the protocol has approved on that chain. Each chain's executor holds the approved list and a starting reserve for each asset, and the factory refuses an asset that is not approved. The starting reserve fixes the opening price in that asset. The launch page shows the pairs available on each chain.

7. Agents and integrations

Everything the website does can be done from code. A script or an autonomous agent mines a salt, computes the opening tick, simulates the launch, sends it from its own wallet, and then uploads the logo and details by signing a message with the same wallet. The signature is checked against the token's on-chain creator, so only the launcher can set or change the details, and the creator can lock them permanently.

Tokens launched this way can carry an Agent badge when the creator wallet is linked to a public account through a signed statement. The badge is a declaration by the operator. It is not proof that an agent acted, and it is not an audit or an endorsement. The agent guide in the documentation contains a complete working example.

8. The $KOSMO token

$KOSMO is the protocol's own token. It is intended to connect activity on Kosmo to the people who hold the token.

The supply, the distribution and the way protocol revenue reaches $KOSMO have not been finalised, so this version of the paper does not state them. They will be published in full, with the date they take effect, before any $KOSMO is issued.

9. Security and trust model

A trader on Kosmo relies on the following, in this order.

1. Uniswap v4. Swaps, pricing and custody of pool funds are handled by Uniswap's PoolManager contract on each chain. Kosmo does not hold trader funds.
2. The fee hook. The hook sets the fee and enforces the opening limits. It runs inside every swap, so it cannot be bypassed by trading through another route.
3. The factory and locker. They deploy the token, place the liquidity and hold the position. The creator's fees are written at launch and cannot be changed afterwards.
4. The fee splitter. It divides the fee as set at launch. Every payment can be checked against the on-chain events.
5. The application. The website, the indexer and the analytics display this data. They are convenience layers, and the contracts remain the source of truth.

A creator relies on the same contracts and, in addition, on the metadata service, which stores the logo and links and accepts changes only when they are signed by the token's on-chain creator.

Audit. An independent audit of the contracts is pending. The report will be published here and in the documentation when it is complete.

10. Risks and roadmap

10.1 Risks

• Market risk. A token launched on Kosmo can lose all of its value. Locked liquidity does not support the price.
• Smart-contract risk. The contracts have been tested on every chain they run on. Like all software, they cannot be proven free of defects, and a flaw in any contract on which a trade depends could affect funds.
• Quote-asset risk. A token paired with another asset inherits that asset's risks, including a loss of its peg.
• Creator risk. The creator chooses the name, the supply and the fees, and may buy first. Read a token's fee settings and protections before trading it.
• Chain risk. Each chain has its own security and uptime. A fault on one chain affects only the tokens on that chain.
• Regulatory risk. Rules for tokens and for launching them differ by country and may change.

Nothing in this paper is financial, legal or tax advice.

10.2 Roadmap

References

1. Uniswap Labs. Uniswap v4 Core. github.com/Uniswap/v4-core
2. Adams, H., Zinsmeister, N., Salem, M., Keefer, R. and Robinson, D. Uniswap v3 Core. 2021. uniswap.org/whitepaper-v3.pdf