Polkaswap
Polkaswap uses community governance to create and maintain order-book markets
Polkaswap uses SORA governance to propose and execute changes to order-book markets. The process covers new trading pairs and maintenance of existing books. Ordinary traders place and cancel their own orders within an existing book through the trading interface. The distinction concerns the object each operation changes: a proposal concerns the shared market, while an order records a participant’s trading instruction. Preparing a proposal does not establish an active book. Governance approval and successful execution must precede the requested market change. Once a book exists, its configuration and status govern available operations. Participants supply the buy and sell orders needed for trading.
Last updated -
Bottom line: Book status controls trading and cancellation permissions after governance creates the market.
A new pair through the governance queue
Creating an order-book pair through governance starts with encoded call data for the proposed operation. With SORA selected, Polkadot.js Apps exposes the relevant call through its Developer and Extrinsics menus. The creation operation appears as
orderbook.createOrderbook
, with parameters identifying the intended book.
A preimage provides the encoded call associated with a governance proposal. Its purpose is to give the proposal a concrete operation the chain can execute. The call’s contents therefore need to match the intended market change, including the selected book.
A proposer can initiate a public proposal or approach the council about placement in the external queue. Council involvement does not itself establish the proposed market.
The creation call must execute successfully before the book exists on-chain. A prepared preimage, submitted proposal and approved proposal represent different stages.
Book identity and executable call data
An order-book proposal targets a specific decentralized exchange (DEX) market through identifiers the protocol can interpret. An order book identifier combines a DEX identifier with the base and quote asset identifiers. The base and quote fields identify the market’s assets, while the DEX field identifies the exchange instance. The quote asset should be a base asset of the selected DEX. These fields give the operation its target; a token ticker alone does not supply that complete identity. Keeping the same identifiers in the proposal explanation and encoded call lets community members evaluate the market the operation would actually affect.
Which changes need another governance decision?
Community voting covers maintenance of an existing book as well as the creation of a new market. Updates to its details and removal pass through this process. Changing an order book’s status requires on-chain governance. These operations affect the shared market available to participants. Placing or cancelling a personal order uses the existing market’s rules and has a different scope.
The update call exposes settings for price increments and quantity increments, alongside minimum and maximum order quantities. These parameters define the prices and sizes the book accepts. A proposal to change them concerns the book’s configuration, not the desired price of one trader’s order. The requested values belong to the identified market; another book can have different settings. Status changes separately control which operations participants may perform.
A pool asset without an order-book market
Consider a hypothetical case in which a reader can select an asset for a pool swap but finds no order book for the intended pair. The reader wants to sell at a chosen limit price. Selection in Swap identifies an asset for that exchange flow. A pool prices exchanges through its own liquidity mechanism, while a limit order belongs to a book containing participant orders.
The missing book makes this a market-creation request. Entering a desired price cannot create the required market through the swap interface. A governance proposal can request the book, and successful execution of an approved creation call can establish it. That produces a market where participants can submit orders when its status permits. Matching still requires suitable opposing orders, so creating the book does not promise execution at the reader’s chosen price.
Book status during maintenance
SORA’s order-book status determines which user operations remain available during changes to a market. The Trade status permits trading operations, including order placement and cancellation. PlaceAndCancel permits limit-order placement and cancellation while prohibiting trading. OnlyCancel allows users to cancel their own limit orders while prohibiting new placements and trades.
The Stop status freezes existing limit orders and blocks trading, order placement and user cancellation. Cancellation availability therefore changes with the book’s status. A connected account or an existing order does not override that restriction. An executed status change can affect outstanding orders, even when it leaves the pair’s asset identifiers unchanged.
Liquidity after market creation
An active order book needs participant orders to provide executable liquidity at particular prices. Creating the book establishes the market structure; it does not populate its bids and asks. A limit price states an acceptable execution condition, while matching requires opposing liquidity compatible with that condition. Order-book depth and pool liquidity describe different sources of trading capacity. Their distinction also matters when considering liquidity aggregation: the existence of a market alone says little about the liquidity available within it.
Open-source development and live market changes
Protocol development changes the implementation, while book administration uses the operations the network already exposes. The order-book codebase forms part of SORA’s Rust and Substrate implementation. Developers can examine its trading logic and contribute changes. The wider exchange also accepts contributions for additional liquidity sources.
A source-code contribution alone does not demonstrate a deployed change to a live book. A book’s configuration reflects executed on-chain operations, including any governance changes to its parameters or status.
Pair proposals and cross-chain asset access
A SORA order-book proposal addresses market configuration, while cross-chain asset access depends on supported bridge routes. Adding a pair does not create a bridge connection or establish support for every external version of a token. Where a proposed market involves bridged assets, the available route and asset representation remain material constraints. Before preparing that proposal, establish whether the required SORA assets already exist or whether cross-chain access also needs attention.
Polkaswap: what people ask
Can council involvement speed up an order-book proposal?
Council assistance can help place an order-book proposal in the external queue. A technical proposal may accelerate handling when circumstances permit. These options concern the governance path and do not guarantee approval or a fixed completion date. The proposed market change still needs successful on-chain execution.
Does selecting an existing order execute it immediately?
Selecting an existing order pre-fills the Buy and Sell widget in the Trade interface. That selection prepares trade details; it does not complete an on-chain trade. The trader must still submit the trade for on-chain execution, and the selected book must permit trading.
Which panel shows my personal order-book trading history?
The History widget shows your past trading activity in the order-book interface. The Market Trades widget shows trades for the selected pair, a broader view than your own activity. A pair-wide trade does not establish that your individual limit order filled, so the panels answer different questions.
Can an integration set a limit order’s lifespan?
The protocol’s place_limit_order call accepts an optional lifespan argument alongside the price, amount and side. An integration must use values the runtime accepts for that argument. The lifespan concerns the individual limit order; it does not define how long the market’s order book exists.
What can API events and errors reveal about book changes?
API events and errors help distinguish successful order-book operations from rejected calls. The interface exposes separate definitions for calls, events, errors and storage. Submission alone does not establish that a requested change took effect. The execution result identifies the operation’s outcome, while stored book data describes the resulting market state.