101: EMC Perps - show Phoenix TWAP progress and time until next suborder
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-10-24
|
||||
@@ -0,0 +1,30 @@
|
||||
# Design
|
||||
|
||||
## Context
|
||||
|
||||
See proposal.md for motivation. Phoenix account reads already fetch one mark per held market and are published atomically per wallet/venue. A failed read retains that venue's complete previous snapshot. EMC reconciles immutable snapshots and has no exchange dependencies.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:** Attach precise, optional TWAP observations to existing positions and preserve their observation time through the service/UI boundary.
|
||||
|
||||
**Non-Goals:** Order placement, rows for unfilled orders, group summaries, new polling loops, live countdown timers or Ticker changes.
|
||||
|
||||
## Decisions
|
||||
|
||||
1. Read one TWAP snapshot per wallet with held positions, through the existing paced HTTP adapter. Validate authority/PDA/subaccount/asset identities against market metadata and trader state. Attach only orders with positive filled base lots and remaining children; never synthesize a position. A TWAP/schema/HTTP failure fails the complete venue read rather than masquerading as order disappearance. Independent partial TWAP refresh/cache would require a larger status model.
|
||||
2. Keep dedicated immutable Phoenix and Evelyn TWAP domain records, with exact integer counts, decimal quantities, a nullable mark and observation/estimated instants. Existing position constructor overloads remain convenient for consumers without TWAP data. A valid absent mark yields unknown price-dependent metrics and still exposes quantities; invalid prices and HTTP failures remain errors.
|
||||
3. Anchor `dueSlot - snapshot.slot` at response receipt and use nominal 200 ms per slot. Completion is `dueSlot + (remaining - 1) × cooldownSlots`; expiry is never used as completion. Already-due schedules, expiry before completion and unrepresentable estimates yield unavailable timing. These estimates require no new RPC client, network dependency or sampling cache. The current nominal 200 ms is documented by the [Solana Foundation](https://solana.com/fr/upgrades/reduced-slot-times), updated October 2026 (400 ms is obsolete). Measured slot duration is deferred; nominal estimates and observation age are explicit in tooltips/docs.
|
||||
4. Decode snapshot counts as total children including dust. Explicit dust subtracts its count from total; legacy positive dust size with zero count replaces one final regular child. Missing dust metadata makes sizes unknown, never silently assumes an equal split. The next child switches to dust once regular children have executed.
|
||||
5. Append a graphic TWAP column using a ProgressBar and overlaid duration label. Counters measure execution count, with fills shown separately. Duration uses integer total hours and updates only with new snapshots. Failed venues show `Retained` instead of a fresh countdown. Tooltips show approximate USD values from the same mark already used for the position and state snapshot timing limitations.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- Nominal slot speed, API lag and delayed child execution → label estimates, show observation time, do not imply actual execution or advance counts locally.
|
||||
- More sequential reads → retain shared pacing/cooldown, skip TWAP reads without held positions; preserve 60-second post-cycle pause.
|
||||
- Nullable marks affect valuations → propagate unknowns into affected totals rather than publish partial totals or hide held positions.
|
||||
- Completed orders can disappear from the active endpoint → no historical completion claim or synthetic completed-order cache.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
No persisted data or configuration changes. Build and inspect focused temporary harnesses/JavaFX previews, update existing documentation and sync the three delta specs. Leave the running Hub untouched; rollback is reverting the source change before a normal owner-controlled deployment.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Proposal
|
||||
|
||||
## Why
|
||||
|
||||
The owner needs to distinguish ongoing Phoenix TWAP execution from the current position size in EMC. Issue #101 requests progress and the estimated wait until the next child without changing refresh frequency or exposing unfilled orders.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Read Phoenix TWAP snapshots alongside existing account observations and attach only filled orders to matching existing positions.
|
||||
- Add a ninth TWAP column with child-count progress, elapsed-hour duration text and detailed estimated timing/quantity tooltips.
|
||||
- Reuse Phoenix mark prices, preserving quantities when a valid response has no mark price and propagating unknown valuations.
|
||||
- Preserve whole-venue observations on TWAP errors; document periodic timing and nominal slot estimates.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
None.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `phoenix-perps-service`: precise TWAP quantities, identities, optional mark prices and read failure behavior.
|
||||
- `evelyn-perps-service`: immutable TWAP observations on existing positions, with retained venue status.
|
||||
- `evelyn-perps-overview`: TWAP progress, long durations and detailed tooltips.
|
||||
|
||||
## Impact
|
||||
|
||||
Phoenix DTOs/reader, Evelyn snapshot/mapping, JavaFX Perps cells and relevant existing project/shared documentation. No trading, new dependencies, faster polling, commits or pushes.
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Perps overview displays a collapsible position hierarchy
|
||||
The Perps tab SHALL display Position, Direction, Margin, Collateral, Leverage, Exposure, Value, uPnL and TWAP in that order beneath the visible Perpetual Contracts root. Isolated hierarchy SHALL be wallet → venue → position; each Phoenix Cross account SHALL add a Cross group above its positions. Groups SHALL show applicable totals, leave direction/aggregate ratios and TWAP blank, and be expanded by default.
|
||||
|
||||
#### Scenario: Open either environment's Perps tab
|
||||
- **WHEN** the owner opens Perps in Production or Test
|
||||
- **THEN** all nine columns, root totals and the account-aware hierarchy are available, with horizontal scrolling where required
|
||||
|
||||
#### Scenario: Collapse and expand groups
|
||||
- **WHEN** the owner collapses and expands a wallet, venue or Cross account
|
||||
- **THEN** descendants hide and return without changing totals
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: TWAP cells show execution progress and snapshot duration
|
||||
Matching filled Phoenix TWAPs SHALL show a progressbar using executed/total child counts and an overlaid estimated duration to the next child in unbounded hours, minutes and seconds. Other cells SHALL be empty. Updates SHALL follow existing snapshots without a live timer. Failed retained observations SHALL be labeled retained; due or unknown schedules SHALL not show negative or wrapped times or imply execution.
|
||||
|
||||
#### Scenario: Long interval
|
||||
- **WHEN** the snapshot's estimated wait is 28 hours 32 minutes 10 seconds, or 128 hours 32 minutes 10 seconds
|
||||
- **THEN** the text is approximately 28:32:10 or 128:32:10 respectively
|
||||
|
||||
#### Scenario: Failed or due observation
|
||||
- **WHEN** the venue read fails or the latest observed next slot is already due
|
||||
- **THEN** the cell communicates retained or awaiting-update status without advancing progress
|
||||
|
||||
### Requirement: TWAP tooltip distinguishes estimates from fills
|
||||
TWAP tooltips SHALL show executed/total progress, Estimated completion, total size, next child size, filled quantity and observation time. Sizes SHALL include their symbol and approximate USD values from Phoenix mark prices where available. Distinct regular/dust sizes and periodic nominal-slot timing assumptions SHALL be explained. Unknown values SHALL remain unknown; expiry SHALL never be presented as completion.
|
||||
|
||||
#### Scenario: Missing price or smaller next child
|
||||
- **WHEN** the mark price is unavailable or the next child is a smaller rest order
|
||||
- **THEN** token amounts remain visible with unknown USD values, or the next size reflects that rest order respectively
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: TWAP observations belong to existing filled positions
|
||||
The service SHALL publish immutable TWAP observations only on matching existing Phoenix positions whose order has a positive actual fill and remaining executions. It SHALL preserve counters, quantities, nullable price and observation/estimated times without UI formatting. No new position SHALL be synthesized. TWAP errors SHALL retain the complete prior venue observation with failure status. Polling frequency SHALL remain unchanged.
|
||||
|
||||
#### Scenario: Unfilled order or no position
|
||||
- **WHEN** an active TWAP has no actual fills or has no matching open position
|
||||
- **THEN** it is absent from every overview row and cannot create a visible venue
|
||||
|
||||
#### Scenario: TWAP read fails
|
||||
- **WHEN** the TWAP read fails after a successful venue observation
|
||||
- **THEN** prior positions, TWAP observations and original timestamps remain with failed venue status
|
||||
- **AND** other venues and wallets continue refreshing
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Read failures cannot masquerade as empty portfolios
|
||||
HTTP, authentication, malformed schema, identity mismatch and numeric conversion errors SHALL fail the read. Requests SHALL have bounded timeouts. Only a valid response with no nonzero positions SHALL produce an empty result. Present mark prices SHALL be positive and finite; an explicitly absent mark SHALL preserve positions and quantities with unavailable price-dependent valuations.
|
||||
|
||||
#### Scenario: Missing mark price
|
||||
- **WHEN** a valid mark response has no mark price for a held position
|
||||
- **THEN** the position and its TWAP quantities remain present with unknown USD valuations
|
||||
- **AND** affected aggregate valuations remain unknown
|
||||
|
||||
#### Scenario: Rejected access or invalid price
|
||||
- **WHEN** an HTTP request is rejected or a present mark price is invalid
|
||||
- **THEN** the read fails instead of returning an empty or partial portfolio
|
||||
|
||||
#### Scenario: Empty account
|
||||
- **WHEN** a valid trader snapshot has no subaccounts or no nonzero positions
|
||||
- **THEN** an empty result is returned without market-price or TWAP requests
|
||||
|
||||
#### Scenario: Public API rate limit
|
||||
- **WHEN** the shared adapter issues requests for PROD and TEST
|
||||
- **THEN** request starts SHALL be spaced at least one second apart
|
||||
- **AND** HTTP 429 SHALL fail the lookup and establish a shared cooldown from Retry-After (seconds or HTTP date, 60 seconds fallback)
|
||||
- **AND** lookups during cooldown SHALL fail without external calls, with no immediate retry
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Read precise TWAP snapshots for held markets
|
||||
The reader SHALL read official TWAP snapshots through its existing paced transport and associate orders by authority, PDA, subaccount and market identity. Only orders with actual fills and remaining children on an existing position SHALL be exposed. Quantities SHALL use exact lot conversion and explicit/legacy dust semantics. Unavailable size inputs SHALL remain unknown. Existing mark prices SHALL be reused without Ticker reads.
|
||||
|
||||
#### Scenario: Explicit and legacy dust
|
||||
- **WHEN** total children are 5, regular size 10 lots and explicit dust count/size are 2/3
|
||||
- **THEN** total size is 36 lots and the fourth child is 3 lots
|
||||
- **AND** legacy zero dust count with size 3 instead represents four regular children and a final 3-lot child
|
||||
|
||||
#### Scenario: Identity mismatch or unfilled order
|
||||
- **WHEN** authority/PDA/subaccount/asset identities disagree or an order has no fills
|
||||
- **THEN** disagreement fails the read, while a valid unfilled order is absent from returned positions' TWAP data
|
||||
|
||||
### Requirement: TWAP time estimates disclose their slot assumption
|
||||
The reader SHALL estimate future execution times from snapshot slot, due slot and cooldown using a documented nominal slot duration and response observation time. Completion SHALL derive from remaining executions, never expiry. Already-due schedules, invalidated completion schedules and unrepresentable estimates SHALL remain unavailable instead of predicting fills.
|
||||
|
||||
#### Scenario: Expiry before planned completion
|
||||
- **WHEN** the scheduled final child lies beyond the order's expiry
|
||||
- **THEN** the reader does not provide that schedule as an estimated completion time
|
||||
@@ -0,0 +1,16 @@
|
||||
# Tasks
|
||||
|
||||
## 1. Phoenix observations
|
||||
|
||||
- [x] 1.1 Add immutable TWAP data and paced snapshot decoding with precise sizes, identities, nullable marks and estimates; verify with focused temporary fixtures for dust, missing prices, errors and matching.
|
||||
- [x] 1.2 Update Phoenix integration documentation for the implemented endpoint, units and timing/error behavior; verify against code and source contracts.
|
||||
|
||||
## 2. Evelyn and EMC
|
||||
|
||||
- [x] 2.1 Map TWAP data into immutable Evelyn position snapshots and render progressbar cells/tooltips; verify long durations, hidden orders, blank groups and retained failures in temporary service/UI checks.
|
||||
- [x] 2.2 Update existing Evelyn and shared r35157_docs documentation to match the ninth column, visibility and estimate limitations; verify links and remove conflicting claims.
|
||||
|
||||
## 3. Integration verification
|
||||
|
||||
- [x] 3.1 Run the normal build, focused read-only live/fixture checks and JavaFX visual checks; record results and material limitations.
|
||||
- [x] 3.2 Sync delta specs, validate the change and affected main specs, and inspect final diffs without committing or pushing.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Verification — issue #101
|
||||
|
||||
Verified locally on 2026-10-24. No Hub restart, deployment, signing, trading,
|
||||
commit or push was performed. Existing unrelated staged/deleted OpenSpec files
|
||||
were preserved.
|
||||
|
||||
## Build
|
||||
|
||||
`JAVA_HOME=/usr/local/software/java/jfx-25 ./gradlew build` succeeded.
|
||||
All 42 existing tests passed, with zero failures/errors. No permanent tests were
|
||||
added; focused harnesses and screenshots are temporary files under `/tmp`.
|
||||
|
||||
## Focused integration checks
|
||||
|
||||
`Issue101Check` passed 48 checks covering:
|
||||
|
||||
- Explicit, legacy, absent and invalid dust metadata; exact total/next/fill quantities.
|
||||
- Positive fills required even on existing positions; no order-only synthetic rows.
|
||||
- Same-symbol Cross/isolated matching, authority/PDA/asset mismatch and duplicate rejection.
|
||||
- Invalid counters, completed observations, already-due timing, expiry before completion and overflow.
|
||||
- Missing marks preserving token amounts and propagating unknown price-dependent totals.
|
||||
- One TWAP and one mark request for two same-market positions; no extra reads for empty wallets.
|
||||
- HTTP/TWAP failures retaining the complete prior venue observation, original timestamp and independent Jupiter refresh.
|
||||
- Snapshot reads without I/O, recovery clearing absent/unfilled TWAPs, and shared 429 cooldown without immediate retry.
|
||||
- Decoding captured real Phoenix data, including the BTC order with 236 smaller children out of 237 total executions.
|
||||
|
||||
## JavaFX and visual inspection
|
||||
|
||||
`Issue101Preview` passed 33 checks. Inspected the actual rendered table and tooltip:
|
||||
nine columns; visible progress and overlaid `≈ 28:32:10` / `≈ 128:32:10`; blank
|
||||
groups/Jupiter/non-TWAP cells; missing USD values; due/retained labels; tooltip fields;
|
||||
clearing recycled cell graphics/tooltips; preserved selection/expansion; horizontal
|
||||
scrolling at small widths. Temporary captures are under `/tmp/issue101-check/`.
|
||||
|
||||
## Read-only live check
|
||||
|
||||
At 2026-10-24 17:07:27–17:08:03 UTC, the real adapter returned 32 positions and 32
|
||||
active filled TWAPs for the checked PROD wallet and no positions for TEST. Only GET
|
||||
requests were used, with existing pacing/timeouts. Observed SOL order: 890/1779,
|
||||
17.79 SOL total and 0.01 SOL next. Observed BTC order: 119/237, 0.0238 BTC total and
|
||||
0.0001 BTC next. Marks were taken directly from Phoenix, with no Ticker dependency.
|
||||
|
||||
## Specifications and documentation
|
||||
|
||||
- All three deltas synced into existing main specs.
|
||||
- Strict validation passed for `101-phoenix-twap-progress`, `phoenix-perps-service`,
|
||||
`evelyn-perps-service` and `evelyn-perps-overview`.
|
||||
- Project/shared documentation links and `git diff --check` passed.
|
||||
- Checking the entire existing index still reports three trailing-blank-line warnings
|
||||
in the unrelated, pre-existing staged issue #97 specs. The index check passes when
|
||||
restricted to this change; those older files were not edited.
|
||||
|
||||
## Limits
|
||||
|
||||
The current nominal slot duration is 200 ms according to the Solana Foundation's
|
||||
October 2026 update, superseding the old 400 ms assumption. Response receipt is only
|
||||
an approximate time anchor. API lag, varying slot times and execution delays can
|
||||
shift estimates, especially long completion estimates. Cell duration is explicitly
|
||||
as of Updated and does not tick between snapshots. Progress counts child executions,
|
||||
not guaranteed filled quantity. USD sizes are current approximate notionals before
|
||||
fees. The existing polling cycle and live Hub were left unchanged.
|
||||
@@ -7,11 +7,11 @@ Let the owner inspect Evelyn perpetual positions grouped by wallet and venue in
|
||||
## Requirements
|
||||
|
||||
### Requirement: Perps overview displays a collapsible position hierarchy
|
||||
The Perps tab SHALL display Position, Direction, Margin, Collateral, Leverage, Exposure, Value and uPnL in that order beneath the visible Perpetual Contracts root. Isolated hierarchy SHALL be wallet → venue → position; each Phoenix Cross account SHALL add a Cross group above its positions. Groups SHALL show applicable totals, leave direction/aggregate ratios blank, and be expanded by default.
|
||||
The Perps tab SHALL display Position, Direction, Margin, Collateral, Leverage, Exposure, Value, uPnL and TWAP in that order beneath the visible Perpetual Contracts root. Isolated hierarchy SHALL be wallet → venue → position; each Phoenix Cross account SHALL add a Cross group above its positions. Groups SHALL show applicable totals, leave direction/aggregate ratios and TWAP blank, and be expanded by default.
|
||||
|
||||
#### Scenario: Open either environment's Perps tab
|
||||
- **WHEN** the owner opens Perps in Production or Test
|
||||
- **THEN** all eight columns, root totals and the account-aware hierarchy are visible
|
||||
- **THEN** all nine columns, root totals and the account-aware hierarchy are available, with horizontal scrolling where required
|
||||
|
||||
#### Scenario: Collapse and expand groups
|
||||
- **WHEN** the owner collapses and expands a wallet, venue or Cross account
|
||||
@@ -89,3 +89,21 @@ EMC SHALL hide venue rows with neither positions nor Cross accounts and show the
|
||||
- **WHEN** a childless venue has never been read successfully and its first read is pending or failed
|
||||
- **THEN** the heading is hidden and its read status is available on the wallet tooltip
|
||||
- **AND** required totals remain unavailable rather than reporting zero
|
||||
|
||||
### Requirement: TWAP cells show execution progress and snapshot duration
|
||||
Matching filled Phoenix TWAPs SHALL show a progressbar using executed/total child counts and an overlaid estimated duration to the next child in unbounded hours, minutes and seconds. Other cells SHALL be empty. Updates SHALL follow existing snapshots without a live timer. Failed retained observations SHALL be labeled retained; due or unknown schedules SHALL not show negative or wrapped times or imply execution.
|
||||
|
||||
#### Scenario: Long interval
|
||||
- **WHEN** the snapshot's estimated wait is 28 hours 32 minutes 10 seconds, or 128 hours 32 minutes 10 seconds
|
||||
- **THEN** the text is approximately 28:32:10 or 128:32:10 respectively
|
||||
|
||||
#### Scenario: Failed or due observation
|
||||
- **WHEN** the venue read fails or the latest observed next slot is already due
|
||||
- **THEN** the cell communicates retained or awaiting-update status without advancing progress
|
||||
|
||||
### Requirement: TWAP tooltip distinguishes estimates from fills
|
||||
TWAP tooltips SHALL show executed/total progress, Estimated completion, total size, next child size, filled quantity and observation time. Sizes SHALL include their symbol and approximate USD values from Phoenix mark prices where available. Distinct regular/dust sizes and periodic nominal-slot timing assumptions SHALL be explained. Unknown values SHALL remain unknown; expiry SHALL never be presented as completion.
|
||||
|
||||
#### Scenario: Missing price or smaller next child
|
||||
- **WHEN** the mark price is unavailable or the next child is a smaller rest order
|
||||
- **THEN** token amounts remain visible with unknown USD values, or the next size reflects that rest order respectively
|
||||
|
||||
@@ -83,3 +83,15 @@ Each venue SHALL carry its last-success time and whether the latest attempt fail
|
||||
#### Scenario: Retained last success
|
||||
- **WHEN** a subsequent read fails
|
||||
- **THEN** its previous observations remain available with their original success time and failure indication
|
||||
|
||||
### Requirement: TWAP observations belong to existing filled positions
|
||||
The service SHALL publish immutable TWAP observations only on matching existing Phoenix positions whose order has a positive actual fill and remaining executions. It SHALL preserve counters, quantities, nullable price and observation/estimated times without UI formatting. No new position SHALL be synthesized. TWAP errors SHALL retain the complete prior venue observation with failure status. Polling frequency SHALL remain unchanged.
|
||||
|
||||
#### Scenario: Unfilled order or no position
|
||||
- **WHEN** an active TWAP has no actual fills or has no matching open position
|
||||
- **THEN** it is absent from every overview row and cannot create a visible venue
|
||||
|
||||
#### Scenario: TWAP read fails
|
||||
- **WHEN** the TWAP read fails after a successful venue observation
|
||||
- **THEN** prior positions, TWAP observations and original timestamps remain with failed venue status
|
||||
- **AND** other venues and wallets continue refreshing
|
||||
|
||||
@@ -21,15 +21,20 @@ Position direction SHALL follow signed quantity. USD size SHALL be the absolute
|
||||
- **THEN** it represents -1.25 base units, Short direction and 130.5625 USD notional
|
||||
|
||||
### Requirement: Read failures cannot masquerade as empty portfolios
|
||||
HTTP, authentication, malformed schema, identity mismatch and numeric conversion errors SHALL fail the read. Requests SHALL have bounded timeouts. Only a valid response with no nonzero positions SHALL produce an empty result. Required mark prices SHALL be positive and finite.
|
||||
HTTP, authentication, malformed schema, identity mismatch and numeric conversion errors SHALL fail the read. Requests SHALL have bounded timeouts. Only a valid response with no nonzero positions SHALL produce an empty result. Present mark prices SHALL be positive and finite; an explicitly absent mark SHALL preserve positions and quantities with unavailable price-dependent valuations.
|
||||
|
||||
#### Scenario: Missing mark price or rejected access
|
||||
- **WHEN** a required price is missing or an HTTP request is rejected
|
||||
#### Scenario: Missing mark price
|
||||
- **WHEN** a valid mark response has no mark price for a held position
|
||||
- **THEN** the position and its TWAP quantities remain present with unknown USD valuations
|
||||
- **AND** affected aggregate valuations remain unknown
|
||||
|
||||
#### Scenario: Rejected access or invalid price
|
||||
- **WHEN** an HTTP request is rejected or a present mark price is invalid
|
||||
- **THEN** the read fails instead of returning an empty or partial portfolio
|
||||
|
||||
#### Scenario: Empty account
|
||||
- **WHEN** a valid trader snapshot has no subaccounts or no nonzero positions
|
||||
- **THEN** an empty result is returned without market-price requests
|
||||
- **THEN** an empty result is returned without market-price or TWAP requests
|
||||
|
||||
#### Scenario: Public API rate limit
|
||||
- **WHEN** the shared adapter issues requests for PROD and TEST
|
||||
@@ -55,3 +60,22 @@ Equity SHALL include collateral, undiscounted price PnL and signed unsettled fun
|
||||
- **WHEN** collateral is 100 USD, PnL 5 USD, unsettled funding -2 USD, and estimated exit fee 1 USD
|
||||
- **THEN** equity is 103 USD and estimated Value 102 USD
|
||||
- **AND** effective Cross leverage uses 103 USD as its denominator
|
||||
|
||||
### Requirement: Read precise TWAP snapshots for held markets
|
||||
The reader SHALL read official TWAP snapshots through its existing paced transport and associate orders by authority, PDA, subaccount and market identity. Only orders with actual fills and remaining children on an existing position SHALL be exposed. Quantities SHALL use exact lot conversion and explicit/legacy dust semantics. Unavailable size inputs SHALL remain unknown. Existing mark prices SHALL be reused without Ticker reads.
|
||||
|
||||
#### Scenario: Explicit and legacy dust
|
||||
- **WHEN** total children are 5, regular size 10 lots and explicit dust count/size are 2/3
|
||||
- **THEN** total size is 36 lots and the fourth child is 3 lots
|
||||
- **AND** legacy zero dust count with size 3 instead represents four regular children and a final 3-lot child
|
||||
|
||||
#### Scenario: Identity mismatch or unfilled order
|
||||
- **WHEN** authority/PDA/subaccount/asset identities disagree or an order has no fills
|
||||
- **THEN** disagreement fails the read, while a valid unfilled order is absent from returned positions' TWAP data
|
||||
|
||||
### Requirement: TWAP time estimates disclose their slot assumption
|
||||
The reader SHALL estimate future execution times from snapshot slot, due slot and cooldown using a documented nominal slot duration and response observation time. Completion SHALL derive from remaining executions, never expiry. Already-due schedules, invalidated completion schedules and unrepresentable estimates SHALL remain unavailable instead of predicting fills.
|
||||
|
||||
#### Scenario: Expiry before planned completion
|
||||
- **WHEN** the scheduled final child lies beyond the order's expiry
|
||||
- **THEN** the reader does not provide that schedule as an estimated completion time
|
||||
|
||||
Reference in New Issue
Block a user