How to read a failure
A Radix transaction is atomic: when an assertion inside the contract fails, the whole transaction is rejected and nothing it would have moved moves. The one thing that is not refunded is the transaction fee, which the manifest locks up front and the network keeps whether the transaction commits or aborts. So a failed buy costs you the network fee and nothing else – no tokens minted, no XRD taken, no vote tokens.
What the wallet shows you is the literal string the failed assertion carries. Every message on this page is one of those strings, copied out of the contract source rather than paraphrased, so the fastest way to use this page is to search it for the exact text you were shown. They are copied from the commit that is deployed rather than from the tip of the repository, which is not the same thing: a platform upgrade changes every caper at once, so until one lands, the branch's messages are not messages anyone can be shown.
Two kinds of failure do not appear below. The first is an access-rule failure: several calls take your account as an argument and then re-assert that account's own owner rule, so a manifest naming an account you cannot sign for fails on the rule rather than on a named assertion, and the message you get is the engine's, not the contract's. The second is a failure that never reaches the contract at all – a rejected manifest, an insufficient fee lock, or a wallet that declined to sign. Neither means anything about the caper you were transacting with.
The fee, window and rate figures quoted below are fields on the deployed component with no setters of their own; the FAQ explains why that is, and reading them off the ledger yourself is still the right way to check this page.
Buying, selling and swapping
| Message | What fired | What to do |
|---|---|---|
Buy too small (minimum 0.001 XRD) | A buy below the floor the curve enforces. | Raise the payment to at least 0.001 XRD. There is no upper limit other than the curve's own cap. |
Invalid Payment Token. Needed XRD | The bucket handed to the call is not XRD. | Every payment leg on the platform – buys, fees, donations – is XRD. Rebuild the manifest to withdraw XRD. |
Curve Cap Exceeded | The buy would push circulation past the curve's cap of 100,000,000,000 tokens. | Buy a smaller amount. The cap is a property of the curve and cannot be raised. |
Curve fully uncollateralized — buy would mint zero tokens | The portion of the payment that advances the curve solves to zero tokens at the current circulation. | Buy more. A payment large enough to mint a positive amount clears it. |
Invalid DAO Tokens | The sell bucket holds some resource other than this caper's own governance token. | Withdraw the caper's token. The resource is checked before the amount is, so this fires ahead of the three rows below it. |
Invalid DAO Token Amount | A sell of zero tokens. | Sell a positive amount. |
Can't sell more than in circulation | The tokens the sell retires are more than the caper's own recorded circulation. Since 15 September 2026 that is the amount sold less the skim's token leg, which changes hands instead of going back to the curve. | This is a ceiling on the caper, not on your balance. Sell no more than the circulating supply. |
Insufficient Curve Liquidity | The curve reserve holds less XRD than the sell would pay out. The same check runs inside an exit, which sells your governance tokens through the curve, and inside a DIVEST execution (below). | It is the standing state of a caper that migrated rather than launched, because migrators escrow origin tokens and the reserve starts at zero. Anyone can top it up permissionlessly by calling donate_collateral, which adds XRD to the reserve without minting anything or acquiring any claim on it. |
Trade leaves the curve reserve below the curve | Core checks, after every buy and every sell, that the curve reserve sits no further below the curve's own integral at the new circulation than it did before the trade. It runs inside an exit and inside INVEST and DIVEST executions too, because each of them trades on a curve. | Nothing in your manifest causes it: the price comes from the live logic, which computes the curve the same way, so an honest trade passes exactly. The check sits in the core, which no upgrade replaces, so that every holder can sell back along the curve whatever a future logic prices. On a migrated caper the reserve may sit below the curve by the shortfall its migrations created, and a trade is held to that, not to zero. |
Cannot swap a cashtag for itself | Both legs of the swap name the same caper. | Name two different cashtags. |
Curve collateral must be XRD | A donate_collateral call whose bucket is not XRD. | The reserve is denominated in XRD and holds 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 above sends you to, so they are worth reading together. |
Migrating into a vampire caper
A vampire caper is launched against an existing token: holders of the origin token escrow it and receive the new caper's governance token at the ratio fixed when the caper was created. The escrow is one-way – there is no matching take – and it is the one path onto a caper's supply that is not a buy, which is why the reserve of a migrated caper starts at zero 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 that was not launched with an origin token. | Nothing – an ordinary caper has no migration path. Buy on the curve instead. |
Must escrow the origin token | The escrowed bucket is not the origin token this caper was created against. | Each caper names exactly one origin token at creation. Withdraw that resource, not a similar one. |
Migration yields zero tokens (not a vampire caper, or zero amount) | The escrowed amount multiplied by the caper's stored ratio rounds to zero. | Escrow more. The ratio is derived from the origin token's tracked total supply at creation and is not adjustable afterwards. |
Migration exceeds curve cap | The migration would push circulation past the 100,000,000,000-token cap. | Escrow a smaller amount. The cap counts migrated tokens and bought tokens alike, so a heavily-migrated caper has less curve left than a fresh one. |
Creating a caper
The creation fee is not flat: it is 10(7 − characters) XRD, so a six-character cashtag costs 10 XRD, a four-character one 1,000 XRD, and a three-character one 10,000 XRD. The call asserts the exact figure, so paying more fails as surely as paying less.
| Message | What fired | What to do |
|---|---|---|
Cashtag Char Count needs to be between 0 and 6 | A cashtag longer than six characters, or empty. | Shorten it. One to six characters inclusive. |
Cashtag must be uppercase letters A-Z or digits 0-9 only | Lower case, punctuation, spaces or a leading $ in the cashtag argument. | Pass the bare uppercase cashtag – ACME, not $acme. |
Invalid Payment Amount | The payment does not equal the price the cashtag's length implies. | Recompute the price from the length and pay exactly that. |
Origin token must expose a tracked total supply | A vampire launch naming an origin token whose resource manager does not track supply. | Pick a token with a tracked supply, or launch without one. The migration ratio is derived from that figure at creation, so a resource that reports nothing gives the caper no ratio to convert at – and $XRD itself is one such resource. |
Origin token must have positive supply | The named origin token tracks its supply and that supply is zero. | Nothing to migrate from. The ratio would divide by it. |
Cashtag already exists | A create_caper naming a cashtag another caper already 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 instead. |
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 assert they are running inside the registry's own frame, so nobody else can strike a token or badge carrying a caper's locked identity metadata (contracts/PENTEST.md, L-3). |
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. |
Opening a proposal
Everything about a proposal's shape is frozen and checked at creation, which is why so many of these fire before any vote happens. The governing rule is that the slate must be votable both ways: between two and five options, 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 creation fee bucket is not XRD. | Every fee on the platform is XRD. The vote call raises the same check under its own name, Vote fee needs to be XRD; the trigger takes no payment, 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 its cap. The limits are in bytes, not characters, so any non-ASCII text reaches them sooner than its length suggests. | Shorten the field the message names. The two proposal-level caps are looser than the per-option ones because options are stored structured in the immortal core, where an unbounded field would be a griefing lever on every read that touches their substates; the proposal's own meta blob sits in a cold entry of its own and gets the looser cap. |
Must have at least 1 DAO Token | The proof handed to create_proposal carries less than one of that caper's governance token. | Buy any meaningful amount on the curve first. |
Insufficient proposal fee | The payment is below the proposal fee: 1% of the largest option's XRD-equivalent value, with a floor of 500 XRD. A token amount converts at the issuing curve's trailing time-weighted average price, not at spot. | Pay at least the fee. A slate whose largest option is under 50,000 XRD, or whose options carry no amount (DEBATE, UPGRADE, METADATA), pays the 500 XRD floor. Unlike the vote fee, the excess is returned – the call takes exactly the fee and hands the change back, so headroom over a fee priced off a token costs nothing. |
Must have at least 2 options / Must have at most 5 options | A slate outside the two-to-five range. | Resize the slate. The threshold the tally applies scales with the width, so a wider ballot is not a softer one. |
Options must include a no-op ("Do nothing") | No option is marked as the no-op. | Add the no-op. Its absence would make a rejection unvotable, which is the reason for the rule. |
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 discriminant is not one of 0, 1, 3, 4, 5 or 6. | Kind 2 was VOTE and was retired with the escrow voting system; the number was left unused rather than recycled, so a proposal built against the old ABI aborts here. Rebuild against the current kinds. |
DEBATE options carry no execution fields | A debate option (kind 6) carrying a currency, amount, recipient, target cashtag, target resource or candidate component. | Strip the execution fields. A debate is settled by the ballot and goes no further, and the contract enforces the emptiness rather than trusting the form. |
Only the $CAPER caper may propose a platform upgrade | An UPGRADE option on any caper other than $CAPER. | Individual capers govern their own treasuries; they do not each run their own version of the protocol. Take it to $CAPER. |
new_main is not a CaperMain component (blueprint: {}) | An UPGRADE naming a candidate that is not a globalized CaperMain. | Name a deployed CaperMain. The message prints the blueprint it actually found. |
METADATA must target this caper's own token | A METADATA option pointed at another caper's resource. | A caper may rewrite only its own token's mutable metadata. |
Payout needs recipient / currency / amount | A PAYOUT option missing one of its three required fields. | Fill all three. Every argument is frozen at creation, so none can be supplied later at execution. |
Invest amount below the 0.001 XRD buy minimum | An INVEST option smaller than the curve's own buy floor. | Raise the amount – the INVEST executes as an ordinary buy and inherits its minimum. |
Payout amount must be positive · Divest amount must be positive | A PAYOUT or DIVEST naming zero or less. | Name a positive figure. INVEST needs no check of its own here because the buy floor in the row above is stricter than zero. |
Invest needs target_resource · Invest needs amount · Divest needs target_resource · Divest needs amount | An INVEST or DIVEST option missing a required field. | Both trade kinds need the resource and the amount at creation, for the same frozen-action reason PAYOUT does. |
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 does not decode, or one that decodes to an update changing nothing. | Supply the missing part. The METADATA payload is decoded at creation rather than at execution, so a malformed blob fails while the proposal is still free to fix. |
Non-XRD amounts need target_cashtag to price the fee | A PAYOUT in a caper token with no cashtag naming which curve prices it. | Name the issuing cashtag. The proposal fee is priced off that caper's curve – at its trailing time-weighted average, not at spot – so creation has no basis without it. One sibling check guards the same pricing: target_cashtag does not issue this currency if the named caper does not issue the currency the payout moves. |
Proposal id already exists | The id handed to create_proposal is already taken on this caper. | Choose another. Ids are per-caper and never recycled, so a retried creation that reuses the id of a proposal that already landed fails here rather than overwriting it. |
Voting
A ballot is a full ranked permutation, and the vote fee is asserted for equality rather than as a floor – 100 XRD exactly, no change given.
| Message | What fired | What to do |
|---|---|---|
Invalid vote fee | The payment is not exactly the vote fee. | Send exactly 100 XRD. Overpaying fails here, which is the difference between this call and create_proposal. |
Voting window closed | The cast is before the voting start or at or after the voting end. | Nothing to do – phase one is over. If the proposal passed its tally, the way to oppose it now is to sell into the market window. |
Ballot must rank every option | The sequence is shorter or longer than the option count. | Rank all of them. A partial ranking is not a valid ballot. |
Ballot ranks an unknown option | An index past the end of the slate. | Indices are zero-based and bounded by the option count. |
Ballot ranks an option twice | A repeated index. | Submit a permutation – every option exactly once. |
Must hold at least 1 DAO Token to vote | The voting account's live balance of the caper's governance token is below one. | The balance is read live at the cast, not from a snapshot taken earlier, so buying in the same transaction works. |
Participant has already voted | The voting account is already in the proposal's participant list. | One account, one ballot. The list is keyed by the account the vote names, and there is no amend or withdraw path – a ballot is final for the window. A second account you control is a different member, and carries that account's own live balance as its weight. |
Vote fee needs to be XRD | The vote fee bucket is not XRD. | Checked before the amount is, so this fires ahead of Invalid vote fee. |
Proposal already tallied | The proposal has been settled. | Also raised by the two tally cranks below when they are called after settlement. |
Tallying: the two cranks
Closing phase one takes one or two permissionless calls. settle_proposal freezes the verdict, and it folds up to SINGLE_PASS_MAX_VOTERS = 60 unfolded ballots itself, so a proposal with 60 or fewer ballots needs only that call; above that, crystallize_ballots folds the excess in chunks first. Neither is reimbursed: whoever sends one pays that transaction's network fee. Until the redeploy of 11 September 2026 the treasury refunded up to 5 XRD a call out of a per-proposal allowance, and the pen-test fixes removed that allowance outright (contracts/PENTEST.md, L-2).
| Message | What fired | What to do |
|---|---|---|
Voting window still open | A crank called before the voting period has elapsed. | Wait. The voting period is readable off the component as voting_period_in_seconds. |
Nothing left to crystallize | The crystallize cursor has already reached the ballot count. | Not an error in substance – the folding is done. Call settle_proposal next. |
Crystallization incomplete — crank crystallize_ballots first | settle_proposal called while more than 60 ballots remain unfolded. | Crank crystallize_ballots until 60 or fewer are left, then settle – the settle folds that remainder itself. |
Trigger and resolve
A legislative pass executes nothing by itself. trigger_proposal, which takes no payment and is open to any account, locks the trailing-average baseline and opens the market window; resolve_proposal compares the window's own average against that baseline once the window closes. The shape is the optimistic one applied to a market rather than to a veto window.
| Message | What fired | What to do |
|---|---|---|
Legislative pass required | A trigger on a proposal that has not been tallied, or was tallied and failed. | Settle phase one first. A Borda leader passes only if its share of cast weight clears 1.5 / option_count and it is not the no-op. |
Proposal already triggered | A second trigger on the same proposal. | The window is already open; wait for it 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 has elapsed. | Wait. The window is readable off the component as proposal_window_in_seconds. |
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 frozen. If it passed, the next step is the matching execute call, which has to land within seven days of the resolve. |
Executing
There are six execute methods for five executable kinds, because an UPGRADE executes in two legs. Each one binds the frozen action and checks it is the kind that method handles, so calling the wrong one is a named failure rather than a silent no-op. Every argument was frozen at creation, which is why a stale amount aborts instead of quietly executing a smaller trade – see execution.
| Message | What fired | What to do |
|---|---|---|
Proposal not settled | An execute before resolve_proposal has run. | Resolve first. Settlement here means the market phase has been resolved, not that the ballot was tallied. |
Proposal did not pass — nothing to execute | The market window's average came in below the baseline locked at the trigger. | The proposal was vetoed by the market. 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 reads an already-executing proposal back deliberately. |
Execution window closed | An execute more than seven days after resolve_proposal ran. | Nothing – the passed action has lapsed. The resolve stamps a deadline of EXECUTION_WINDOW_SECONDS (7 days) and every execute path refuses a call after it, so a payout the treasury could not fund when it passed lapses rather than staying armed until the treasury fills (contracts/PENTEST.md, H-2). To do the same thing, put it up again as a new proposal. |
Winning option is a no-op | The Borda leader was the “Do nothing” option. | A leader that is the no-op fails by rule even when it clears the threshold, which is what makes ranking it first a real vote against. |
Proposal action is not a PAYOUT / an INVEST / a DIVEST / an UPGRADE / a METADATA | The execute method does not match the winning kind. | Call the method for the kind that actually won. PAYOUT must execute via execute_payout is the same check seen from the other side. |
Invest must deposit the target caper's tokens | The INVEST leg returned a resource other than the target caper's token. | The target resource is frozen 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 100,000,000,000-token cap. The INVEST runs as an ordinary buy on the target's curve, so it meets the trading checks at execution as well as the buy floor at creation. | Nothing to fix at execution: the amount was frozen at creation and the target's circulation was not. Put up a smaller INVEST as a new proposal. The buy's other guard, Curve fully uncollateralized — buy would mint zero tokens, is checked at the same point, and the last check on the path, Invest must deposit a positive token amount, is a backstop that guard reaches first. |
target_cashtag does not match the proposed action | The execute call names a different cashtag from the one the option froze. | Pass the frozen cashtag. Executing a different trade from the one that passed would break the frozen-action rule. Where the frozen option carries no cashtag at all, the same two calls fail first as Invest needs target_cashtag or Divest needs target_cashtag. |
Insufficient Curve Liquidity | A DIVEST execution whose sale the target caper's curve reserve cannot pay for. The DIVEST runs as an ordinary sell on the target's curve, so it meets the sell checks at execution, the way an INVEST meets the buy checks. | Nothing to fix in the call: the amount was frozen at creation and the target's reserve was not. Anyone can top the reserve up with donate_collateral inside the seven-day window, or the caper can put up a smaller DIVEST as a new proposal. If the treasury now holds less of the token than the frozen amount, the withdrawal fails before the sell, with the engine's own vault error rather than a contract message. |
Metadata needs target_resource · Malformed METADATA payload | A METADATA execution whose frozen option carries no resource, or whose payload does not decode. | Neither is fixable at execution – both were frozen at creation, where the same checks run under their own names. A proposal reaching here with either missing was built against a different ABI. |
Only the $CAPER caper may upgrade the platform | An UPGRADE execution on any caper other than $CAPER. | The propose side raises the near-identical Only the $CAPER caper may propose a platform upgrade; this is the execution-side half of the same rule, asserted again rather than inferred from it. |
Proposal not in execution phase | The UPGRADE activate leg called on a proposal whose first leg has not run. | Run the first leg. This is the one message whose precondition is that the proposal is already executing, which is why it reads backwards next to the rows above it. |
Pending upgrade is another candidate | The UPGRADE 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 the candidate its own proposal voted for. |
Pending upgrade was proposed by the other path | The pending candidate was put there by the protocol admin badge, and the activate leg is the governance path (or the reverse, on the admin's own activate call). | Since 11 September 2026 the slot records which path proposed it, and neither may activate the other's candidate. |
No pending upgrade | The UPGRADE activate leg called while the registry's pending slot is empty. | Run the first leg, which puts the candidate in the slot. Since 6 October 2026 the logic reads the slot itself before the registry does, so 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 below, caught by the logic before it reads the deadline. A later proposal or the protocol admin has replaced this one. |
Activation window closed | The activate leg called more than seven days after the candidate became activatable. | Nothing – the upgrade has lapsed. Until 6 October the activate leg had no deadline of its own (contracts/PENTEST.md, H-4). 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_seconds has run. | On this deployment the delay reads 0, so only the first can fire in practice. Run the first leg before the second. |
Exiting, and the founder's withdrawal
The exit right redeems a slice of the treasury equal to (t·v)/(V·T), and it needs both amounts positive because that expression has your vote tokens in the numerator. Since the redeploy of 21 September 2026 an exit is two calls in one transaction. The manifest first calls exit_open, which records the member's vote-token balance; it then withdraws both legs from the member's account and passes them to exit as buckets. exit checks that the account it pays signed the transaction, and accepts only vote tokens that account's balance has lost since exit_open, so one account's vote tokens cannot be paired with another's governance tokens (contracts/PENTEST.md, M-3). Governance tokens are not bound the same way, because they transfer. From 11 to 21 September exit withdrew both amounts itself, which failed for any account controlled by a key: a contract cannot withdraw from such an account on its owner's behalf.
An exit sells the governance tokens through the curve, so besides the rows below it meets the sell checks in Buying, selling and swapping: Insufficient Curve Liquidity and, since 6 October 2026, Trade leaves the curve reserve below the curve.
| Message | What fired | What to do |
|---|---|---|
Exit requires vote tokens | The vote-token amount is zero. | Cast a ballot. Since the redeploy of 11 September 2026 a ranked ballot is the only way a member earns vote tokens – each mints VOTE_MINT = 1 – and buying, selling, swapping and transfers all mint none, so a holder who has only ever traded cannot exit. Older material saying a single buy opens the exit describes the deployment before that date. |
Exit requires governance tokens | The governance-token amount is zero. | 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 with the member's account and the caper's vote-token address before withdrawing the vote tokens. The exit manifest the Caper app builds does this. |
Vote tokens must all come from the recipient | The vote tokens passed in differ from what the paid account's own balance lost since exit_open. | Withdraw the vote tokens from the account being paid, after exit_open, and pass exactly that amount. |
Invalid vote tokens | The vote-token bucket holds some other resource. | Pass this caper's own vote tokens. |
Must present founder badge | A founder withdrawal with no badge, or a badge from a different caper. | The mismatch case names itself separately as Invalid founder badge for this caper. |
Nothing to withdraw | A founder withdrawal asking for zero XRD and zero tokens. | Name a positive amount on at least one leg. A zero on one leg alone is fine – that leg is skipped. |
Withdrawal exceeds founder balance · Withdrawal exceeds founder token balance | A leg asking for more than the founder has banked. | Withdraw no more than the accrued balance. The two legs accrue separately – the XRD leg as a share of the curve XRD each trade moves, the token leg as a share of the tokens it moves – so one can be exhausted while the other is not, and each names itself. |
When the message is not on this page
Three cases. An unknown proposal or cashtag fails on a lookup rather than an assertion, so the message reads Unknown proposal or comes back as a missing entity – check the identifier rather than the state. An access-rule failure means the manifest named an account whose owner rule the signing keys do not satisfy. And a message that contradicts this page means the platform logic has moved: a single UPGRADE proposal on $CAPER swaps the logic for every caper at once, with nothing for a founder to opt into, 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. Resolve current_main on the CaperRegistry, then read the fields and the ABI off the component it names. Resolve it rather than copying the address written here: the component a logic upgrade activates is new every time, and nine different ones have been current since 11 September 2026. Check the registry's address as well as its answer – every registry the platform has retired still answers, and each still resolves a current_main of its own, which will be whatever was current the day it was replaced. The FAQ sets out the same discipline for the fees and the windows.