Portfolio console

Nexus is an AI portfolio management platform. Its operating loop observes markets, analyses the regime, decides allocations within the mandate, executes on-chain actions, and reviews outcomes. The console is organized around that loop and the capital it manages.

Main navigation

There are 11 primary destinations and eight supporting screens. / opens Portfolio; the former /treasury address also forwards there.

Area	Page	What you manage or inspect
Portfolio	Overview & performance	NAV, exposure, earning positions, returns, benchmarks, P&L attribution, accounting coverage and external capital flows
Portfolio	Wallets	Squads custody and execution-wallet balances, addresses, reconciliation time, gas and working reserves
Portfolio	Strategy & guardrails	Standing AI mandate, sleeve targets, exposure limits, reserves and live ladder
On-chain tools	Liquidity pools	Your LP positions, ranges, fee income, pool and vault catalogs
On-chain tools	Lending	Your supplied positions, owner, venue, APY, and ranked lending markets
On-chain tools	Orders & swaps	Resting limit orders, account verification, recorded portfolio movements, conversion evidence and transaction links
AI & operations	Analysis & decisions	Analysis briefs, thesis, dream review, standing decisions and proposed order plan
AI & operations	AI cycles	Persisted output freshness, cycle health, degraded specialists and flow status
AI & operations	Market data	Market observations and their history
AI & operations	Execution health	Execution readiness, arming state, price guards, reconciliation and ladder state
AI & operations	Settings	Models and reasoning settings used by portfolio cycles, plus AI usage

Supporting pages are contextual links, not another long sidebar:

• AI cycles: schedules, job history and learning.
• Market data: data health, feature inspector and managed market scope.
• Execution health: custody and spending-limit ceremony.
• Settings: platform logs.

Page search includes both the main destinations and the supporting screens.

Daily workflow

1. Start with Portfolio: check NAV freshness, incomplete sources, earning positions, returns and any accounting disputes.
2. Review Strategy & guardrails and Analysis & decisions to understand the mandate and the rationale for the next allocation.
3. Inspect LP positions, lending, and Orders & swaps to see where the capital sits and what movements were recorded.
4. Check AI cycles and Execution health if the expected action or output is missing. Use the contextual schedule, job-history, market-data and log views to investigate.
5. Use Settings to change cycle models. Use custody controls when the spending authorization needs to change.

The UI continues to use the existing execution and authorization paths. The portfolio refocus does not add a direct swap, supply, LP or limit-order mutation button or broaden the Solana proxy's write allowlist. Strategy and execution status screens describe the existing AI-managed process. Some controls, such as arming and deployment-level limits, remain managed through the established operator/GitOps workflow.

Reading orders and activity correctly

Open orders come from /api/solana/exec/v1/orders/open. Account verification means the order account was found on-chain; it is not evidence that an order filled. Amounts are displayed exactly as reported. This endpoint does not supply a token-precision contract, so the page does not infer a converted limit price or dollar value from those fields.

Portfolio activity comes from /api/nexus/v1/desk/pnl/flows?limit=200 and shows the latest 200 recorded movements. This is a bounded portfolio ledger, not an exhaustive wallet transaction index. Swaps are represented by ladder and swing movement kinds (ladder_fire, swing_buy, swing_sell), not a fictional swap kind. A swing movement may record placement rather than a fill; read its evidence and note. Liquidity and lending filters use their own kinds.

Conversion legs have explicit evidence:

• exec_fill: reported fill.
• exec_quote: quoted output, not a realized fill.
• derived: amount derived from balances.
• Missing provenance: fill detail unavailable.

Transaction links are shown only when a transaction signature is present. Missing quantities and wallet snapshots remain unavailable; a reported zero balance is rendered as zero.

Swing orders and results

Orders & swaps shows buy/sell direction and links between entry and exit orders. The swing table includes the latest 30 ledger orders, including filled and cancelled entries. Sell orders can link to multiple entry lots. Order links open their on-chain accounts.

Realized profit is matched by buy/sell order ID against the portfolio accounting snapshot. It is expressed in USDC and includes the close date. Missing results stay unavailable; unknown fees and disputed accounting are explicitly marked. The same round-trip result can appear on both linked legs: do not sum the rows. Planned exit prices are targets, not realized profit.

What was removed

The console no longer includes the general-purpose software-agent builder, manual skill/memory editors, project boards/Kanban, task goals, software-action approvals, host/mob/registry administration, duplicate run history, or static integration/Telegram reference screens. Their old URLs redirect to Portfolio. The generic fleet dashboard is replaced by the portfolio entry point.

The former combined exchange/futures screen is replaced with the dedicated on-chain wallet and order views. Accounting remains authoritative: if the NAV backend includes exchange holdings in its inclusion map, those components still appear in Portfolio. Hiding an asset from the total would change the accounting scope; this UI change does not do that.

Underlying runtime services, historical records, account credentials and scheduled jobs are preserved. The AI still depends on hosts, versioned skills, knowledge and execution services; removing their generic UI editors does not remove those runtime capabilities. Existing task-type schedules can still be seen for operational continuity, but new UI-created schedules are engine jobs.

Validation

The refocus retains the NAV/P&L tests and adds checks for missing values, the actual movement kinds, quote-versus-fill evidence and unknown asset labels. Browser checks cover primary and supporting routes, legacy redirects, context navigation, and populated wallet/order/lending examples. Test fixtures are synthetic and never trigger production transactions.

The earlier visual audit documents the design foundation and historical 35-route inventory. Its navigation screenshots and inventory precede this portfolio-only refocus.

Ladder votes and dream output health

Repricing requires at least two analysis votes, a dream vote, and a decision proposal with explicit prices within the configured 24-hour window. The voters do not need identical prices: the decision officer supplies the executable numbers. “Dream no” means no qualifying structured vote was recorded; it does not prove the dream's written opinion was against the move.

The September 27 incident produced readable dream reports with a missing final JSON root brace. Their positive votes were not persisted, while text-only cycle health appeared successful. The host now validates the complete dream object before considering its final step healthy. It can append one missing outer brace only when every nested structure and string is already complete and the resulting object passes validation. The vote and prices are never invented or modified. Repairs are recorded as accum_dream_repaired; other invalid outputs are recorded as accum_dream_rejected and mark the cycle degraded. Historical reports are not replayed automatically.

Analysis and dream prompts now state the production ladder constraints: triggers at least 5% below the live oracle index, at most 95% upward repricing per call, no increased total budget, descending rungs, and repriceable state. An unavailable/suspended index cannot be replaced by a portfolio valuation mark to certify execution eligibility. Shallow 1–2% pullback zones do not fit this ladder contract. These are existing execution limits, not relaxed by the fix.

Wallet coverage and accounting quality

Wallets reports native SOL and wrapped SOL separately. Both are valued at the SOL mark and included once in portfolio NAV and SOL exposure; only native SOL is available for the gas reserve. A wrapped balance does not mean funds were lost or transferred. Restoring visibility does not unwrap or move tokens.

The lending table filters the execution service's combined positions response: LP positions appear on Liquidity, not as blank lending balances.

For partial swing sales, displayed cost is the cost of the filled portion. Execution-reported profit is net proceeds minus that cost; reported fees remain visible separately and are not subtracted a second time. Missing historical fee evidence remains marked unknown.

Snapshots written before wrapped-SOL coverage can understate NAV. The first complete snapshot is a coverage boundary, not proof of a new deposit. Returns whose baseline crosses that boundary are unavailable pending historical reconciliation. Unconfirmed flows and unexplained amounts remain disclosed; they are not automatically accepted as withdrawals or erased.

Portfolio budget checks remain log-only in production: exposure and liquidity figures are advisory, with no new portfolio cap enforcement. Negative headroom after reservations is not a missing-cash balance. Existing transaction and oracle safety checks continue independently.

Oracle and certificate operations

The price plane reads Pyth accounts at confirmed commitment. Finalized reads add chain finalization delay to sponsored-feed updates and can spuriously trip the freshness gate near an update boundary. The 60-second freshness limit, confidence and divergence checks are unchanged; a genuinely stale feed still suspends execution.

HTTP-01 certificate renewal requires ingress-controller access to cert-manager solver pods on TCP 8089. The dedicated solver NetworkPolicy grants that path without changing the namespace default deny or signer access.

Active review of idle liquidity

The Liquidity page shows the dollar value outside earning ranges. Analysis, dream and decision cycles receive the same position-level productivity review, ranked by idle value, with range distance, token composition and a variable-rate lending comparison for the USDC leg. LP value is no longer included in the lending subtotal. Wrapped SOL is included in idle wallet inventory, separately from native gas; funding an opening still requires a supported token route.

Every out-of-range position should receive a decision: reposition, close and redeploy, or retain for a concrete entry/exit purpose with a price condition and a review deadline by the next decision. Cheap transactions make active review worthwhile, but the comparison includes swap slippage, inventory conversion, possible divergence loss, and rent tied up or refunded. Pool headline APR is not the current yield of an out-of-range position.

This is an input and policy improvement to the existing decision/execution cycle, not a blanket close command or a new portfolio cap. Actions use the existing lp_plan, actual position IDs and confirmed returned balances. A snapshot cannot establish how long a position has been out of range, so duration remains unknown until supported by history.

Orca explains range-dependent fee earning in its liquidity terminal guide.

Restated historical NAV

When confirmed transaction evidence establishes a previously omitted wallet balance over a bounded interval, history can carry a separate restatement. The chart adds that quantity at each snapshot's original SOL and USDT marks; it never uses today's price to rewrite yesterday's value. Original NAV, ledger entries and a full snapshot backup are preserved. The history API exposes raw NAV alongside the restated value and explains the correction on the chart.

This repairs the missing-asset drop and the apparent jump when live coverage was restored. It does not establish a deposit or earned profit. Historical returns, drawdown and flow-based comparisons remain unavailable/provisional until their separate ledger reconciliation is complete. No balances are extrapolated before the interval supported by receipts.