Zeitgeist market creation bonds and launch choices

Zeitgeist market creation reserves ZTG for an oracle bond and a creation bond chosen by the launch mode. Permissionless markets use a validity bond; advised markets use an advisory bond and await committee approval. The creator funds both bonds, even when another account acts as oracle. Reserved bonds reduce the spendable balance, while their return follows separate approval or resolution rules. Creation also requires valid market parameters and a responsive chain accepting the relevant transaction.

Updated
Committee approval releases the advisory bond while leaving the creator's oracle bond reserved for settlement.

Trading choices before the market opens

Hybrid markets support liquidity-pool trading and order matching, while categorical parimutuel markets collect bets into a shared pot. This choice changes the capital preparation and participants' exit options.

Pool liquidity and matching orders

Neo Swaps pools use the Logarithmic Market Scoring Rule to price outcome tokens. Pool deployment needs liquidity; market creation alone does not supply it. Orders offer another source of counterparties and reserve the maker's offered assets. A fill transfers the filled amount to the taker; cancellation releases the unfilled amount to the maker. A hybrid market can support both mechanisms. A proposed advised market must clear approval before these market operations become available.

Categorical bets in a pot

Parimutuel participation funds the pot through bets, without requiring a separate market-making liquidity pool. Zeitgeist limits this mechanism to categorical markets. The mechanism does not offer a sale exit, and later bets can change the eventual return. This trading commitment differs from the exit opportunities pool trading or order matching can provide before market closure.

Which ZTG bonds apply at creation?

The creator reserves an oracle bond plus the creation bond for the selected mode, even when the market uses another asset as collateral.

Permissionless validity bond

A permissionless launch uses the validity bond and starts with Active status. Approval does not precede creation. The trading period and selected mechanism still govern which actions the market permits. The validity bond remains separate from the money backing outcome tokens and from capital committed to a pool.

Advised creation bond

An advised launch uses the advisory bond and starts with Proposed status. Committee approval releases this creation bond and enables the market's active operations, subject to its trading period. The smaller reservation in the published runtime configuration comes with an approval dependency, which can outlast the intended opening time.

Oracle bond

The market creator funds the oracle bond even when another account acts as oracle. Naming an account does not establish its willingness or ability to report. Agree on that responsibility before submission, because the creator's reserved ZTG carries the reporting exposure.

Illustration: Zeitgeist market creation: Oracle bond

View full-size image

Collateral, liquidity, and creator fees

The base asset backs the market's outcome claims; the creator's ZTG bonds secure separate protocol responsibilities. A supported foreign collateral asset does not replace the ZTG bond reservation. In a complete-set market, minting an equal amount of every outcome locks the corresponding base asset in the prize pool. Liquidity funding supplies trading inventory and creates a different exposure from holding a refundable bond.

The creator sets a creator fee within the runtime's permitted limit. Order-book fills charge it in the market's base asset. Neo Swaps can charge pool swap fees alongside external fees. Setting a creator fee does not provide initial liquidity or ensure anyone will trade.

Define outcomes and resolution terms together

Categorical markets need distinct outcomes covering the event's meaningful possibilities. Scalar markets need a numerical range, with Long and Short payouts following the resolved value. A question about a measurement must specify its unit, observation time, time zone, and resolution source. Cancellation or postponement needs an explicit treatment where either could change the answer. Leaving these decisions until reporting makes the creator's intended meaning harder to establish.

Keep the metadata's category order consistent with the market's outcome order. Zeitgeist stores a metadata reference on-chain, while clients retrieve the question and description from external storage such as IPFS. Text availability and correct token mapping both matter: a successful creation transaction does not repair an unreadable description or an incorrectly ordered outcome list.

Market terms should concern information participants can legitimately observe. Markets about harm to individuals or private personal information can breach creation rules. Permissionless creation bypasses prior approval, while those subject restrictions still apply.

When does an advised market become active?

In runtime specification 62, an advised market becomes Active when the authorized approval action succeeds. Approval does not wait for the scheduled start; pool deployment and order matching require Active status.

Before approval, the proposal can exist on-chain with its metadata reference, oracle, and deadlines. The protocol blocks complete-set purchases and pool deployment during this state. A successful creation transaction therefore establishes a proposal without proving readiness to trade. Approval and outcome reporting serve different purposes: the committee assesses the proposed market, while the oracle later reports the event's result.

Closing time and reporting windows

The trading period records the intended opening and scheduled closing boundaries, while the reporting deadlines govern what follows closure. Periods can use block numbers or timestamps. For disputable markets, the configured grace period delays reporting after trading ends; the oracle duration then defines the designated reporting window. Plan the closing boundary around when the event becomes knowable, with enough time for the oracle to obtain the required result.

Disputable markets also specify a dispute duration and a resolution mechanism, such as the court or authorized resolution. Trusted markets omit a dispute mechanism and require a zero dispute duration. Only the designated oracle can report a trusted market after closure, and an accepted report resolves it immediately. That choice changes settlement safeguards independently of whether creation uses advised or permissionless mode.

When does the creator recover reserved ZTG?

The advisory bond returns on approval, while the permissionless validity bond normally returns at resolution. These release points concern the creation bond. The oracle bond follows the reporting outcome, so approval does not release the creator's entire reservation.

If a proposed advised market reaches its ending boundary without approval or rejection, expiry processing returns both initial bonds. The protocol removes the expired proposal. This differs from an approved market closing for reporting.

Rejection settles the advisory bond using the configured slashing percentage and returns the remainder, along with the oracle bond. An oracle report surviving the applicable resolution process releases its bond. In a disputable market, an outsider can report after the oracle window ends if no report exists. The outsider receives the oracle bond at resolution only if its report matches the final outcome. If a dispute overturns the oracle's report, the creator loses the oracle bond under the selected mechanism's settlement rules.

Closing trading does not settle every bond. Keep track of the market's report, final outcome, and bond records during maintenance. Bonds for outsider reporting, disputes, or early-close requests attach to those later actions; ordinary creation does not reserve all of them upfront.

Runtime amounts and balance terminology

Zeitgeist runtime specification 62 defines a 200 ZTG advisory bond, a 1 000 ZTG validity bond, and a 200 ZTG oracle bond. Under that configuration, initial reservations total 400 ZTG for advised creation or 1 200 ZTG for permissionless creation, before transaction fees and any liquidity funding. These totals describe that runtime configuration and do not establish the version a connected deployment runs.

The same configuration sets the advisory rejection slashing percentage to zero. The rejection mechanism therefore does not imply a universal bond loss. Read the connected runtime's AdvisoryBond, ValidityBond, OracleBond, and AdvisoryBondSlashPercentage parameters when preparing the balance. An account's total balance can include reservations or locks, so the transferable amount determines whether it can fund another operation.

Readiness before the first reservation

Before creating an advised proposal without a pool, check the conditions the creation transaction relies on:

  • The connected chain advances and accepts the required market-creation call.
  • The creator has transferable ZTG covering the applicable initial bonds and transaction fee.
  • The market type, outcome definitions, period, and reporting deadlines satisfy the deployment's limits.
  • The designated oracle can report the specified result within the market's reporting window.
  • The metadata reference retrieves the intended question, description, and correctly ordered outcome labels.

A recorded proposal

A successful create_market transaction emits MarketCreated and records the advised market with Proposed status. Query the resulting market identifier and compare its creator, oracle, period, and bonds with the submission. Continue only after the transaction succeeds and the recorded state matches. Pool deployment remains blocked while the proposal awaits approval.

A failed or unreadable submission

An insufficient bond balance or invalid parameter can prevent creation. Correct the specific failure before submitting again. If the connection fails before returning a usable result, establish the original transaction's outcome first; an unreadable response does not prove the chain rejected it. If creation already succeeded, retain that proposal and wait for its approval.

After approval, decide whether to deploy a supported liquidity pool and allocate the separate capital it requires.

Questions people ask about Zeitgeist market creation

Can a creator edit an advised market after submission?

The creator can edit a Proposed market after an authorized edit request. The edit call requires both that request and the original creator's signature. It can revise specified market parameters while preserving the existing market identifier and bonds. Approval cannot proceed while the edit request remains pending, so a requested correction belongs before approval.

Which SDK mode supports submitting a market-creation transaction?

Zeitgeist SDK V2 requires full mode or RPC mode for market-creation submissions. The transaction also needs a signer from a wallet extension or keyring. An indexer connection supplies queried market data; it does not provide the chain connection and signature needed to submit creation. Use a client version compatible with the target runtime.

Why does Polkadot.js Apps show an unknown market query result?

In Polkadot.js Apps, an unknown chain-state or RPC query result can reflect a slow or broken connection or incompatible client type definitions. A browser-console error saying decoded input does not match the input indicates incompatible type definitions. This display alone does not establish a market's creation state or approval status. Resolve the connection or decoding problem before treating the query as a usable result.

Do outcome tickers have to match an existing cryptocurrency ticker?

A creator can define tickers for the market's outcome labels. These tickers describe outcome tokens and do not need to copy an existing cryptocurrency's ticker. Keep each label consistent with its category and metadata order. Choosing a familiar ticker does not change the market's collateral asset or the meaning of the event it resolves.

Can market creation and pool deployment share one transaction?

The protocol provides create_market_and_deploy_pool for permissionless hybrid markets. This combined call creates the market, buys complete sets, and deploys the Neo Swaps pool in one transactional operation. Its funding requirements therefore include pool capital as well as creation bonds. An advised proposal follows its approval dependency before pool deployment becomes available.

Why can a distant closing date prevent market creation?

The runtime enforces MaxMarketLifetime when validating the market period. This limit measures the interval from creation to the closing boundary, including any wait before the scheduled opening. A closing date beyond the permitted lifetime can therefore fail validation even if the planned trading window seems short. The connected deployment's configured limit governs the accepted period.