# Long trigger versus execution price — 15 September 2026

No arithmetic or direction bug was found in the observed long position. The old
UI compared an inventory-based activation level with an oracle-based execution
cap. The main long tiles now show the latter, making their meaning comparable
to the short's execution limits. The inactive counterpart is indicative.

## Contract relationship

For long, target base is `N × callDelta(S)` at the current oracle price `S`.
If the inventory-neutral price `X` solves `N × callDelta(X) = held`, the long
buys when `S` is sufficiently **above** `X` and sells when sufficiently **below**.
Minimum quote value and base-quantum rounding create the no-trade gap.

The inventory-derived activation price is not used to price the emitted order.
Buy maximum is oracle × `(1 + slippage)`; sell minimum is oracle ×
`(1 − slippage)`, with the contract's token-atom rounding. Short grid prices
also depend on inventory and their configured oracle window; they need not be
perfectly symmetric around spot.

Source: `ThetaCattlePair.sol` `_preview`, `_callDelta`, `_baseToQuoteDown`,
`_quoteBoundDown`, `_quoteBoundUp`, and `BlackScholesMath.sol`. Independent
review found the relevant source unchanged from deployed source commit
`ebe65df`. This is a scoped pricing check, not a complete contract audit.

## Live arithmetic

See [the raw witness](live-witness.json), recorded at Base block 51,314,988,
14 September 2026 20:55:23 UTC (15 September in Singapore).

| Input or result | Value |
|---|---|
| Oracle, USDC per wstETH | 3,212.876394943420456879 |
| Inventory-neutral price | approximately 3,155.705912 |
| Buy activation estimate | approximately 3,162.567299 |
| Held wstETH | 0.646977490008352754 |
| Contract target wstETH | 0.767881877589088566 |
| Base quantum | 0.00001 wstETH |
| Rounded buy amount | 0.1209 wstETH |
| Maximum payment | 390.378939 USDC |
| Slippage cap | 50 bps |

The independent integer calculation exactly matched both order amounts.
The selected feed-answer ratio exactly matched `oracleState()`. Frontend
delta was 0.7678818776515378; contract delta was 0.767881877651537869.
The lens reported no HF refusal. `getTradeableOrder` also returned the same
amounts with 277 seconds remaining, above the 65-second publication floor.

## Timing and publication

A historical read at block 51,313,347, 20:00:41 UTC, found only a 0.0099-wstETH
rounded gap worth approximately 31.28390863 USDC. It was below the configured
50-USDC minimum. The exact revert was:

```text
PollTryAtEpoch(1789419600, "no order")  // retry at 21:00 UTC
```

By 20:55:23 the gap was large enough for a valid buy. A watchtower obeying that
earlier retry could therefore wait until the next epoch while spot moves away
from the old activation level. Source explicitly schedules ordinary no-order
and HF-refused retries at the next epoch. We did not inspect hosted watchtower
logs, so this is a supported explanation, not proof of its actual polling path.

At the initial CoW API check the account had ten orders, all fulfilled; the
latest was created at 19:00:37 UTC and expired at 20:00. A valid contract preview
does not establish that a corresponding order has been published. The public
[CoW account history](https://explorer.cow.fi/base/address/0x7bbf122149fa2d8727325e3f8f05c6e79c010d58)
is linked from the cards.

## Next-epoch observation

At 21:01:26 UTC, the production CoW API reported a new buy created at
21:00:36.816833 UTC, already fulfilled. It bought 0.09597 wstETH, with a maximum
308.581507 USDC and an executed payment of 306.730614 USDC. The account history
count increased from ten to eleven. The new size differs from the earlier
0.1209-wstETH preview because price and model epoch had advanced. A subsequent
Base read confirmed the held balance increased to 0.742947490061459363 wstETH.
At that later price, the oracle was below the new sell trigger and the contract
correctly previewed a sell. Raw values are in the witness.

This observed publication at the requested retry boundary supports the hourly
retry explanation. It does not establish the exact hosted-watchtower poll logs.
More frequent response would be a backend liveness/design change, distinct from
fixing price arithmetic or renaming the frontend fields.

No transaction, order posting, signature, watchtower configuration or backend
contract change was made during this investigation.