Aster is built Around Pro Order Entry and Fill Verification

Aster is an order-book perpetuals venue whose Pro panel exposes the decisions that determine execution before an order leaves the screen. A trader chooses the market, side, order type, price or trigger, size, margin settings, and modifiers such as Post Only, then checks Order History to distinguish acceptance, partial execution, rejection, and a completed fill.

That workflow matters because an accepted instruction is not the same as an executed trade. The sections below follow the panel from account preparation through fee classification, submission, status changes, fill verification, and correction of a rejected order.

Bottom line: Post Only rejects a crossing limit order, so a missing fill can reflect correct maker-only behavior.

Aster Pro Versus 1001x: Order-Book Control Before Submission

Four supported networks - BNB Chain, Ethereum, Solana, and Arbitrum - give Aster Pro a deposited, order-book workflow with explicit price and execution controls. Aster 1001x operates on two networks, uses the ALP liquidity pool, and removes the Pro deposit step. Pro therefore fits an order-entry process that requires resting limits, maker-only instructions, conditional triggers, and granular status records; 1001x favors direct pool-based entry with fewer panel decisions.

Post Only Makes Fee Classification Visible Before Submission

Two liquidity outcomes - adding an order to the book or matching existing liquidity - determine whether a completed Aster Pro trade is classified as maker or taker.

Post Only applies that distinction before execution. The modifier tells the matching engine to accept the limit order only when it adds liquidity. A price that would immediately cross the best available quote produces a rejection rather than a taker fill. Acceptance therefore confirms that the instruction entered the book, not that another trader matched it. The order earns maker classification only after it rests and later receives a fill, while cancellation before a match produces no executed notional or trading fee.

The fee base is executed notional, calculated as filled quantity multiplied by fill price. Aster also documents a 5% discount when ASTER pays perpetual trading fees. That discount does not change whether Post Only was accepted, rejected, partially filled, or fully filled; it applies after a fill creates a fee.

What Must Be Set Before an Aster Pro Order Is Submitted?

Five core choices define an Aster Pro instruction before submission: market, buy or sell side, order type, quantity, and the applicable price or trigger.

The account also needs the correct collateral and margin configuration. Pro settles in USDT and offers two account modes: single-asset mode uses USDT, while multi-asset mode evaluates supported collateral across the account in cross margin. MetaMask, Binance Wallet, and WalletConnect provide documented connection routes. A wallet connecting through BNB Chain needs at least 0.001 BNB for the connection workflow, and the selected network must match the deposited balance shown in the Pro account.

Before pressing the buy or sell control, read the symbol and side together, then compare quantity with displayed notional. Conditional exits add another decision: take-profit and stop-loss triggers reference either Mark Price or Last Price. Those two sources can reach the same level at different moments, changing when the instruction becomes active.

Seven Order Instructions and Their Execution States

Seven order types appear in Aster Pro’s documented perpetuals interface: LIMIT, MARKET, STOP, STOP_MARKET, TAKE_PROFIT, TAKE_PROFIT_MARKET, and TRAILING_STOP_MARKET. Each instruction changes which fields matter and what state follows submission.

The choice controls the trade-off between price certainty and execution certainty. A market instruction seeks an immediate fill, although several order-book levels can determine its average price. A limit instruction protects its boundary but can remain open. STOP and TAKE_PROFIT preserve a limit after activation, whereas their market counterparts prioritize execution after the trigger. A trailing stop accepts a callback rate from 0.1% through 4%; a reversal by that percentage activates a market order.

How Does Post Only Behave When the Price Would Cross?

One Post Only condition forces a crossing limit instruction to fail instead of taking liquidity at the price already available in the order book.

The API expresses Post Only as GTX, one of four time-in-force values alongside GTC, IOC, and FOK. GTC rests until filled or canceled, IOC fills immediately where possible and cancels the remainder, and FOK requires the entire quantity immediately. Best-bid-offer placement can supply a displayed quote automatically, yet the book can move before acceptance. If that selected price becomes marketable, Post Only rejects it; IOC or FOK is the closer fit when immediate execution matters more than maker classification.

Order Status Creates the Fill Verification Trail

Six documented order statuses - NEW, PARTIALLY_FILLED, FILLED, CANCELED, REJECTED, and EXPIRED - separate acceptance, execution, and termination in Aster Pro’s verification trail.

Submission creates an order record before it creates a completed trade. NEW means the engine accepted an instruction that still has unfilled quantity. A marketable instruction can advance rapidly to PARTIALLY_FILLED or FILLED, while a resting limit remains NEW. REJECTED records a failed submission and produces no filled quantity. Once execution occurs, cumulative filled quantity rises, the average fill price is calculated, the position and available balance update, and FILLED confirms that no original quantity remains open.

A partial fill requires two separate checks. Executed quantity already changes the position, while remaining quantity stays eligible for later matching. The average fill price can differ from the original limit because multiple permitted price levels contribute to the completed amount.

The signed all-orders query returns 500 records by default, accepts up to 1,000, and limits each query window to less than seven days. A client order identifier also has a 36-character ceiling, giving programmatic workflows a durable key for matching submission records with later status updates.

Order History provides the human-readable verification layer and supports status filtering. For continuous programmatic checks, an Aster user-data stream key lasts 60 minutes unless renewed, while one WebSocket connection lasts 24 hours. Both routes should agree on symbol, side, original quantity, cumulative filled quantity, average price, and terminal status.

Minimum Notional Rejection Has a Direct Recovery Path

A 5.0 USDT baseline appears in Aster’s MIN_NOTIONAL rejection message, while the active symbol filter supplies the exact threshold enforced for that market.

For a limit order, notional equals price multiplied by quantity. A market order uses the mark price because no submitted limit price exists. Error -4164 means that calculated amount is below the symbol’s permitted minimum, except where the documented reduce-only exception applies. Return to the size field, keep the intended side and order type unchanged, and raise quantity until the panel’s notional satisfies the active filter before submitting again.

Changing leverage alone does not repair a notional rejection. Leverage changes the margin required to support a position, while price multiplied by quantity still determines order notional. Adjusting size addresses the failed rule directly and preserves the original execution choice.

Verification-Focused Traders Fit the Pro Workflow

Three records - open quantity, cumulative filled quantity, and terminal status - make the Pro workflow useful when execution evidence matters after every submission. The panel suits traders who deliberately separate an instruction from its fill, use Post Only to control liquidity classification, and reconcile partial execution before changing a position. That favors Aster Pro over 1001x when granular order states matter more than direct pool-based entry.