> ## Documentation Index > Fetch the complete documentation index at: https://docs.coinversa.ai/llms.txt > Use this file to discover all available pages before exploring further. # Sharpe ratios > Annualized realized-PnL Sharpe for any tracked Hyperliquid wallet: 30-day score, custom 1–90-day intervals, three monthly buckets, a top-50 Sharpe leaderboard and Sharpe filters on cohort endpoints. Starter. A **Sharpe ratio** asks how steady a wallet's profits are, not how large. Pulse computes one for every tracked Hyperliquid wallet from its daily realized PnL — a single wallet's score, the same score over any window in the last 90 days, three month-sized buckets to see whether it is improving, and a leaderboard of the most consistent wallets with real equity behind them. All four endpoints are **Starter**. ## How the score is computed ```text theme={null} annualizedPnlSharpe = √365 × mean(daily realized PnL) ÷ sample standard deviation(daily realized PnL) ``` * **Daily realized PnL**, in dollars, from the same per-wallet daily rollup as the rest of Pulse. It is not limited to perps. * **Every day in the window counts.** A day without fills counts as `0`, so a wallet that trades twice a month is not scored on its two good days. * **Completed UTC days only.** Today is always excluded; `asOf` is midnight UTC at the end of the window, and `calculatedAt` is when the number was computed. * **Risk-free rate is zero.** Annualized with √365 because crypto trades every day. * **Null, not zero,** when there are fewer than two days or the daily PnL never varies. The score is rounded to 4 decimals. > [!WARNING] > > **This is a realized-PnL proxy, not a portfolio Sharpe.** It is not divided by account equity, so it measures dollar PnL rather than percentage returns, and it excludes **fees, funding and unrealized PnL**. A wallet sitting on a large open loss can score well. **It rewards consistency, not size.** A wallet that makes $3 a day without fail can outrank one that made $1.5M with some red days, and a wallet with a single winning day in 30 scores √(365/30) ≈ 3.49 whatever the amount. On the 14 Oct 2026 leaderboard, before activity floors were added, the #2 wallet had \$77.85 of realized PnL over the 30 days. The leaderboard now applies activity floors by default (see [below](#the-leaderboard)); the wallet endpoints do not. Always read `annualizedPnlSharpe` alongside `realizedPnl` and `trades`, which every response carries next to it with `meanDailyPnl` and `stdDailyPnl`. ## Endpoints | Endpoint | MCP tool | What it returns | Window | | - | - | - | - | | `/pulse/trader/{address}/sharpe` | `pulse_trader_sharpe` | One wallet's score and its inputs | Last 30 completed UTC days (`days` accepts only `30`) | | `/pulse/trader/{address}/sharpe/interval` | `pulse_trader_sharpe_interval` | The same, over a window you choose | `startDay` (`YYYY-MM-DD`, inclusive) and `days` (1–90), both required | | `/pulse/trader/{address}/sharpe/monthly` | `pulse_trader_sharpe_monthly` | Exactly three buckets, newest first | 3 × 30 days, or calendar months with `useCalendarMonths=true` | | `/pulse/sharpe-leaderboard` | `pulse_sharpe_leaderboard` | Top 50 wallets by score | Last 30 completed UTC days (`days` accepts only `30`) | The wallet endpoints answer for wallets Pulse tracks; an address it has never indexed returns `404`. They apply **no equity filter** — any tracked wallet gets a score. ### Custom intervals `/sharpe/interval` scores 1–90 completed days. `startDay` must be no earlier than 90 days before today, and the exclusive end (`startDay + days`) cannot be later than today. **Out-of-range windows are rejected, not shortened** — unlike the silent `since` clamps elsewhere in the API: a malformed `startDay`, a start more than 90 days ago or an end later than today is a `400`; a missing, non-integer or out-of-range `days` (outside 1–90) is a `422`. A one-day interval returns a `null` score and a standard deviation of `0`. ### Monthly buckets `/sharpe/monthly` always returns three buckets, newest first, each with its own `startDay`, `endDayExclusive`, `days` and `asOf`: * **Default** (`useCalendarMonths=false`): the last 30 completed days, the 30 before that, and the 30 before that — 90 days in all. * **`useCalendarMonths=true`**: the completed days of the current UTC month plus the two full calendar months before it — at most 93 days. On the 1st of a month the current bucket has `days: 0`, zero statistics and a `null` score. ### The leaderboard `/pulse/sharpe-leaderboard` ranks the top **50** wallets. To be eligible a wallet needs **at least \$2,500 of stored account equity** (`minEquity`) and must clear two **activity floors**. Both apply by default and can be changed: | Parameter | Default | Range | Keeps wallets with | | - | - | - | - | | `minActiveDays` | `10` | 1–30, integer | at least this many completed UTC days in the window with one or more fills | | `minPnl` | `1000` | −1,000,000,000 to 1,000,000,000 | summed realized PnL over the window of at least this many dollars (inclusive) | All three checks happen **before** ranking, so the 50 slots go to wallets that pass. Wallets with no equity on record, or with zero variance, are left out. Ties break by realized PnL, then by wallet address. Each row also reports `activeDays`, and the response echoes the floors it applied as `minActiveDays` and `minPnl` next to `minEquity`. Out-of-range, non-integer `minActiveDays` or non-finite values are a `422`. The defaults keep wallets whose score rests on a couple of lucky days or a few dollars off the board. `minActiveDays` counts fill days the same way as `/pulse/hidden-gems`, but only inside the 30-day window (hidden-gems counts over all time). `minPnl` has the same name, dollar meaning and default as on `/pulse/max-pain-events` and `/pulse/perfect-exits`, but unlike them it accepts negative values, so the floor can be switched off. To see the whole field, pass `minActiveDays=1&minPnl=-1000000000`. * `accountValue` and `equityUpdatedAt` are the wallet's **latest stored equity checkpoint** — not necessarily its live balance, and no checkpoint is too old to count. * The result is **cached and refreshed every 30 minutes**; if a refresh fails, the previous result may be served. `calculatedAt` tells you how old the answer is. ## Sharpe filters on cohort endpoints Nine cohort and positioning endpoints take two optional filters that keep only wallets above a Sharpe threshold: | Parameter | Score it filters on | Refreshed | | - | - | - | | `minRecentSharpe` | The wallet's score over the last 30 completed UTC days | Hourly | | `minTotalSharpe` | The wallet's score from its first available daily history through yesterday UTC | Daily | Both are **inclusive minimums**. Zero and negative values are valid; non-finite values are `422`. Leave a filter out and nothing is filtered on it; set it and wallets without a score are excluded. Set both and a wallet must pass both. Filters apply **before** limits and aggregation, so totals and medians describe the qualifying wallets only. The filter uses each wallet's **current** score. On trade and lifecycle history, a fill from three weeks ago is kept or dropped by the wallet's score today, not its score then — do not use it to backtest. > [!NOTE] > > **These filters have no activity floor.** Unlike the leaderboard, they do not take `minActiveDays` or `minPnl`. The stored score does not record how many days a wallet traded, and a wallet with a single winning day in the window scores about **3.49**. A `minRecentSharpe` below that can therefore admit one-day wallets. The cohort itself (its PnL or size tier) is the only size floor. | Endpoint | Tier | MCP tool | | - | - | - | | `/live/cohort-bias/{coin}` | Starter | `live_cohort_bias` | | `/live/positioning-by-entry/{coin}` | Pro | `live_positioning_by_entry` | | `/pulse/cohorts/{tierType}/{tier}/positions` | Pro | `pulse_cohort_positions` | | `/pulse/cohorts/{tierType}/{tier}/trades` | Pro | `pulse_cohort_trades` | | `/pulse/cohorts-recent/{tierType}/{tier}/positions` | Pro | `pulse_cohort_recent_positions` | | `/pulse/cohorts-recent/{tierType}/{tier}/trades` | Pro | `pulse_cohort_recent_trades` | | `/pulse/cohorts-recent/{tierType}/{tier}/top-positions` | Pro | `pulse_cohort_recent_top_positions` | | `/pulse/cohorts-recent/{tierType}/{tier}/lifecycle-stats` | Pro | `pulse_cohort_recent_lifecycle_stats` | | `/pulse/cohorts-recent/{tierType}/{tier}/alpha-concentration` | Pro | `pulse_cohort_recent_profit_concentration` | The filters do not change an endpoint's tier. ## What you can ask | Question | Tool | | - | - | | Who are the most consistent traders on Hyperliquid this month? | `pulse_sharpe_leaderboard` | | Which consistent traders made at least \$50k over the last 30 days? | `pulse_sharpe_leaderboard` with `minPnl: 50000` | | What's the Sharpe ratio of 0x…? | `pulse_trader_sharpe` | | How did 0x…'s Sharpe look between 1 and 21 September? | `pulse_trader_sharpe_interval` | | Is 0x… getting more or less consistent month by month? | `pulse_trader_sharpe_monthly` | | How is BTC positioned among Apex wallets with a 30-day Sharpe above 2? | `live_cohort_bias` with `minRecentSharpe: 2` | | Where did high-Sharpe wallets get into their ETH positions? | `live_positioning_by_entry` with `minTotalSharpe` | ```bash curl theme={null} curl "https://api.coinversa.ai/api/public/v1/pulse/trader/0xYOUR_WALLET/sharpe/interval?startDay=2026-09-01&days=21" \ -H "X-API-Key: $COINVERSA_API_KEY" ``` ## Coverage * **Wallets**: every wallet Pulse tracks (see [Data coverage](/concepts/data-coverage)). The leaderboard additionally needs a stored equity checkpoint of at least $2,500 and, by default, 10 fill days and $1,000 of realized PnL in the window. * **History**: per-wallet scores and intervals reach back **90 days**; the monthly view up to 93. `minTotalSharpe` uses each wallet's full available daily history. * **Freshness**: wallet scores are computed on each request from the daily rollup; the leaderboard is up to 30 minutes old; the stored filter scores refresh hourly (recent) and daily (total). See the [tier matrix](/api-reference/tiers) for plans and the [API reference](/api-reference/introduction) for full response schemas. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.