Data model & core entities
The FortisX data model provides a common language for describing validator-based networks, the actors that participate in them, and the signals that matter for staking decisions. It is designed to be explicit, stable, and auditable: every metric, risk indicator, and policy decision is expressed in terms of well-defined entities and relationships.
This section introduces the core objects in the model and how they relate to each other. It does not prescribe a particular physical database schema, but it does fix the conceptual structure that the rest of the platform relies on.
Design goals
The data model is guided by a few principles:
Network-agnostic core – Ethereum, Solana, Polkadot, Avalanche, and Cosmos differ in protocol details, but the same model should apply across them wherever possible.
Separation of concerns – static identifiers and metadata are kept separate from time-varying measurements and derived indicators.
Reproducibility – it must be possible to reconstruct a historical view of networks, validators, and allocations at any given time, based on recorded data and model versions.
Policy alignment – entities and relationships must be rich enough to express realistic allocation and risk policies without depending on ad hoc fields or implicit assumptions.
The entities described below form the backbone of this model.
Networks
A Network represents a validator-based protocol (for example, Ethereum, Solana, Polkadot, Avalanche, Cosmos). Each network has:
a stable identifier used across the platform;
basic static metadata (name, human-readable code, protocol family, consensus mechanism);
protocol parameters that influence staking and validation (for example, expected participation behaviour, penalty regimes, key protocol upgrade milestones).
Time-varying network characteristics such as staking participation, concentration, and changes in governance parameters are represented as metrics attached to the Network, not as fields on the Network object itself.
Networks act as the top-level scope for other entities: validators, pools, providers, metrics, and policies are all defined within one or more networks.
Validators
A Validator is an entity that participates in consensus or block production within a given network. The model distinguishes between:
a stable Validator identity (how FortisX refers to the validator over time); and
time-varying attributes such as status, performance, and configuration.
Each Validator includes:
network identifier (which Network it belongs to);
one or more protocol-specific identifiers (for example, indices, addresses, keys);
associations to Providers or Pools, where applicable;
static metadata where available (self-declared name, description, metadata references).
Metrics such as participation, uptime, penalties, rewards, and configuration changes are stored as time series associated with the Validator. These metrics are the basis for validator-level analytics and risk assessments.
Pools
In networks where stake is aggregated through pools (for example, staking pools, liquid staking protocols, or managed validator sets), FortisX models a Pool as a distinct entity:
a Pool groups one or more Validators under a shared policy, brand, or operational unit;
delegators may enter or exit positions at the Pool level;
pool-level metrics (total stake, inflows, outflows, concentration across underlying validators) are derived from validator- and network-level data.
The relationship between Pools and Validators is many-to-many in general: a pool may operate multiple validators, and a validator may, in some networks, be associated with more than one pool or deferred delegation mechanism. The data model makes these relationships explicit rather than assuming a single mapping.
Pools are important for allocation and risk policies that operate at a higher level than individual validators.
Providers
A Provider represents an operational entity that runs validators or offers staking as a service. In some cases, a provider corresponds to a well-known operator; in others, it may be an internal construct used to group validators and pools that share infrastructure or control.
A Provider may be associated with:
multiple Validators across one or more Networks;
one or more Pools that it operates or supports.
By modelling Providers explicitly, FortisX can:
track concentration of stake and risk across providers, not only across validators;
express policies in terms of provider exposure (for example, limits on how much capital may be allocated to a single provider across networks);
incorporate provider-related events (such as incidents, audits, or configuration changes) into risk assessments.
Provider metadata is intentionally minimal and focused on operational aspects; marketing labels or self-descriptions do not play a role in the data model.
Delegator segments
FortisX does not attempt to model every individual delegator. Instead, it uses Delegator segments to represent patterns of stake behaviour where the origin or specific identity is not required for policy decisions.
A DelegatorSegment is defined by:
the Network and, optionally, Pool or Provider it relates to;
properties that distinguish behaviour (for example, large vs. small stakes, short-term vs. long-term patterns, specific entry/exit profiles).
Metrics associated with Delegator segments capture:
flows of stake in and out of Pools, Validators, or Networks;
reactions to protocol events or changes in performance;
the emergence of large, concentrated positions that may affect risk.
These segments are used primarily in analytics and risk modeling to understand how the distribution of stake evolves over time and where concentration or liquidity risks may arise.
Events and alerts
Raw behaviour in networks and infrastructure is captured initially as Events. Examples include:
validator participation or missed duties;
penalties, slashing, or other protocol-enforced actions;
stake operations (bond, unbond, delegate, redelegate), where visible;
configuration changes for validators or Pools;
significant changes in network parameters.
Based on these Events, FortisX generates higher-level Alerts. Alerts are structured summaries of conditions that may be relevant for operators or policies, for example:
large stake inflows or outflows to a Pool or Validator over a short period;
unusual changes in performance or participation;
sudden shifts in concentration levels.
Alerts are associated with the relevant entities (Network, Validator, Pool, Provider) and carry enough context to be traceable back to underlying Events and metrics. They are used both in human-facing interfaces and, where appropriate, as triggers in policy evaluations.
Metrics and indicators
Metrics represent quantitative observations over time. In the data model, they are not fields on entities but separate objects that link:
a subject (Network, Validator, Pool, Provider, or DelegatorSegment);
a metric type (for example, participation rate, effective balance, stake share, concentration index);
a timestamp or interval;
a measured value, and optional contextual attributes (such as measurement method or data source).
Derived indicators are also modeled explicitly. These are values that combine multiple metrics into a single number or categorical label, for example:
validator reliability scores based on missed duties and downtime;
network-level concentration metrics based on stake distribution;
operational health indicators derived from incident and configuration history.
By treating metrics and indicators as first-class objects, FortisX enables:
recomputation of indicators when definitions change;
comparison of the same metric across different subjects and networks;
explicit links between policies and the metrics they depend on.
Risk profiles
A Risk profile is a structured view of how FortisX evaluates a particular entity (Validator, Pool, Provider, or Network) along several dimensions. In the data model, a Risk profile includes:
the subject it applies to;
a reference to the model version used to compute it;
values for individual factors (for example, technical reliability, concentration exposure, operational history);
an overall classification or bucket, where applicable.
Risk profiles are time-stamped and can be stored as a series, allowing FortisX to show how risk assessments evolve as new data arrives or as models are updated.
Policies and external systems can refer to risk profiles explicitly (for example, “exclude validators in certain risk buckets”), and because model versions are recorded, it remains possible to understand which assumptions were in force at the time.
Policies and allocation proposals
Policies and allocation decisions are central to the role of FortisX as a staking platform.
Policies
A Policy encodes a set of rules and constraints that define how capital may be distributed. In the data model, a Policy includes:
scope (which Networks, Providers, Pools, or Validators it applies to);
references to relevant metrics and risk factors (for example, concentration indicators, reliability scores);
quantitative limits and thresholds (for example, maximum allocation to a provider, minimum required characteristics for a network);
metadata such as owner, approval status, and version.
Policies are treated as configuration objects that can be audited and versioned. Changes to a policy are recorded so that historical allocation decisions can be interpreted in context.
Allocation proposals
An Allocation proposal represents the outcome of applying Policies to current data. For a given portfolio or capital pool, it includes:
current allocations across Networks, Providers, Pools, and Validators;
recommended target allocations that satisfy configured policies;
a description of the changes needed to reach those targets (for example, amounts to increase or decrease in specific positions);
the data snapshot and model versions used to derive the proposal.
Allocation proposals are not actions by themselves. They form a bridge between the analytics and policy layers of FortisX and the external systems that execute staking operations. Each proposal can be accepted, rejected, or modified by those systems, and its history can be traced back to the underlying metrics and policies.
Relationships and identifiers
To make the model usable across networks and over time, FortisX maintains a set of internal identifiers that are:
stable – they do not change when external representations (such as addresses or indices) change as a result of protocol upgrades or operational changes;
scoped – identifiers are namespaced by entity type and Network where necessary;
traceable – mappings between internal identifiers and protocol-level identifiers are recorded with validity intervals.
Relationships between entities (for example, Validator–Network, Validator–Provider, Pool–Provider) are explicit and time-aware. This allows the platform to:
reconstruct historical point-in-time views (which validators belonged to which provider at a given time);
reason about concentration across different dimensions;
apply policies consistently even as underlying infrastructure changes.
Summary
The FortisX data model defines a small, focused set of entities—Networks, Validators, Pools, Providers, Delegator segments, Events, Alerts, Metrics, Risk profiles, Policies, and Allocation proposals—and the relationships between them. This structure allows:
data from heterogeneous networks and providers to be expressed in a common form;
analytics and risk models to be built on top of a clear and auditable foundation;
allocation and rebalancing decisions to be expressed as explicit, reproducible objects.
Subsequent sections describe how these entities are populated with metrics and how risk modeling, policies, and operational practices build on top of this model.
Last updated