Live access, trading locked

Browse markets, charts and documentation without signing in. Sign in with a Solana or EVM wallet for account actions and testing trades. Choose Live for live market references or Testing for practice orders. Live orders, deposits and withdrawals are blocked at the server; connecting a wallet cannot enable them.

Your testing balance and positions are saved under your verified wallet account. They have no monetary value and never become live collateral. No custody or settlement contracts have been deployed.

Portfolio margin design

Planned positions share collateral. Liquidation depends on total margin equity versus total maintenance and close-fee requirements, rather than one position reaching an isolated liquidation price. The initial calculation core uses integer microdollars and rounds requirements upward.

Two $5,000 positions at 5× have $10,000 gross exposure and a $2,000 combined base initial-margin requirement, before fees. A $1,000 account needs an explicit hedge-credit policy to support them. Being long one coin and short another is not automatically a hedge. Zero size-based slippage does not eliminate divergent prices, manipulation, insolvency or liquidation risk.

Cross-coin hedge credits are not enabled. Unpaid claims do not count as collateral, and the calculation currently gives no extra credit to net unrealized profits. Correlation stresses, concentration limits, oracle/funding design, backed PnL treatment and liquidation execution need calibration before trading can open.

Reference: Hyperliquid margin mechanics

01. Your testing account

Testing begins with $10,000 in practice funds for a new signed-in wallet. The account, positions, history and scenario settings are saved to the account service. Sign in with the same wallet to resume; different wallets have separate accounts. The old anonymous device balance is not imported.

Database ownership rules prevent other accounts from accessing your testing record. Saves use revision checks; if another tab changes the account, reload before continuing. Failed saves pause testing rather than reset the balance. Testing uses a client-calculated, resettable simulation and must not be used for rewards, leaderboards or monetary claims.

Live prices use market references; Scenario prices use synthetic values for controlled experiments. The chart still shows the spot market. Testing retains isolated position margin while the production portfolio-margin rules are developed. Open Testing .

Position controls and automatic closes

In Testing, use Manage beside a position to close 25%, 50%, 75%, all, or a custom percentage. Partial closes release the corresponding margin and allocate entry/exit fees to that portion. Profits still follow the Payout Engine queue. Take-profit and stop-loss triggers can be edited or removed.

Limit orders reserve the required margin and entry fee until filled or canceled. A long limit fills at or below its limit; a short limit fills at or above it. Current leverage and exposure rules are checked again on fill. Orders that no longer qualify are rejected and their reservations released. Close-only markets keep entry orders waiting until they reopen or you cancel.

Live-reference testing positions and orders are checked by a background executor approximately every 30 seconds, including when your browser is closed. It checks liquidation first, then TP/SL, then resting limits. Liquidation uses each position’s existing isolated margin and maintenance requirement. This is not the planned portfolio-margin engine. Trigger prices are not guaranteed fill prices: gaps and downtime use the next valid observed reference. Stale or inconsistent prices pause execution. Scenario prices only move when you change them; background live references never replace scenario prices.

Watchlists and up to three recently viewed markets are saved to your verified account. Mobile Chart, Trade and Positions tabs share the same market selection and chart.

Wallet sign-in and account access

A message signature verifies wallet ownership through the account service. This is not a transaction, token approval or permission to move funds. Solana and EVM wallets are supported. Each verified wallet identity has its own testing account; wallet linking is not enabled.

Sessions are scoped to this browser tab and checked with the server on reload and focus. Signing out clears private account data from the screen while public browsing remains available. Already-issued access tokens expire within 15 minutes; single-use sensitive authorization is still required before funded features.

On a phone, choose Open in Phantom for Solana or Open in MetaMask for EVM. The link opens this site inside the installed wallet app; tap Sign in there and approve the ownership message. The verified session stays inside that wallet browser and does not transfer back to Safari or Brave. Desktop extensions still work. WalletConnect relay and QR sessions are not implemented. Never enter a seed phrase or private key here.

02. Where winning payouts come from

The Payout Engine starts at $0. Realized trading losses and fees grow it. The planned project memecoin may contribute a portion of fees, but no contribution is assumed until funds arrive. Trader deposits and open-position margin are liabilities, not engine income.

On a winning close, original margin is returned after any applicable fees. Profit is paid from available Payout Engine funds. Unpaid profit joins a FIFO queue. In this prototype, the oldest claim may be partially paid, and later claims cannot jump ahead. Queued profit cannot be withdrawn or used as margin. This intentionally differs from some Papertrade features.

Negative engine equity is possible once unpaid claims are counted. A nonnegative cash balance does not establish solvency; open positions can create additional liabilities. A reward token or a growing queue does not create cash.

How Citrus statistics are calculated

Methodology updated September 14, 2026. All dollar figures are USD-denominated. Testing and Scenario dollars have no monetary value. These definitions describe the current implementation; funded execution has not launched.

What each data view measures

Token shows external spot-market data. Market cap, fully diluted valuation (FDV), spot volume and liquidity come from the deepest eligible DEX Screener reference pair. Spot volume is that pair’s reported 24-hour volume, not volume across every venue or activity on Citrus. Market cap and FDV are provider estimates; missing values display as unavailable, and FDV never substitutes for missing market cap. See reference-price selection.

Citrus shows platform activity for the selected market. Platform stats sums all listed markets within the selected scope. Live, live-price Testing and Scenario are stored separately and never combined. Live displays zero because live orders, deposits and withdrawals are locked. Testing records practice trades using market references. Scenario records practice trades using user-adjustable example prices.

Notional trading volume

Fill notional = executed token quantity × execution price in USD
Volume = sum of the absolute notionals of recorded fills

Each user opening and each closing counts once, whether long or short. Opening notional already includes leverage: $200 margin at 5× opens $1,000 of exposure and contributes $1,000 volume, not $200 or $5,000. The opening stores this notional; closing notional uses the quantity actually closed and its exit price. Fees are tracked separately and are not added to volume. No additional counterparty or Payout Engine leg is invented.

Partial closes count only the quantity closed. Market orders, filled limits, take-profit exits, stop-loss exits and liquidation closes all count. A liquidation is one closing fill and is not added twice. Pending, rejected or canceled unfilled orders, reserved margin, deposits, withdrawals, payout queue payments and edits to TP/SL contribute no volume. Repeated saves of the same recorded fill add nothing.

Worked example: ignoring fees, open 2,000 tokens at $0.50 with $200 margin at 5×. Opening volume is $1,000. Close 500 tokens at $0.60: this adds $300 volume, leaving 1,500 tokens open. Close the remaining 1,500 at $0.45: this adds $675. The complete round trip contributes $1,975 volume. The opening and two closes are three fills.

Open interest (OI)

Market long exposure = remaining long quantity × current reference price
Market short exposure = remaining short quantity × current reference price
Market OI = long exposure + short exposure
Platform OI = sum of market OI in USD

Citrus uses gross user exposure: every open user position counts once. Longs and shorts are not netted, and the total is not divided by two. A $1,000 long and a $1,000 short contribute $2,000 OI even when they are in the same market. This convention must be checked before comparing OI with another platform. The synthetic counterparty adds no separate position to this total.

OI measures remaining exposure at current prices, not posted margin, entry notional, account equity, available cash or payout capacity. Price changes can change USD OI without a trade. Closing reduces remaining quantity; pending limit orders add no OI until they fill. In the example above, after the partial close, 1,500 tokens at $0.60 produce $900 OI. If the reference falls to $0.45 before the final close, OI becomes $675. The final close reduces it to zero.

Positions come from the latest saved account state. USD OI is calculated in the viewer’s browser using its current reference quotes, so it is an indicative valuation, not a canonical settlement oracle value. Scenario OI uses the viewer’s locally selected scenario prices; different viewers can value the same simulated quantities differently. The chart depicts a spot pair and may differ from the aggregated reference used for OI.

Time windows, updates and unavailable values

24-hour volume sums fills whose server recording timestamp is within the preceding 24 hours at snapshot generation. It is a rolling window, not a midnight reset. The timestamp is when a saved trade first reaches the metrics log, not the client’s trade time or a blockchain timestamp. A delayed save can therefore enter a later window. Volume since tracking began includes all recorded fills from the collection start shown in Platform stats. Each market and platform total follows the same rules.

The server schedules aggregate snapshots every 30 seconds; the browser polls every 30 seconds. Successful API responses can be cached for 10 seconds at the CDN and 5 seconds in the browser. These are not real-time guarantees: saves, background-tab throttling, scheduling or network failures can cause further delay. The panel’s timestamp is the aggregate snapshot time, shown in your local timezone, not the time of its latest price.

A snapshot older than two minutes, or a failed refresh, is marked delayed. The last valid snapshot can remain visible; without one, statistics show unavailable instead of fabricated zeros. OI requires a positive, finite reference received within 60 seconds and not dated in the future. Missing or stale prices for nonzero exposure display as “—”; if any exposed market cannot be valued, the platform’s corresponding OI total is also unavailable rather than silently excluding it. Zero quantity remains zero even without a quote. Receipt time measures when Citrus received the data, not the age of the provider’s underlying trades.

Recording, resets and data limits

A database trigger observes accepted Testing account saves, records newly seen openings and closes, and updates remaining position quantities. Fill identities prevent duplicate recording; a reset generation separates reused position IDs after a reset. Resetting or deleting an account removes its open exposure but retains already recorded historical volume. Reset itself is not a closing fill, so it can reduce OI without increasing volume. Trimming the on-screen trade history does not erase fills already recorded in the metrics log.

Collection began September 14, 2026. Existing positions were included in outstanding exposure without reconstructing earlier volume from incomplete account histories. Unsaved activity is absent. An event removed from the capped account history before a successful save may never be captured, so lifetime volume means recorded volume since collection began, not a guarantee of every historical trade.

Testing statistics are client-editable practice telemetry. Wallet ownership checks protect access to accounts; they do not independently prove submitted balances or executions. The current totals are not audited, wash-trade-filtered or Sybil-resistant, and no unique-human activity is implied. They are not real-money exchange volume and must not determine competitions, points or airdrops. Those uses need trusted execution, anti-abuse controls and a separate reward ledger.

Public statistics and the read-only metrics API contain aggregates, not wallet addresses or individual orders. Individual records remain private. Controlled development verification records are removed after tests; any future change to these definitions or data correction should be documented here.

Other displayed metrics and rounding

Fills counts recorded openings and closes in the window. Open positions counts remaining position records, not traders or wallets. Fees sums recorded opening and exit fees; it is not simply volume multiplied by the headline rate because Testing exit fees are capped by available position equity. Liquidations counts position closes marked liquidated, while liquidated notional sums their closed quantity × exit price. Both are already included in fill count and volume.

Opening notionals and fees are rounded to six decimal places by the Testing engine. Closing notionals and OI use quantity × price. The interface rounds displayed dollars to cents or compact K/M notation, so adding rounded labels can differ slightly from the unrounded aggregate. Volume counts positive notional for both directions regardless of profit or loss.

The public API provides the underlying aggregates at Live metrics JSON, Testing metrics JSON and Scenario metrics JSON. Its volume fields are USD notionals; longQuantity and shortQuantity are token units and must be multiplied by the corresponding current reference price to reproduce OI. The API does not return an authoritative USD OI quote.

03. Reference prices and execution checks

The displayed reference is a liquidity-capped weighted median of eligible spot-pool prices from DEX Screener. It is not an arithmetic average, a volume-weighted average, or a time-weighted average (TWAP). The current calculation is:

1. Request the listed token’s pool data. Keep only the configured chain and exact base-token contract address, a positive finite USD price, and at least $10,000 reported USD liquidity. Deduplicate by pair address.
2. Find the ordinary median price across those pools. With an even number of pools, average the middle two prices.
3. Remove pools more than 5% above or below that median. If no pool remains, the new reference is unavailable.
4. Give each remaining pool a weight of min(reported USD liquidity, $500,000). The cap limits the weight of any single pool; it does not establish independent liquidity or stop coordinated manipulation.
5. Sort the remaining pools from lowest to highest price. Starting at the lowest, add weights until the cumulative weight reaches at least half the total. That pool’s price becomes the reference. An exact halfway tie selects the lower price at which the threshold is first reached.

Example: three eligible pools quote $0.98 with $100k liquidity, $1.00 with $400k, and $1.02 with $2m. Their capped weights are $100k, $400k and $500k. Total weight is $1m; cumulative weight reaches half at $1.00, so the reference is $1.00.

The browser requests live references every 20 seconds. The background Testing executor requests its own references on its approximately 30-second schedule. Different observation times can produce different values. If a refresh fails, a previously received quote can remain on screen with its original receipt time; after 60 seconds it is no longer eligible for execution. A one-pool market can still produce a reference, so a displayed price does not establish agreement between independent sources.

The DEX Screener chart shows the deepest eligible reference pair, while the header and Testing fills use the aggregate described above. Their prices can therefore differ, as can the time of their latest update. Scenario mode uses user-adjustable synthetic prices for its ticket and trades while the chart continues to show the real spot pair.

Execution checks reject a reference older than 60 seconds or one where (highest accepted pool price − lowest accepted pool price) / reference price > 3%. These checks run after the 5% outlier filter. New Testing orders also have a two-second simulated delay. Receipt time is when Citrus fetched the data; DEX Screener does not supply a verified source timestamp for each sampled reference. These are experimental Testing controls, not a production oracle or proof of resistance to manipulation or MEV.

A production oracle needs qualified independent pools, a robust reference, price-age and confidence checks, chain finality and outage handling, and delayed orders committed before their execution observation. Long averages can become exploitable stale prices. Wash trading can distort volume weighting; multiple pools may share the same economic liquidity.

Per-position, per-side and global exposure must be sized against conservative estimates of attack cost. Market cap alone cannot provide that estimate. Pyth integration guidance · Uniswap oracle mechanics

04. Leverage follows market quality

Testing-only limits: below $100k reported liquidity in the deepest pool, new opens stop; $100k–$1m allows up to 2×; $1m–$5m up to 3×; $5m+ up to 5×. Absolute 24-hour price changes above 30% cap new leverage at 2×. These arbitrary test parameters are not production listing thresholds. 10× remains disabled pending stress tests.

When a limit falls, existing positions retain their stored maintenance requirement and original entry leverage. The limit applies to new positions. A threshold change alone does not liquidate a trader; market losses can. The prototype uses 2.5% of current notional as maintenance plus an exit-fee allowance. Gaps can exhaust margin and create bad debt; recorded gap debt is diagnostic, not recovered from users.

Low-liquidity markets become close-only while reliable pricing remains. Unreliable or stale prices pause execution rather than close traders at a fabricated price. Production retirement needs a preannounced wind-down, settlement methodology, dispute/fallback process and a liveness solution if prices never recover. Merely dropping leverage to 1× or 2× does not solve oracle manipulation.

05. Fees and proposed token

The starting experiment charges 0.10% of position notional on entry and 0.10% on exit, at the respective prices. A $100 margin trade at 5× costs $0.50 to open and approximately $0.50 to close if price is unchanged: about 1% of margin round-trip. All testing trading fees fund the Payout Engine; the production allocation is undecided.

Realized losses earn one testing point per dollar. These points have no value, transferability, revenue claim or voting power. The proposed real token, fee routing, loss rewards, governance, issuance curve and protection against intentional-loss farming are unimplemented and require economic design.

06. Build status & next steps

v0.5.0: Citrus branding, persistent platform statistics, Token / Citrus metrics, and mobile market cap / FDV. Published calculation formulas, worked examples, recording rules and data limitations. Live money actions remain locked.

v0.4.0: mobile wallet-app handoffs, compact mobile tabs, private watchlists and three recent markets, partial closes, editable TP/SL, reserved/cancellable limit orders and a scheduled testing executor. Live financial endpoints remain locked.

v0.3.2: public browsing with on-demand wallet sign-in for account actions; private testing data clears on sign-out and wallet changes.

v0.3.1: Citrus theme, Precision rail, original-theme archive, five more logo concepts, required wallet sign-in, Live/Testing selection, and private saved testing accounts. Live financial actions remain locked.

v0.3.0 · Prelaunch foundation: notional order estimates, custom tick leverage control, separate lab, authenticated account endpoint, server locks for trading/funding and initial portfolio margin calculation core. The design board includes six themes, three logos and three interactive leverage alternatives; a final choice remains open.

v0.2.5 · Wallet accounts: Solana and EVM wallet sign-in integration, verified identities, tab-scoped sessions, rejection/cancellation handling, sign-out and hardened browser headers. Trading remains a wallet-linked testing.

v0.2.4: consistent interface styles, page URLs and browser navigation, static documentation, custom recovery states and design proposals.

v0.2.3: custom keyboard-accessible dropdowns, the Payout Engine name, clearer execution benefits and a cleaner testing account button.

v0.2.2: browser-tested order entry, independent market filters, clearer quote status, chart retry, and compact responsive layouts. Order costs stay visible before submission.

v0.2 · September 10, 2026: a compact trading terminal with a discovery sidebar, searchable ticker selector, spot chart tools, and tabbed balances, positions, orders, history and payouts. Limit orders and TP/SL remain planned.

v0.1 · September 10, 2026: market discovery, live reference adapter, scenario mode, long/short trading, isolated margin, fee accounting, liquidation simulation, FIFO payout queue, portfolio, CSV history, explanatory docs and wallet-linked persistence.

Next: historical stress tests and oracle design; then Solana devnet and Robinhood testnet implementations. Testnet contracts, real token issuance, shared trading balances and public voting are not part of this version. Testing state is private per wallet; production settlement is separate and not deployed. BNB market references support the supplied examples; BNB settlement is not in the priority plan.

Early listings are owner-selected. Community nominations and token voting come later. Every proposed listing may be rejected if its price cannot be supported safely.

Papertrade settlement accounting · Robinhood Chain configuration · Market data API