Analytics API & roadmap
The Analytics API is the primary interface through which external systems access the same data and signals that FortisX uses internally for analytics, risk modeling, and policy evaluation. It is designed to be predictable, versioned, and suitable for integration into monitoring systems, internal dashboards, risk engines, and execution platforms that participate in staking across validator-based networks.
This section describes the role of the Analytics API, the main data domains it exposes, how it fits into typical integration patterns, and how FortisX is expected to evolve over time in terms of coverage, models, and interfaces.
Role of the Analytics API
Internally, FortisX maintains a continuous data pipeline and a set of models that produce metrics and risk profiles for networks, validators, pools, and providers, and that generate allocation evaluations and proposals. The Analytics API exposes a structured view of these outputs so that:
operators and teams can build their own dashboards and monitoring around FortisX data;
risk and governance systems can incorporate metrics, risk factors, and policy evaluations into their own workflows;
execution platforms can receive allocation proposals and context, then apply their own controls before taking action.
The API does not attempt to encapsulate all operational logic. Instead, it presents clear, queryable representations of entities, metrics, risk profiles, and policy outcomes that can be combined with local information and processes.
Design principles
Several principles guide the design of the Analytics API:
Consistency with the data model — endpoints reflect the conceptual model described elsewhere in this document: Networks, Validators, Pools, Providers, Metrics, Events, Alerts, Risk profiles, Policies, and Allocation proposals.
Read-focused and side-effect free — the Analytics API is primarily read-only from the perspective of external systems. Configuration and policy management are handled through controlled channels rather than general-purpose public endpoints.
Deterministic responses — given a defined snapshot and model version, the same query yields the same result. Where data changes over time, responses are tied to timestamps or versions so that consumers can reason about evolution.
Versioning and stability — changes to response structures or semantics are introduced through explicit versioning, rather than silent modifications of existing endpoints.
Transparency of provenance — responses include references to data sources, model versions, and policy versions where relevant, so that downstream systems can evaluate and log not only values but also their context.
Data domains
At a high level, the Analytics API is organised around a small set of domains corresponding to core entities and outputs in FortisX.
Networks
Network-oriented endpoints provide:
identifiers and metadata for supported validator-based networks;
high-level participation, stake distribution, and concentration metrics over time;
indicators related to churn, protocol events, and structural decentralization characteristics.
These endpoints allow consumers to understand the environment in which validators and pools operate, and to compare networks along structural dimensions rather than solely on the basis of individual actors.
Validators and pools
Validator and pool endpoints expose:
static metadata (where available) and identifiers needed to link back to on-chain or external representations;
time-series metrics such as participation, availability, penalties, configuration changes, stake share, and flows;
derived indicators and factor scores that summarise aspects of reliability and behaviour.
Consumers can use these endpoints to build detailed views of individual validators and pools, to compare them within and across networks, and to analyse how their behaviour changes over time.
Providers
Provider endpoints aggregate information across validators and pools operated by the same entity:
stake distribution and concentration across networks;
aggregated reliability and operational indicators;
exposure metrics for use in provider-level policies.
This enables policies and monitoring that target operational entities rather than only individual validators.
Events and alerts
Events and alerts represent structured signals about notable conditions observed by FortisX. API endpoints in this domain provide:
access to raw or normalised events (for example, penalties, configuration changes, governance actions) tied to specific entities and times;
alert streams indicating large stake movements, significant changes in performance, or deviations from expected patterns.
These outputs are suitable for integration into incident management, monitoring, and risk workflows.
Metrics and risk profiles
For more detailed analysis, the API exposes:
specific metric series for entities over configurable windows and resolutions;
risk profiles with factor scores and bucket classifications, tagged with model versions.
This allows consumers to incorporate FortisX factorisation of risk directly into their own logic, or to compare their own assessments with those calculated by the platform.
Policies and allocation evaluations
Finally, policy-related endpoints expose:
the set of policy definitions active within a given scope, including metadata and versioning;
evaluations of current allocations against policies, indicating where allocations are within bounds and where they diverge;
allocation proposals generated by the policy engine, including target allocations, required changes, and references to the data and policies used.
These endpoints do not execute any actions. They bridge the gap between analytics and external execution systems, providing a structured representation of how FortisX would adjust allocations under given conditions and policies.
Integration patterns
The Analytics API is designed to support multiple styles of integration:
Periodic polling Systems that maintain their own internal state (for example, risk engines or reporting pipelines) can periodically query metrics, risk profiles, and allocation evaluations for their scope of interest.
Event-driven integration Using webhooks or message-based integrations, FortisX can deliver alerts and allocation proposals to downstream systems as they are generated, reducing the need for continuous polling.
Dashboard and tooling integration Internal tools and dashboards within an organisation can query the API directly to render network views, validator comparisons, risk summaries, or policy compliance reports.
Hybrid approaches For some use cases, a combination of scheduled queries for baseline data and event-driven delivery for changes or incidents is appropriate.
In all cases, the API is intended to be a source of structured data that can be combined with local context such as portfolio hierarchies, client-specific constraints, or internal approval records.
Versioning and compatibility
To maintain stability, the Analytics API follows an explicit versioning strategy:
Endpoint families are versioned so that changes in response structure or semantics can be introduced without breaking existing integrations.
Risk models and policy sets are versioned separately; API responses reference these versions, allowing consumers to log and interpret data under the correct assumptions.
Deprecations are managed with notice periods and documentation, rather than abrupt removal of functionality.
Consumers are expected to:
record model and policy version identifiers alongside the data they retrieve;
migrate to new API versions according to their own change management processes.
This approach aligns with the broader emphasis of the platform on reproducibility and auditability.
Roadmap: evolution of analytics and interfaces
The FortisX platform is expected to evolve along several dimensions. While details and timelines are subject to change, the general direction of development can be grouped into a few themes.
Broader network coverage
Over time, additional validator-based networks may be integrated, provided they expose sufficient data to support FortisX analytics and policy logic. This includes:
extending the ingest pipeline and data model to cover new protocols where appropriate;
documenting network-specific nuances so that metrics and risk factors remain interpretable;
ensuring that cross-network comparisons remain grounded in a coherent structure.
Network additions are evaluated based on technical characteristics, data availability, and their relevance to the organisations using the platform.
Deeper metrics and models
Within existing networks, analytics and risk modeling are expected to deepen:
new metrics may be introduced as protocols evolve or as additional signals become available;
factor definitions and model combinations may be refined based on observed behaviour and feedback from users;
support for additional dimensions (for example, more granular infrastructure dependence indicators) may be added.
Such changes are introduced through the model versioning framework described earlier, with attention to compatibility and interpretability.
Policy expressiveness and tooling
The policy engine and configuration interfaces may be extended to:
support richer constraints and combinations of conditions, within a structured and reviewable configuration model;
provide simulation tools that allow users to test prospective policies against historical data;
improve introspection into how specific clauses contributed to particular allocation evaluations or proposals.
The goal is to increase expressiveness without compromising determinism or transparency.
Integration and workflow support
To fit more closely into existing operational processes, additional integration and workflow features may be developed, such as:
tighter integration patterns with common monitoring, incident management, or governance tooling;
extended SDKs and client libraries in multiple languages that simplify API consumption;
standardised data formats for exchanging allocation proposals and evaluations with execution systems.
These developments are focused on reducing integration friction rather than changing the core responsibilities of FortisX.
Operational and compliance artefacts
As the platform matures, FortisX may provide more structured artefacts for operational and compliance use, for example:
enriched status and health endpoints for inclusion in external monitoring;
extended logs and reports that summarise changes in policies, models, and allocation proposals over time;
documentation that maps platform features to common control frameworks used by institutional users.
These artefacts are intended to help organisations align FortisX with their own governance and risk management practices.
Summary
The Analytics API is the external face of the FortisX analytics and policy engine. It:
exposes the data model, metrics, risk profiles, policy evaluations, and allocation proposals in a structured, versioned form;
supports multiple integration patterns, from dashboards to automated execution flows;
is designed to evolve in a controlled way as network coverage, metrics, models, and policies develop.
The roadmap for FortisX emphasises incremental extension of coverage and depth, improved expressiveness and introspection in policies, and tighter integration with operational and compliance frameworks, while maintaining the core design principles of transparency, determinism, and separation of duties.
Last updated