Extend the existing Perps overview with real Phoenix positions alongside Jupiter. Use the same PROD and TEST wallet lists already configured in NenjimHub.
Scope
Introduce a read-only PhoenixPerpsService integration following the existing separation between service interfaces and implementations.
Retrieve Phoenix trader state through the official REST API.
Inject the Phoenix integration into EvelynPerpsService through NenjimHub.
Include Phoenix in the existing background refresh cycle: initial retrieval on startup, followed by a 60-second delay between completed cycles.
Preserve the parameterless, in-memory getPositionsSnapshot() operation and EMC’s three-second polling interval.
Update project documentation and the relevant system documentation in r35157_docs.
Account and position mapping
Query each configured wallet as the Phoenix authority, using trader PDA index 0, following Phoenix’s documented current user-account model.
Include both cross-margin and isolated subaccounts returned by trader state.
Include only positions with nonzero size.
Use a stable position ID composed of trader PDA index, subaccount index, and market symbol within the wallet’s Phoenix venue. Do not use changing sequence numbers as identity.
Derive Long/Short from the signed position quantity.
Display a readable instrument label such as SOL-PERP.
Populate the USD-size column with the absolute current position notional. Use Phoenix’s documented notional value where available, or calculate it from correctly scaled position quantity and the appropriate mark price.
Verify numeric units and conversion against official documentation. Do not substitute collateral, margin, entry value, or raw lot counts for current USD notional.
Preserve decimal precision and deterministic ordering.
Presentation
Keep the existing three columns and wallet → venue → position hierarchy. Phoenix appears alongside Jupiter under each wallet.
Do not add another tree level for subaccounts. Positions from different subaccounts must remain distinct even when their market symbols match.
Preserve existing formatting, direction colors, selection, and expansion state. Add no sample data or Refresh button.
Refresh and failure behavior
Retain the last successful data independently for each wallet and venue.
A Phoenix failure must not prevent Jupiter from refreshing, and vice versa.
A failure for one wallet must not prevent attempts for the others.
A successful empty result removes that wallet’s previous positions for the corresponding venue only.
Treat HTTP, authentication, malformed-response, and conversion errors as failures, not empty portfolios.
Use bounded request timeouts and log failures.
Keep integration refresh independent of EMC window visibility.
Snapshot reads must never trigger external requests.
Verification reference
During investigation, Phoenix returned 32 nonzero cross-margin positions for:
H5Yrdm7B4FHhTxhPw9SVwFzQyTEL6bAPptZuTyRxcepq
The response contained 30 Long positions and two Short positions, FET and TLT. The other returned subaccounts had no positions.
Use this wallet for live verification, comparing against its current Phoenix state. These counts are observations, not permanent requirements.
Acceptance criteria
PROD and TEST show Phoenix positions only for their existing configured wallets.
Both cross-margin and isolated positions are supported without identity collisions.
Instrument, direction, and USD notional match the corresponding Phoenix data and documented units.
Live verification includes a wallet with actual open positions.
Jupiter behavior remains intact, including when Phoenix requests fail.
Successful refreshes add, update, and remove positions without resetting retained UI state.
Refreshes run asynchronously without overlapping cycles; EMC reads remain inexpensive snapshot operations.
No transaction signing, trading, account activation, or account modification is invoked.
Project documentation and r35157_docs describe the integration, refresh behavior, and known limitations.
Out of scope
Position management, WebSocket streaming, additional columns, stale-data indicators, and a new wallet-configuration system.
Extend the existing Perps overview with real Phoenix positions alongside Jupiter. Use the same PROD and TEST wallet lists already configured in NenjimHub.
**Scope**
- Introduce a read-only `PhoenixPerpsService` integration following the existing separation between service interfaces and implementations.
- Retrieve Phoenix trader state through the official REST API.
- Inject the Phoenix integration into `EvelynPerpsService` through NenjimHub.
- Include Phoenix in the existing background refresh cycle: initial retrieval on startup, followed by a 60-second delay between completed cycles.
- Preserve the parameterless, in-memory `getPositionsSnapshot()` operation and EMC’s three-second polling interval.
- Update project documentation and the relevant system documentation in `r35157_docs`.
**Account and position mapping**
- Query each configured wallet as the Phoenix authority, using trader PDA index `0`, following Phoenix’s documented current user-account model.
- Include both cross-margin and isolated subaccounts returned by trader state.
- Include only positions with nonzero size.
- Use a stable position ID composed of trader PDA index, subaccount index, and market symbol within the wallet’s Phoenix venue. Do not use changing sequence numbers as identity.
- Derive Long/Short from the signed position quantity.
- Display a readable instrument label such as `SOL-PERP`.
- Populate the USD-size column with the absolute current position notional. Use Phoenix’s documented notional value where available, or calculate it from correctly scaled position quantity and the appropriate mark price.
- Verify numeric units and conversion against official documentation. Do not substitute collateral, margin, entry value, or raw lot counts for current USD notional.
- Preserve decimal precision and deterministic ordering.
**Presentation**
Keep the existing three columns and wallet → venue → position hierarchy. Phoenix appears alongside Jupiter under each wallet.
Do not add another tree level for subaccounts. Positions from different subaccounts must remain distinct even when their market symbols match.
Preserve existing formatting, direction colors, selection, and expansion state. Add no sample data or Refresh button.
**Refresh and failure behavior**
- Retain the last successful data independently for each wallet and venue.
- A Phoenix failure must not prevent Jupiter from refreshing, and vice versa.
- A failure for one wallet must not prevent attempts for the others.
- A successful empty result removes that wallet’s previous positions for the corresponding venue only.
- Treat HTTP, authentication, malformed-response, and conversion errors as failures, not empty portfolios.
- Use bounded request timeouts and log failures.
- Keep integration refresh independent of EMC window visibility.
- Snapshot reads must never trigger external requests.
**Verification reference**
During investigation, Phoenix returned 32 nonzero cross-margin positions for:
```text
H5Yrdm7B4FHhTxhPw9SVwFzQyTEL6bAPptZuTyRxcepq
```
The response contained 30 Long positions and two Short positions, FET and TLT. The other returned subaccounts had no positions.
Use this wallet for live verification, comparing against its current Phoenix state. These counts are observations, not permanent requirements.
**Acceptance criteria**
- PROD and TEST show Phoenix positions only for their existing configured wallets.
- Both cross-margin and isolated positions are supported without identity collisions.
- Instrument, direction, and USD notional match the corresponding Phoenix data and documented units.
- Live verification includes a wallet with actual open positions.
- Jupiter behavior remains intact, including when Phoenix requests fail.
- Successful refreshes add, update, and remove positions without resetting retained UI state.
- Refreshes run asynchronously without overlapping cycles; EMC reads remain inexpensive snapshot operations.
- No transaction signing, trading, account activation, or account modification is invoked.
- Project documentation and `r35157_docs` describe the integration, refresh behavior, and known limitations.
**Out of scope**
Position management, WebSocket streaming, additional columns, stale-data indicators, and a new wallet-configuration system.
**References**
- [[Phoenix REST API](https://docs.phoenix.trade/api/index)](https://docs.phoenix.trade/api/index)
- [[Trader state endpoint](https://docs.phoenix.trade/api/trader/get-trader-state)](https://docs.phoenix.trade/api/trader/get-trader-state)
- [[Phoenix account model](https://docs.phoenix.trade/sdk/accounts)](https://docs.phoenix.trade/sdk/accounts)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Extend the existing Perps overview with real Phoenix positions alongside Jupiter. Use the same PROD and TEST wallet lists already configured in NenjimHub.
Scope
PhoenixPerpsServiceintegration following the existing separation between service interfaces and implementations.EvelynPerpsServicethrough NenjimHub.getPositionsSnapshot()operation and EMC’s three-second polling interval.r35157_docs.Account and position mapping
0, following Phoenix’s documented current user-account model.SOL-PERP.Presentation
Keep the existing three columns and wallet → venue → position hierarchy. Phoenix appears alongside Jupiter under each wallet.
Do not add another tree level for subaccounts. Positions from different subaccounts must remain distinct even when their market symbols match.
Preserve existing formatting, direction colors, selection, and expansion state. Add no sample data or Refresh button.
Refresh and failure behavior
Verification reference
During investigation, Phoenix returned 32 nonzero cross-margin positions for:
The response contained 30 Long positions and two Short positions, FET and TLT. The other returned subaccounts had no positions.
Use this wallet for live verification, comparing against its current Phoenix state. These counts are observations, not permanent requirements.
Acceptance criteria
r35157_docsdescribe the integration, refresh behavior, and known limitations.Out of scope
Position management, WebSocket streaming, additional columns, stale-data indicators, and a new wallet-configuration system.
References