Architecture & data flow
This section describes how FortisX is structured as a system and how data moves through it. The goal is not to specify particular implementation technologies, but to make clear which components exist, what each of them is responsible for, and how they interact to produce analytics, risk assessments, and allocation proposals.
At a high level, the platform is organised into three conceptual layers:
Data acquisition – ingesting and normalising information from validator-based networks and related infrastructure.
Analytics and risk – turning raw and aggregated data into metrics, indicators, and risk signals.
Policies and interfaces – applying configurable rules to produce allocation and rebalancing evaluations and proposals, and exposing data and proposals to external systems.
The same architecture is applied consistently across supported networks such as Ethereum, Solana, Polkadot, Avalanche, and Cosmos, while allowing for network-specific nuances in data sources and metrics.
Data sources
FortisX relies on multiple kinds of upstream information:
On-chain data – blocks, validator sets, consensus participation, slashing and penalty events, staking transactions, rewards, and other protocol-level signals.
Validator and provider endpoints – where available, telemetry or status endpoints exposed by validators, pools, or infrastructure providers.
Indexers and explorers – services that pre-process on-chain data into higher-level events or aggregate views.
Network metadata – protocol parameters, governance state, configuration changes, and release schedules.
These sources differ by network in terms of structure, latency, and availability. The architecture is designed to treat them as interchangeable inputs into a common ingest pipeline, rather than tying the platform to any single provider.
Ingest pipeline
The ingest layer is responsible for continuously collecting data from external sources, validating it, and transforming it into a format suitable for analytics. Conceptually, it is composed of:
Network-specific collectors – processes dedicated to particular networks (for example, Ethereum, Solana, Polkadot, Avalanche, Cosmos) that understand the network’s RPC and indexing interfaces and know how to interpret network events.
Normalisation stage – logic that converts heterogeneous data structures into FortisX’s internal representation of networks, validators, pools, and events.
Validation and quality checks – basic integrity checks such as:
consistency of block heights and timestamps;
detection of missing or out-of-order data;
cross-checks between multiple providers, where available.
Ingest queues and buffering – internal queues that decouple upstream variability from downstream processing, so that short-lived spikes or delays upstream do not immediately affect the rest of the system.
Ingest processes run continuously and incrementally. Rather than performing large batch imports, they track the current position in each data source (for example, block height or slot index) and advance as new data becomes available.
Storage and aggregation
Once data passes through the ingest pipeline, it is stored in a combination of time series and relational structures:
Raw event storage – a log of low-level events (such as validator participation, penalties, configuration changes, and stake movements) that can be replayed if models need to be recomputed.
Time-series metrics – regularly sampled measurements (per epoch, slot, block, or fixed interval) for validators, pools, and networks.
Aggregated views – precomputed aggregates used in analytics and risk modeling, such as:
rolling averages and percentiles of validator performance;
stake concentration across providers or regions;
network-level participation and churn metrics.
The storage layer is designed so that:
raw data and derived metrics are clearly separated;
derived views can be recomputed from raw data when models or definitions change;
historical behaviour can be analysed over different time horizons without re-ingesting external sources.
This separation makes it possible to evolve the analytics and risk models without losing the ability to reproduce previous outputs.
Analytics services
On top of storage, FortisX runs a set of analytics services that compute metrics and indicators needed for the policy engine and for any internal or client-facing tools built on top of the Analytics API. These services:
transform raw events and baselines into higher-level metrics (for example, validator reliability scores, participation ratios, or network concentration indicators);
align metrics across networks into a common vocabulary, while preserving network-specific details where they matter;
maintain current and historical views that are optimised for different use cases, such as:
comparing validators within a network;
comparing networks on structural characteristics;
tracking changes in risk indicators over time.
Analytics services are typically stateless with respect to long-term data; they read from the storage layer, compute metrics or projections, and write updated aggregates back. This keeps their behaviour transparent and makes it easier to audit how particular results were obtained.
Risk modeling layer
The risk modeling layer takes outputs from analytics and organises them into a set of dimensions relevant for staking decisions. Conceptually, it operates as follows:
Factor calculation – metrics are grouped into factors such as technical reliability, concentration and decentralisation, operational behaviour, and infrastructure dependence.
Normalisation – values are normalised into comparable ranges so that they can be combined even when raw units differ between networks or metrics.
Scoring and bucketing – factor scores are combined into overall indicators or buckets (for example, different levels of operational or concentration risk for a validator, pool, or network).
The models and thresholds used here are explicitly configured and versioned. When assumptions change, new versions of the model can be introduced and their impact studied, while preserving the ability to re-run previous versions on the same historical data.
The outputs of this layer are not treated as definitive ratings, but as structured signals that can be used by policies.
Policy engine
The policy engine is the component that translates analytics and risk signals into concrete allocation and rebalancing evaluations and proposals. It operates on three main inputs:
current allocations across validators, pools, and networks;
metrics and risk indicators computed by the analytics and modeling layers;
explicit policy definitions configured by users or governance processes.
Policies are expressed as constraints and rules, such as:
maximum allowable exposure to a single provider or validator;
required characteristics for eligible networks (for example, minimum decentralisation indicators);
exclusion of entities with specific risk profiles;
limits on how much allocations may change in a given time window.
Given these inputs, the engine produces:
allocation evaluations – assessments of whether current allocations comply with configured policies, and where they diverge;
allocation proposals – suggested changes that would bring allocations back within policy, including specific targets and transition paths (for example, moving part of a position from one set of validators to another).
The policy engine is designed to be deterministic: given the same allocations, data, and policies, it should produce the same output. This property is important for auditability and for reproducing decisions ex post.
External interfaces and execution flow
The results produced by FortisX must be consumable by external systems that hold assets, operate validators, or maintain internal records. To support this, the architecture exposes:
dashboards and views for human operators, showing validator, network, and policy status;
alert streams highlighting events such as large stake movements, changes in risk indicators, or policy breaches;
an Analytics API that allows external systems to query networks, validators, metrics, risk indicators, and policy evaluations;
integration hooks (for example, webhooks or message-based interfaces) through which allocation proposals can be delivered to downstream execution systems.
In a typical flow:
FortisX ingests and processes data, updates analytics, and evaluates policies.
If policies indicate that allocations should change, the engine produces a set of proposals.
Proposals are surfaced via dashboards and interfaces, and received by systems responsible for custody, validator operations, or portfolio management.
Those systems apply their own checks and approval processes and, if actions are authorised, execute the necessary on-chain operations.
As allocations change, FortisX observes the resulting state and incorporates it into subsequent evaluations.
This separation keeps FortisX focused on analytics and policy logic, while allowing different organisations to implement execution and governance in ways that fit their own requirements.
Resilience and observability
Although detailed operational practices are covered in a later section, certain resilience and observability aspects are part of the architecture itself:
Decoupling of components – ingest, storage, analytics, risk modeling, policy evaluation, and interfaces are separate services connected through well-defined contracts and queues. This reduces the impact of localised failures.
Replay and re-computation – maintaining raw event logs allows models, metrics, and policies to be recomputed if assumptions change or if inconsistencies are detected.
Instrumentation – each component exposes health indicators and performance metrics, making it possible to monitor data freshness, processing latency, and error rates.
These properties are necessary for a platform that is expected to operate continuously across multiple networks, while remaining transparent enough for external teams to review and rely on its outputs. Subsequent sections describe the data model, metrics, models, and operational practices that build on this architectural foundation.
Last updated