Policy engine & allocation rules
The policy engine is the component of FortisX that turns observable data and risk assessments into concrete decisions about how capital may be allocated and how positions should be rebalanced. It does not move assets itself; instead, it evaluates allocations against explicit rules and produces proposals that can be acted on by external systems responsible for execution.
This section describes what a policy is in FortisX, how policies are evaluated, which inputs they use, how allocation proposals are constructed, and how the overall process remains deterministic and auditable.
Objectives
The policy engine is designed to:
express staking and allocation rules in a formal, machine-readable way;
ensure that current allocations are measured against those rules, using the same metrics and risk model defined elsewhere in the platform;
provide concrete proposals for reallocating capital when allocations drift away from the defined policies;
make every step of this process traceable and reproducible, so that decisions can be reviewed by operators and governance bodies.
The engine acts as the link between data and action: it consumes analytics and risk signals, and produces structured recommendations rather than informal guidance.
Inputs to the policy engine
The policy engine operates on three main classes of input:
Current allocations A snapshot of how capital is presently distributed across:
Networks;
Providers;
Pools;
Validators.
Allocations may be represented at different levels of granularity depending on the use case (for example, per portfolio, per client, or per internal book).
Analytics and risk profiles The metrics and risk outputs described in earlier sections:
validator-level metrics and derived indicators;
network and decentralization metrics;
provider-level aggregations;
risk profiles for each subject, including factor scores and buckets.
Policies A set of configuration objects that specify:
what exposures are allowed or disallowed;
which entities are eligible or ineligible;
how quickly allocations may change;
how policy breaches should be flagged.
Policies are versioned and time-stamped, just like data and models, so that evaluations can be understood in context.
Policy structure
In FortisX, a Policy is a structured object rather than a free-form script. While the exact configuration language may evolve, policies are conceptually composed of:
Scope The set of subjects the policy applies to, such as:
one or more Networks;
a class of Providers or Pools;
specific portfolios or allocation books.
Eligibility rules Conditions that define when an entity may be considered for allocation, for example:
minimum technical reliability factors;
acceptable ranges for concentration or decentralization indicators;
exclusion of entities in certain risk buckets or with specific incident histories.
Exposure limits Quantitative constraints on how much capital can be allocated:
maximum share of a portfolio in a single Validator, Pool, Provider, or Network;
bounds on aggregate exposure to a group of entities sharing characteristics (for example, validators operated by the same provider, or networks in a given protocol family).
Rebalancing rules Parameters that govern how quickly and how far allocations may change:
maximum change in allocation to a subject over a time window;
thresholds for when a deviation from target allocations triggers a proposal;
rules for gradual transitions versus immediate corrections.
Alerting and escalation hooks Definitions of when policy breaches or high-severity changes in risk should produce alerts, require manual review, or trigger specific workflow steps in external systems.
By structuring policies in this way, FortisX ensures that they can be interpreted and evaluated consistently, and that their effect on allocations can be analysed in advance.
Evaluation process
Policy evaluation in FortisX proceeds in two main phases: compliance checks and proposal generation.
Compliance checks
In the compliance phase, the engine:
Loads the current allocation snapshot for the relevant scope.
Fetches the corresponding analytics and risk profiles for all subjects under that scope.
Evaluates each applicable Policy against:
current exposures;
eligibility criteria;
any referenced risk profiles or metric thresholds.
The output of this phase is:
a set of policy evaluation records that indicate, for each subject and policy:
whether the policy is currently satisfied;
the magnitude and direction of any deviations (for example, by how much an exposure exceeds a limit);
any associated alerts that should be emitted.
These records can be consumed both by dashboards and by external systems that monitor policy adherence.
Proposal generation
Where policies are not satisfied and rebalancing is permitted, the engine can move to proposal generation:
Computes feasible target allocations that:
bring exposures back within policy-defined bounds;
respect any constraints on maximum change per interval;
preserve other invariants, such as total allocated capital within a portfolio.
Constructs allocation proposals that describe:
new target weights or amounts for each subject;
the net increase or decrease required relative to the current state;
any sequencing or phasing information, if rebalancing is intended to occur in steps.
Attaches metadata to each proposal, including:
which policies were involved;
which data snapshot and model versions were used;
evaluation timestamps and identifiers.
Allocation proposals are deterministic given the inputs: running the engine with the same data and policies yields the same result.
Determinism and auditability
Determinism is a key property of the policy engine:
For a given combination of:
allocation snapshot;
analytics and risk profiles;
policy set and model versions;
the engine produces the same evaluations and proposals.
This supports:
Auditability – it is possible to reconstruct the reasoning behind a past allocation proposal by re-running the engine with historical data and configurations.
Explainability – operators and risk committees can inspect which metrics, risk factors, and policy clauses were active and how they contributed to a given proposal.
Testing and simulation – model and policy changes can be applied to historical data in a non-production environment to understand their impact before adoption.
To facilitate this, all relevant inputs and outputs are stored with identifiers and timestamps, and references between them are recorded explicitly.
Governance and policy lifecycle
Policies themselves are subject to governance and lifecycle management. In FortisX, policies:
are created, updated, and retired through controlled processes;
carry metadata such as:
author or owner;
creation and modification timestamps;
approval status and, where applicable, governance references;
are versioned, so that changes result in new policy versions rather than silent edits in place.
The policy engine always evaluates allocations against a specific set of policy versions that is in force at the evaluation time. When policies are updated, the resulting change in behaviour can be analysed by comparing the outputs of the engine under old and new versions, using the same historical data.
Interaction with external execution systems
FortisX does not assume custody of assets or direct control over validator keys. Instead, external systems are responsible for:
approving or rejecting allocation proposals;
translating proposals into concrete execution steps (for example, on-chain staking operations or internal booking changes);
enforcing any additional internal rules, approvals, or compliance checks.
The policy engine supports this integration by:
exposing evaluations and proposals through dashboards, APIs, and integration hooks;
structuring proposals in a way that is compatible with typical execution flows (for example, specifying target positions rather than assuming step-by-step transactions);
recording the identifiers necessary for external systems to correlate proposals with their own events and decisions.
This separation allows organisations to embed FortisX into their existing governance and operational frameworks while still benefiting from a consistent analytic and policy layer.
Examples of policy types
While detailed examples are outside the scope of this section, the following high-level patterns illustrate how policies can be composed:
Concentration limits Limit the share of a portfolio that may be allocated to:
a single validator or pool;
a single provider across all networks;
a single network within a broader multi-network strategy.
Eligibility filters Exclude entities that:
fall into certain risk buckets along a specific factor (for example, persistent operational issues);
have unresolved incidents of a particular type;
do not meet defined decentralization or participation criteria at the network level.
Change control Restrict how fast allocations can be adjusted:
maximum relative or absolute change per interval;
minimum time between major reallocations under normal conditions.
Event-driven safeguards Require additional review or suspend certain types of changes when:
severe incidents are detected at a provider or network level;
specific governance or protocol events occur.
These patterns can be combined and specialised to reflect different risk appetites and operational constraints without changing the core behaviour of the policy engine.
Summary
The FortisX policy engine provides a formal link between data and allocation decisions. It:
consumes current allocations, analytics, and risk profiles;
evaluates explicit, versioned policies against this data;
produces deterministic, auditable allocation evaluations and proposals;
leaves execution and custody to external systems that operate under their own governance.
By separating analytics, risk modeling, policies, and execution, FortisX allows organisations to automate parts of their staking allocation process while retaining control over how decisions are implemented and reviewed.
Last updated