How Transmuter works

Overview

Most tokens die, and when they do their holders are left with nothing. There is no reserve to fall back on, no orderly wind-down, no floor under the collapse. Transmuter treats that ending as part of the design instead of ignoring it.

Transmuter is a launchpad with end of life infrastructure. Every token launched here carries a funded, non-custodial reserve from day one, and a contract defined path for what happens when the project ends: holders vote, the protocol liquidates, and everyone redeems their share of the EOL reserves.

The architecture is chain agnostic. The first deployment targets Solana; the design assumes nothing that ties it to one chain.

Token Types

Three token types make up the protocol. One is created at every launch, the project's own token; the other two, the contingency asset that backs it and the governance token that runs the system, are protocol wide and shared across every launch.

The Collateral Chain

Three layers, each backed by the next. A launched token's treasury holds cTokens. A cToken is a deflationary wrapper of a blue-chip asset (BTC, SOL) that burns supply on every trade, and it accumulates its own isolated reserve of tokenized gold as the last resort. Because its supply only ever shrinks, both backing ratios climb over time: each cToken comes to hold more of its underlying asset and more gold per token as it is traded, which is exactly what makes it an ideal EOL reserve asset.

If a project fails, its holders exit into cTokens. If a cToken's underlying asset (its base asset) ever fails, cToken holders exit into the gold reserve. Every point of failure is addressed.

Ratios & Verification

Two ratios with two different jobs. One counts what each token can claim from the reserve; the other evaluates live backing to drive the automatic mint trigger. Neither one sets a market price, and keeping them separate is what makes the system hard to manipulate.

The redemption ratio uses no prices at all, so no flash loan, pool manipulation, or market action can move it. It is not constant: it grows over time as trading fees flow into the treasury and supply burns, and because that growth tracks real trading volume it is not perfectly predictable in advance. What it never does is move off a price feed, it changes only from on-chain quantities. The backing ratio is the one that tracks market price, and it can open mint events but never sets the market price or the redemption ratio. Both are public reads; the dashboard shows them independently and together.

Launching a Token

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

Allocations

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

The Public Sale

Three sale types, no bonding curve, each chosen for what a launch needs most:

• Fixed price, for certainty. One known price, one known valuation. The simplest story, and the right tool when a creator wants a predictable raise.
• Reverse Dutch auction, for price discovery. The price opens high and decays toward a floor, and buyers clear at whatever price the market meets it. There is no fixed cheap entry for a sniper to grab, so real demand sets the clearing price. The creator sets the start price, the floor (which becomes the listing anchor), the decay step, and how often it steps down.
• Overflow pool, for demand led depth. The creator sets a fixed number of sale tokens and a target raise, and the pool simply collects funds. Price is an output, not an input: the final listing price is the total raised divided by the tokens sold, so the launch valuation is set by real demand rather than guessed in advance. Raise 66M against 10M tokens and it lists at $6.60; raise 100M and it lists at $10. This has the strongest potential to build deep liquidity and a large treasury. If the pool raises less than target the sale fails and everyone reclaims, because the target is what guarantees the escrow, treasury, and liquidity minimums. A mandatory 24 hour window, in which deposits close but withdrawals stay open, keeps a late whale from repricing everyone at the last moment, and an optional raise cap scales anything above it down pro rata to hold the valuation where the creator wants it.

All three seed the reserve before the token trades, and in every type buyers deposit the backing cToken, which makes each launch direct demand for the reserve asset itself.

Nobody sets the listing price. In all three sale types it falls out of the raise. If a sale offers half the supply and takes in 5M dollars, the whole supply is worth 10M dollars, and the listing price is that valuation divided by the token count. Because the pool is paired at exactly that price, the listing and the sale price are the same number by construction, and no buyer is handed an instant loss.

What the creator sets, and what follows from it. A creator chooses the escrow amount the team needs (which may be zero), how the token supply is split between the public sale, the liquidity pool, the team and the rest, and a total raise to target. Those choices decide the minimum raise between them, and each pushes it in a direction worth understanding:

• A larger escrow raises the minimum, because the sale has to fund it before anything else.
• A larger liquidity allocation raises the minimum, because more tokens have to be paired with cash.
• A smaller public sale also raises the minimum, and this one is less obvious. Selling less of the supply for the same money implies a higher price per token, so a higher valuation, so the pool's tokens cost more to pair.

From those inputs the protocol computes the rest: the price, the market cap, the cash that pairs the pool, and the treasury. The treasury is never chosen. It is whatever remains after the pool is paired and escrow is funded, and it may never land below 10% of market cap. A creator who wants a deeper treasury does not set a number, they raise more: at the minimum the treasury sits exactly on 10%, and it climbs from there with every extra dollar.

Redirecting overflow surplus. In an overflow sale, funds up to the target fund the launch exactly as designed: the liquidity pool takes the amount that pairs its tokens at the sale price, escrow takes the fixed amount the team asked for, and the treasury takes everything left. Beyond target, every dollar scales those same proportions, so the listing price keeps tracking what buyers actually paid and the treasury keeps its share of market cap automatically. Escrow is the exception. Its ask was a fixed number, so it has no claim on money raised above target: at least three quarters of the escrow's surplus share is always redirected (a protocol wide minimum, never touching escrow's target funding), and the creator may forego more.

Redirected escrow goes to the treasury, in full. There is no option to route it into the liquidity pool, and the reason is worth understanding. The pool's token count is fixed at launch, so adding cash without adding tokens prices each token higher: the same 2M tokens paired with 4M dollars instead of 2M lists at twice the price. That sounds like a stronger launch and is the opposite. It lowers the backing ratio, because the market cap grows while the reserves do not, and it hands a large share of the money to arbitrage traders, who sell into the inflated pool on the first day and drain its cash back down toward the price the sale cleared at. Cash sitting in a pool can be taken by whoever trades against it. Cash in the treasury cannot. The treasury route raises backing per token and leaves the listing price exactly where buyers set it. Because the 75% minimum is fixed protocol wide rather than set per creator, buyers know every overflow sale strengthens backing as it fills, which is exactly what makes overflowing one worth their while.

The 10% and 15% are minimums, and only the minimum is enforced. Raise above it and every extra dollar deepens the reserves: the pool takes the share that pairs its tokens at the sale price, and the treasury takes everything else. A creator who wants a more resilient token simply raises more, or sells more supply. Either way the reserves are seeded before the token trades.

Raise Protection

The reserve protects a holder's downside even if a team walks away. But the funds a project raises for development are a separate pot, and a team disappearing with that runway is one of the most common failures in the space. Transmuter closes that gap: development funds lock in a non-custodial escrow at launch and release to the team in vested tranches, enforced by contract. A team can fund real work but cannot take the runway in a single move.

Fees

A transfer fee applies to every trade, set by the creator between 0.40% and 2%, split four ways:

Two further creator options, both carved from the same transfer fee rather than stacked on top. An optional burn fee (0, or 0.05% to 1%) burns the token's own supply on every transfer, for creators who want their token deflationary by design. An optional creator fee (0, up to 0.5%) pays the creator a share of every trade, the same way the protocol takes its own cut; because it comes out of the adjustable part of the fee, a creator who takes it simply directs less to backing, and it is shown at launch so buyers see it up front. Reserve minting carries its own descending premium, described under Mint to Scale below.

Mint to Scale

If a token's backing thins, the protocol can rebuild it. One event type, two ways to open it. Every event prices the same way: a capped amount of new supply becomes mintable at the token's market price plus a premium, charged at the higher of a manipulation-resistant snapshot (a 6-hour time-averaged, dual-oracle read) or the live price, so a mint can never be cheaper than simply buying on the open market. The premium opens high, around 20%, and decays down to a 3% minimum, a descending auction that discovers a fair rate: buyers mint once it falls far enough to beat the market after slippage. Because every mint pays above market into the treasury, each one deposits more than the existing per token claim, so backing and the redemption ratio both rise, and the premium itself accrues to the reserve. Supply grows, but each token ends up better backed, never diluted.

Automatic path

If the backing ratio stays below the creator's activation threshold (set between 5% and 17%) continuously for 6 hours, an event opens by itself for up to a flat 15% of supply, snapshotted at open, with no vote and no creator action. It closes again once backing climbs back above a higher deactivation threshold (set between 20% and 35%). The gap between the two, always at least 10 points, is a deadband that stops the event flapping on and off around a single line. The 6-hour continuity requirement is the manipulation defense: no flash loan survives it, and that same 6-hour read prices the mint.

Governance path

Holders can vote an event open for strategic cases: an ambassador proposes a percentage between 5% and 15%, approval needs 55% of participating staked weight with a 3% quorum, and the vote runs for a creator set window of 24 to 48 hours. Because a Mint to Scale only ever adds fresh, fully backed supply and can never remove value from anyone, the token's holders decide it alone, with no DAO overturn.

End of Life

When a project is finished, holders end it on their terms instead of watching it bleed out.

1. Trouble gate. Liquidation cannot even be proposed unless the token shows real trouble: its price sits within 10% of its reserve value for a sustained stretch, its volume falls below 1% of market cap, or an escrow freeze has already passed. Either DAO body can also vote the gate open directly, so a token cannot be kept artificially "healthy" to block a needed wind-down. Opening the gate only permits a proposal; it decides nothing. This keeps anyone from proposing the death of an obviously healthy token. 2. Proposal. Once the gate is open, any holder of the token, or a council ambassador, can propose liquidation. 3. Vote. A 14-day vote of staked weight decides, needing a 67% supermajority with a 10% quorum, resolved only at the window's end. 4. DAO circuit breaker. The token's holders run this themselves; the DAO never has to approve them, and the DAO votes at the same time, in the same window, not afterwards. The protocol DAO community and the elected council each vote alongside the holders; the holder outcome stands unless both DAO bodies, each independently at 67%, land against it, cancelling a passed liquidation or carrying a failed one through. One body is never enough. This is what answers a hostile takeover: if someone buys up enough supply to vote down every liquidation and hold the token hostage, the two bodies together can still wind it down. Because liquidation only ever distributes the treasury pro-rata, even an override pays every holder their fair share and seizes nothing. A failed proposal cannot be re-raised for two weeks. Transmuter's founders also hold a cancel-only emergency veto, checked at execution, that can only stop a liquidation, never force one; it begins as a multi use precaution early in the protocol's life and is renounced one way only, stepping down to a single use per cycle and eventually to nothing as the DAO matures. 5. Execution. Anyone can then trigger it: pending fees settle, the protocol LP unwinds into cTokens for the treasury, minting closes forever, and the token enters its final state.

After liquidation, redemption stays open forever. Wallet balances and staked balances are untouched; every holder redeems against the full treasury at the final redemption ratio, whenever they choose.

The same logic exists one layer down: if a cToken's underlying asset suffers a verified, sustained collapse, the DAO can end that cToken's life, needing both the elected council and the DAO community at a 67% supermajority.

What a cToken end of life actually does, and why it is not an attack. It does exactly one thing: it adds a second redemption option. Before it, a cSOL holder redeems for SOL. After it, that holder redeems for SOL or for tokenized gold, their choice, one or the other on each redemption. The underlying redemption never closes. Nothing is seized, no balance changes, no supply is minted, and nobody is forced out of anything.

This is why triggering it falsely gains an attacker nothing. Suppose one were somehow passed against a perfectly healthy cSOL. The attacker's reward is the right to swap SOL they could already redeem for gold instead, at a price that is deliberately worse for them, while every other holder simply carries on redeeming SOL as before. There is no drain to perform, either: the gold reserve pays pro rata, so holding 5% of the supply is a claim on 5% of the reserve and nothing more. To reach all of it you would have to own every token, which means having bought out the entire market first. That is not an exploit, it is a purchase.

That layer is the chain's last resort, and it has no further fallback because it does not need one.

Governance

Transmuter runs on Mutually Assured Alignment. The model is built so that harming one party harms whoever tries it first, and acting in the protocol's interest becomes the same as acting in your own.

Everything consequential is opt-in: a change or action takes effect only when a vote actively approves it, never by default. The things put to a vote are always things that matter, so nothing meaningful happens to a token unless its holders decide it.

Authority sits in layers, none of them us. Token holders govern their own token: they decide changes to it, approve a Mint to Scale, and decide its end of life. The protocol DAO and its elected council of 7 to 100 (10 to 50 at genesis) are not rulers but guardians. Their power is deliberately narrow, to stand against a hostile takeover. For a token's end of life, the DAO can only override the holders when both bodies move together, each at 67%, never either alone. For changes at the protocol level, authority takes any two of three groups, the DAO community, the council, and the founders, so no single party can force a change or block one by sitting out; if any one group is ever captured, the other two can still keep the protocol moving. The DAO elects and can impeach the council. The layers check each other, so no single party, captured or hostile, can force an outcome the others would refuse.

Two forces keep it honest. Deterrence: anyone who votes for a harmful change is held through a short lock afterwards, so if it damages the token it damages them first. Incentives: the people who steer governance well earn a share of protocol fees, revocable by the community or the founders if they act in bad faith. Good stewardship is paid, bad faith is removed. And against an active attack there is a freeze: any two of the three groups can freeze a staked position that is being used to push a harmful vote, which stops it voting and unstaking without ever touching a wallet balance or a transfer. Frozen tokens are never seized or redistributed, so a mistaken freeze is fully reversible, but an attacker's capital can be trapped for as long as the attack lasts.

It is the same logic that secures a blockchain. No single validator can rewrite Solana, and taking over enough of them to try is too expensive to be worth it. Spread authority across many aligned parties and capture stops being a switch someone can flip; it becomes a cost almost nobody can pay.

There are no hidden admin keys. Treasuries move only through redemption and voted, on-chain execution. Two founder powers exist, and we would rather describe them plainly than let you find them in the code.

The first is a veto. It can only ever cancel a pending end of life or liquidation, never trigger or accelerate one, and it steps down one way as a community matures until it is gone.

The second is an emergency action, and it can push rather than only block. A protocol that sells itself as a safety layer cannot sit and wait for a week long vote while an exploit drains a contract, so this one executes the moment it is authorised. Early on, founders authorise it alone. After that authority sunsets, it needs the founders plus the council or the holders, and the council can clear it in minutes rather than days. What makes it safe is not a delay, it is what the power cannot reach: an emergency action can never move a treasury, mint a token, alter a balance, block a redemption, or force a liquidation. It can pause a contract and ship a fix. You can always redeem, even while a contract is paused. Every use is public on chain, any two of the three governing groups can reverse it afterwards, and the founders only phase ends automatically, at a deadline fixed in the contract before launch, or the moment the DAO proves it is alive, whichever comes first. We can also end it early, and never restart it.

We think that is the honest trade. The worst a founder can do with this power is halt a contract for a while, in public, and have the DAO undo it. There is no version of it that ends with your funds moved or new supply printed, because those actions are not in its reach.

Status

The protocol specification is complete and the first deployment is in development, targeting Solana, with independent audits and a public beta gating every release. Nothing ships unreviewed.

Questions, integrations, early access: team@themidasinitiative.com