Changelog

​

Trader tags on trader stats

• Trader stats rows (GET /api/v1/traders/stats and the list_trader_stats MCP tool) now include tags: editorial trader tags as { category, name } pairs, lowercase, e.g. { "category": "thematic", "name": "ai capex buildout" }.
• The first shipped category is thematic: which macro themes a trader’s book expresses (AI capex buildout, power and energy, critical metals and minerals, robotics, macro rotations, crypto). Categories are an open set and may grow without a version bump.
• tags is always present and empty for untagged traders. Tag visibility follows the same trader visibility rules as the rest of the stats row.

​

Partner Feed

• Added GET /api/v1/feed and the list_feed MCP tool: presentation-ready source-message groups that embed the source preview, source identity, trader, and asset display fields needed for direct rendering, ordered by source-message post time.
• Server-side curation removes fabricated events with no message evidence: assumed and GC-generated closes, instant opens fabricated at a position’s close, and assumed opens siblinged with another event for the same message and asset. Lone inferred opens remain visible with assumed: true, and retrospective events remain flagged with retrospective: true.
• limit counts source-message groups (default 20, maximum 100). traderIds and assetIds filters plus startTime/endTime bounds select groups by source-message post time.
• cursor scrolls back through older groups. since is an ingestion-watermark change feed with whole-group upsert semantics: merge returned groups by id and replace each prior payload. The two parameters are mutually exclusive; persist the newest non-null nextCursor after every successful poll, including empty polls.
• The feed uses the new feed.read scope on REST API keys and MCP OAuth connections. MCP connections authorized before the scope existed need one disconnect and reconnect to pick it up; API keys are unaffected.
• Added the Partner Feed guide and updated query-semantics, data-reads, and MCP docs for the new read family.

​

Trader rankings and activity summaries

• Added GET /api/v1/traders/rankings and the rank_traders MCP tool: server-side trader ranking by event_count (default), position_count, win_rate, avg_return, median_return, or sharpe_ratio over an explicit UTC time window, without supplying trader IDs.
• Performance-metric rankings evaluate the timeBasedPerformanceWindow (default 7D) and require minPositions evaluated positions (default 3); rows expose the evaluated sample size. Windows whose startTime is more recent than the evaluation window are rejected with a corrective 422 instead of returning a silent empty ranking.
• Added GET /api/v1/activity-summaries and the summarize_message_activity MCP tool: deterministic message and event counts grouped by trader or overall, bucketed by hour, day, or week. Activity summaries are count evidence, not generated narrative summaries.
• Both reads use the stats.read scope, default to the last 7 days, and return small bounded results (default limit 10, maximum 50) with no pagination. Activity summary requests above 168 buckets per group are rejected with 422.
• Updated MCP capabilities and filter-guide resources so ranking, count, and trend prompts route to the aggregate tools instead of paging list_events/list_messages.

​

Trader discovery trade counts

• Trader discovery rows now include tradeCount, the eligible visible position count for the discovery result.
• GET /api/v1/traders and list_traders now accept minTrades, defaulting to 3; pass minTrades=0 for the full visible trader directory.
• Trader discovery now accepts startTime and endTime to scope tradeCount and minTrades by position open time.
• Updated REST, MCP, and platform docs to identify trader discovery as the supported source for discovery-level activity counts.

​

Source-aware payloads

• Message rows now expose source metadata under source.identity and message display data under source.preview.
• The old flat message url, text, attachments, and originalCreatedAt fields were replaced by the nested source payload.
• source.platform can be TELEGRAM or X, enabling platform-specific links, labels, avatars, and audience counts.
• GET /api/v1/messages, list_messages, and delegated chat assistant message reads now accept sourcePlatforms for Telegram-only or X-only message feeds.
• Trader discovery and trader stats rows now include one source identity, and their reads accept sourcePlatforms.

​

Opaque Source Message IDs and X-backed message reads

• Source Message IDs are now opaque identifiers returned by source-message views, not Telegram channel/message tuples.
• GET /api/v1/messages, list_messages, and event messageId hydration use those opaque IDs through ids.
• Source-message URLs may point to Telegram or X depending on the source platform.

​

Product and contract documentation refresh

• Replaced the old Arena product page with current product-surface docs for Trader Discovery, Asset Discovery, Feed, Following, profiles, Assistant, and source transparency.
• Added API-key, Connected Apps, and contract-limit guides for REST, MCP, and agent clients.
• Clarified messages vs events vs positions, positioning vs performance, event classification flags, and time-based performance windows.
• Updated REST docs to list generated channel and aggregate summary endpoints as first-class read families.

​

Event and message contract compaction

• Event rows now return flat type, positionId, and messageId fields instead of eventType, nested position, or nested source.
• Event reads now filter event kinds with types.
• Message reads now hydrate Source Message IDs with ids and no longer expose traderId or event-derived filters.

​

Generated narrative summary guidance

• Clarified MCP and docs language for channel and aggregate summaries as generated narrative summaries.
• Added guidance that generated narrative summaries are useful for market narratives but are not evidence for exact trade counts, public activity rankings, or current open-position skew.
• Clarified that current positioning claims should use open-position reads.

​

Position History Reads

• Replaced GET /api/v1/positions/closed/valid and list_valid_closed_positions with GET /api/v1/positions and list_positions.
• Position history reads return open and closed positions by open time with 1D, 7D, and 30D time-based performance.
• Open-position reads continue to expose current marks and live mark-to-market returns.

​

Centaur API naming

• Updated user-facing copy to use “Centaur API” and “Centaur MCP”.
• Updated examples to use a generic <api-key> placeholder.

​

Trader-attributed channel summaries

• Added top-level traderId to GET /api/v1/channel-summaries and list_channel_summaries results so clients can connect summaries from the same trader over time.
• Channel summaries still do not accept trader or Telegram channel filters, and they do not return trader metadata, channel identity, or raw source material.
• Generated aggregate summaries remain source-anonymous and unchanged.

​

Summary access

• Removed the separate Summary Entitlement row-returning gate from generated channel and aggregate summaries.
• Summary reads still require summaries.read authorization through REST API-key permissions or MCP OAuth scopes.
• New default Centaur API keys include summaries.read.

​

Generated aggregate narrative summaries

• Added GET /api/v1/aggregate-summaries and list_aggregate_summaries for cross-source generated aggregate narrative summaries.
• Aggregate summaries use summaries.read, support Source Window-style overlap filtering, and default to safe summaries.
• Public responses expose source coverage counts but not trader or channel identities.

​

MCP OAuth eligibility

• Changed MCP OAuth eligibility from existing active API-key ownership to an active Centaur account with a verified email.
• REST remains API-key based, and generated summaries require normal summaries.read authorization.
• Runtime reads now reject API-key and OAuth owners whose Core account later becomes blocked or unverified.

​

Source Window overlap filtering

• Changed GET /api/v1/channel-summaries and list_channel_summaries so startTime and endTime select summaries whose Source Windows overlap the requested interval.
• A Source Window now matches when windowEnd is after startTime and windowStart is before endTime.
• This fixes daily summary reads so UTC day bounds return summaries covering that day instead of summaries selected only by their window end timestamp.

​

Documentation and client guidance

• Updated the OpenAPI descriptions, REST docs, MCP filter guide, and public skill guidance to describe Source Window overlap semantics.

​

Messages now default to feed semantics

• Changed GET /api/v1/messages and list_messages to return eligible messages even when they have no linked extracted events.
• Kept assetIds, directions, and eventTypes as filters that narrow messages through linked events when supplied.
• Superseded on 2026-06-13: message reads now support Source Message ID hydration with ids plus time bounds, limit, and cursor; trader, asset, direction, and event-type filters are no longer part of the public message contract.

​

Documentation and MCP guidance

• Clarified the new message-feed behavior in the public docs, generated API reference, and MCP filter guidance resource.
• Kept the response shape and pagination contract unchanged.

​

Broader read surface

• Expanded the documented and generated REST surface beyond events to cover messages, positions, and stats under /api/v1.
• Expanded the documented MCP surface to cover the same read-only trading data families across events, messages, generated summaries, positions, discovery, and stats.

​

Query and pagination updates

• Removed allTime from the public date-range contract. Time-bounded reads now use startTime and endTime.
• Standardized list-style reads on forward-only cursor pagination and documented the applied time bounds echoed back in relevant responses.

​

Access and authentication behavior

• Clarified that returned data can reflect current access and eligibility rules, so visible rows and available history can vary by caller context.
• Hardened event pagination so paging remains stable even as the currently visible result set changes.

​

Documentation and client guidance

• Reframed the docs around a broader read-only trading data surface instead of an events-only product view.
• Added a data-reads guide, aligned public skill guidance, and refreshed client setup docs to match the expanded REST and MCP surface.

​

Task-first onboarding

• Reworked the homepage around access, path selection, and quickstarts for both REST and MCP.
• Added concrete MCP setup guides for Claude Code, Cursor, and Codex.

​

API reference improvements

• Strengthened the generated OpenAPI-backed reference with richer examples and schema descriptions.
• Kept Swagger available as a secondary technical artifact rather than the primary docs surface.

​

Information architecture

• Reworked the MCP/API docs around task guides, generated API reference, and changelog pages.
• Moved public skills into a more clearly supplemental role within the docs.