101: EMC Perps - show Phoenix TWAP progress and time until next suborder
This commit is contained in:
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user