104: EMC Perps: show estimated Jupiter Value and mark affected totals with ≈

This commit is contained in:
2026-10-26 09:18:29 +01:00
parent cfb49ed896
commit 805e2e7e6e
18 changed files with 338 additions and 36 deletions
+15 -2
View File
@@ -505,8 +505,21 @@ Value er et estimat ved referencepriser, ikke et eksekverbart tilbud. Phoenix me
collateral, pris-uPnL og signed uafregnet funding og fratrækker estimerede takergebyrer
med kontoens fee override. Slippage, price impact, swaps, netværksgebyrer og kontorent
indgår ikke. Ukendt spot-collateral gør de berørte værdiansættelser utilgængelige.
**Jupiter Value er foreløbig utilgængelig**, fordi API'ets netværdi trækker åbningsgebyrer
fra igen, og collateral-/profitloft-semantikken ikke er fuldt verificeret. Se
Jupiters rapporterede `valueUsd` vises uændret som et estimat, fx `≈$123.23`, efter
præcis konvertering fra heltals-mikro-USD. Tooltip forklarer, at det faktiske provenu
ved lukning kan afvige. En tidligere observation trak åbningsgebyrer fra, selvom
collateral allerede var registreret efter gebyrer; gebyrbehandlingen er derfor
usikker, og collateral-/profitloft-semantikken er fortsat ikke verificeret. Det
beviser ikke, at alle API-estimater er forkerte, eller at forskellen kun er små gebyrer.
Der tilføjes ingen gebyrer tilbage og foretages ingen korrigeret netberegning.
Tilgængelige Value-estimater fra både Jupiter og Phoenix samt deres venue-, wallet-
og **Perpetual Contracts**-totaler har ét `≈` foran beløbet. Totalens tooltip forklarer
de bidragende estimatkilder, også ved blandede venues og sammenfoldede grupper.
Nul og negative beløb bevares. Manglende/null Value gør fortsat den berørte total `—`
uden numerisk estimatmarkering; en succesfuldt læst tom gruppe kan give nul. Ugyldige
beløb fejler hele observationen, så tidligere data og oprindelig læsetid bevares med
fejlstatus. En ny succes erstatter den tidligere værdi, også når den nye Value mangler. Se
[Jupiter-overblikket](JupiterPerpsOverview.md) og [Phoenix-integrationen](PhoenixPerps.md)
for datakilder, enheder og beregninger.
+30 -10
View File
@@ -25,7 +25,7 @@ amounts fail the read.
| Leverage | Exposure / positive Collateral; not equity-based leverage |
| uPnL | `pnlBeforeFeesUsd / 10^6`, price PnL before separately reported fees |
| uPnL percent | 100 × uPnL / positive Collateral |
| Value | Unavailable; API net-value semantics have not passed verification |
| Value | `valueUsd / 10^6`, Jupiter's reported estimate, unchanged and displayed with `≈` |
| Risk reference price | Positive `markPriceUsd / 10^6` from the same response |
| Reported liquidation price | Positive `liquidationPriceUsd / 10^6`; missing/nonpositive values are unavailable |
@@ -42,7 +42,26 @@ metrics. Present malformed amounts still fail the read. Isolated signed distance
the owner's neutral-distance policy and expiration are described in
[Perps risk presentation](Evelyn.md#risiko-i-perps).
## Why API Value is not displayed
## Reported Value and its uncertainty
The overview preserves optional `valueUsd` exactly as supplied, including zero
and signed values. EMC displays it with `≈` and two USD decimals (for example,
`≈$123.23`). Its tooltip explains: “Estimated position value reported by Jupiter.
Actual proceeds on closing may differ.” Missing/null values remain unavailable;
present malformed amounts fail the complete observation. Successful observations
replace earlier values, including replacing an estimate with unavailable Value.
Failed reads retain the original observation, success time and failure indication.
Available Jupiter, wallet and Perpetual Contracts Value totals inherit the estimate
qualification independently of expansion state. Mixed Phoenix/Jupiter totals
identify both estimate sources; Phoenix's existing account-aware closing estimates
and single counting of shared Cross capital are preserved. A missing required Value
still makes the affected total `—`, without a numeric approximation marker. A
successfully read empty scope can total zero.
This reports a venue estimate, not verified closing proceeds. It does not add
opening fees back, correct the API number, introduce closing quotes or combine
additional on-chain observations with the response.
On 24 October 2026 the funded configured wallet's six API sizes and collateral
amounts matched read-only on-chain position data. For its SOL Short, the response
@@ -56,14 +75,15 @@ borrowFeesUsd = 7 valueUsd = 35551
`35551 = 18559 + 17721 - 361 - 361 - 7`. The on-chain collateral was also
18559; the official [position account documentation](https://developers.jup.ag/docs/perps/position-account)
defines collateral as after fees. Blindly displaying this API Value would
subtract the settled opening fee again. Adding it back alone does not establish
defines collateral as after fees. This observation raises uncertainty about
subtracting a settled opening fee again; it does not prove that every API estimate
is wrong. Adding that fee back alone would not establish
the full contract: collateral-currency valuation and the `lockedAmount` profit
cap must also be verified. The response does not expose that cap. The overview
therefore shows an em dash with an explanation, and higher Value totals containing
such a position also remain unavailable. It does not merge unmatched on-chain
observations into the API snapshot or build unsigned closing transactions.
cap remain unverified. The response does not expose that cap. The possible difference
from actual closing proceeds is not known to be limited to small fees. Issue #100
therefore withheld Value; [issue #104](https://git.r35157.com/r35157/com_r35157_nenjim-hubd-impl_ref/issues/104)
replaces that presentation with the explicitly qualified venue estimate.
This is a known first-version limitation, not verified closing-value parity with
Jupiter. Counts, amounts and prices above are observations, not fixed expectations.
There is no verified closing-value parity with Jupiter. Counts, amounts and prices
above are historical observations, not fixed expectations.
See the change's `verification.md` for observation times and current checks.