For an entry, the potential benefit is straightforward: more net shares for the same total spend, if filled within your approved limits. For an exit before resolution, it is potentially more net proceeds for the same shares, again only if filled within your limits.
Pursuing that improvement should not require constant order babysitting. But permission to maintain an order is not automatically permission to keep trying for longer.
That distinction matters when an automated attempt can involve several successive order instructions. If an instruction is replaced, which deadline still governs the overall attempt?
TickBetter is PRE-ALPHA and currently in development. The automation and deadline-preservation behavior discussed here are proposed requirements, not available functionality.
One attempt, several instructions, one original endpoint
Imagine you have already chosen your Polymarket market and outcome. You approve a budget or share quantity, a price boundary, and an overall stopping time.
The following diagram is fictional. It illustrates a proposed design, not the behavior of TickBetter, Polymarket, or another product.
```text ONE OVERALL ATTEMPT Start -------------------------------- Original stopping time Instruction A Instruction B replaces A Instruction C replaces B
Every replacement remains inside the original waiting window. The endpoint does not move merely because an instruction changes. ```
An instruction might be replaced as part of maintaining the remaining goal. The important question is not whether the replacement has its own expiration setting. It is whether the original authorization to keep trying still ends at the same time.
In this fictional design, a new instruction belongs to the existing attempt. It does not create a fresh waiting window.
A restarted countdown gives different permission
Now consider a second fictional design with the same user, economic goal, price limit, and originally intended endpoint.
Instead of retaining the original stopping time, this design starts a new relative countdown whenever it replaces an instruction. A replacement made later can therefore move the endpoint later.
These designs grant different durations:
- Fixed overall stopping time: routine replacements use only the time remaining in the original window.
- Restarted countdown: each replacement starts another waiting window, potentially extending the attempt beyond the original endpoint.
This comparison does not establish which design would receive more fills or produce a better price. It exposes a difference in what the user has authorized. Neither example describes an existing product implementation.
The decision to make explicit is: does the deadline belong to each instruction, or to the entire attempt?
An order expiration is not a complete automation mandate
Polymarket’s order-placement documentation and order-creation documentation describe expiration at the individual-order level.
That is useful information about an order’s lifetime. On its own, however, it does not establish how a separate automation system would bound a goal containing successive instructions. In particular, it does not tell you whether replacements preserve an original overall stopping time.
A whole-attempt deadline therefore needs its own explicit requirement. It should not be inferred merely from the existence of an expiration control on individual orders.
What less manual maintenance should mean
TickBetter’s planned automation aims to work the remainder after partial fills, reducing routine manual cancel-and-replace work. Planned bounded repricing would pursue the remaining entry or exit goal without chasing beyond a user-confirmed price limit.
The proposed time-bound requirement is equally important: routine maintenance must not silently restart the overall waiting window.
When evaluating such a design, ask:
- Does replacing an instruction preserve the original stopping time?
- Does the remaining goal stay subject to the approved budget or quantity and price boundary?
- Is extending the attempt treated as new permission, rather than an automatic consequence of maintenance?
- Is the deadline distinguished from confirmed order status?
That last distinction prevents a misleading conclusion. Reaching a deadline is not, by itself, evidence that cancellation has completed or that every order’s final status is known. A deadline requirement must not be presented as a guarantee of exact cancellation timing or a confirmed execution outcome.
Keep the economic comparison compact—and complete
For entry, compare total debit including applicable fees, net shares received, and effective entry. A lower spend accompanied by fewer shares is not automatically an improvement; unspent money is not savings.
For a pre-resolution exit, compare the same shares through gross proceeds, applicable fees, net proceeds, and effective exit. Unsold shares are not proceeds. More net proceeds should not be called more profit without the cost basis needed to support that statement.
Neither a fixed deadline nor automated maintenance guarantees a fill or an economic improvement.
The principle to carry forward
Less manual work should mean fewer routine adjustments—not an unnoticed extension of your commitment.
For TickBetter’s proposed PRE-ALPHA design, the requirement is to keep both boundaries intact: pursue potential improvement within the approved price limits, and preserve the original overall stopping time unless the user explicitly authorizes a change.