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.
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 Token Amount | A sell of zero tokens. | Sell a positive amount. |
Can't sell more than in circulation | The sell is larger than the caper's own recorded circulation. | 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. | 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. |
Cannot swap a cashtag for itself | Both legs of the swap name the same caper. | Name two different cashtags. |
$XRD caper has no bonding curve — use migrate() instead | A buy against the root $XRD caper. | $XRD has no curve, so there is nothing to buy it on. It is reached through migrate, not buy_token. |
$XRD caper has no bonding curve — governance tokens are non-salable | A sell against the root $XRD caper. | There is no sell side. The same shape appears as cannot swap from XRD, cannot swap into XRD and nothing to collateralize on the other curve calls. |
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. |
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 |
|---|---|---|
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 500 XRD creation fee. | Pay at least 500 XRD. Unlike the vote fee, the excess is returned – the call takes exactly the fee and hands the change back. |
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. |
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 10% execution fee is priced at that caper's spot, so the trigger has no basis without it. |
$XRD caper has no curve — the optimistic phase needs a market signal | A proposal on the root $XRD caper. | $XRD cannot take proposals: with no curve there is no price for the second phase to resolve against. |
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. |
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 two permissionless calls in order – crystallize_ballots folds the ballots in chunks, then settle_proposal freezes the verdict. Both are reimbursed out of the proposal's own creation fee, up to 5 XRD per call and 500 XRD per proposal, so calling them costs the caller nothing beyond the network fee.
| 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 ballots remain unfolded. | Keep cranking crystallize_ballots until it reports nothing left, then settle. |
Trigger and resolve
A legislative pass executes nothing by itself. trigger_proposal prices the execution fee, 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, and nothing owed: a debate never reaches a trigger, so it never incurs the 10% execution fee. |
Proposer-pays trigger requires the execution fee | The ballot voted proposer-pays and the trigger carried no payment. | Attach the fee. Who pays is the ballot's second question, settled by plain weight majority, and a tie is a treasury waiver – a treasury-pays trigger is free and stays permissionless. |
Insufficient execution fee | The payment is below 10% of the winning action's XRD-equivalent value at that moment's spot. | Pay at least the fee; the excess is returned. UPGRADE and METADATA name no amount, so their basis is zero and the trigger is free either way. |
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. |
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. |
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. |
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. |
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 buckets non-empty because that expression has your vote-token balance in the numerator.
| Message | What fired | What to do |
|---|---|---|
Exit requires vote tokens | The vote-token bucket is empty. | Vote tokens mint on three surfaces at one rate – one per ranked ballot cast, and 0.01 per XRD of gross value on a buy and on a sell. The holder who cannot exit is the one whose tokens arrived by transfer, because a transfer mints nothing. A single buy opens the exit in the same transaction that opens the position. |
Exit requires governance tokens | The governance-token bucket is empty. | Redeem a positive amount of the caper's own token alongside the vote tokens. |
Invalid vote tokens / Invalid governance tokens | A bucket holding some other resource. | Both buckets are checked against this caper's own resources before any payout is computed, so a foreign resource cannot be used to set your own payout percentage. |
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. |
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. The FAQ sets out the same discipline for the fees and the windows.