A caper can be launched on top of a token that already exists, and that token's holders can swap into the new caper token at a fixed rate set at launch. Caper calls this a vampire caper, and it is the Vampire migration tab on Create a caper. Anyone holding the origin token can migrate at any time, without asking permission and without paying a fee. The origin tokens they hand over are locked away permanently, and what they receive is an ordinary caper token, indistinguishable on-ledger from one bought off the curve.
A caper bound at launch to one existing fungible token, its origin token. The founder names the origin token's resource address in the launch transaction, and the binding cannot be added, changed or removed afterwards: a caper launched without one is a standard caper for good, and one launched with it stays a vampire caper.
A plain token has holders, a price and nothing else. A caper gives the same holders a treasury they own, a proposal system that spends it, and an exit that pays out a share of it. Migration moves a community from the first to the second: it keeps its distribution and arrives with governance attached.
Only one caper can absorb a given token. The registry records the origin token when the first vampire caper names it and refuses every later launch that names it again, so two capers cannot compete for the same community.
A fixed rate, set once at launch from the origin token's total supply and stored on the caper, where anyone can read it. The rate maps the whole origin supply onto everything the caper's curve can issue, so if every origin token migrates, the community holds the whole curve, in the same proportions it held the origin token.
The supply is read from the ledger once, in the launch transaction. Later changes to the origin token cannot move the rate, which is why the rate means most for an origin token whose supply is fixed.
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. In effect the tokens are burned, but they stay visible on-ledger instead of being 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 ways out are the ones every caper token has: sell it back to the curve, or exit with a share of the treasury once you have voted. Neither returns the origin token.
The contract also checks that what you deposit is the resource the caper was bound to. A different token, however similar, is refused.
No. Migration takes no payment, so there is no fee and no skim, and nothing goes to the founder, a treasury or the protocol. A holder pays only the Radix network fee for the transaction, as for any other on-ledger action.
The founder pays the ordinary registration fee once, when the caper is launched, priced by the cashtag's length as set out in Getting started, and nothing further for migrations.
Because migrated tokens arrive without anyone paying $XRD for them. On a standard caper every token in circulation was bought, so the reserve, the $XRD that sales back to the curve are paid out of, grows with supply. A migration adds tokens to circulation and nothing to the reserve, so a vampire caper starts with a large circulating supply and a reserve short of what that supply would have paid in.
Later buys close the gap. While the reserve is short, part of each buy goes into the reserve instead of minting tokens; the part is larger the wider the gap, and it shrinks as the gap closes, so the reserve fills faster as it goes. Every buy still mints some tokens and still moves the price.
From the buyer's side, an early buy into an unfunded vampire caper gets fewer tokens than the same payment would on a fully backed caper, because part of it is refilling the reserve. The buy transaction the site builds carries a minimum-output floor taken from the quote, and aborts if the mint comes in under it. An early buyer is underwriting the reserve that later sales are paid from, and the holders best placed to sell into it are the migrators, who paid nothing to arrive.
For a migrating holder: early sales are paid from a reserve that has not filled yet, and the caper is fully backed only once buyers have put in what the migration skipped. A community that migrates and then buys is funding its own curve; one that migrates and sells at once is selling into a reserve it never funded.
Then the curve has no room left to mint into, so buys cannot refill the reserve, and the reserve starts empty, so a sale fails as soon as it needs more $XRD than the reserve holds.
Anyone can fix this by donating $XRD to the caper's reserve. A donation mints nothing and gives the donor no tokens, no vote record and no claim on what they gave, and it cannot be withdrawn. It can be made on the caper's own component as well as through the platform, so it works even if the upgradable platform logic does not. A community planning to migrate in full should plan to fund the reserve as part of the same exercise.
The same token, with one thing that has to be earned. A migrated token can be sold, used to raise a proposal or handed in at exit, like any other.
Vote weight, however, is earned by voting, and migrating earns none. Neither does buying or selling; casting a ballot does. A holder who migrates and never votes carries no weight, and since the exit needs the same vote record, they have no treasury share to take either, only the curve's price for their tokens.
So an origin-token whale arrives with a stake that starts to count the first time they vote, and buying more of the token does not change that. For a community migrating together, influence follows who takes part after the launch rather than who held most before it.
Before committing, tell the community the two hard facts: the escrow is permanent, and the reserve behind the new token starts empty and fills from later buys.
What is a caper covers the model itself. Bonding curve explains the pricing a migrated supply lands on, and Raising funds covers the skim and who it pays. An AI agent can read a caper through the MCP surface in Querying a caper from an AI agent, and launch one headlessly as Build on Caper as an agent describes: a vampire launch is the optional originToken field on create-caper.