Make Evelyn Mission Control's Perps tab show collateral, leverage, estimated closing value, unrealized PnL and gross exposure, with useful group and portfolio totals. The owner wants a first working version that can be inspected with real numbers before further presentation refinement.
This is an implementation task, following the existing Jupiter and Phoenix integrations (#98 and #99). It supports the owner's ability to inspect Evelyn's capital and risk. Keep the implementation read-only and limited to the existing configured wallets and environments.
Presentation
Use these columns, in order:
Position | Direction | Margin | Collateral | Leverage | Exposure | Value | uPnL
Margin contains the readable text Isolated or Cross. Use text, not custom icons, for this version.
Rename Position size, USD to Exposure, preserving the existing position-size meaning and values. Do not silently change Jupiter's size basis or replace Phoenix's current notional with entry notional.
Make the tree root visible and name it Perpetual Contracts (the corrected spelling of the owner's requested name).
Keep wallet → venue → position for isolated positions. Under Phoenix, introduce a Cross group for each cross-margin account, with its cross positions beneath it. This intentionally supersedes #99's prohibition on an extra subaccount level. Preserve distinct isolated-position identities even when symbols match.
Show readable USD amounts with grouping separators and two decimals, leverage as e.g. 3.25×, and position uPnL as e.g. +$0.09 (+12.9%) or -$1.22 (-18.0%).
Positive uPnL is green, negative red, and rounded zero neutral. Keep signs; do not rely on color alone. Avoid displaying signed negative zero.
Keep existing faint Long/Short row backgrounds. Group rows have no direction color; group labels/totals should be visually distinguishable.
Right-align numeric columns and choose widths that remain usable in the existing EMC window. Use tooltips for definitions and unsupported values.
Missing/unsupported values display —, never a fabricated zero. Group direction and inapplicable ratios are blank.
Numerical contract
Exposure and aggregation
Exposure is gross, with positive absolute notionals for both Long and Short. For example, $100 Long + $100 Short totals $200, not zero.
Sum Exposure and dollar uPnL through all hierarchy levels to the root, independently of expansion state.
Never sum or average leverage or uPnL percentages. Leave aggregate uPnL percentages blank in this version.
Value totals must count each isolated position and each shared cross account exactly once. Do not add both a Cross group and its descendant values.
A missing required component makes that field's aggregate unavailable; never present a partial sum as a complete total. A successfully read empty scope can total zero. Retained data after failed refreshes keeps the existing last-success behavior and must not be described as fresh.
Isolated positions
Collateral is the actual current collateral amount in USD, as defined by the venue.
Leverage is Exposure / Collateral for this version. Explain that basis in the tooltip; do not confuse it with effective leverage against equity including uPnL. For a nonpositive denominator, display —.
uPnL is the open position's unrealized price PnL before separately accounted funding/fees. Percentage is 100 × uPnL / Collateral when the denominator is positive. Explain the percentage basis.
Value is estimated net proceeds from closing the entire position, using the venue's verified valuation or a documented calculation that includes outstanding funding/borrowing and estimated closing fees. Do not subtract settled fees twice. Include venue-specific collateral valuation and profit caps where applicable.
Explain that Value is an estimate at reference prices, not an executable quote; slippage, swaps and account rent must not be silently presented as included.
Cross-margin accounts and positions
Keep Collateral in USD throughout the column. Do not mix dollars for isolated with utilization percentages for cross, and do not repeat an account-wide percentage on every position.
On a cross-position row, Collateral shows that position's initial margin requirement, with a tooltip explicitly explaining that it is a requirement against shared collateral, not separately deposited or owned collateral. Use Phoenix's actual size-dependent margin rules, including tier interpolation/rounding. Do not substitute maintenance margin or allocate account collateral in proportion to exposure.
On the Cross group, Collateral shows the actual shared collateral balance in USD, counted once. It is not the sum of child margin requirements. Handle non-USDC collateral correctly or mark affected valuations unavailable; do not ignore it.
Cross-position uPnL in USD is independently computable. Match Phoenix's position ROI percentage only if its definition can be verified; otherwise display the dollar amount alone and explain the missing percentage in a tooltip.
Cross-position Value displays —: there is no uniquely owned collateral portion to return on closing that one position.
Cross-group Value shows estimated net account value after closing its positions, including unused shared collateral and applicable unsettled funding/estimated closing fees. Therefore wallet/root Value includes free capital held in the included cross accounts, not just margin consumed by open positions. It does not include unrelated wallet balances.
Keep a valid cross account with nonzero collateral visible even when it has no open positions, so its value does not disappear when its last position closes. Do not create synthetic positions to represent balances.
Cross-position leverage should match Phoenix's displayed convention only if that convention is verified. Otherwise display — with a tooltip directing attention to the Cross group. Never label the market's maximum allowed leverage as actual position leverage.
Show effective leverage on the Cross group as sum(absolute position notionals) / account equity before estimated exit fees, with a tooltip. Use undiscounted equity, not risk-adjusted effective collateral. Use — when the denominator is nonpositive or unavailable. Other group leverage cells stay blank.
A full account margin-utilization percentage is out of scope for this first version. It would require accounting for open orders and Phoenix's risk adjustments as well as positions; a position-only fraction must not be labeled account utilization.
These fallbacks deliberately keep the first version implementable without inventing Phoenix UI semantics. Missing Cross ROI/leverage must be identified in the delivery notes, not claimed as implemented parity with Phoenix.
Existing code and data sources
Start by inspecting these .tjava sources:
com/r35157/evelyn/emc/impl/ref/PerpsTab.tjava: existing tree, formatting and identity reconciliation.
com/r35157/evelyn/service/perps/PerpsSnapshot.tjava: currently carries only instrument, direction and size; extend it to represent actual account balances separately from positions.
com/r35157/evelyn/service/perps/impl/ref/EvelynPerpsServiceImpl.tjava: background refresh and per-wallet/per-venue last-success retention.
com/r35157/libs/phoenix/perps/ and its impl/ref/PhoenixPerpsServiceImpl.tjava: existing REST adapter, decimal conversion, pacing and cooldown.
com/r35157/libs/jupiter/perps/impl/anchoridl/AnchorIdlJupiterPerpsServiceImpl.tjava: Value, PnL, PnL percentage, leverage and market price are currently dummy zeros. Do not wire those placeholders into the new columns.
Jupiter's official CLI client provides a promising read-only source: GET https://perps-api.jup.ag/v2/positions?walletAddress=.... Its published response has count, dataList, position identity, sizeUsd, collateralUsd, valueUsd, leverage, markPriceUsd, fee fields, and PnL before/after fees. Verify current response units and semantics, including percentage scaling, completeness and fees, against actual reads before adopting it. Prefer a coherent venue snapshot over merging unmatched on-chain/API observations. Keep existing signing, trading, alarm and entry-price behavior intact; limit any new valuation read path to the overview's needs.
For Phoenix, use official trader state, market metadata and mark prices. Relevant inputs include shared collateral, spot collateral, basePositionLots, virtualQuotePositionLots, unsettledFundingQuoteLots, leverage tiers and fee overrides. Verify units against the SDK: quote lots are 1e-6 USD; base-lot exponents vary by market. Derive PnL using precise virtual quote/base amounts rather than rounded displayed entry prices. Handle pending funding and fee overrides explicitly.
Use exact decimal/integer arithmetic. Round monetary display values only at the presentation boundary, except required venue rounding. Keep venue-specific calculations in the integrations/service layer, not JavaFX cells. No general financial platform or new wallet-configuration system is needed.
Preserve operational behavior
Existing PROD and TEST wallet lists and data separation.
Initial background refresh and 60-second delay after each completed cycle; no overlapping refresh cycles.
EMC's three-second, parameterless in-memory snapshot reads and visibility lifecycle; no external requests on the UI thread or from snapshot access.
Independent failure retention for each wallet/venue; valid empty results clear that scope, failures do not. A failure for one venue/wallet does not block attempts for the others.
Bounded HTTP timeouts, interruptibility, existing Phoenix request pacing and 429 cooldown. Avoid introducing a per-position request explosion.
Stable IDs, deterministic order, immutable published snapshots, preserved selection/expansion and no flicker on unchanged snapshots.
No sample data in the application, Refresh button, trading, signing, account activation, deposits/withdrawals, or automatic live Hub restart/deployment.
Acceptance and verification
All eight columns and the visible Perpetual Contracts root render correctly in both environments.
Jupiter and Phoenix isolated rows show verified collateral, defined leverage, price uPnL and estimated Value; unsupported individual values are explicitly unavailable, not zero.
Phoenix Cross groups count collateral/Value once, expose effective account leverage, and preserve balances after the last position closes.
Same-market cross and isolated positions remain distinct; account membership is never inferred from the instrument label.
Gross exposure, signed dollar uPnL and Value totals are correct at venue, wallet and root levels, including collapsed groups and empty accounts.
A hand-checkable case with two cross positions proves no shared-collateral double counting; a $100 Long/$100 Short case totals $200 Exposure.
Compare at least one currently funded configured wallet against read-only venue data. Record observation time and valuation definitions; counts/prices are observations, not fixed expectations.
Inspect a standalone JavaFX preview/screenshot with real read-only data where available, and controlled edge cases separately. Check readability, colors, tooltip definitions and preserved tree state. Do not start the full trading Hub merely to verify the view.
Run the normal build and existing relevant checks. Follow repository/OpenSpec instructions on test placement; temporary focused verification harnesses are acceptable, and no new permanent test suite is requested.
Update applicable OpenSpec requirements, project documentation and relevant r35157_docs documentation. Record known unavailable metrics, valuation approximations and refresh limitations.
Suggested implementation sequence: establish the snapshot/account contract and definitions; implement and independently verify venue values; add tree aggregation and formatting; inspect the preview and finish verification/documentation. Follow AGENTS.md, the canonical Evelyn-first prioritization and existing ValueTag rules. Edit .tjava sources, not generated Java. Do not modify shared detag.conf without the owner's explicit approval.
Make Evelyn Mission Control's Perps tab show collateral, leverage, estimated closing value, unrealized PnL and gross exposure, with useful group and portfolio totals. The owner wants a first working version that can be inspected with real numbers before further presentation refinement.
This is an implementation task, following the existing Jupiter and Phoenix integrations (#98 and #99). It supports the owner's ability to inspect Evelyn's capital and risk. Keep the implementation read-only and limited to the existing configured wallets and environments.
## Presentation
Use these columns, in order:
`Position | Direction | Margin | Collateral | Leverage | Exposure | Value | uPnL`
- `Margin` contains the readable text `Isolated` or `Cross`. Use text, not custom icons, for this version.
- Rename `Position size, USD` to `Exposure`, preserving the existing position-size meaning and values. Do not silently change Jupiter's size basis or replace Phoenix's current notional with entry notional.
- Make the tree root visible and name it **Perpetual Contracts** (the corrected spelling of the owner's requested name).
- Keep wallet → venue → position for isolated positions. Under Phoenix, introduce a **Cross** group for each cross-margin account, with its cross positions beneath it. This intentionally supersedes #99's prohibition on an extra subaccount level. Preserve distinct isolated-position identities even when symbols match.
- Show readable USD amounts with grouping separators and two decimals, leverage as e.g. `3.25×`, and position uPnL as e.g. `+$0.09 (+12.9%)` or `-$1.22 (-18.0%)`.
- Positive uPnL is green, negative red, and rounded zero neutral. Keep signs; do not rely on color alone. Avoid displaying signed negative zero.
- Keep existing faint Long/Short row backgrounds. Group rows have no direction color; group labels/totals should be visually distinguishable.
- Right-align numeric columns and choose widths that remain usable in the existing EMC window. Use tooltips for definitions and unsupported values.
- Missing/unsupported values display `—`, never a fabricated zero. Group direction and inapplicable ratios are blank.
## Numerical contract
### Exposure and aggregation
- Exposure is **gross**, with positive absolute notionals for both Long and Short. For example, $100 Long + $100 Short totals $200, not zero.
- Sum Exposure and dollar uPnL through all hierarchy levels to the root, independently of expansion state.
- Never sum or average leverage or uPnL percentages. Leave aggregate uPnL percentages blank in this version.
- Value totals must count each isolated position and each shared cross account exactly once. Do not add both a Cross group and its descendant values.
- A missing required component makes that field's aggregate unavailable; never present a partial sum as a complete total. A successfully read empty scope can total zero. Retained data after failed refreshes keeps the existing last-success behavior and must not be described as fresh.
### Isolated positions
- Collateral is the actual current collateral amount in USD, as defined by the venue.
- Leverage is `Exposure / Collateral` for this version. Explain that basis in the tooltip; do not confuse it with effective leverage against equity including uPnL. For a nonpositive denominator, display `—`.
- uPnL is the open position's unrealized price PnL before separately accounted funding/fees. Percentage is `100 × uPnL / Collateral` when the denominator is positive. Explain the percentage basis.
- Value is estimated net proceeds from closing the entire position, using the venue's verified valuation or a documented calculation that includes outstanding funding/borrowing and estimated closing fees. Do not subtract settled fees twice. Include venue-specific collateral valuation and profit caps where applicable.
- Explain that Value is an estimate at reference prices, not an executable quote; slippage, swaps and account rent must not be silently presented as included.
### Cross-margin accounts and positions
- Keep Collateral in USD throughout the column. Do **not** mix dollars for isolated with utilization percentages for cross, and do not repeat an account-wide percentage on every position.
- On a cross-position row, Collateral shows that position's **initial margin requirement**, with a tooltip explicitly explaining that it is a requirement against shared collateral, not separately deposited or owned collateral. Use Phoenix's actual size-dependent margin rules, including tier interpolation/rounding. Do not substitute maintenance margin or allocate account collateral in proportion to exposure.
- On the Cross group, Collateral shows the actual shared collateral balance in USD, counted once. It is not the sum of child margin requirements. Handle non-USDC collateral correctly or mark affected valuations unavailable; do not ignore it.
- Cross-position uPnL in USD is independently computable. Match Phoenix's position ROI percentage only if its definition can be verified; otherwise display the dollar amount alone and explain the missing percentage in a tooltip.
- Cross-position Value displays `—`: there is no uniquely owned collateral portion to return on closing that one position.
- Cross-group Value shows estimated net account value after closing its positions, including unused shared collateral and applicable unsettled funding/estimated closing fees. Therefore wallet/root Value includes free capital held in the included cross accounts, not just margin consumed by open positions. It does not include unrelated wallet balances.
- Keep a valid cross account with nonzero collateral visible even when it has no open positions, so its value does not disappear when its last position closes. Do not create synthetic positions to represent balances.
- Cross-position leverage should match Phoenix's displayed convention only if that convention is verified. Otherwise display `—` with a tooltip directing attention to the Cross group. Never label the market's maximum allowed leverage as actual position leverage.
- Show effective leverage on the Cross group as `sum(absolute position notionals) / account equity before estimated exit fees`, with a tooltip. Use undiscounted equity, not risk-adjusted effective collateral. Use `—` when the denominator is nonpositive or unavailable. Other group leverage cells stay blank.
- A full account margin-utilization percentage is **out of scope for this first version**. It would require accounting for open orders and Phoenix's risk adjustments as well as positions; a position-only fraction must not be labeled account utilization.
These fallbacks deliberately keep the first version implementable without inventing Phoenix UI semantics. Missing Cross ROI/leverage must be identified in the delivery notes, not claimed as implemented parity with Phoenix.
## Existing code and data sources
Start by inspecting these `.tjava` sources:
- `com/r35157/evelyn/emc/impl/ref/PerpsTab.tjava`: existing tree, formatting and identity reconciliation.
- `com/r35157/evelyn/service/perps/PerpsSnapshot.tjava`: currently carries only instrument, direction and size; extend it to represent actual account balances separately from positions.
- `com/r35157/evelyn/service/perps/impl/ref/EvelynPerpsServiceImpl.tjava`: background refresh and per-wallet/per-venue last-success retention.
- `com/r35157/libs/phoenix/perps/` and its `impl/ref/PhoenixPerpsServiceImpl.tjava`: existing REST adapter, decimal conversion, pacing and cooldown.
- `com/r35157/libs/jupiter/perps/impl/anchoridl/AnchorIdlJupiterPerpsServiceImpl.tjava`: **Value, PnL, PnL percentage, leverage and market price are currently dummy zeros. Do not wire those placeholders into the new columns.**
- `com/r35157/nenjim/hubd/impl/ref/NenjimHubImpl.tjava`: environment wiring.
Jupiter's official CLI client provides a promising read-only source: `GET https://perps-api.jup.ag/v2/positions?walletAddress=...`. Its published response has `count`, `dataList`, position identity, `sizeUsd`, `collateralUsd`, `valueUsd`, `leverage`, `markPriceUsd`, fee fields, and PnL before/after fees. Verify current response units and semantics, including percentage scaling, completeness and fees, against actual reads before adopting it. Prefer a coherent venue snapshot over merging unmatched on-chain/API observations. Keep existing signing, trading, alarm and entry-price behavior intact; limit any new valuation read path to the overview's needs.
For Phoenix, use official trader state, market metadata and mark prices. Relevant inputs include shared collateral, spot collateral, `basePositionLots`, `virtualQuotePositionLots`, `unsettledFundingQuoteLots`, leverage tiers and fee overrides. Verify units against the SDK: quote lots are 1e-6 USD; base-lot exponents vary by market. Derive PnL using precise virtual quote/base amounts rather than rounded displayed entry prices. Handle pending funding and fee overrides explicitly.
Use exact decimal/integer arithmetic. Round monetary display values only at the presentation boundary, except required venue rounding. Keep venue-specific calculations in the integrations/service layer, not JavaFX cells. No general financial platform or new wallet-configuration system is needed.
## Preserve operational behavior
- Existing PROD and TEST wallet lists and data separation.
- Initial background refresh and 60-second delay after each completed cycle; no overlapping refresh cycles.
- EMC's three-second, parameterless in-memory snapshot reads and visibility lifecycle; no external requests on the UI thread or from snapshot access.
- Independent failure retention for each wallet/venue; valid empty results clear that scope, failures do not. A failure for one venue/wallet does not block attempts for the others.
- Bounded HTTP timeouts, interruptibility, existing Phoenix request pacing and 429 cooldown. Avoid introducing a per-position request explosion.
- Stable IDs, deterministic order, immutable published snapshots, preserved selection/expansion and no flicker on unchanged snapshots.
- No sample data in the application, Refresh button, trading, signing, account activation, deposits/withdrawals, or automatic live Hub restart/deployment.
## Acceptance and verification
- [ ] All eight columns and the visible `Perpetual Contracts` root render correctly in both environments.
- [ ] Jupiter and Phoenix isolated rows show verified collateral, defined leverage, price uPnL and estimated Value; unsupported individual values are explicitly unavailable, not zero.
- [ ] Phoenix Cross groups count collateral/Value once, expose effective account leverage, and preserve balances after the last position closes.
- [ ] Same-market cross and isolated positions remain distinct; account membership is never inferred from the instrument label.
- [ ] Gross exposure, signed dollar uPnL and Value totals are correct at venue, wallet and root levels, including collapsed groups and empty accounts.
- [ ] A hand-checkable case with two cross positions proves no shared-collateral double counting; a $100 Long/$100 Short case totals $200 Exposure.
- [ ] Verify positive/negative/zero PnL, zero denominators, missing metrics, unknown collateral, funding signs, fee accounting, size-dependent margin tiers, failed refresh and successful empty responses.
- [ ] Compare at least one currently funded configured wallet against read-only venue data. Record observation time and valuation definitions; counts/prices are observations, not fixed expectations.
- [ ] Inspect a standalone JavaFX preview/screenshot with real read-only data where available, and controlled edge cases separately. Check readability, colors, tooltip definitions and preserved tree state. Do not start the full trading Hub merely to verify the view.
- [ ] Run the normal build and existing relevant checks. Follow repository/OpenSpec instructions on test placement; temporary focused verification harnesses are acceptable, and no new permanent test suite is requested.
- [ ] Update applicable OpenSpec requirements, project documentation and relevant `r35157_docs` documentation. Record known unavailable metrics, valuation approximations and refresh limitations.
Suggested implementation sequence: establish the snapshot/account contract and definitions; implement and independently verify venue values; add tree aggregation and formatting; inspect the preview and finish verification/documentation. Follow AGENTS.md, the canonical Evelyn-first prioritization and existing ValueTag rules. Edit `.tjava` sources, not generated Java. Do not modify shared `detag.conf` without the owner's explicit approval.
## References
- [Jupiter official CLI Perps client](https://github.com/jup-ag/cli/blob/main/src/clients/PerpsClient.ts)
- [Jupiter position account](https://developers.jup.ag/docs/perps/position-account)
- [Phoenix account model](https://docs.phoenix.trade/sdk/accounts)
- [Phoenix margin math](https://docs.phoenix.trade/phoenix/margin-and-risk/margin-math)
- [Phoenix SDK margin](https://docs.phoenix.trade/sdk/margin)
- [Phoenix PnL and fee separation](https://docs.phoenix.trade/phoenix/margin-and-risk/entry-price-pnl)
- [Phoenix SDK source](https://github.com/Ellipsis-Labs/rise-public)
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.
Make Evelyn Mission Control's Perps tab show collateral, leverage, estimated closing value, unrealized PnL and gross exposure, with useful group and portfolio totals. The owner wants a first working version that can be inspected with real numbers before further presentation refinement.
This is an implementation task, following the existing Jupiter and Phoenix integrations (#98 and #99). It supports the owner's ability to inspect Evelyn's capital and risk. Keep the implementation read-only and limited to the existing configured wallets and environments.
Presentation
Use these columns, in order:
Position | Direction | Margin | Collateral | Leverage | Exposure | Value | uPnLMargincontains the readable textIsolatedorCross. Use text, not custom icons, for this version.Position size, USDtoExposure, preserving the existing position-size meaning and values. Do not silently change Jupiter's size basis or replace Phoenix's current notional with entry notional.3.25×, and position uPnL as e.g.+$0.09 (+12.9%)or-$1.22 (-18.0%).—, never a fabricated zero. Group direction and inapplicable ratios are blank.Numerical contract
Exposure and aggregation
Isolated positions
Exposure / Collateralfor this version. Explain that basis in the tooltip; do not confuse it with effective leverage against equity including uPnL. For a nonpositive denominator, display—.100 × uPnL / Collateralwhen the denominator is positive. Explain the percentage basis.Cross-margin accounts and positions
—: there is no uniquely owned collateral portion to return on closing that one position.—with a tooltip directing attention to the Cross group. Never label the market's maximum allowed leverage as actual position leverage.sum(absolute position notionals) / account equity before estimated exit fees, with a tooltip. Use undiscounted equity, not risk-adjusted effective collateral. Use—when the denominator is nonpositive or unavailable. Other group leverage cells stay blank.These fallbacks deliberately keep the first version implementable without inventing Phoenix UI semantics. Missing Cross ROI/leverage must be identified in the delivery notes, not claimed as implemented parity with Phoenix.
Existing code and data sources
Start by inspecting these
.tjavasources:com/r35157/evelyn/emc/impl/ref/PerpsTab.tjava: existing tree, formatting and identity reconciliation.com/r35157/evelyn/service/perps/PerpsSnapshot.tjava: currently carries only instrument, direction and size; extend it to represent actual account balances separately from positions.com/r35157/evelyn/service/perps/impl/ref/EvelynPerpsServiceImpl.tjava: background refresh and per-wallet/per-venue last-success retention.com/r35157/libs/phoenix/perps/and itsimpl/ref/PhoenixPerpsServiceImpl.tjava: existing REST adapter, decimal conversion, pacing and cooldown.com/r35157/libs/jupiter/perps/impl/anchoridl/AnchorIdlJupiterPerpsServiceImpl.tjava: Value, PnL, PnL percentage, leverage and market price are currently dummy zeros. Do not wire those placeholders into the new columns.com/r35157/nenjim/hubd/impl/ref/NenjimHubImpl.tjava: environment wiring.Jupiter's official CLI client provides a promising read-only source:
GET https://perps-api.jup.ag/v2/positions?walletAddress=.... Its published response hascount,dataList, position identity,sizeUsd,collateralUsd,valueUsd,leverage,markPriceUsd, fee fields, and PnL before/after fees. Verify current response units and semantics, including percentage scaling, completeness and fees, against actual reads before adopting it. Prefer a coherent venue snapshot over merging unmatched on-chain/API observations. Keep existing signing, trading, alarm and entry-price behavior intact; limit any new valuation read path to the overview's needs.For Phoenix, use official trader state, market metadata and mark prices. Relevant inputs include shared collateral, spot collateral,
basePositionLots,virtualQuotePositionLots,unsettledFundingQuoteLots, leverage tiers and fee overrides. Verify units against the SDK: quote lots are 1e-6 USD; base-lot exponents vary by market. Derive PnL using precise virtual quote/base amounts rather than rounded displayed entry prices. Handle pending funding and fee overrides explicitly.Use exact decimal/integer arithmetic. Round monetary display values only at the presentation boundary, except required venue rounding. Keep venue-specific calculations in the integrations/service layer, not JavaFX cells. No general financial platform or new wallet-configuration system is needed.
Preserve operational behavior
Acceptance and verification
Perpetual Contractsroot render correctly in both environments.r35157_docsdocumentation. Record known unavailable metrics, valuation approximations and refresh limitations.Suggested implementation sequence: establish the snapshot/account contract and definitions; implement and independently verify venue values; add tree aggregation and formatting; inspect the preview and finish verification/documentation. Follow AGENTS.md, the canonical Evelyn-first prioritization and existing ValueTag rules. Edit
.tjavasources, not generated Java. Do not modify shareddetag.confwithout the owner's explicit approval.References