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 = 80,000,000,000 / origin supply

Every caper mints a notional 100 billion tokens across its bonding curve. A full migration – every last origin token moving across – is sized to fill 80% of that curve, not all of it. The remaining 20 billion stay unminted, so there is still curve left for buyers who arrive after the migration, and circulation stays clear of the point where the curve's price integral divides by zero.

Worked example. An origin token with a supply of 1,000,000 gives a rate of 80,000 caper tokens per origin token. A holder of 10,000 – one per cent of the origin supply – receives 800,000,000 caper tokens, which is one per cent of the migrated block and 0.8% of the curve's full cap. Proportions inside the community are preserved exactly; what changes is that the community now sits alongside curve headroom it can sell into.

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.

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.

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 participation, and participation starts at nothing. A holder who migrates a large balance and never votes carries almost no weight, and because exit pays the same weight, they claim almost none of the treasury either. An origin-token whale does not arrive holding the new organization; they arrive holding a stake that only counts once they use it. For a community migrating together, that is the substantive change: influence stops being a function of who bought most and starts being a function of who shows up.

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 80,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 read-only MCP servers.