The per-pool console

The admin screens lists eleven screens, all of them in the sidebar. This one is not: the per-pool console at /admin/staking/pool/{id}, reached by opening the View action on any row of the Pools table.

It is where per-pool analytics live, where the external performance log is recorded, and where the Activate / Deactivate button for a single pool sits. It is worth knowing well, because two of its headline figures are computed differently from the same-named figures on the Overview screen.

Everything from Details tab onwards describes a fixed-rate pool. The same URL renders a different set of tabs for an on-chain one — see In on-chain mode at the foot of this page.

The header strip

The hero shows the pool's name, symbol, APR, lock period and its count of ACTIVE positions, with four actions:

All four doors now enforce the one-active-pool rule

The button goes through the full pool update endpoint, and that endpoint re-checks the rule before saving: activating this pool while another ACTIVE pool exists for the same symbol and walletType in the same product is refused with

An ACTIVE staking pool already exists for USDT (SPOT). Only one ACTIVE pool is allowed per symbol and wallet type.

The two dedicated status routes — PUT /api/admin/staking/pool/{id}/status and the bulk PUT /api/admin/staking/pool/status — used to validate only that the value was one of ACTIVE, INACTIVE, COMING_SOON and then write it through the generic status helper, so a scripted status change could put two ACTIVE pools on one asset. Both now run the shared guard before writing, with a different sentence:

An ACTIVE pool for USDT already exists ("Tether 30-day"). Deactivate it first, or edit this pool instead of activating it.

The bulk form also checks the batch against itself, so promoting two pools for one asset in a single call is refused rather than letting the second slip past a check that only looked at the database.

Deactivating a pool stops new stakes and nothing else. Existing positions keep accruing and still settle on schedule — see Creating pools.

Details tab

A read-only panel of the pool's own columns: APR, admin fee, earning frequency, lock period, early-withdrawal fee, auto-compound, minimum and maximum stake, capacity, description, timeline, the risk boilerplate and the pool terms list.

The capacity meter counts settled positions

The Pool Capacity card divides totalStaked by totalStaked + availableToStake. totalStaked here is a raw SUM(amount) over every position row in the pool — no status filter and no soft-delete filter. Completed and cancelled positions are in it.

That is not the same number as anywhere else:

The bar cannot read over 100%: both halves of the sum are non-negative — staking is refused above availableToStake, and a negative capacityDelta is refused unless there is that much headroom to take — so the ratio is bounded at one. What it does instead is drift toward 100% as a pool churns, whatever room is genuinely left, because a settled position stays in the numerator forever while its principal is handed back to the headroom in the denominator. On a pool that has been running long enough for positions to mature, the reading stops meaning anything. Use the Overview screen to judge whether a pool is out of room. The availableToStake figure printed beside it is live and correct; it is the percentage and the "total staked" figure that are cumulative.

Positions tab

The same position table as /admin/staking/position, scoped to this pool: same columns, same analytics strip, same view dialog, and the same Approve withdrawal / Reject withdrawal row actions on PENDING_WITHDRAWAL rows, gated on edit.staking.position. Create and inline edit are switched off here; delete and view are not.

The view dialog adds what the shared details panel does not carry — the full position UUID, when it was opened and closed, unclaimed rewards, the date of the last earning row, and the pool APR.

The pool-scoped list endpoint

This route differs from the global /api/admin/staking/position in exactly one way that matters: the pool scope is forced from the path, and any poolId the caller puts in the query filters is stripped before the query runs. A client cannot widen it to another pool or to the whole book.

The tab on screen reads the global endpoint with a seeded poolId filter instead, so the two produce the same rows for an operator; the forced-scope route is what you want when you are handing an API key to something that must only ever see one pool.

Both include the position's duration tier (id, name, lockPeriod, apr, earningFrequency) on every row, read with soft-deleted tiers included so a retired term still resolves rather than coming back null.

Analytics tab

Driven by GET /api/admin/staking/pool/{id}/analytics, with a range selector (7d · 30d · 90d · 1y) and four sub-tabs — Overview, Earnings, Users and Performance. The Export Data button is present on this tab.

Expected versus actual APR is not the Overview's promised-versus-realised

This is the single most important thing on the page to get right. The Pool Performance card and the Performance metric tile compare two numbers:

Those external rows are the ones you type in by hand on this same tab (see below). Nothing about credited rewards, accruals or the wallet ledger enters this calculation.

The APR Performance chart on the Performance sub-tab has the same basis: one point per day in the window, carrying the external row's APR for that day or 0 where none was recorded, against a flat line at the pool's APR.

The rest of the tab

• Overview — staked amount, earnings and distinct stakers per bucket (daily for 7d/30d, weekly for 90d, monthly for 1y), plus an earnings distribution donut counting earning rows into 0–10 / 10–50 / 50–100 / 100–500 / 500+ amount bands.
• Earnings — earnings over time, and earnings split by row type.
• Users — activity, retention by position count (1 / 2 / 3+ positions), and two derived boxes. "Retention rate" is COMPLETED positions ÷ all positions, and "early withdrawal rate" is CANCELLED positions ÷ all positions. Cancellation is the punitive terminal state described in Positions, not an early exit — an approved early withdrawal ends as COMPLETED and lands in the retention figure. Treat that second box as a cancellation rate.

The endpoint no screen calls

Accepts timeframe of 24h, 7d, 30d, 90d or all. No admin screen renders it today; it is there for reporting and integrations, and it is the better source of the two because it is measured from real rows rather than typed in:

• metrics.totalValueLocked and metrics.utilizationRate use ACTIVE + PENDING_WITHDRAWAL principal — the correct basis, unlike the Details tab.
• historicalData.tvlHistory, positionHistory and rewardsHistory are reconstructed by walking an opening balance through each day's real inflows and outflows, capped at 366 buckets.
• CANCELLED positions carry no exit timestamp, so they cannot be placed on a timeline and are excluded from those three series. The count that was left out is reported in historicalData.meta.excludedCancelledPositions, alongside from, to, granularity and truncated.
• financialMetrics.effectiveAPY is a modelled figure — the pool's APR compounded 365 times a year — not a measurement of anything.

The external performance card

On the Performance sub-tab, and only when the pool has an externalPoolUrl set. Internal pools do not get this form, deliberately: the platform computes their performance itself, and a manual entry form would let an admin record numbers that contradict the ledger.

It lists what has been logged for this pool — date, APR, total staked, profit, notes — newest first, and a Record button opens a dialog with those five fields.

poolId, date, apr, totalStaked and profit are all required; notes is optional and an empty string is dropped rather than saved. apr and totalStaked must be ≥ 0; profit may be negative. A date in the future is rejected by the model with "date: Cannot be in the future", which the route returns as a 400 validation error.

Recording a row also writes an admin notification, and its link is dead: it points at a staking/performance path that no page.tsx serves. Clicking it 404s. The rows are only visible on this card.

Display order is not edited here

Two endpoints set the sequence pools appear in:

The POST form takes {"poolIds": [...]}, de-duplicates while preserving your sequence, refuses unknown IDs, and then globally re-numbers all non-deleted pools from 1 — the IDs you sent lead, everything else follows in its current order. The PUT form takes {"poolOrders": [{poolId, order}, ...]} and refuses duplicate IDs or duplicate order values, writing exactly what you send and touching nothing else. It also writes one activity-log row per pool.

What is not on this console

• Duration tiers. Added, edited, retired and featured on the pool form (/admin/staking/pool/new and /admin/staking/pool/{id}/edit, the Duration Tiers tab). See Duration tiers.
• Capacity changes. The availableToStake input on the edit form is inert; capacity moves only through an explicit capacityDelta on PUT /api/admin/staking/pool/{id}. See Creating pools.
• Reward distribution. The Earnings screen carries one of the two doors — its Distribute dialog posts to /api/admin/staking/earning/distribute (singular), the one-off BONUS payout. The APR accrual catch-up, POST /api/admin/staking/earnings/distribute (plural), is on no screen at all: it is an API-only route, like /pool/{id}/analytics/performance above. Call it with an API client. See Rewards.
• The activity log. Written by this console's actions, read at GET /api/admin/staking/activity.

In on-chain mode

The URL is the same and the console is not. A pool created in REAL mode has apr, lockPeriod, availableToStake, earlyWithdrawalFee, earningFrequency, autoCompound, externalPoolUrl, profitSource and fundAllocation all null by construction — not defaulted to zero — because none of them is a thing an on-chain pool has. What that changes here:

The form behind the Edit button is a different form too — an activated chain it inherits, two numbers that are its only terms, a per-pool intake switch, a commission that opens a notice period, and a list of fixed-rate fields it refuses by name rather than ignoring. See Creating on-chain pools.