Overview

Most tokens leave holders with nothing when they end. Transmuter writes the reserves, the governed runway and the end of life rules into the contract before launch, so what stands behind a token can be read on-chain at any moment and returned to holders if the project is finished.

Every token launched here carries a funded, non-custodial treasury from the first block and contract-owned liquidity it cannot lose. If the project ends, holders vote, the reserves are unwound, and every holder redeems their share.

Transmuter launches on Solana. An EVM specification already exists for expansion to other chains.

Token Types

Three token types make up the protocol. One is created at every launch; the other two are shared across every launch.

Reserve Assets

A cToken wraps a base asset. Its job is to let everything standing behind an EOL token read as one figure, and to make that figure grow.

What the cToken does

Each cToken holds its base asset in an isolated reserve. An EOL token's treasury holds cTokens, and a holder who redeems receives the base asset those cTokens represent.

The cToken's backing per token, counted in the base asset, never falls. Every operation that touches it either raises backing per token or leaves it unchanged:

• When a treasury mints cTokens, a fee is taken from what it deposits, and part of that fee stays in the reserve. Backing per cToken rises.
• When a holder redeems, cTokens burn and exactly their share of the reserve leaves. Backing per cToken is unchanged.
• Fee contributions from every EOL token built on it enter the reserve without creating any new cTokens. Backing per cToken rises.

Because the cToken is shared, every project built on it strengthens it. Each project's treasury is its own, and nothing is pooled or cross-collateralised. What is shared is the reserve layer underneath, so every project that ends here leaves the next one stronger.

Why a system token

A cToken is a record of reserves, not something to speculate on. If anyone could mint one, they could enter a reserve at the last moment and claim value that others spent years building. If it could be traded, its price could drift away from what actually backs it and be pushed around. So only an EOL token's own contract can mint one, straight into its own treasury, and once minted it cannot move. That closes both routes completely.

Two variants

A project chooses its cToken at launch. There are two kinds, and they are separate tokens, not settings on one token.

Gold is optional. A project picks one version or the other at launch.

The trade off is efficiency against an extra layer of safety. In the gold contingency variant, more than half of every fee bound for the reserve goes to gold rather than to the base asset. The base asset reserve therefore grows more slowly than it would in the pure variant. In return, holders have a fallback that does not depend on crypto markets at all.

A pure cToken puts every reserve-bound fee into its base asset, so it scales fastest, and it carries no second layer.

cGold is a pure cToken whose base asset is tokenised gold. Gold is its first and only reserve, and it is always redeemable, the same as SOL is for cSOL.

The gold

Gold in the contingency variant is a third-party tokenised gold asset on Solana, chosen for liquidity depth and issuer credibility. Issuing Transmuter's own tokenised gold is under consideration for a later stage.

In the contingency variant, gold belongs to the cToken, not to any EOL token. When an EOL token reaches end of life, its holders are paid in the base asset, and the gold stays behind the cToken for as long as the base asset holds. It is claimable only if the base asset itself fails, and only by reserves that were in place before that failure began, so nobody can enter late and claim gold that others built.

Ratios and Verification

Two ratios with two different jobs. Neither sets a market price, and keeping them separate is what makes the system hard to manipulate.

The redemption ratio uses no prices, so no flash loan, pool manipulation or market action can move it. It changes only when the treasury or supply actually changes, and it trends upward as fees accumulate.

Both ratios are public reads. Contract addresses will be published once deployed, and the dashboard will show both ratios for any token, including before you buy it.

Launching a Token

Launching is free and permissionless. The creator sets identity, supply, allocations, the cToken it launches against, fees and reserve parameters. After deployment, parameters are locked on-chain and the treasury is non-custodial: no one can move it, including the creator and including us.

Allocations

Vesting clocks for team and investors start at sale finalisation, not at deployment.

How the raise is sized

A creator sets three things: the escrow the team needs (which may be zero), how supply is split, and a total raise. The protocol computes everything else: the price, the market cap, the cash that pairs the pools, and the treasury.

The treasury is never chosen. It is whatever remains once the pools are paired and escrow is funded. The raise is sized so the treasury lands on 10% of market cap and the pools on at least 10%. A creator who wants a deeper treasury raises more.

The minimum raise is back-solved, not guessed: the smallest raise that pairs the pools, funds the escrow and leaves the treasury on 10%. Three choices push it up:

• A larger escrow, because the sale must fund it first.
• A larger liquidity allocation, because more tokens must be paired with cash.
• A smaller public sale, which is less obvious. Selling less of the supply for the same money implies a higher price per token, so the pool's tokens cost more to pair.

Converting the raise into reserves costs a little: swapping USDC into SOL, and the cToken mint premium. So that those costs can never void a sound launch, a launch is accepted with the treasury at 8% or more of market cap, and treasury plus the cash in the pools at 18% or more. Both are checked before anything moves. A launch below either does not happen, and every deposit stays reclaimable.

The Public Sale

Sales are raised in USDC. There are three sale types.

• Fixed price, for certainty. One known price, one known valuation.
• Reverse Dutch auction, for price discovery. The price opens high and decays toward a minimum the creator sets, so real demand sets the clearing price and there is no cheap entry for a sniper.
• Overflow pool, for demand-led depth. The creator sets the tokens on offer and a target raise. Price is an output: the listing price is the total raised divided by the tokens sold.

Nobody sets the listing price. It falls out of the raise, and because the pools are paired at exactly that price, the listing and the sale price are the same number. No buyer is handed an instant loss.

Overflow surplus. Above target, the pools and treasury scale in the same proportions, so the listing price keeps tracking what buyers paid. Escrow is the exception: its ask was a fixed number, so at least three quarters of its share of any surplus is redirected to the treasury, and the creator may forego more. It is never routed into the pools, because cash added to a pool without tokens raises the price rather than the backing, and arbitrage takes it straight back out.

Escrow

The treasury protects holders if a team walks away. The funds a project raises for development are a separate pot, and a team disappearing with its runway is one of the most common failures in the space. Transmuter closes that gap.

Escrow is optional. A project that needs no runway can launch without one, and then every dollar raised above the pool pairing goes to the treasury.

There is no vote that can pull escrow out and move it anywhere else. A power like that would reward sabotaging a working project to reach its money. Halting releases hurts a team that is not delivering without paying anyone to cause it.

Why it matters: a team that raises money for development and refuses to hold it in escrow is the case this filter exists for. A team that needs no runway launches without one.

Fees

The transfer fee

Every trade pays a transfer fee, set by the creator between 0.5% and 2%. Going above 1% is not recommended; the upper range exists for experimental products. The total cannot be set below 0.5%. Amounts above the fixed and minimum portions are split by the creator between liquidity and the treasury. 0.60% is the recommended default.

Two optional creator settings are carved from the same fee rather than stacked on top: a burn fee (0, or 0.05% to 1%) that makes the token deflationary, and a creator fee (0, up to 0.5%). Both are shown before launch.

The full fee a holder pays is the creator-set total, 0.5% to 2%. The 0.15% is Transmuter's share inside it.

What Transmuter earns

Protocol governance can move fees only within bounds set before launch.

Redemption

Holders can redeem at any time. An ordinary redemption, while the project is running, pays a 0.50% fee: 0.15% to the protocol, and 0.35% that stays in the treasury, raising the redemption ratio for everyone who remains. After end of life, redemption is free.

Reserve conversion

When a treasury converts its proceeds into cTokens, a fee is taken from those proceeds.

The minimum raise already includes this cost, so it cannot void a launch.

End of life

When a project ends, a fee of 1.25% is charged on its treasury: 0.25% to Transmuter and 1.00% added to the cToken's own reserve, in its base asset for a pure cToken or in gold for one with a contingency. It is never charged on the USDC escrow.

This is a real cost to the project that ends. It is also how the reserve layer is built for the projects that come after: nobody pays for access to it up front, and each project protected by it on the way through adds to it on the way out.

For launch platforms using Transmuter's infrastructure, these figures are Transmuter's own. A platform can add its own fee on top.

Mint to Scale

If a token's backing thins, the protocol can rebuild it by selling new supply into the treasury.

A buyer pays in SOL. The SOL enters the cToken's reserve, cSOL is minted into that EOL token's treasury, and the buyer receives EOL tokens. Every event is priced at the higher of a manipulation-resistant snapshot (a 6-hour time-averaged, dual-oracle read) and the live price, plus a premium that can open as high as 100% and descends to a 5% minimum.

Why it raises backing

A mint raises backing per token, counted in the base asset, whenever the sale brings in more of that asset than the quantity already behind each token. Every new token sold takes only an equal share of the reserve, the same as every other token. So each sale lifts backing per token for everyone, holders and new buyers alike.

This does not happen in one go. Backing climbs with every sale through an event, and keeps climbing across later events, for as long as the price paid stays above what each token is backed by.

The premium is not what makes this work. It does two other jobs:

• Price discovery. Buying the same amount on the open market would cost far more in slippage than the premium. A buyer who wants size pays close to fair value, and the money lands in the treasury instead of the pool.
• No sniping. A mint can never be cheaper than buying on the market.

The protocol's share of each mint

Part of every mint can go into the token's contract-owned liquidity instead of to the buyer. It is set between 0% and 15%, with around 10% the recommended setting.

At 10%, for every nine tokens sold to buyers, the protocol mints one more for itself. It pays the same price for it, which becomes that token's backing in the treasury, and it pairs the token with cash from the sale in the pools. So out of the sale proceeds, one tenth of the mint's value pays for the protocol's tokens and stays in the treasury, and another tenth leaves to pair them.

What it buys is depth. Every mint deepens the pools as well as the treasury, and each one pairs into pools the previous mints already deepened, so the effect compounds. A token that has run hard and minted into that strength is much harder to sink afterwards, because the pools absorb selling far better. That also offsets the one real downside of Mint to Scale: while a mint is open, buyers who mint are not buying on the open market.

What it costs is small. At the end, the pools' tokens burn and their cash joins the reserves, so at an unchanged price the two routes pay holders exactly the same. The only difference comes from the price moving afterwards: if a token ends above the price it minted at, routing to the pools pays holders slightly more, and if it ends below, slightly less, because cash held in a pool moves with the price and cash in the treasury does not.

Automatic path

If the backing ratio stays below the creator's activation threshold (5% to 17%) continuously for 6 hours, an event opens by itself for up to 15% of supply, with no vote. It closes once backing climbs back above a higher deactivation threshold (20% to 35%), or once its allocation has been fully minted. The gap between the two thresholds is always at least 10 points, so the event cannot flap on and off. No flash loan survives six hours.

Governance path

Holders can vote an event open: an ambassador proposes 5% to 15% of supply, approval needs 55% of participating staked weight with a 3% quorum, and the vote runs for 24 to 48 hours. A token's holders decide this alone. If a token has run hard and its holders want to scale its backing, that is their call.

What Happens When a Project Stops

This section is for holders.

What you receive

You do not file a claim. Every holder receives the same share of the reserves per token held, whenever they choose to redeem, and that option stays open forever.

What you receive is made of three things:

• Your share of the treasury, paid in the base asset, such as SOL.
• Your share of the pools' cash side. When the project ends, both pools unwind, their cash is converted into the treasury, and their tokens burn.
• Your share of any unspent escrow, converted into the reserve asset, joined to the treasury, and redeemed with it.

Why the figure is higher than the treasury alone

At the end, two things shrink the number of tokens sharing the reserves:

• The pools' own tokens burn. They held a large share of supply, and none of it claims anything.
• Any unvested team allocation burns. Investor allocations do not.

So the reserves are divided between fewer tokens than circulated while the project was live.

Live and end of life redemption

These are two different figures, and the dashboard shows both.

The gap between them is usually large. Most of what a holder is owed sits behind the end of life figure.

What price you are paid at

An end of life does not happen at whatever the market price was when the vote passed. Once redemption opens, anyone can buy below it and redeem for a profit, or sell above it. The market price converges on the redemption value, and every holder is paid from there. Where the price sits when the vote passes changes how far it travels, not where it lands.

How long it takes

About two months from vote to payout. You can see the figure you would receive before any of it begins.

What this does not do

End of life returns what the reserves hold at the end. It is not reimbursement of what anyone paid for the token.

End of Life

When a project is finished, its holders end it on their terms.

1. Proposal. An end of life can be proposed only when at least two parties agree, and at least one of them is the token's creator or the token's holders. The creator and the holders together also qualify.

The other three, Transmuter, the DAO council and the DAO's holders, act as verification. Any of them can be the second party, but none of them, even all three together, can open an end of life without the creator or the holders.

Holders are not required, so a token cannot get stuck just because its holders never act. No single party can open one, and no single party can block one: if the creator refuses, the holders and a verifier can proceed, and the other way round.

2. Vote. A 14-day vote of staked weight decides, needing a 67% supermajority with a 10% quorum, resolved at the end of the window.

3. DAO circuit breaker. The DAO votes at the same time, not afterwards. The holder outcome stands unless both DAO bodies, each independently at 67%, land against it. One body is never enough. This is what answers a hostile takeover: if someone buys enough supply to hold a token hostage, the two bodies together can still end it. Because holders redeem pro rata, even an override pays every holder their fair share and seizes nothing.

Transmuter's founders hold a cancel-only veto, checked at execution. It can stop an end of life, and cannot force one. It also runs against the founders' own interest: Transmuter earns a share of the end of life fee, so using the veto costs them.

4. Execution. Anyone can trigger it. Pending fees settle, any unvested team allocation burns, both pools unwind, their tokens burn and their cash is converted into the treasury, the end of life fee is charged, and minting closes forever.

After that, redemption stays open forever, free of fees, at the final redemption ratio.

cToken end of life

A pure cToken has no end of life, because there is nothing to add: its holders can always redeem the base asset.

A cToken with a gold contingency has one, and it does exactly one thing: if the base asset suffers a verified, sustained collapse, both DAO bodies at a 67% supermajority, with a quorum of 10% of circulating supply, can open the gold. That adds a second way to redeem. Before it, a holder redeems for the base asset. After it, they can choose the base asset or gold. The base asset redemption never closes, nothing is seized, and no balance changes.

Triggering it falsely gains an attacker nothing. Their reward would be the right to swap an asset they could already redeem for gold, at a rate deliberately worse for them, while everyone else carries on as before. The gold pays pro rata, so reaching all of it would mean owning every token, which is not an exploit but a purchase.

For Launch Platforms

Transmuter is infrastructure first; the launchpad is one way to use it. Other platforms can run their launches on it and give their tokens the same reserves, escrow and end of life.

A platform keeps its own users and its own launches, and can add its own fee on top. Transmuter's share stays the same everywhere: 0.15% on transfers and redemptions, 0.25% on mints and at end of life.

Every launch on the infrastructure is built on Transmuter's cTokens, so every one strengthens the reserve layer beneath all the others.

Governance

The current design is described in the docs and is being revised.

Transmuter runs on Mutually Assured Alignment. Harming the protocol harms whoever tries it first, so acting in its interest becomes the same as acting in your own.

Everything consequential is opt-in: nothing meaningful happens to a token unless a vote actively approves it.

Who decides what.

• Token holders govern their own token: its settings, its Mint to Scale events and its end of life.
• The protocol DAO and its elected council of 7 to 100 (10 to 50 at genesis) are guardians, not rulers. Their power is deliberately narrow: to stand against a hostile takeover. On a token's end of life they can only override holders when both bodies act together.
• Protocol level changes need any two of three groups: the DAO community, the council and the founders. No single party can force a change or block one by sitting out.

What can change after launch, and what cannot.

• The escrow schedule cannot be rewritten by anyone. Holders can halt it and advance one tranche.
• Fees can move through governance, only within bounds set before launch.
• The treasury moves only through redemption and end of life.

Deterrence and incentives. Anyone who votes for a harmful change is held through a short lock afterwards, so if it damages the token it damages them first. People who steer governance well earn a share of protocol fees, revocable if they act in bad faith. Any two of the three governing groups can freeze a staked position being used to push a harmful vote. A freeze stops it voting and unstaking, never touches a wallet balance, and is fully reversible.

No hidden admin keys. Two founder powers exist, and we would rather describe them than have you find them in the code.

The first is the cancel-only veto described above.

The second is an emergency action, for when an exploit is live and a week-long vote would be too slow. Early on, the founders can authorise it alone; after that it needs the founders plus the council or the holders. It can pause a contract and ship a fix. It can never move a treasury, mint a token, alter a balance, block a redemption or force an end of life. You can always redeem, even while a contract is paused. Every use is public, any two of the three groups can reverse it, and the founders' sole authority ends automatically at a deadline fixed before launch, or as soon as the DAO proves it is active.

The worst a founder can do with it is halt a contract for a while, in public, and have the DAO undo it.

Status

The protocol specification is complete and the first deployment is in development on Solana.

• Audit: independent, one to two months before launch, currently targeted for Q1 to Q2 2027.
• Contract addresses: published once deployed.
• Dashboard: in development. It will show the reserves, both ratios and both redemption figures for any token, including before you buy it.
• End of life calculator: in development.
• Other chains: an EVM specification exists, for expansion once the Solana deployment is established.

Nothing ships unreviewed.

Questions, integrations, beta testing: info@transmuter.net