Entries are optional. Exits are mandatory. The engine is built around that.

How the Loxley AI sell engine works: position tracking, trailing stop-loss evaluation, take-profit ladders, aggregator sell simulation, and the design rule that sells are never blocked by the safety scanner.

Most trading bots invest their cleverness in entries and treat selling as an afterthought. Loxley AI inverts that priority: the sell engine is the most protected subsystem in the stack. This document explains how positions are tracked and how exits — trailing stop-losses, take-profit ladders, manual sells — are executed on Robinhood Chain.

Position tracking

Every executed buy registers a position keyed to the member's wallet and the token contract. The tracker stores entry amount, entry price basis, and the member's configured exit parameters. Position state lives server-side, not in the chat UI, so a member who closes Telegram still has working stops.

Trailing stop-loss mechanics

A trailing stop follows the price up and never follows it down. Concretely, the engine records the highest observed value since entry (the peak) and arms an exit when the current value falls a configured percentage below that peak. Three implementation details matter:

• The peak is trade-based, not candle-based: value is sampled from executable quotes — what the position could actually sell for — rather than from chart midpoints that nobody can transact at.
• The trigger is evaluated continuously, not on an interval timer. After a trigger fires, the exit order goes through the same quoting and simulation pipeline as any sell, at market.
• Partial profits detach cleanly: if a take-profit ladder has already sold part of the position, the trailing stop manages the remainder and recomputes its basis accordingly.

Take-profit ladders

Members can set ladder rungs — for example, sell 25% at +50%, another 25% at +100%. Rungs execute independently of the trailing stop, and each execution updates the tracked remainder. Ladders are how communities institutionalize discipline: nobody has to be brave at 3 AM; the rung was decided at entry.

Aggregator sell simulation leads

Before any exit is broadcast, the engine dry-runs it. Sell simulations query the same aggregator-grade routing used for execution and validate that the position is actually exitable at the quoted terms. If an internal estimate and a route-level simulation disagree, the route-level simulation wins. This catches the classic rug pattern where a chart looks alive but the pool cannot absorb a sell — and it catches V4 hooks that behave differently on exit than on entry.

The prime directive: sells are never blocked

The safety scanner exists to protect entries. It has no veto over exits. A token can be rated critical, a hook can be flagged, a pool can look terminal — and a member's manual sell still executes immediately, with every lane pushing the sale rather than obstructing it. The same holds for automatic exits: stops and ladders fire even when the scanner would forbid a new buy. Protection at entry must never become imprisonment at exit.

Failure handling

If a route fails, the engine retries through alternate routes and RPC endpoints rather than giving up after one attempt. Persistent failures surface to the member with a plain-language status, and operators see aggregate exit-failure signals in their dashboard — never silently.

Next: V4 hook safety scanner → All docs

Built for operators, not slippage goblins. Talk to us →