prediction-market
Binary prediction market with YES/NO outcome tokens, liquidity pool trading, and vote-based settlement
Prediction Market
Instruction text for agents that use the Prediction Market skill, loaded by bb dev skills prediction-market and the MCP get_skill_instructions tool.
Try it
Paste this into Claude Code, Codex, or Cursor with the BitBadges MCP server wired. The agent loads the skill, builds, verifies, and hands back a link to review and sign.
Load the prediction-market skill and build me one: binary prediction market with YES/NO outcome tokens, liquidity pool trading, and vote-based settlement. Use the session tools, run validate, review, and simulate in parallel, fix anything critical, then call get_review_url and give me the link.From a shell, bb dev skills prediction-market prints the same instructions.
Summary
Required standards: ["Prediction Market"]
- Use bb build prediction-market; YES token 1 and NO token 2 are collateralized pairs.
- Deposit 1 collateral base unit to mint 1 YES and 1 NO base unit; pair redemption reverses this.
- Winner burns 1 raw unit for 1 collateral base unit. Push burns 2 raw units for 1 collateral base unit.
- New markets support repeated consuming redemptions. Frozen legacy markets may allow only one claim per initiator.
- The verifier controls mutable voting challenges. This is not an immutable, mutually exclusive outcome oracle.
- Quote before proposing; never silently discard odd push dust or burn losing positions.
- Preserve frozen permissions, no-forceful-transfer invariant and escrow-funded payout routing.
Instructions
Prediction Markets
CLI First
Use the canonical builder rather than hand-writing approval ratios:
bb build prediction-market --verifier "$VERIFIER" --denom USDC --name "Example market" --description "Define the event, evidence and resolver policy" --image "ipfs://image" > market.json
bb check market.json
bb deploy market.json --browser
bb prediction-markets show "$COLLECTION_ID"
bb prediction-markets deposit "$COLLECTION_ID" --creator "$HOLDER" --amount 1000000 > deposit.json
bb deploy deposit.json --browserCreation returns seven frozen approvals: paired mint, transferable, pair redeem, YES winner, NO winner, push YES and push NO. YES is token 1 and NO token 2. Alias paths uyes/uno expose display units; amounts supplied to deposit, quote and redeem are always integer base units. For six-decimal collateral, 1000000 base units equals one display coin. Payout amounts exclude network and protocol fees.
Exact Redemptions
bb prediction-markets quote "$COLLECTION_ID" --state yes-wins --yes-amount 250000 --yes-balance 1000000
bb prediction-markets redeem "$COLLECTION_ID" --creator "$HOLDER" --state yes-wins --yes-amount 250000 > redeem.json
bb deploy redeem.json --browser
bb prediction-markets quote "$COLLECTION_ID" --state push --yes-balance 5 --no-balance 3
bb prediction-markets redeem "$COLLECTION_ID" --creator "$HOLDER" --state active --pair-amount 1 > pair.jsonExplicit --yes-amount / --no-amount selects a partial redemption. It must match a whole payout lot and fit the supplied balance. An explicit side amount of 0 skips that side, retaining its full balance. Pair amounts must be positive. Without an explicit amount, a supplied balance selects the maximum complete lots. The push example burns 4 YES and 2 NO, receives 3 collateral base units and retains one raw unit of each side. Explicit --yes-amount 5 for push fails; it is never rounded. Retained complementary YES/NO dust can be paired and redeemed for one collateral unit. A single unmatched raw unit cannot pay half a collateral base unit and remains transferable.
Winner redemption leaves losing positions untouched. Pair redemption is an independently available consuming route; the canonical frozen recipe does not stop pair deposits or pair redemptions at resolution. Do not describe this as an enforced trading deadline.
New settlements have an overall MAX_UINT64 transfer-count ceiling with no per-initiator limit. Repeated and later-acquired positions can redeem while the selected approval remains eligible and escrow is funded. Existing deployed approvals are never rewritten. Legacy per-initiator one-shot approvals may be exhausted after an earlier partial claim; quote reports the policy and unknown eligibility when tracker state has not been loaded. Current balances, votes, tracker counts, approval windows, escrow liquidity and fees still require fresh validation/simulation before signing.
Verifier Trust
bb prediction-markets resolve "$COLLECTION_ID" --creator "$VERIFIER" --outcome yes > resolution.json
bb deploy resolution.json --browserYES/NO emit one vote; push emits votes for both push approvals. Independent voting challenges authorize payouts. They do not supply an immutable single terminal outcome or cross-approval exclusion. The resolver must follow the stated event policy; do not claim trustless finality or guaranteed collateral solvency under inconsistent resolver decisions. Frozen collection permissions do not freeze votes. A stronger finality model requires a separate proven primitive or oracle design.
SDK and MCP
quotePredictionMarketRedemption(collection, request) returns exact payout, burn legs, retained positions, observed approval IDs/versions, policy and eligibility caveats. buildPredictionMarketRedeemTx with collection uses the same quote and refuses a known exhausted allowance. The lower-level overload cannot discover deployed terms; prefer the collection-aware path.
MCP standard_prediction_markets_quote and standard_prediction_markets_redeem mirror CLI arguments and only return reads or unsigned proposals. Use the CLI for browser signing. Approval presets remain available for advanced composition, with the same conserving ratios and amount scaling; run validation on the complete collection after composing.
Checks
Never infer finality from a deadline, an indexed status or a successful earlier vote alone. Do not invent an approval ID or silently fall back to an unrelated transfer approval when a payout approval is missing. Use current observed approval versions. Do not convert base-unit balances through floating-point numbers. Unknown state is not zero balance or an unused allowance.