Topic Launching · vampire capers Set at GenesisLaunch only – a caper cannot adopt an origin token later Rate 100,000,000,000 / origin supply caper tokens per origin tokenFixed at launch from the origin token's total supply, and never changes Cost to migrate None beyond … network fee Reversible No – escrow is one-waymigrated tokens stay in escrow for good Related Getting started (/w… (/wiki/markets/bonding-curve)

Yes – aA caper can be launched on top …oken that already exists, and ithat token's holders can swap into the new one at a fixed, published ratecaper token at a fixed rate set at launch. Caper calls this a vampire caper, and it is the secVampire migrationd tab on Create a caper (/create-caper) . You name the origin token's resource address when you launch; from that moment aAnyone holding the origin token can migrate, at any time, without asking p…ion and without paying a fee. WhatThe origin tokens they hand over isare locked away permanently, and …ive is an ordinary caper token with the same treasury claim, voting weight and exit right as, indistinguishable on-ledger from one bought off the curve.

What is a vampire caper? A caper bound at birtlaunch to one existing fungible token. The binding is a single argument on the launch transaction – the origin token's resource address – and it, 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: a caper launched without itone is a standard caper forever good, and a caperone launched with it istays 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 p…ice and nothing else. A caper wrapgives the same holder base ins a treasury they own, a propos… out a share of it. Migration is the bridge between the two: the communmoves a community from the first to the second: ity keeps its distribution and arrives with governance already attached. Only one caper can ever absorb a given token. The regi… when the first vampire caper claimnames it and rejectfuses every later attempt, so a token cannot be the subject of two competing migrationslaunch that names it again, so two capers cannot compete for the same community.

What exchange rate do holders get? A fixed ratioe, 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 t and stored on the caper, where anyone can read it. The ratioe maps the origin supply onto the whole of it – curve_cap /whole 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 (/wiki/markets/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 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 …nce, in the launch transaction, and stored. Later changes to the origin …ve the rate, which is why the origin token must be fixed-supply for the number to mean anythingrate means most for an origin token whose supply is fixed.

Which tokens qualify as an origin token? - Fungible. The mMigration path takes a fungible bucket;tokens; a non-fungibles cannot be an origin token. - …orts if the resource does not publishtrack one. On Radix thisat is a flag set when thea 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. - A supply above zero. A token with no supply is refused. - Not already claimed. No ea…hing in the contract forbids a mintablen origin token that can still be minted, but the rate is frozen at la…rate and compete for the same 100 billion, so once circulation reaches the cap the contract refusesroom on the curve, so once the curve is full the holders still waiting to cross are refused.

What happens to the tokens I h…kes anything out of that vault –: not for the founder, not for …he holder who deposited them. The escrow iIn effect the tokens are burn in every sense that matters, with the deposited tokens lefted, but they stay visible on-ledger rather thaninstead of being destroyed. Migration is there…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, nways out are the ones every caper token has: sell it back to the curve, or exit (/wiki/foundations/leaving-a-caper) with a share of the treasury once you have voted. Neither returns the origin toke…ecks that what you deposit is exactly the resource the caper was bou… token, however similar, is rejected outrightfused.

Does migrating cost anything? No. Migration takes no payment argument at all, so there is no registration fee and no skim, and nothing g…work fee for the transaction, the same asas for any other on-ledger action. T…ordinary registration fee once, when the caper is launched –, priced by the cashtag's length, as set out in Getting starte…/foundations/getting-started) –, and nothing further for migrations.

Why is a freshly migrated cape… reserve empty? Because migration mints tokensed tokens arrive without anyone paying $XRD for them. On a standard ca…ion was bought, so the reserve grows in step with supply and the curve is fully backed at all times, the $XRD that sales back to the curve are paid out of, grows with supply. A migration advancesds tokens to 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:and nothing to the reserve, so a vampire caper starts with a large circulating supply behiand 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. Tshort 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's buy manifest adds an on-chain minimum-output floor when the caller supplies a slippage tolerance, and that assertionilds carries a minimum-output floor taken from the quote, and aborts isf 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 wmint comes in under it. An early buyer is underwriting the reserve that later sell-backales are paid out offrom, and the holders best placed to takesell into it are the migrators, who paid nothing to arrive. The practical reading fFor a migrating holder: early sell-backs are quoted againstales are paid from a reserve that has not yet been filled yet, and the caper becomeis fully backed only once buyer…hat migrates and then buys is funderwriting its own curve; one that migrates and immediately sellssells at once is selling into a reserve it …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 exactlyThen 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 donate_collateral is public on every caper, takes XRD, and puts it straight ining $XRD to the curveaper's reserve – minting nothing, moving circulation not at all, and granting. A donation mints nothing and gives the donor no tokens, no vote …ord and no claim on what they put in. Anyone may call it, and it is deliberately callablgave, and it cannot be withdrawn. It can be made on the caper's own component…s 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, so it works even if the upgradable platform logic doesign: there is no matching withdrawal not. A community planning to migrate wholesalein full should plan to collateralizfund the reserve as part of the same exercise.

Do migrated holders get the same rights? The same token, 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 … (/wiki/governance/proposals) , or handed backin at exit, like any other. Votinge weight (/wiki/governance/voting) , however, is the product of stake and an earned recordearned by voting, and migration aloneng earns none of it. migrate takes no payment and mints no vote token, and since the redeploy of 11 September 2026 n. Neither does a buying or a sell – a ranked ballot mints 1 and nothing else a member can do mints anything. So aing; casting a ballot does. A holder who migrates and then does notnever votes carries no weight, at all – the weight formula is multiplicative, so a zero record zeroes the product – and because exit pays that samnd since the exit needs the same vote record, they have no treasury share to take 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 holdingther, only the curve's price for their tokens. So an origin-token whale arrives with a stake that starts to counting the first time they cast a ballvote, and buying more of the token does not shorten that waichange that. 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 afterwardsinfluence follows who takes part after the launch rather than who held most before it.

How do I launch a vampire cape…first that it is fungible and publishes atracks its total supply, since the launc… and pay the registration fee that the cashtag's length sets. - Publish the rate to your holders. It is 100,000,000,000 / origin supplyTell your holders the rate. It is fixed at launch and it will not change. - Holders mig…ross, but the room is finite: the curve cap counts every caper token in circulation, bought or migrated, and a migration that would take circulation past 100 billion aborts on Migration exceeds curve cap (contracts/core/src/caper_dao.rs)migrated and bought tokens share everything the curve can issue, and a migration that would go past it aborts. Every token bought off the curve before the community has cross…s refused. Before committing, be clear withtell the community about the two hard facts: the escrow…pty and fills from later buys.

Where next What is a caper (/…ers the skim and who it pays. If you are reading this through an AI agent,An AI agent can read a caper through the MCP surface in Querying a caper from an AI …ing-a-caper-from-an-ai-agent) documents the MCP read surface, and, and launch one headlessly as Build on Caper as an agent (…/build-on-caper-as-an-agent) covers launching one headlessly –describes: 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 tabfield on create-caper.

Why is a freshly migrated cape…caper at the same circulation.The contract does not measure … as part of the same exercise.

Do migrated holders get the sa… take rather than a small one.An origin-token whale does not… something with it afterwards.

Which tokens qualify as an ori…t the rate is frozen at launch, so any later minting quietly dilutes the migration for everyone who has not yet. Tokens minted later convert at the same rate and compete for the same 100 billion, so once circulation reaches the cap the contract refuses the holders still waiting to crossed.

How do I launch a vampire cape…r they choose. Nothing expires, and no one is forced across, but the room is finite: the curve cap counts every caper token in circulation, bought or migrated, and a migration that would take circulation past 100 billion aborts on Migration exceeds curve cap (contracts/core/src/caper_dao.rs). Every token bought off the curve before the community has crossed takes room a migrating holder would need, and the last holders to arrive are the ones refused. Before committing, be clear …pty and fills from later buys.

Does migrating cost anything? …o there is no registration fee, no trade fee and no share taken by the founder and no skim, and nothing goes to the founder, a treasury or the protocol. A holder pay…othing further for migrations.

Where next What is a caper (/…ts/raising-funds) covers the founder's reward and the trade feeskim and who it pays. If you are reading this thro…thout opening the browser tab.

Where next What is a caper (/… the founder's reward and the fee legstrade fee. If you are reading this thro…thout opening the browser tab.

Why is a freshly migrated cape…teral is public on every caper but the root $XRD one, takes XRD, and puts it strai… as part of the same exercise.

Do migrated holders get the sa…ayment and mints no vote token – unlike a buy or a sell, each of which mints 0.01 v per XRD of gross value, and unlike a ballot, which mints 1, 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 neither tradoes nort votes carries no weight at all – th… counting the first time they tradcast a ballot, and buying more onf the curve or cast a ballotoken does not shorten that wait. For a community migrating t… something with it afterwards.

Why is a freshly migrated cape…ates 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 mi… as part of the same exercise.

Topic Launching · vampire cape…t an origin token later Rate 8100,000,000,000 / origin supply … (/wiki/markets/bonding-curve)

What exchange rate do holders … token's total supply: rate = 8100,000,000,000 / origin supply …okens 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 las… origin token moving across – is sized to fill 80%therefore lands circulation at the very top of thate curve, not all of rather than part-way up it.The remaining 20 billion stay unminted, so there is still curve leftis 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 who arriveing after thea migration, and keeping circulation stays clear of the point where the c…rice integral divides by zero. The ceiling is gone; the bonding curve (/wiki/markets/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 tok… of 1,000,000 gives a rate of 8100,000 caper tokens per origin … the origin supply – receives 81,000,000,000 caper tokens, which is one per cent of the migrated block and 0.8% of the curve's full cap. Prop…ommunity are preserved exactly; w. What has changesd is that the community now sits alongside curve headroom it can sell intoe 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 …r the number to mean anything.

Why is a freshly migrated cape…nto 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.

How do I launch a vampire cape…e rate to your holders. It is 8100,000,000,000 / origin supply …pty and fills from later buys.

Where next What is a caper (/…m-an-ai-agent) documents the read-only MCP serversMCP read surface, and Build on Caper as an ag…thout opening the browser tab.

Do migrated holders get the sa…, is the product of stake and participan earned record, and migration, and participation starts at nothing. A holder who migrates a large balance and nevelone earns none of it. migrate takes no payment and mints no vote token – unlike a buy or a sell, each of which mints 0.01 v per XRD of gross value, and unlike a ballot, which mints 1. So a holder who migrates and then neither trades nor votes carries no weight at a… is multiplicative, so a zero participation termrecord zeroes the product – and beca…y arrive holding a stake that only counts once they use istarts counting the first time they trade on the curve or cast a ballot. For a community migrating t…stops being a function of who bought mostheld most before the launch and starts being a function of who shows updoes something with it afterwards.

Where next What is a caper (/…ents the read-only MCP servers, and Build on Caper as an agent (/wiki/foundations/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.

Do migrated holders get the sa…lance and never votes carries almost no weight,no weight at all – the weight formula is multiplicative, so a zero participation term zeroes the product – and because exit pays theat same weight, they claim almost none of the treasury eitherand 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 n…ng a function of who shows up.

Topic Launching · vampire capers Set at Genesis only – a caper cannot adopt an origin token later Rate 80,000,000,000 / origin supply caper tokens per origin token Cost to migrate None beyond the Radix network fee Reversible No – escrow is one-way Related Getting started (/wiki/foundations/getting-started) , Raising funds (/wiki/markets/raising-funds) , Bonding curve (/wiki/markets/bonding-curve)

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 (/create-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 (/wiki/foundations/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 (/wiki/governance/proposals) , or handed back at exit. Voting weight (/wiki/governance/voting) , 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? - Open Create a caper (/create-caper) and choose the Vampire migration tab before filling anything else in. - Paste the origin token's Radix resource address. Check first that it is fungible and publishes a total supply, since the launch aborts otherwise. - Fill in the name, description and cashtag as for any launch, and pay the registration fee that the cashtag's length sets. - Publish the rate to your holders. It is 80,000,000,000 / origin supply and it will not change. - 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 (/wiki/foundations/what-is-a-caper) covers the model itself. Bonding curve (/wiki/markets/bonding-curve) explains the pricing a migrated supply lands on, and Raising funds (/wiki/markets/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 (/wiki/foundations/querying-a-caper-from-an-ai-agent) documents the read-only MCP servers.