Tick and lot rounding as an agent authorization boundary

Precision changes the instruction

We preserve the proposed limits through normalization, including a case where no admissible order exists.

A language model can propose a price or quantity outside a venue's accepted increments. Turning that proposal into an executable order requires normalization. The normalization is economically meaningful: rounding a buy price upward can exceed a maximum, and rounding size upward can exceed an exposure allowance.

Bybit's instrument specification endpoint documents price tick size, quantity step, minimums, and other product-specific constraints. Its spot and derivative schemas differ. An adapter therefore needs the relevant instrument metadata rather than a universal number of decimal places.

An illustrative constrained buy

Suppose a hypothetical instrument has price tick 0.05, quantity step 0.01, and minimum notional 10. An agent is authorized to buy at most 0.137 units at a price no higher than 100.03.

A normalized buy price of 100.00 preserves the ceiling. A price of 100.05 exceeds it. A normalized size of 0.13 preserves the size cap; 0.14 exceeds it. The resulting notional is 13.00, satisfying the illustrative minimum.

If the size cap were 0.097 instead, rounding down gives 0.09 and notional 9.00. That fails the illustrative minimum. Increasing size to 0.10 would meet the minimum but violate the authorization. The correct normalization result can therefore be no admissible order, with an explicit reason. An executable neighboring number may violate the authorized bounds.

Apply direction-aware arithmetic

Represent price and size as exact decimals or integer multiples of their steps. For a maximum buy price, choose the greatest valid tick no greater than the ceiling. For a minimum sell price, choose the least valid tick no lower than the floor. For a maximum size, round downward to the quantity step.

Then recheck all economic constraints using the normalized values. A valid tick and valid lot still require notional, balance, price-range, and margin checks. Record the original proposal, metadata version, rounding direction, and final serialized values so an evaluator can inspect the transformation.

Displayed decimal formatting can differ from tick size. A price may have two decimal places while valid increments are 0.05 rather than 0.01. Similarly, contract counts may require integer quantities even if a model outputs a decimal base amount.

An offline normalization fixture

Use the two examples above and assert that the first produces 100.00 and 0.13, while the second produces no admissible order. Add an already valid value, a value one tiny decimal below a boundary, a sell floor, and changed metadata between proposal and submission.

Metadata can drift. The runtime needs a stated refresh policy and a way to record which specification governed the request. The appropriate freshness policy depends on venue and product behavior; this note leaves refresh intervals dependent on venue behavior.

After submission, a rejection may reveal another constraint or changed specification. Preserve it as evidence and resolve the cause before altering the instruction. Repeatedly nudging values until accepted can silently enlarge risk.

For frontier trading agents, this is a concrete test of whether executable actions remain faithful to authorized intent. This mathematical adapter check leaves economic success as a separate evaluation question.

Fit the receipt into the full trace

Our execution and settlement framework connects these mechanics to recorded outcomes. The operating-layer controls paper explains why the machinery around an agent deserves its own evaluation.