A Radix transaction is atomic: when a check inside the contract fails, the whole transaction is rejected and nothing it would have moved moves. The network fee is the one cost that stays spent, because the network keeps it whether the transaction commits or aborts. A failed buy costs you that fee and nothing else: no tokens minted, no $XRD taken, no vote tokens.
Your wallet shows the exact text of the check that failed. Every message on this page is copied verbatim from the contract, so search the page for the text you were shown. A platform upgrade changes every caper at once, so the messages listed are the ones the deployed contract carries, not whatever sits in the repository.
Two kinds of failure do not appear below. The first is an access-rule failure: several calls take your account as an argument and check that you can sign for it, so a manifest naming an account your keys do not control fails with the engine's own message rather than the contract's. The second never reaches the contract at all: a rejected manifest, too small a fee lock, or a wallet that declined to sign. Neither says anything about the caper you were transacting with.
This page quotes no fees. The Caper app shows each one before you sign: the Cashtag field on the launch form shows the registration cost, the Proposal fee line on the create-proposal form shows the proposal fee, and the CAST BALLOT button on a proposal page shows the vote fee. Your wallet then shows the amount leaving your account in the transaction summary.
| Message | What fired | What to do |
|---|---|---|
Buy too small (minimum 0.001 XRD) | A buy below the minimum the message names. | Pay more. |
buy_apply requires XRD payment | The bucket handed to a buy is not $XRD. | Every payment on the platform is $XRD: buys, fees and donations. Rebuild the manifest to withdraw $XRD. |
Curve Cap Exceeded | The buy would push the caper's supply past the fixed cap on its curve. | Buy a smaller amount. The cap cannot be raised. |
Curve fully uncollateralized — buy would mint zero tokens | The payment would buy no tokens at the caper's current supply. | Buy more. A payment that mints any tokens at all clears it. |
Invalid DAO Tokens | The sell bucket holds something other than this caper's own governance token. | Withdraw the caper's own token. The contract checks the token before the amount, so this fires ahead of the rows below it. |
Invalid DAO Token Amount | A sell of zero tokens. | Sell a positive amount. |
Can't sell more than in circulation | The sell would retire more tokens than the caper has in circulation. | This is a ceiling on the caper, not on your balance. Sell less. |
Insufficient Curve Liquidity | The caper's reserve holds less $XRD than the sale would pay out. The same check runs inside an exit, which sells your governance tokens back, and inside a DIVEST execution (below). | It is the standing state of a caper that migrated rather than launched, because its reserve starts empty. Anyone can top the reserve up by calling donate_collateral, which adds $XRD without minting anything or giving the donor any claim on it. |
Trade leaves the curve reserve below the curve | The trade would leave the caper's reserve less able to pay sellers than it was before. It runs on every buy and sell, inside an exit, and inside INVEST and DIVEST executions. | Nothing in your manifest causes it, and an honest trade always passes. The check sits in the core, which no upgrade replaces, so every holder can always sell back whatever a future upgrade changes. A migrated caper is held to the reserve it already had, not to a full one. |
Cannot swap a caper for itself | Both legs of the swap name the same caper. | Name two different capers. |
not a caper | A buy, sell or swap naming a component that is not a caper of the current deployment: a token, a treasury, an account, or a caper from a deployment before 11 October 2026. | Pass the caper's own component address, read from the current registry. |
caper of another registry | A buy, sell or swap naming a caper created by a different registry. | Trade only capers the current registry created. |
Curve collateral must be XRD | A donate_collateral call whose bucket is not $XRD. | The reserve holds $XRD and nothing else. |
Donation must be positive | A donation of zero. | Donate a positive amount. Both of these fire on the call the Insufficient Curve Liquidity row sends you to. |
A vampire caper is launched against an existing token: holders of that origin token escrow it and receive the new caper's governance token at a rate fixed when the caper was created. The escrow is one-way, and it is the one way onto a caper's supply that is not a buy, which is why a migrated caper's reserve starts empty and the Insufficient Curve Liquidity row above is its standing state.
| Message | What fired | What to do |
|---|---|---|
This caper does not support migration | A migrate against a caper launched without an origin token. | An ordinary caper has no migration path. Buy instead. |
Must escrow the origin token | The escrowed bucket is not the origin token this caper was created against. | Each caper names one origin token at creation. Withdraw that token, not a similar one. |
Migration yields zero tokens (not a vampire caper, or zero amount) | The amount escrowed converts to zero tokens. | Escrow more. The conversion rate is fixed at creation and cannot change. |
Migration exceeds curve cap | The migration would push the caper's supply past its cap. | Escrow less. Migrated tokens count against the cap the same as bought ones, so a heavily migrated caper has less room left. |
The registration cost depends on the cashtag: shorter cashtags cost more. The Cashtag field on the launch form shows the cost of the cashtag you type, and the contract requires that exact amount, so paying more fails as surely as paying less.
| Message | What fired | What to do |
|---|---|---|
Invalid Payment Token. Needed XRD | The registration payment is not $XRD. | Pay in $XRD. |
Cashtag Char Count needs to be between 0 and 6 | A cashtag that is empty or longer than the platform allows. | Shorten it. The launch form accepts only lengths the contract allows. |
Cashtag must be uppercase letters A-Z or digits 0-9 only | Lower case, punctuation, spaces or a leading $ in the cashtag. | Pass the bare uppercase cashtag: ACME, not $acme. |
Invalid Payment Amount | The payment is not exactly the registration cost for that cashtag. | Pay the amount the Cashtag field shows, no more and no less. |
Origin token must expose a tracked total supply | A vampire launch naming an origin token that does not track its total supply. | Pick a token that tracks its supply, or launch without one. The conversion rate is set from that supply at creation, so a token that reports none gives the caper nothing to convert at. |
Origin token must have positive supply | The origin token tracks its supply and that supply is zero. | There is nothing to migrate from. |
Cashtag already exists | A create_caper naming a cashtag another caper holds. | Pick another cashtag. |
A vampire caper already exists for this origin token | A vampire launch naming an origin token another caper was already launched against. | The registry allows one vampire caper per origin token. Migrate into the existing one. |
capers are minted only by the registry | A manifest calling the CaperDao or DaoTreasury constructor directly instead of create_caper. | Use create_caper. Since 11 September 2026 both constructors refuse to run anywhere but inside the registry, so nobody else can mint a token or badge carrying a caper's identity. |
XRD is the network's native token, not a cashtag | A launch naming XRD as its cashtag. | Choose another cashtag. $XRD is the currency every caper is priced in, so no caper may take its name, and the protocol admin's badge does not lift the refusal. |
Everything about a proposal's shape is fixed and checked at creation, which is why so many of these fire before anyone votes. The governing rule is that the slate must be votable both ways: at least one no-op and at least one answer that is not.
| Message | What fired | What to do |
|---|---|---|
Payment needs to be XRD | The proposal fee bucket is not $XRD. | Pay in $XRD. The vote call raises the same check under its own name, Vote fee needs to be XRD; the trigger is free, so it has no such check. |
Title too long (max 512 bytes) · Description too long (max 16384 bytes) · Option title too long (max 256 bytes) · Option description too long (max 4096 bytes) · Option extra too long (max 1024 bytes) | A text field over the limit the message names. The limits count bytes, not characters, so accented letters, other scripts and emoji reach them sooner than their length suggests. | Shorten the field the message names. |
Must have at least 1 DAO Token | The proof handed to create_proposal carries less of the caper's governance token than the message names. | Buy the caper's token first. |
Insufficient proposal fee | The payment is below the proposal fee for this slate. Options that move more value pay a larger fee, and a slate that moves nothing (DEBATE, UPGRADE, METADATA) pays the minimum. | Pay at least the amount the Proposal fee line on the create-proposal form shows. The contract takes the fee and returns any excess, so paying a margin over it costs nothing. The form marks the figure as an estimate when an option is paid in a caper's token, whose price can move before the transaction lands. |
Must have at least 2 options · Must have at most 5 options | A slate with too few or too many options. | Resize the slate. |
Options must include a no-op ("Do nothing") | No option is marked as the no-op. | Add the no-op; the Caper app appends one for you. Without it nobody could vote to reject. |
Options must include an answer other than "Do nothing" | Every option is a no-op. | Add an executable action or a debate position. |
Unknown action kind (VOTE actions are retired) | An option whose action kind the contract does not recognize. | The VOTE kind was retired, so a proposal built against the old interface aborts here. Rebuild it against the current kinds. |
DEBATE options carry no execution fields | A debate option carrying a currency, amount, recipient, target cashtag, target resource or candidate component. | Remove the execution fields. A debate is settled by the ballot and goes no further. |
Only the $CAPER caper may propose a platform upgrade | An UPGRADE option on any caper other than $CAPER. | Each caper governs its own treasury; the platform itself is governed by $CAPER. Take it there. |
new_main is not a CaperMain component (blueprint: {}) | An UPGRADE naming a candidate that is not a deployed CaperMain. | Name a deployed CaperMain. The message prints the blueprint it found instead. |
METADATA must target this caper's own token | A METADATA option pointed at another caper's token. | A caper may rewrite only its own token's metadata. |
Payout needs recipient · Payout needs currency · Payout needs amount | A PAYOUT option missing one of its three required fields. | Fill all three. Every argument is fixed at creation, so none can be added at execution. |
Invest amount below the 0.001 XRD buy minimum | An INVEST option smaller than the minimum buy. | Raise the amount. An INVEST executes as an ordinary buy and has the same minimum. |
Payout amount must be positive · Divest amount must be positive | A PAYOUT or DIVEST naming zero or less. | Name a positive amount. |
Invest needs target_resource · Invest needs amount · Divest needs target_resource · Divest needs amount | An INVEST or DIVEST option missing a required field. | Supply the token and the amount at creation, for the same reason as PAYOUT. |
UPGRADE action missing new_main · METADATA needs a MetadataUpdate blob in `extra` · METADATA must set at least one field | An UPGRADE with no candidate named, a METADATA whose extra field does not decode, or one that changes nothing. | Supply the missing part. The METADATA payload is checked at creation, so a malformed one fails while the proposal can still be fixed. |
Non-XRD amounts need target_cashtag to price the fee | A PAYOUT in a caper token with no cashtag naming which caper issues it. | Name the issuing cashtag: the proposal fee for a token amount is priced off that caper's market. A sibling check, target_cashtag does not issue this currency, fires if the named caper does not issue the token the payout moves. |
Proposal id already exists | The id handed to create_proposal is already taken on this caper. | Choose another. Ids are never reused, so a retried creation whose first attempt already landed fails here rather than overwriting it. |
A ballot ranks every option. The vote fee must be paid exactly: the call gives no change.
| Message | What fired | What to do |
|---|---|---|
Invalid vote fee | The payment is not exactly the vote fee. | Pay the amount the CAST BALLOT button on the proposal page shows, no more and no less; your wallet shows it before you sign. Overpaying fails here, unlike create_proposal. |
Voting window closed | A ballot cast before voting opens or after it closes. | Voting is over. If the proposal passed, the way to oppose it now is to sell during its market window. |
Ballot must rank every option | The ranking has more or fewer entries than the slate has options. | Rank all of them. A partial ranking is not a valid ballot. |
Ballot ranks an unknown option | An option index past the end of the slate. | Indices start at zero and stop at the last option. |
Ballot ranks an option twice | A repeated option. | Rank every option exactly once. |
Must hold at least 1 DAO Token to vote | The voting account holds less of the caper's governance token than the message names. | The balance is read at the moment you vote, so buying in the same transaction works. |
Participant has already voted | The voting account has already cast a ballot on this proposal. | One account, one ballot. A ballot cannot be amended or withdrawn. |
Vote fee needs to be XRD | The vote fee bucket is not $XRD. | Pay in $XRD. This is checked before the amount, so it fires ahead of Invalid vote fee. |
Proposal already tallied | The votes on this proposal have already been counted. | Nothing to do. Counting calls sent after the count raise it too: since 20 October 2026 the chunk that finishes the count records the verdict, so any chunk that lands after it ends here. |
Votes are counted by permissionless calls that anyone can send once voting closes, and whoever sends one pays its network fee. The COUNT VOTES button on a proposal page, and Count votes on the home feed, send them from your wallet: a small electorate is counted in one settle_proposal, a larger one in a set of crystallize_ballots chunks sent together, and the chunk that finishes the count records the verdict. Until 11 September 2026 the treasury refunded whoever sent these calls; that refund was removed.
| Message | What fired | What to do |
|---|---|---|
Voting window still open | A counting call sent before voting closes. | Wait until voting closes. |
Nothing left to crystallize | A crystallize_ballots call on a proposal that has no ballots left to count and no verdict yet, such as one nobody voted on. | Call settle_proposal, which records the verdict. |
Too many ballots to fold inline – crank crystallize_ballots | settle_proposal called on a proposal with more ballots left than one call counts. | Send crystallize_ballots chunks instead; the COUNT VOTES button does this. The chunk that finishes the count records the verdict, so nothing needs sending after it. |
A vote that passes executes nothing by itself. trigger_proposal, which is free and open to any account, opens a market window on the caper's token; once it closes, resolve_proposal checks whether the market held up against where it stood at the trigger. The shape is optimistic governance, with the market in place of a veto window.
| Message | What fired | What to do |
|---|---|---|
Legislative pass required | A trigger on a proposal whose votes have not been counted, or were counted and failed. | Count the votes first. The leading option passes only with a supermajority, and never when it is the no-op. |
Proposal already triggered | A second trigger on the same proposal. | The window is already open. Wait for it to close and call resolve_proposal. |
DEBATE options are terminal at the tally — nothing to trigger | The winning option is a debate position. | Nothing to do: a debate is settled by the ballot and opens no market window. |
Proposal window still open | resolve_proposal called before the market window closes. | Wait for the window to close. |
Proposal not triggered | A resolve on a proposal with no open window. | Someone must call trigger_proposal first. |
Proposal already settled | A second resolve. | The verdict is final. If it passed, the next step is the matching execute call, which must land before the execution window closes. |
Each executable kind has its own execute method, and UPGRADE has two, one per leg. Each method checks that the winning action is the kind it handles, so calling the wrong one fails by name rather than doing nothing. Every argument was fixed at creation, which is why a stale amount aborts instead of executing a smaller trade: see execution.
| Message | What fired | What to do |
|---|---|---|
Proposal not settled | An execute before resolve_proposal has run. | Resolve first. Settled here means the market window has been resolved, not that the votes were counted. |
Proposal did not pass — nothing to execute | The market vetoed the proposal during its window. | Nothing to do. Doing nothing ratifies a proposal; defeating one takes selling. |
Proposal already executed | A repeat execution. | Nothing to do. The UPGRADE activate leg is the one call that deliberately acts on a proposal already executing. |
Execution window closed | An execute after the execution window that opens at resolve_proposal has closed. | The passed action has lapsed, so a payout the treasury could not fund when it passed does not stay armed. To do the same thing, put it up again as a new proposal. |
Winning option is a no-op | The leading option was “Do nothing”. | A no-op leader fails by rule even with a supermajority, which is what makes ranking it first a real vote against. |
Proposal action is not a PAYOUT · Proposal action is not an INVEST · Proposal action is not a DIVEST · Proposal action is not an UPGRADE · Proposal action is not a METADATA | The execute method does not match the winning kind. | Call the method for the kind that won. PAYOUT must execute via execute_payout is the same check from the other side. |
Invest must deposit the target caper's tokens | The INVEST buy returned a token other than the target caper's. | The target token is fixed at creation; check it still matches the caper being bought. |
Curve Cap Exceeded | An INVEST execution whose buy would push the target caper past its cap. An INVEST runs as an ordinary buy, so it meets the buy checks at execution. | Nothing to fix at execution: the amount was fixed at creation and the target's supply was not. Put up a smaller INVEST as a new proposal. The buy's other check, Curve fully uncollateralized — buy would mint zero tokens, runs at the same point, and Invest must deposit a positive token amount backs it up. |
target_cashtag does not match the proposed action | The execute call names a different cashtag from the one the option fixed. | Pass the fixed cashtag. Where the option carries no cashtag at all, the same calls fail first with Invest needs target_cashtag or Divest needs target_cashtag. |
Insufficient Curve Liquidity | A DIVEST execution whose sale the target caper's reserve cannot pay for. A DIVEST runs as an ordinary sell, so it meets the sell checks at execution. | Nothing to fix in the call: the amount was fixed at creation and the target's reserve was not. Anyone can top the reserve up with donate_collateral before the execution window closes, or the caper can put up a smaller DIVEST. If the treasury holds less of the token than the fixed amount, the withdrawal fails first with the engine's own vault error. |
Metadata needs target_resource · Malformed METADATA payload | A METADATA execution whose option carries no token, or whose payload does not decode. | Neither is fixable at execution; the same checks run at creation under their own names. A proposal that reaches here was built against an older interface. |
Only the $CAPER caper may upgrade the platform | An UPGRADE execution on any caper other than $CAPER. | The execution-side half of Only the $CAPER caper may propose a platform upgrade, checked again rather than assumed. |
Proposal not in execution phase | The UPGRADE activate leg called before the first leg has run. | Run the first leg. |
Pending upgrade is another candidate | The activate leg called while the registry's pending slot holds a different candidate from the one this proposal voted for. | The slot holds one candidate and either path may overwrite it, so a later proposal or the protocol admin has replaced this one. The activate leg only ever activates its own proposal's candidate. |
Pending upgrade was proposed by the other path | The pending candidate was put there by the protocol admin, and the activate leg is the governance path (or the reverse). | Since 11 September 2026 the slot records which path proposed it, and neither may activate the other's candidate. |
No pending upgrade | The activate leg called while the pending slot is empty. | Run the first leg, which puts the candidate in the slot. On the governance path this fires ahead of the registry's own No main proposed (below). |
Pending upgrade is not this proposal's candidate | The activate leg called while the slot holds a different candidate from the one this proposal voted for. | The same case as Pending upgrade is another candidate above, caught earlier. A later proposal or the protocol admin has replaced this one. |
Activation window closed | The activate leg called after its activation window closed. | The upgrade has lapsed. To install the same logic, put it up again as a new proposal. |
No main proposed · Upgrade timelock has not elapsed | The activate leg called with the registry's pending slot empty, or before the registry's upgrade delay has run. | Run the first leg before the second, and wait out any delay the registry sets. |
The exit right redeems your fair share of the treasury. It needs both your governance tokens and your vote tokens, and a member earns vote tokens only by casting a ranked ballot, so a holder who has only ever traded has no exit. Since 21 September 2026 an exit is two calls in one transaction.
The manifest first calls exit_open, then withdraws both tokens from the member's account and hands them to exit. exit pays only the account that signed, and accepts only vote tokens that account's own balance gave up since exit_open, so one account's vote tokens cannot be paired with another's governance tokens. The exit the Caper app builds does all of this.
An exit sells your governance tokens back, so besides the rows below it meets the sell checks in Buying, selling and swapping: Insufficient Curve Liquidity and Trade leaves the curve reserve below the curve.
The founder withdrawal pays out the founder share, which goes to whoever holds the caper's founder badge. The Founder fees cell in your position on the caper's page shows what is available.
| Message | What fired | What to do |
|---|---|---|
Exit requires vote tokens | The exit carries no vote tokens. | Cast a ballot. Buying, selling, swapping and transfers earn no vote tokens. Older material saying a single buy opens the exit describes the platform before 11 September 2026. |
Exit requires governance tokens | The exit carries no governance tokens. | Redeem a positive amount of the caper's own token alongside the vote tokens. |
Call exit_open for this member and caper first | exit ran without an exit_open earlier in the same transaction for the same account and caper. | Call exit_open for your account and the caper before withdrawing the vote tokens. |
Vote tokens must all come from the recipient | The vote tokens handed in differ from what the paid account's own balance gave up since exit_open. | Withdraw the vote tokens from the account being paid, after exit_open, and hand in exactly that amount. |
Invalid vote tokens | The vote-token bucket holds some other token. | Hand in this caper's own vote tokens. |
Invalid founder badge for this caper | A founder withdrawal presenting a badge that is not this caper's founder badge. | Present this caper's founder badge. |
Must present founder badge | A founder withdrawal whose badge bucket is empty. | Withdraw the founder badge into the manifest and present it. |
Nothing to withdraw | A founder withdrawal asking for nothing on either the $XRD or the token side. | Ask for a positive amount on at least one side. Zero on one side alone is fine; that side is skipped. |
Withdrawal exceeds founder balance · Withdrawal exceeds founder token balance | A withdrawal asking for more than the founder balance holds. | Withdraw no more than the Founder fees cell shows. The $XRD and token balances build up separately, so one can run out before the other, and each message names its side. |
Three cases. An unknown proposal or cashtag fails on a lookup, so the message reads Unknown proposal or Unknown cashtag, or the call finds no entity at all; check the identifier rather than the state. An access-rule failure means the manifest named an account your keys cannot sign for. A message that contradicts this page means the platform logic has moved: one UPGRADE proposal on $CAPER changes the logic for every caper at once, so what the deployed component says today is what every caper does today.
That is also how to check this page rather than trust it. Read current_main off the CaperRegistry and read the component it names. Resolve it each time rather than copying an address, because every logic upgrade activates a new component. Check the registry's address as well: every registry the platform has retired still answers, each with the current_main it had the day it was replaced.