Federated AI Infrastructure with Verifiable Storage and ESG Integration

Functional Architecture

The functional architecture consists of four interoperable domains: AI compute (A, CMP), decentralised data storage (B, STR), distributed ledger infrastructure (C, DLT) and orchestration (D, ORC). These components are functionally decoupled to ensure modularity, jurisdictional separation and operational independence across heterogeneous regulatory contexts. The interaction and separation of these domains are illustrated in Figure 1.

AI compute (A, CMP) is divided into two subdomains: centralised training (A1, TRN) and decentralised inference (A2, INF). Training is concentrated in a high-density facility optimised for large-model development, including pretraining, fine-tuning and reinforcement workflows. Inference is executed across geographically distributed nodes in five standardised classes, configured for energy integration, regulatory containment and latency-efficient operation. The separation of training and inference enables auditability, reduces latency externalities and permits granular control over workload distribution. Decentralised data storage (B, STR) is provided by nodes operating under certified capacity, location and availability constraints. Data are encrypted, partitioned and distributed in compliance with data residency and access governance requirements. Logical separation from compute infrastructure prevents unauthorised inference and enables independent auditing of storage operations. The distributed ledger infrastructure (C, DLT) maintains verifiable contract state, token settlement and coordination logic. It records routing instructions, ESG scoring metrics and service-level compliance under formal consensus conditions. Smart contracts execute within this layer to isolate enforcement, reduce coordination load and support sovereign governance under multi-jurisdictional constraints. System orchestration (D, ORC) is implemented by a verifiable control layer interfacing with compute, storage and ledger domains. It manages task scheduling, node registration, resource discovery and fault isolation. This layer enforces protocol-level consistency across decentralised operations and preserves coherence, auditability and regulatory traceability under functional separation.

The interaction between these domains is formalised in Equation Eq. 1.

The function $\mathcal{F}$ maps the operational domains, comprising decentralised inference ($A2$), storage ($B$) and ledger infrastructure ($C$), into a system-wide operational state $\mathcal{O}$, governed by the orchestration layer ($D$). Orchestration functions as a verifiable control interface that enforces protocol-level consistency and ensures auditability across otherwise decoupled domains. Centralised training ($A1$) is excluded from this coordination logic, reflecting its independent role in large-model development. The expression $A = A1 \cup A2$, with $A1 \cap A2 = \emptyset$, formalises the architectural separation of training and inference. The orthogonality condition $D \perp (A1)$ states that orchestration operates independently of the training facility.

Infrastructure Topology

We propose a physically distributed Federated AI Infrastructure, structured as a jurisdictionally bounded system of interoperable node types. The topology reflects regulatory separation, functional independence and operational scalability across national infrastructure. The model is designed for sovereign deployment and supports integration with decentralised AI workloads, contract-based coordination and ESG-auditable resource governance. The relationship between functional domains and node types is shown in Figure 1.

The infrastructure consists of three node types, each assigned distinct roles within the system architecture. Node Type I corresponds to the centralised AI training facility (A1, TRN), providing the high-density compute required for pretraining and model refinement. Node Type II implements the orchestration layer (D, ORC), responsible for coordination, routing and contract logic. Both types are centralised components and are required in every instance of the national system. They form the operational core of the architecture and are typically deployed within controlled, high-compliance environments.

The distributed ledger is implemented as a permissioned consortium DAG (Directed Acyclic Graph) using a leaderless asynchronous Byzantine Fault Tolerant (aBFT) consensus protocol. Master DAG nodes, responsible for transaction finality, ordering and cross-domain validation, are integrated into Type II. Execution-level DAG nodes, which handle contract execution and local validation, are distributed across Type III infrastructure.

Node Type III comprises all decentralised infrastructure elements, including inference nodes (A2, INF), data storage (B, STR) and operational ledger components (C, DLT). These nodes vary in physical capacity and are deployed in five standardised sizes: micro (μ), small (S), medium (M), large (L) and extra-large (XL). While Types I and II are fixed in number and function, Type III nodes are variable in quantity and configuration. Their distribution depends on stakeholder investment decisions, local energy availability, regulatory incentives and ESG objectives. This modularity enables each jurisdiction to calibrate its infrastructure layout to national priorities while maintaining interoperability and functional symmetry across the system.

DAG-based consensus protocols support efficient, leaderless asynchronous Byzantine fault tolerance with high throughput and fairness. One system builds on DAG-Rider and Narwhal/Tusk, combining a communication DAG with synchronous fast-path optimisation to achieve atomic broadcast without additional consensus rounds (Spiegelman et al. 2022). A recent survey classifies DAG-based distributed ledger technologies into availability-focused and consistency-focused designs, analysing trade-offs in finality, fault tolerance, and fairness (Raikwar et al. 2025). Another framework implements permissioned asynchronous DAG consensus with logical time ordering and leaderless practical BFT across consortium participants (Choi et al. 2018). FAII adopts a permissioned consortium DAG with leaderless asynchronous BFT and integrates orchestration nodes to enforce finality, sustaining throughput and fault resilience under partial synchrony.

The system-wide infrastructure can be formalised as a tuple over node types and domain assignments, as shown in Equation Eq. 2.

The infrastructure is formalised as the tuple $\mathcal{I} = \big( \mathcal{N}_\text{I}, \mathcal{N}_\text{II}, \mathcal{N}_\text{III} \big)$, where $\mathcal{N}_\text{I}$, $\mathcal{N}_\text{II}$ and $\mathcal{N}_\text{III}$ denote the sets of deployed nodes of Type I, II and III, respectively. Each set is mapped to its associated functional domain. Type I nodes implement centralised AI training and are mapped to the subdomain $A1$. Type II nodes implement orchestration $D$ and host the master nodes $C^* \subset C$ of the distributed ledger infrastructure. Type III nodes support decentralised inference $A2$, decentralised data storage $B$, and the remaining DAG infrastructure $C \setminus C^*$, where $C \setminus C^*$ denotes the execution-level ledger nodes not assigned to Type II. This formalism captures the infrastructure layout and domain separation in a system-wide view.

While Node Types I and II are deployed as single instances within each national deployment of the Federated AI Infrastructure, their physical design must support scalable capacity. This includes vertical extension through modular upgrades and, where required, horizontal replication at the site level. During the planning and initial deployment phase, their sizing must reflect projected system traction, expected inference and coordination workloads, and jurisdiction-specific constraints on sustainable and non-renewable grid energy, commonly referred to as grey energy. Both node types are subject to an upper capacity bound determined by the maximum allocatable energy at the site, in order to prevent grid overload, maintain local infrastructure stability and support ESG-aligned deployment strategies. In this context, capacity denotes the aggregate technical potential of a node to perform its assigned function over a defined interval under nominal operating conditions. For Node Type I, this refers to sustained floating-point throughput (FLOPS) or training tokens per day, metrics standard in high-performance computing capacity planning (RAND Corporation 2024; Wikipedia contributors 2025b). For Node Type II, capacity corresponds to orchestration layer throughput, expressed as operations per second or validated control-state transitions per second, consistent with benchmarks used in orchestration and container-management frameworks (Straesser et al. 2023; G et al. 2023). In both cases, capacity is a function of hardware configuration, software stack efficiency, power provisioning, thermal design and compliance with operational duty cycles. It forms the basis for scaling decisions, energy budgeting and service-level estimation in infrastructure planning (TierPoint 2023; RAND Corporation 2024). The corresponding sizing constraints for Node Types I and II are formalised in Equations Eq. 3 and Eq. 3.

Here, $C_{\text{TRN}}$ and $C_{\text{ORC}}$ denote the installed capacities of the central training facility (Type I) and orchestration node (Type II), respectively. Each capacity must exceed a minimum functional threshold $C_{\text{min}}^{\cdot}$ while remaining within a jurisdiction-specific upper bound $C_{\text{max}}^{\cdot}(E_{\text{avail}}^{\cdot})$, determined by the permanently allocatable energy. This includes both renewable sources and transitional grey energy earmarked for AI infrastructure. These constraints ensure compliance with energy regulation and prevent destabilisation of local supply during deployment. The total installed capacity of Type III infrastructure is determined by the number and class of deployed decentralised nodes. Each node belongs to one of five standardised classes: micro, small (S), medium (M), large (L) and extra-large (XL). Node capacity is fixed per class. Stakeholders scale the system by replicating nodes within each class. The corresponding sizing constraint and class-level definitions are formalised in Equations Eq. 4 and Eq. 4.

Here, $C_{\text{III}}$ denotes the total installed capacity of Type III infrastructure. The lower bound $C_{\text{min}}^{\text{III}}$ corresponds to minimum viable operation. The upper bound $C_{\text{max}}^{\text{III}}(E_{\text{avail}}^{\text{III}})$ reflects the maximum permitted capacity under ESG-aligned energy allocation. The class-level components are defined by fixed node capacities $c_{i}$ and the number of deployed nodes $n_{i}$, for each class $i \in \{\mu, \text{S}, \text{M}, \text{L}, \text{XL}\}$.

Unlike Node Types I and II, which scale through capacity extension within a fixed node instance, Type III infrastructure scales horizontally by replicating nodes across the defined classes. Each Type III node operates at a fixed capacity determined by its class and is not internally extendable.

When additional capacity is required, stakeholders may provision new nodes in any of the five standardised sizes. This scaling logic preserves operational granularity, simplifies energy budgeting and supports incremental expansion strategies tailored to local constraints and stakeholder resources.

Each Node Type III instance integrates all operational subsystems required for decentralised participation, including AI inference execution (A2, INF), certified data storage (B, STR) and distributed ledger operations (C, DLT). This composite design ensures that each deployed node can independently execute inference tasks, host partitioned and encrypted data, and validate or execute smart contracts within the permissioned DAG infrastructure. Embedding all three functional domains in a unified physical unit enables modular deployment, localised resilience and protocol-level interoperability across geographically distributed infrastructure.

Pricing and eligibility proposal

A uniform flat rate by size, capacity and online time creates adverse selection and underprovision of high performance roles. A fully performance driven schedule risks centralisation in large classes and weak edge participation. A hybrid mechanism balances efficiency with decentralisation and ESG policy. Let node $j$ in class $i\in\{\text{\textmu},\mathrm{S},\mathrm{M},\mathrm{L},\mathrm{XL}\}$ process task types $t\in\mathbb{T}$. Define availability $a_{ij}\in[0,1]$, verified work $V_{ij,t}$, energy $e_{ij}$, non energy operating costs $o_{ij}$, and penalties $\ell_{ij}$. Let $c_i$ denote the fixed per node capacity unit. The payout decomposes into a size neutral availability floor, a performance component with policy multipliers, and deductions.

The availability floor $P^{\mathrm{base}}_{ij}$ pays for measured uptime and capacity readiness without favouring size beyond installed capacity. The performance term $P^{\mathrm{perf}}_{ij}$ remunerates verified work at task specific posted prices $p_t$, adjusted by three transparent multipliers. The ESG multiplier $m^{\mathrm{ESG}}_{i}\in[1,\overline{m}_{\mathrm{ESG}}]$ increases with the renewable share and certified carbon intensity of class $i$. The latency multiplier $m^{\mathrm{lat}}_{i,t}\in[1,\overline{m}_{\mathrm{lat}}]$ increases with SLO tightness and measured success for task type $t$. The diversity multiplier $m^{\mathrm{div}}_{i}$ counteracts concentration by reducing rewards as a class dominates the workload. Let $s_i$ denote the systemwide share of verified work executed by class $i$, and let $\bar{s}\in(0,1)$ be a target upper bound for any single class. A simple convex form is

Task routing remains size agnostic by default but preserves edge capacity for latency sensitive services. For a subset $\mathbb{T}_{\mathrm{edge}}\subseteq\mathbb{T}$ and reserve parameter $\alpha_t\in(0,1]$, $$\begin{align} \sum_{i\in\{\text{\textmu},\mathrm{S}\}} \phi_{i,t} \;\ge\; \alpha_t \qquad \text{for all } t\in\mathbb{T}_{\mathrm{edge}}, \label{eq:edge-reserve} \end{align}$$ where $\phi_{i,t}$ are orchestration routing shares. Posted prices clear congestion through a transparent surcharge tied to normalised queue length $q_t\in[0,\infty)$,

A flat uniform scheme is simple yet inefficient and prone to misallocation under heterogeneous costs and SLO constraints. A hybrid schedule with a size neutral availability floor and modest, measurable multipliers for ESG, latency and anti concentration delivers higher welfare and maintains diversity without engineering large ROI gaps. Expected behaviour under this design is a stable mixed fleet, with large and extra large nodes specialising in high throughput roles when they demonstrate superior verified work net of energy and penalties, and micro to medium nodes sustaining edge inference and local storage through the reserve and latency multiplier. Investors with cheap renewable energy and compliance readiness prefer larger classes. Risk averse or bandwidth constrained stakeholders prefer smaller classes, supported by the availability floor and edge routing guarantees.

Tiered token model and workload linked rewards

All Node Type III operators are remunerated through a unified token system. Tokens function as the invariant on chain unit of account and settlement measure across the system. Where fiat settlement is required, stakeholders convert tokens into a fiat redeemable stablecoin issued by a regulated entity under FINMA supervision or the competent national authority in the deployment jurisdiction, for example under an e money or payment institution regime. Conversion and redemption occur via licensed exchanges or settlement partners with full KYC and AML compliance and adherence to the travel rule. The regulated issuer maintains segregated one to one reserves with periodic attestations, and redemption is at par subject to fees. Protocol level token issuance, conversion and redemption are segregated duties: rewards are minted on chain to operators, while the stablecoin is issued off chain against reserves by the regulated issuer. This design preserves compliance readiness, auditability and cross node interoperability without prescribing a single jurisdictional monetisation pathway. Let the set of execution tiers be $\mathbb{T}=\{1,2,3,4\}$. Each tier $t\in\mathbb{T}$ represents increasing compute intensity, energy use and expected duration and is assigned a tier factor $\theta_t$ with $1=\theta_1<\theta_2<\theta_3<\theta_4$. Let operator $j$ in class $i\in\{\text{\textmu},\mathrm{S},\mathrm{M},\mathrm{L},\mathrm{XL}\}$ process verified work $V_{ij,t}$ for tier $t$. Let $a_{ij}\in[0,1]$ denote measured availability, $c_i>0$ the fixed per node capacity unit, $e_{ij}$ energy use, $o_{ij}$ non energy operating costs and $\ell_{ij}$ penalties. Let $p>0$ be the base token rate per unit of verified work and $p_0>0$ the availability rate. Token payouts decompose into a size neutral availability floor and a performance component with policy multipliers, net of deductions

The SLO multiplier $m^{\mathrm{SLO}}_{ij,t}$ rewards reliable, low latency execution and scales with success relative to a tier target $\bar s_t$

Tier pricing is posted and congestion aware. Let $q_t\ge 0$ be a normalised queue for tier $t$

Caps and dispersion constraints prevent reward concentration and misrouting

A flat, class based schedule is obtained as a special case by setting $m^{\mathrm{ESG}}_{ij}=m^{\mathrm{SLO}}_{ij,t}=m^{\mathrm{DIV}}_{i}=1$, $\gamma_t=0$ and dropping Eq. 26. The hybrid design in Eq. 21–Eq. 26 remains class neutral at the base layer while aligning payouts with verifiable performance, energy externalities and decentralisation.

Expected behaviour under the hybrid design is a mixed fleet. Large and extra large nodes specialise in higher tiers when their verified work net of energy and penalties is superior. Micro to medium nodes sustain edge and mid tier tasks, supported by availability floors, dispersion and diversity incentives. Investors with low cost renewable energy and compliance readiness tend to prefer larger classes. Risk averse or bandwidth constrained stakeholders prefer smaller classes with stable availability income and low variance SLO profiles. A purely flat scheme simplifies accounting yet misallocates work under heterogeneous costs and SLO constraints, while the hybrid preserves simplicity at the base level and uses bounded multipliers and caps to prevent concentration and reward distortion.

Table 1 provides an illustrative overview of typical workloads, indicative SLO, and example token payouts per validated unit of work. DAG operations are accessible to all Type III nodes. Micro nodes prioritise low-latency edge inference and local storage, while XL nodes focus on high-throughput inference and ledger validation, subject to energy and bandwidth availability. This proposal serves as a baseline for refinement in real deployments and future research using empirical workload traces and energy pricing data.

Typical node roles All Type III nodes participate in DAG operations. Micro and Small prioritise edge inference and local storage with steady DAG participation. Medium balances interactive inference and storage with continuous DAG work. Large and XL specialise in batch inference and high throughput DAG validation subject to site energy and bandwidth. Notation $p$ denotes the base token unit. Figures are illustrative and subject to calibration in production.

The token multipliers used in Table 1 are straight and equidistant $(1p, 2p, 3p, 4p)$, applied here for demonstrative purposes. This linear schedule is a simplifying placeholder and does not fully reflect non-linear costs, congestion effects, SLO risk or differing PUE (Power Usage Effectiveness, the ratio of total facility energy to energy used for compute) across node classes. Variations in PUE impact the real cost of verified work and must be reflected in the reward function. A fair and incentive-compatible design will generally require non-equidistant multipliers derived from observed performance and market conditions, for example $(1p, 2.221p, 3.476p, 4.333p)$ once calibrated to verified work, energy intensity and latency success.

Initial deployment may exhibit imbalance as demand, hardware efficiency and orchestration policy co evolve. GPU performance per watt, network costs and SLO penalties will shift relative economics over time, which implies that fixed linear multipliers will misprice tasks and bias routing. A data driven procedure that estimates multipliers from telemetry and queue observations improves fairness under the proposed Nash equilibrium, since prices then internalise congestion and risk rather than rewarding size alone.

We propose live testing and periodic optimisation while the system is active. Tier multipliers are updated on a published schedule from simulation and real workload traces, subject to caps on change to preserve stability, for example a maximum relative adjustment per period. Updates are proposed on chain, reviewed by the consortium and adopted by vote, and the new schedule is published with methodology and validation artefacts. This governance process mirrors an index calculation, ensures transparency and allows the multiplier curve to converge toward efficiency as evidence accumulates.

Network equilibrium and coordination constraints

Beyond computational, monetary and energy-layer equilibria, the operational feasibility of a federated AI infrastructure depends on network-level constraints governing routing, latency and connectivity. A task may be economically and energetically optimal on a given node but must also be physically deliverable within service-level thresholds. This introduces a fourth equilibrium dimension: network equilibrium, defined by the topology, bandwidth and latency properties of the physical and virtual network interconnecting all participating nodes. This layer captures the real-time viability of inference, storage and ledger operations under dynamic routing conditions. It constrains the token model indirectly via node selection and affects ESG compliance when rerouting increases energy externalities. Network equilibrium must be integrated into orchestration logic to prevent systemic misallocation, geographic underutilisation and latency violations. Security and governance equilibria, addressing adversarial robustness and inter-jurisdictional coordination, are acknowledged for completeness but fall outside the operational scope of this paper. These aspects are reserved for future work. The design of the Federated AI Infrastructure requires coordination among heterogeneous, self-interested stakeholders. Each actor, including node operators, energy providers and regulatory entities, optimises its own objective function subject to common protocols, physical constraints and market interactions. These actors operate independently and may act strategically, especially in settings where partial compliance, opportunistic reporting or selective engagement offer local benefit. Stability cannot be assumed ex ante but must emerge from a structure in which individual incentives are aligned with collective feasibility. This condition is modelled through the classical Nash equilibrium, which characterises a configuration in which no participant can unilaterally improve their outcome given the strategies of others (Osborne and Rubinstein 2004). Let $\mathcal{P}$ be the set of participants, each with strategy set $S_i$ and utility function $U_i$. A strategy profile $s^* = (s_1^*, s_2^*, \ldots, s_n^*) \in S_1 \times S_2 \times \cdots \times S_n$ constitutes a Nash equilibrium if and only if

This equilibrium structure reflects the decentralised nature of the system. It requires no central enforcement and is stable under rational behaviour, provided that system parameters remain fixed. The use of Nash equilibrium in this context captures the strategic logic of federated infrastructure governance, where participants are individually rational, partially aligned, and jointly constrained. The next section identifies four operational domains in which such equilibria structure coordination outcomes.

Operationalising ESG in Federated AI Infrastructure

The Federated AI Infrastructure (FAII) aligns high-performance AI workloads with verifiable ESG criteria. Unlike conventional data centres, FAII requires decentralised coordination across heterogeneous nodes. To make ESG computable for orchestration and token allocation, environmental impact must be expressed through internal, measurable indicators.

AI infrastructure creates environmental externalities mainly through electricity consumption, cooling overhead and energy source composition. Among these, sourcing and cooling efficiency account for most operational variance (Cao et al. 2021). External metrics such as national Power Usage Effectiveness (PUE), defined as total facility energy divided by energy used for compute (Hanstein 2015), or grid-average carbon intensity do not apply to FAII, which allocates tasks only within its own infrastructure. Internal benchmarks such as PUE, Carbon Usage Effectiveness (CUE) and Water Usage Effectiveness (WUE) are therefore used for coordination and ESG scoring (Wilson 2023; LATAM 2023).

To enable verifiable comparison without imposing fixed assumptions, we define a discrete, internal scoring model across four indicators. First, carbon source profile reflects the share of certified renewable or zero-carbon energy in a node’s mix, based on real-time reporting and audit. Second, cooling efficiency is measured as relative PUE (rPUE), the ratio of a node’s PUE to the FAII-wide average, enabling fair comparison across heterogeneous infrastructure. Third, energy-to-work efficiency captures verified inference or validation operations per kilowatt-hour, normalised by task type and node class. Fourth, the grid externality score estimates marginal burden on the local power grid, based on geolocation and grid stress data. Let $\mathcal{N}$ be the set of active nodes and let each node $i \in \mathcal{N}$ report a four-dimensional ESG indicator vector:

Each node is thus assigned a composite score reflecting its relative environmental performance within the FAII. These scores inform task scheduling, token rewards and orchestration preferences. Because all indicators are internally defined and normalised, they enable incentive-compatible environmental optimisation without reliance on external benchmarks or central enforcement.

While the renewable energy share $\rho_i$ reflects the proportion of non-fossil inputs in a node’s energy mix, it does not distinguish among the heterogeneous externalities of different renewable sources. Solar, wind, hydro, geothermal and biomass vary significantly in emissions, storage requirements and lifecycle footprint. To capture this heterogeneity, the FAII consortium may establish a weighted index over certified renewable energy types. Each source $s \in \mathcal{S}$ is assigned a strategic multiplier $\lambda_s \in [0,1]$, reflecting its relative desirability under ESG objectives. The adjusted renewable share becomes

The orchestration layer uses $\rho_i^{\text{adj}}$ as the input for ESG-based routing and token allocation, ensuring that source quality, not just quantity, informs decision logic. Table 2 illustrates a hypothetical assignment of weights for illustrative purposes only. Actual values must be derived from transparent, multi-stakeholder evaluation and are expected to vary across jurisdictions.

This extension improves alignment between ESG goals and orchestration logic. It preserves flexibility for jurisdictional variation and reflects strategic policy objectives. Future research should focus on empirical validation of weights, lifecycle impacts across regions, and resilience trade-offs under demand fluctuations.

ESG-aware orchestration logic and system biasing

System orchestration (D, ORC, Type II node) coordinates decentralised operations and executes ESG policy within the FAII. In addition to routing, task allocation and protocol enforcement, ORC integrates environmental preference structures into its decision logic. This includes a programmed bias towards ESG-optimised nodes based on real-time performance scores.

ORC receives as input the composite ESG score $\text{ESG}_i$ and its component metrics: adjusted renewable share $\rho_i^{\text{adj}}$, relative cooling efficiency $\eta_i$, energy-to-work ratio $\varepsilon_i$, and local grid impact $\gamma_i$. These are updated continuously via the IIoT layer and validated through the permissioned DAG. Carbon credits, source attestations and routing events are immutably recorded with timestamps and geolocation, ensuring auditability. This design establishes a game-theoretic feedback loop. Node operators, knowing that ESG performance affects workload and token allocation, are incentivised to adapt sourcing and infrastructure. The system thereby converges towards decentralised environmental optimisation without central enforcement. This dynamic depends on verifiable metrics, coherent signals and synchronised subsystem flows. The DAG ensures traceability and event-binding; ORC operationalises ESG input into task decisions.

The orchestration logic follows a constrained optimisation model. Let $\mathcal{T}$ be the task pool, $\mathcal{N}$ the active nodes. Define $\delta_{t,i} \in \{0,1\}$ as the assignment indicator, and $\mathcal{S}(t,i) \in \{0,1\}$ as technical eligibility. Then:

This ensures every task is assigned to a compatible node while maximising aggregate ESG alignment. The resulting distribution mechanism embeds environmental policy directly into operational logic, serving performance and governance objectives concurrently.

Internal market coordination and bounded price dynamics

The Federated AI Infrastructure (FAII) implements a closed internal market for decentralised workload allocation. Each Type III node operator acts as a market participant, offering compute, storage or validation capacity in exchange for token-based compensation. Tokens are minted upon verifiable service delivery, with output weighted by performance, reliability and ESG-adjusted multipliers. Internal pricing of service-level objectives (SLOs) is determined dynamically through decentralised offer logic, constrained by governance-defined corridors. Let $\bar{p}$ denote the system-wide average token price per standardised workload unit. Each node $i \in \mathcal{N}_{\text{III}}$ may submit an offer to process tasks at an effective unit price $p_i$. To prevent destabilising undercutting or speculative inflation, all bids must fall within a bounded corridor around the current system average:

Nodes with lower ESG multipliers, due to suboptimal energy sourcing or cooling efficiency, can remain competitive by offering discounts. This creates a rational trade-off between investing in ESG upgrades to improve token multipliers and reducing price within corridor bounds to attract tasks despite lower scores. The orchestration layer evaluates both the adjusted ESG score and the declared price $p_i$ when making routing decisions.

Let $m_i \in [0,1]$ be the ESG-based token multiplier assigned to node $i$. The effective token reward for a unit workload is:

This pricing logic creates a self-regulating and incentive-compatible environment. It embeds economic and environmental competition within FAII’s tokenised infrastructure without requiring centralised optimisation. Strategic autonomy is preserved, while bounded price constraints prevent market fragmentation and disincentives for ESG alignment. Threshold parameters $\delta^-$ and $\delta^+$ are adjustable by the FAII governance consortium and may be revised in response to macroeconomic shifts, policy changes or system-wide coordination goals.