Logx
Logx Separated Position Request Submission From Execution and a Verified Exit
Logx separated a perpetual position action into a submitted request and a keeper-executed state change. The wallet transaction that submitted a request did not prove that a position opened or closed. The documented path reached a terminal state only after the position changed, collateral returned or withdrawn funds reached the receiver.
The short version: Logx required separate proof of request submission, keeper execution and the final position or receiver balance before an exit was complete.
Product availability set the first boundary
Product availability decided whether the documented path applied. The public product screen announced a relaunch, while detailed perpetual material described the request-based venue that preceded it. A function sequence from that venue did not establish that the same market, collateral route or parameters remained available in a replacement product.
An actionable position workflow needed an active market exposing the matching collateral and order path. Without that boundary, a correctly formed legacy request was not a usable trading route. The older mechanics still explain how request states differed, but they do not establish present access.
The product version boundary also affected terminology. A published contract name could accurately describe the earlier system while saying nothing about the relaunch architecture. Keeping those contexts separate prevents a technical walkthrough from becoming an unsupported claim about a newer product.
A submitted request was only the first checkpoint
Submission recorded intent rather than an open position. An increase began with approval for the collateral token and amount. The following request carried token identities, collateral amount, USD size change, direction, acceptable price and an execution fee.
Optional take-profit or stop-loss values could accompany a market request under their own execution-fee requirements. That first transaction created a request for keeper handling. It could later execute or fail, so its receipt proved only that the request had entered the workflow.
The next useful evidence was the position state. No new position meant the entry had not completed. A changed size and collateral record showed that the requested increase had reached the trading state. Acting from the request receipt alone could therefore make a later decrease target a position that did not yet exist.
The same fields led to different state changes
An increase request and a later decrease request described opposite transitions through related fields. Their shared completion standard was observable state, not the requested outcome. Comparing the same dimensions shows where the normal path and an execution edge case required different next actions.
| Field | Increase request | Decrease request | What confirmed the state |
|---|---|---|---|
| Collateral token | Address of the token supplied as collateral | Address of the collateral token for the existing position | The request and resulting position identified the intended collateral token |
| Index token | Address of the token whose price defined the exposure | Address of the index token for the existing position | The decrease targeted the same position identity |
| Size delta | USD value added to position size | USD value removed from position size | The resulting size moved in the requested direction |
| Direction | Long or short flag for the new exposure | Long or short flag of the position being reduced | The decrease matched the open side |
| Acceptable price | Execution boundary for the increase | Execution boundary for the decrease | Keeper execution satisfied the submitted condition |
| Execution fee | At least the market-order minimum exposed by the contract | The market-order minimum exposed by the contract | The call supplied the equivalent native token through its value field |
| Receiver | The sender received collateral back if an increase request terminated | The supplied receiver obtained withdrawn tokens after successful execution | The balance change appeared at the correct address |
| Shared test | Request creation recorded intent | Request creation recorded intent | Only changed position or funds proved completion |
On the normal path, the increase produced a larger position and the later decrease reduced it. When an execution condition failed, the position did not change. The same comparison resolved both outcomes: inspect the remaining size and the balance of the address that should receive funds.
If the state moved, the next action used the new position values. If it did not, returned collateral or an unchanged position had to be reconciled before another request made sense. That decision did not depend on an assumed fill.
Keeper execution converted intent into position state
Keeper execution was the transition between a request and a position change. A keeper watched contract requests and submitted the execution transaction. The wallet transaction that created the request did not perform this second action, which made pending, executed and failed materially different states.
For market orders, the keeper updated the price feed and executed the request in one transaction. The combined operation was intended to reduce front-running exposure around a separate price update. Once it landed, contract state determined the entry or exit that occurred, rather than the earlier quote or request screen.
A request identifier could help locate the action, but it was not completion proof by itself. The account state provided the decisive evidence: a position appeared, its size changed or the relevant funds moved. Each outcome identified the stage that the request actually reached.
Collateral and PnL separated entry from exit
Collateral accounting determined what could appear at exit. An increase moved supplied collateral into the position path. A successful decrease reduced position size and sent withdrawn collateral plus profit and loss (PnL) to the receiver.
PnL could add to or subtract from collateral, while position, borrowing and funding charges could also affect the returned amount under the applicable product rules. The expected transfer therefore was not simply the original collateral plus the raw price movement.
Reconciliation tracked the same values throughout: starting collateral, realized PnL, accumulated charges and destination address. A visible transfer alone did not prove that the full requested size closed. Likewise, a zero remaining position with an unexpected receiver balance pointed to accounting or destination details that still needed resolution.
How did a close request become a verified exit?
A verified exit required both a completed decrease and no unintended residual position. The first wallet transaction merely requested the decrease, so its successful status could not settle the question.
The size delta supplied the intended reduction. A partial value left a smaller position open; a full reduction should have removed the remaining size. Collateral delta had another role: zero meant that no separate leverage adjustment was requested, not that the position reduction was zero.
The receiver supplied the second evidence point. Successful execution sent withdrawn tokens there, which meant that checking only the initiating wallet could create the false impression that funds were missing.
Together, the changed position record and receiver balance separated a verified exit from a pending request, partial close or failed attempt. Once those observations agreed, the next decision concerned the returned assets rather than the old position.
Failed requests returned to a different checkpoint
Failure returned the workflow to a different place depending on the requested action. The documented increase path could terminate when its acceptable price was not fulfilled, with its collateral returning to the sender. That outcome proved that the requested increase never executed; it did not prove that an existing position had closed.
A decrease that had not executed required another reading. The pre-existing position remained the controlling state until an actual reduction appeared, so the absence of a receiver transfer did not justify an automatic retry. A pending request called for waiting. A terminated request required its failure reason to be understood before another request was submitted, because an unchanged position alone did not distinguish the two states.
A second request made sense only after the first request state was known. Otherwise, two requests could describe overlapping intent while the reader was still reconciling the original position. The request status, together with unchanged size or returned funds, identified which branch had occurred.
Liquidation could replace the planned close
Liquidation could end the position before the planned decrease executed. The earlier perpetual model compared remaining collateral, after fees and unrealized PnL, with its maintenance requirement. Falling below that requirement triggered protocol-driven closure rather than the user-directed decrease path.
Liquidation needed separate reconciliation because liquidation charges could reduce the remainder. A historical maintenance percentage or liquidation fee should not be carried into another product generation without matching contract state. In this lifecycle, liquidation evidence explained why the final balance differed from a voluntary close.
A position that disappeared through liquidation was closed, but it did not prove that the submitted decrease request executed. The cause of closure determined which request and balance evidence remained relevant.
The next action followed the verified state
An executed increase moved attention to the live position values. A terminated increase moved it to returned collateral. A partial decrease left size to manage, while a full decrease shifted the task to reconciling receiver funds.
Submission, keeper handling and final state remained separate observations. Treating them as one event obscured the stage at which the workflow stopped. When position size and destination balance agreed with execution, the lifecycle was complete. When they did not, the mismatch identified the next fact to resolve.
Helpful answers about Logx
Must the receiver address match the wallet that created the request?
The documented flow treated the receiver as a separately supplied address. Successful decrease execution sent withdrawn tokens there, while a failed increase refunded the sender. An interface could still constrain the address that may be entered, so the practical checks were the receiver recorded in the submitted request and the resulting balance at that address.
Is a zero collateral delta the same as a zero-size close?
No. In a decrease request, a zero collateral delta meant that no separate leverage adjustment was requested; the size delta controlled how much position size was removed. A full exit therefore depended on the size reduction matching the remaining position, while the collateral-delta field alone could not prove closure.
Does cancelling a pending order also close an existing position?
No. A pending order was an instruction that had not yet changed the position, while closing an existing position required an executed decrease. Removing the order only prevented that instruction from triggering. The current position still had to be checked and, if open, handled through its own close path.
Why is token approval not proof that collateral entered a position?
Token approval only authorized the Order Manager contract to use the specified collateral token and amount. The account still had to submit an increase request, and a keeper had to execute it successfully. Until the resulting position state appeared, approval showed permission rather than collateral movement into an open position.
Could a partial decrease be mistaken for a full exit?
Yes, if only the transaction receipt or returned funds were checked. A decrease could remove part of the size and leave a residual position open. A full exit required the remaining size to disappear and the receiver funds to be reconciled with PnL and applicable charges.
Are legacy fee figures valid for a relaunched Logx product?
Not without current confirmation. Earlier materials separated product variants and exposed minimum execution fees through contract values, while the public product surface announced a relaunch. A replacement venue could use different contracts, assets or parameters. Historical figures describe earlier mechanics; they do not establish the terms of a new product.
Last updated ยท