Yes – a caper can be launched on top of a token that already exists, and its holders can swap into the new one at a fixed, published rate. Caper calls this a vampire caper, and it is the second tab on Create a caper. You name the origin token's resource address when you launch; from that moment anyone holding the origin token can migrate, at any time, without asking permission and without paying a fee. What they hand over is locked away permanently, and what they receive is an ordinary caper token with the same treasury claim, voting weight and exit right as one bought off the curve.

What is a vampire caper?

A caper bound at birth to one existing fungible token. The binding is a single argument on the launch transaction – the origin token's resource address – and it cannot be added, changed or removed afterwards. A caper launched without it is a standard caper forever, and a caper launched with it is a vampire caper forever.

The purpose is to give an existing community a way to acquire the things it does not have. A plain token has holders, a price and nothing else. A caper wraps the same holder base in a treasury they own, a proposal system that spends it, and an exit that pays out a share of it. Migration is the bridge between the two: the community keeps its distribution and arrives with governance already attached.

Only one caper can ever absorb a given token. The registry records the origin token when the first vampire caper claims it and rejects every later attempt, so a token cannot be the subject of two competing migrations.

What exchange rate do holders get?

A fixed ratio, set once at launch from the origin token's total supply:

rate = 100,000,000,000 / origin supply

Every caper mints a notional 100 billion tokens across its bonding curve, and the ratio maps the origin supply onto the whole of it – curve_cap / origin_supply, computed once in CaperDao::new (contracts/core/src/caper_dao.rs). A full migration – every last origin token moving across – therefore lands circulation at the very top of the curve rather than part-way up it.

This changed on 29 August 2026, and it is worth knowing which side of the change you are reading. Until then a MIGRATION_CEILING held the ratio at 80% of the cap, leaving 20 billion tokens of headroom for buyers arriving after a migration and keeping circulation clear of the point where the curve's price integral divides by zero. The ceiling is gone; the bonding curve's own clamp was tightened instead, so the singularity is handled in the arithmetic rather than by holding a fifth of every vampire's supply back from the community it was minted for.

Worked example. An origin token with a supply of 1,000,000 gives a rate of 100,000 caper tokens per origin token. A holder of 10,000 – one per cent of the origin supply – receives 1,000,000,000 caper tokens, one per cent of the curve's full cap. Proportions inside the community are preserved exactly. What has changed is the other half of that sentence: after a full migration there is no unsold curve to sell into, because there is none left.

The supply is read from the ledger once, in the launch transaction, and stored. Later changes to the origin token cannot move the rate, which is why the origin token must be fixed-supply for the number to mean anything.

Which tokens qualify as an origin token?

• Fungible. The migration path takes a fungible bucket; non-fungibles cannot be an origin token.
• Total supply tracked on-ledger. The launch reads the origin token's total supply and aborts if the resource does not publish one. On Radix this is a flag set when the resource is created and it cannot be turned on afterwards – XRD itself does not qualify.
• Positive supply. A supply of zero is rejected, since the rate would divide by it.
• Not already claimed. No earlier vampire caper may have named the same token.
• Fixed supply in practice. Nothing in the contract forbids a mintable origin token, but the rate is frozen at launch, so any later minting quietly dilutes the migration for everyone who has not yet crossed.

What happens to the tokens I hand over?

They go into the caper's migration vault and stay there. The contract has no method that takes anything out of that vault – not for the founder, not for a passing proposal, not for the holder who deposited them. The escrow is a burn in every sense that matters, with the deposited tokens left visible on-ledger rather than destroyed.

Migration is therefore one-way and final. There is no unwind, no cooling-off period and no route back to the origin token. The exit that does exist is caper's ordinary one: sell the caper token back to the curve, or hand back tokens and vote record together and take a treasury share. Both pay in XRD, neither returns the origin token.

The contract also checks that what you deposit is exactly the resource the caper was bound to. A different token, however similar, is rejected outright.

Does migrating cost anything?

No. Migration takes no payment argument at all, so there is no registration fee, no trade fee and no share taken by the founder or the protocol. A holder pays only the Radix network fee for the transaction, the same as any other on-ledger action.

The founder pays the ordinary registration fee once when the caper is launched – priced by cashtag length, as set out in Getting started – and nothing further for migrations.

Why is a freshly migrated caper's reserve empty?

Because migration mints tokens without anyone paying XRD for them. On a standard caper every token in circulation was bought, so the reserve grows in step with supply and the curve is fully backed at all times. A migration advances circulation on its own, which leaves the reserve holding less XRD than that level of circulation implies. This is the structural trade of a vampire launch and it is visible from the first block: a large circulating supply behind a reserve that starts at zero.

The gap closes out of later buys rather than out of anyone's pocket. When someone buys into a vampire caper whose reserve is short, part of their payment is diverted into the reserve without advancing the curve, and only the remainder mints new tokens. The diverted share tracks how large the shortfall is, and it is capped below the whole payment – at most 90% – so every buy still mints something and the price still moves. As buys accumulate the shortfall shrinks and the diverted share falls with it, which means healing accelerates rather than dragging on.

That cap is a floor under the mint, not a ceiling on the price, and read from the buyer's side it is the worst case rather than the reassurance. Where the shortfall is large enough to bind it, nine tenths of a buyer's payment goes into the reserve and one tenth advances the curve – so the buyer receives the tokens that one tenth of their money would have bought on a fully backed caper at the same circulation. The contract does not measure that against a quote: the buy path takes a payment bucket and asserts only that the mint came out greater than zero. The site's buy manifest adds an on-chain minimum-output floor when the caller supplies a slippage tolerance, and that assertion is the only thing between a buyer and that price. Buying early into an unfunded vampire is an act of underwriting and should be priced as one, because the XRD is what later sell-backs are paid out of and the holders best placed to take it are the migrators, who paid nothing to arrive.

The practical reading for a migrating holder: early sell-backs are quoted against a reserve that has not yet been filled, and the caper becomes fully backed only once buyers have put in what the migration skipped. A community that migrates and then buys is underwriting its own curve; one that migrates and immediately sells is selling into a reserve it never funded.

What happens if everyone migrates?

A full migration is the case the healing-through-buys account above does not cover, and it is worth stating plainly rather than leaving to be inferred. Since the ratio maps the origin supply onto the whole cap, a community that all crosses lands the caper at s = 1 with a reserve of zero – and at that point the curve is shut in both directions. Buys have no headroom left to mint into, so the vampire backfill that would otherwise seed the reserve can never run; sells are paid out of a reserve that sell_apply checks before paying, so the first sell large enough to price above the clamp reverts on Insufficient Curve Liquidity and keeps reverting.

The way out is a method that exists for exactly this: donate_collateral is public on every caper but the root $XRD one, takes XRD, and puts it straight into the curve reserve – minting nothing, moving circulation not at all, and granting the donor no tokens, no vote record and no claim on what they put in. Anyone may call it, and it is deliberately callable on the caper's own component as well as through the platform logic, so un-bricking a curve does not depend on the swappable tier being healthy. Donations are one-way by design: there is no matching withdrawal. A community planning to migrate wholesale should plan to collateralize as part of the same exercise.

Do migrated holders get the same rights?

The same, with one thing that has to be earned. A migrated token is the caper's ordinary token – indistinguishable on-ledger from one bought off the curve – so it can be sold, used to raise a proposal, or handed back at exit.

Voting weight, however, is the product of stake and an earned record, and migration alone earns none of it. migrate takes no payment and mints no vote token, and since the redeploy of 11 September 2026 neither does a buy or a sell – a ranked ballot mints 1 and nothing else a member can do mints anything. So a holder who migrates and then does not vote carries no weight at all – the weight formula is multiplicative, so a zero record zeroes the product – and because exit pays that same weight, and asserts a non-empty vote-token bucket before it pays anything, they have no exit to take rather than a small one. An origin-token whale does not arrive holding the new organization; they arrive holding a stake that starts counting the first time they cast a ballot, and buying more of the token does not shorten that wait. For a community migrating together, that is the substantive change: influence stops being a function of who held most before the launch and starts being a function of who does something with it afterwards.

How do I launch a vampire caper?

1. Open Create a caper and choose the Vampire migration tab before filling anything else in.
2. Paste the origin token's Radix resource address. Check first that it is fungible and publishes a total supply, since the launch aborts otherwise.
3. Fill in the name, description and cashtag as for any launch, and pay the registration fee that the cashtag's length sets.
4. Publish the rate to your holders. It is 100,000,000,000 / origin supply and it will not change.
5. Holders migrate whenever they choose. Nothing expires, and no one is forced across.

Before committing, be clear with the community about the two hard facts: the escrow is permanent, and the reserve behind the new token starts empty and fills from later buys.

Where next

What is a caper covers the model itself. Bonding curve explains the pricing a migrated supply lands on, and Raising funds covers the founder's reward and the fee legs. If you are reading this through an AI agent, Querying a caper from an AI agent documents the MCP read surface, and Build on Caper as an agent covers launching one headlessly – a vampire launch is the optional originToken parameter on the create-caper manifest, so an agent can bind the origin token without opening the browser tab.