SettleFL: Trustless and Scalable Reward Settlement Protocol for Federated Learning on Permissionless Blockchains (Extended version)

Shuang Liang; Yang Hua; Linshan Jiang; Peishen Yan; Tao Song; Bin Yao; Haibing Guan

cs.CRFeb 26, 2026

SettleFL: Trustless and Scalable Reward Settlement Protocol for Federated Learning on Permissionless Blockchains (Extended version)

Authors: Shuang Liang, Yang Hua, Linshan Jiang, Peishen Yan, Tao Song, Bin Yao, Haibing Guan

Organizations: Shanghai Jiao Tong University · Queen's University Belfast · Queen’s University Belfast · National University of Singapore

Abstract

In open Federated Learning (FL) environments where no central authority exists, ensuring collaboration fairness relies on decentralized reward settlement, yet the prohibitive cost of permissionless blockchains directly clashes with the high-frequency, iterative nature of model training. Existing solutions either compromise decentralization or suffer from scalability bottlenecks due to linear on-chain costs. To address this, we present SettleFL, a trustless and scalable reward settlement protocol designed to minimize total economic friction by offering a family of two interoperable protocols. Leveraging a shared domain-specific circuit architecture, SettleFL offers two interoperable strategies: (1) a Commit-and-Challenge variant that minimizes on-chain costs via optimistic execution and dispute-driven arbitration, and (2) a Commit-with-Proof variant that guarantees instant finality through per-round validity proofs. This design allows the protocol to flexibly adapt to varying latency and cost constraints while enforcing rational robustness without trusted coordination. We conduct extensive experiments combining real FL workloads and controlled simulations. Results show that SettleFL remains practical when scaling to 800 participants, achieving substantially lower gas cost.

Figures & tables

Figure 1. Overview of SettleFL protocol family. Our protocol resolves the conflict between costly on-chain execution and high-frequency FL updates. It navigates the scalability-finality trade-off through two variants: Commit-and-Challenge for minimal cost, and Commit-with-Proof for instant finality. A shared SNARK architecture flexibly enforces correctness by either guaranteeing validity upfront or resolving disputes with minimal on-chain overhead. The figure illustrates the design and components of the SettleFL protocol across three panels: \par**Left Panel: Motivation & Context** * **Problem Domain:** Focuses on "FL Fairness", explicitly treating "Contribution Evaluation" as an "Input" to "Reward Settlement" (the core focus). * **Key Insight:** States that "FL needs *collaboration fairness*, but blockchains alone are not enough." * **Metrics:** Highlights the trade-off between "Scalability" and "Finality" in a Trustless environment. * **Legend:** Distinguishes between "Orthogonal directions" (grey) and "Our focus" (green/highlighted). \par**Middle Panel: Protocol Strategies (SettleFL-CP vs SettleFL-CC)** * **Commit-with-Proof (SettleFL-CP):** * **Mechanism:** Aggregator commits reward with proof \pi. * **Characteristics:** Commit Finality, but higher cost and latency. * **Commit-and-Challenge (SettleFL-CC):** * **Mechanism:** Aggregator commits reward digest C; others verify off-chain. * **Interactive Process:** Anyone challenges misbehavior; Aggregator may counter. * **Characteristics:** Quasi Finality with low cost/latency, but depends on an interactive dispute resolution period. * **SettleFL Goal:** Use the SettleFL protocol to balance finality with scalability overhead (cost and latency). \par**Right Panel: Challenge Mechanism Detail** * **Objective:** "Use SNARK proofs to minimize cost" during disputes. * **Process:** Depicts a step-by-step state comparison between the Prover (Aggregator) and a Challenger. * **Divergence Check:** * Shows a sequence of states $C$ and $C'$. * Identifies the specific step $j$ where the states diverge: matching at $j-1$ ($C'_{j-1} = C_{j-1}$) but differing at $j$ ($C'_j \neqC_j$). * **Outcome:** This mechanism allows the protocol to enforce correctness with minimal on-chain computation. — Figure 1. Overview of SettleFL protocol family. Our protocol resolves the conflict between costly on-chain execution and high-frequency FL updates. It navigates the scalability-finality trade-off through two variants: Commit-and-Challenge for minimal cost, and Commit-with-Proof for instant finality. A shared SNARK architecture flexibly enforces correctness by either guaranteeing validity upfront or resolving disputes with minimal on-chain overhead. The figure illustrates the design and components of the SettleFL protocol across three panels: \parLeft Panel: Motivation & Context * **Problem Domain:** Focuses on "FL Fairness", explicitly treating "Contribution Evaluation" as an "Input" to "Reward Settlement" (the core focus). * **Key Insight:** States that "FL needs *collaboration fairness*, but blockchains alone are not enough." * **Metrics:** Highlights the trade-off between "Scalability" and "Finality" in a Trustless environment. * **Legend:** Distinguishes between "Orthogonal directions" (grey) and "Our focus" (green/highlighted). \parMiddle Panel: Protocol Strategies (SettleFL-CP vs SettleFL-CC) * **Commit-with-Proof (SettleFL-CP):** * **Mechanism:** Aggregator commits reward with proof \pi. * **Characteristics:** Commit Finality, but higher cost and latency. * **Commit-and-Challenge (SettleFL-CC):** * **Mechanism:** Aggregator commits reward digest C; others verify off-chain. * **Interactive Process:** Anyone challenges misbehavior; Aggregator may counter. * **Characteristics:** Quasi Finality with low cost/latency, but depends on an interactive dispute resolution period. * **SettleFL Goal:** Use the SettleFL protocol to balance finality with scalability overhead (cost and latency). \parRight Panel: Challenge Mechanism Detail * **Objective:** "Use SNARK proofs to minimize cost" during disputes. * **Process:** Depicts a step-by-step state comparison between the Prover (Aggregator) and a Challenger. * **Divergence Check:** * Shows a sequence of states $C$ and $C'$ . * Identifies the specific step $j$ where the states diverge: matching at $j-1$ ( $C'_{j-1} = C_{j-1}$ ) but differing at $j$ ( $C'_j \neqC_j$ ). * **Outcome:** This mechanism allows the protocol to enforce correctness with minimal on-chain computation.

Figure 2. Landscape of Settlement Strategies. Unlike the active baselines L2FL ( Alief et al., 2023 ) , StateFL ( Iacoban, 2024 ) , and BCFL ( Xu et al., 2021 ) which require user participation, SettleFL enables passive interaction via its two variants, SettleFL-CC (CC) and SettleFL-CP (CP). Notably, if anchored finality is compromised to the windowed stage, the protocol essentially degrades to an

n

-round batched CC or CP. +————-+——————+——————+——————+ | Interaction | Windowed | Quasi | Commit | +————-+——————+——————+——————+ | Active | L2FL | StateFL | BCFL | | | | | | | | | | | v | v | v | v | | Passive | n-round CC/CP | CC | CP | +————-+——————+——————+——————+ (Anchored Finality Axis –>)

Figure 3. Timeline Analysis of Latency. By synchronizing settlement with the aggregation cycle, SettleFL eliminates extrinsic delays, bounding latency to the theoretical minimum. Timeline diagrams comparing four commitment strategies. \par(a) Commit-per-update: - Visual: Frequent interaction. - Flow: Participants compute -> Immediate update to Blockchain. - Blockchain Timeline: Dotted with many black diamonds (records). \par(b) Commit-per-round over L2: - Visual: Two-layer interaction. - Flow: Participants -> L2 (Long block time) -> Main Blockchain. - Difference: Adds an intermediate L2 timeline above the chain. \par(c) Commit-per-round (Standard): - Flow: Participants compute -> Aggregator performs Aggregation (Sigma) -> Single commit to Blockchain. - Visual: A distinct aggregation block precedes the on-chain record. \par(d) Commit-per-round with proof (Proposed): - Flow: Participants compute -> Aggregator performs Aggregation (Sigma) -> Proof Generation (Pi) -> Single commit. - Visual: Adds a gray "Proof generation" block after aggregation, delaying the on-chain record compared to (c).

Figure 4. System architecture overview. Shared cryptographic primitives underpin the architecture, enabling specialized modules to enforce distinct security assumptions. System Modules: - 4.1 Architecture - 4.2 Commitment Scheme - 4.3 Smart Contracts - 4.4 Circuit Gadgets - 4.5 Main Circuits - 4.6 Incentive Compatibility \parActors: - SettleFL-CC - SettleFL-CP \parSmart Contract Functions: - Commit(

C

) - Commit(

C, \pi

) - Distribute(

\cdots, \pi

) - Challenge(

\cdots, \pi

) - Counter(

\cdots, \pi

) \parCircuit Components: - Challenge Circuit - Transition Circuit - Distribution Circuit - (Compose of) \parVisual Relationships: - The diagram is layered from Actors (top) to Smart Contracts (middle) to Circuits (bottom). - CC (Green) connects to Commit(

C

) and Incentive Compatibility. - CP (Brown) connects to Commit(

C, \pi

), Distribute, and the Commitment Scheme. - The Transition Circuit serves as a dependency, connecting via arrows to the Challenge Circuit and Distribution Circuit.

Figure 5. System Workflow. tx : on-chain transaction; event : smart contract event; peer : off-chain peer communication. System Workflow. ## Roles: - Blockchain (Smart Contract) - Aggregator - Participants \par## Sequence: \parInit - (t1) tx create() - (e1) event created() - (p1) peer join() \parCommit Stage (loop) - (p2) peer pubModel() - action train() - (p3) peer pubUpdate() - action aggregate() - (t2) tx commit() - (p4) peer sync() - (e2) event committed() - action check() - action verify() \parFinal Stage - (t3) tx finalize() - (t4) tx challenge() - (t5) tx counter() - (t6) tx distribute()

Figure 6. Design space of cryptographic binding mechanisms for reward enforcement. We show four approaches with increasing stronger binding. We adopts the second, using aggregator-signed commitments to balance cost, scalability, and verifiability. The diagram displays four distinct commitment architectures involving an Aggregator (

\mathcal{A}

), Client (

\mathcal{C}

), and Participants (

\mathcal{P}

). \parLegend key: - Solid arrow: Round-level Commit - Dashed arrow: Session-level Commit - Dotted arrow: Unsigned Commitment - Pen icon: Sign the Commitment \par1. Unilateral Commit: - Feature: "No cryptographic binding to participants" - Structure:

\mathcal{A}

sends to

\mathcal{C}

. \par2. Signed Broadcast: (Highlighted) - Feature: "Aggregator signs the commitment" - Structure:

\mathcal{A}

signs and transmits to both

\mathcal{C}

and

\mathcal{P}

. \par3. Pair Signatures: - Feature: "Each

\mathcal{P}

signs and receives aggregator's signature" - Structure:

\mathcal{A}

engages in bidirectional signing with multiple

\mathcal{P}

s. \par4. Multi-Signature: - Feature: "Joint signature over commitment" - Structure:

\mathcal{A}

and multiple

\mathcal{P}

s coordinate for a collective signature.

Figure 7. Contract state transitions. In (b) Commit-and-challenge, if a dispute exists, challenges are allowed at any point before distribution. The protocol follows either a multi-shot (ms) or one-shot (1s) path based on the chosen distribution method. The figure displays two related state transition diagrams labeled (a) and (b). \par## (a) Commit-with-proof [] –> A_Committed: create() A_Committed –> A_Committed: commit(C) A_Committed –> A_RewardInit: finalize() \parA_RewardInit –> A_Distributing A_RewardInit –> A_Distributed: distribute_1s(P, v, \pi) \parA_Distributing –> A_Distributing: distribute_ms(P, v, \pi) A_Distributing –> A_Distributed: distribute_ms(P, v, \pi) \par## (b) Commit-and-challenge [] –> B_Committed: create() B_Committed –> B_Committed: commit(C) B_Committed –> B_RewardInit: finalize() \parB_Committed –> Challenged: challenge(C, r, \pi) B_RewardInit –> Challenged: challenge(C, r, \pi) Challenged –> Challenged: challenge(C, r, \pi) Challenged –> B_RewardInit: counter(\pi) Challenged –> RewardDistributable: after delay \parB_RewardInit –> RewardDistributable: after delay \parRewardDistributable –> B_Distributing RewardDistributable –> B_Distributed: distribute_1s(P, v, \pi) \parB_Distributing –> B_Distributing: distribute_ms(P, v, \pi) B_Distributing –> B_Distributed: distribute_ms(P, v, \pi) \par

Dataset	Samples	Classes	Task
MNIST ( Deng, 2012 )	70,000	10	image classification
Fashion-MNIST ( Xiao et al., 2017 )	70,000	10	image classification
CIFAR-10 ( Krizhevsky, 2009 )	60,000	10	image classification
Bank ( Moro et al., 2014 )	45,211	2	tabular data classification
Cora ( McCallum et al., 2000 )	2,708	7	graph node classification
Twitter ( Go et al., 2009 )	1,194,723	2	text classification

Table 1. Characteristics of datasets.

Figure 8. End-to-end protocol accuracy over training rounds under different participant counts. Results use a default learning rate of 0.001, a batch size of 32, and 2 local epochs per round, except for Cora (learning rate 0.015, 10 local epochs) and Twitter (1 local epoch). Three-panel line chart: the left, middle, and right panels correspond to MNIST, Fashion-MNIST, and CIFAR-10, respectively. In each panel, three curves represent experiments with 5, 10, and 20 participants. The x-axis denotes training rounds (1–20), and the y-axis shows global model test accuracy in percent. Vertical error bars indicate the minimum and maximum accuracies across multiple independent runs evaluated by the aggregator. All panels present results for exactly 20 training rounds under identical hyperparameters.

	SettleFL-CP		SettleFL-CC
Operation	mETH	USD	mETH	USD
$\operatorname{create}$	0.012	0.02	0.012	0.02
$\operatorname{commit}$ (per call)	0.021	0.04	0.005	0.01
$\operatorname{commit}$ (50 $\times$ total)	1.066	2.08	0.239	0.47
$\operatorname{finalize}$	0.005	0.01	0.005	0.01
$\operatorname{challenge}$	–	–	0.021	0.04

Table 2. Cost breakdown comparison of representative Sepolia deployments for SettleFL . (800

\mathcal{P}

, 50 rounds on MNIST)

Figure 9. Per-round cost and latency comparison. SettleFL variants achieve stable gas usage and low latency.

Figure 10. Gas cost comparison of StateFL and SettleFL . StateFL incurs 456k gas per participant. Conversely, SettleFL-CC and SettleFL-CP cost 63k and 281k gas per round, remaining more efficient except in high-round, low-participant settings. The figure compares gas consumption of StateFL and \sys{} across two scalability dimensions. \textbf{Left (x-axis: Participants):} StateFL shows a linearly increasing curve with participant count and remains flat across rounds. In contrast, \sys{} appears as multiple horizontal lines, each representing a fixed number of rounds (10, 50, 100, 200), since its cost does not depend on participants. \textbf{Right (x-axis: Rounds):} \sys{} shows a linearly increasing curve with rounds and remains flat across participants. StateFL appears as multiple horizontal lines, each corresponding to a fixed number of participants (10, 50, 100, 200). Gas values are derived from theoretical models calibrated by empirical measurements: about 456k gas per participant for StateFL (from our re-implementation on Perun) and about 63k gas per round for \sys{} (measured on Ethereum-compatible deployment). The curves highlight that \sys{} maintains lower cost in typical regimes and only exceeds StateFL when the number of rounds is very large (e.g., above 200) and the participant set is very small (e.g., fewer than 25). — Figure 10. Gas cost comparison of StateFL and SettleFL . StateFL incurs 456k gas per participant. Conversely, SettleFL-CC and SettleFL-CP cost 63k and 281k gas per round, remaining more efficient except in high-round, low-participant settings. The figure compares gas consumption of StateFL and \sys{} across two scalability dimensions. **Left (x-axis: Participants):** StateFL shows a linearly increasing curve with participant count and remains flat across rounds. In contrast, \sys{} appears as multiple horizontal lines, each representing a fixed number of rounds (10, 50, 100, 200), since its cost does not depend on participants. **Right (x-axis: Rounds):** \sys{} shows a linearly increasing curve with rounds and remains flat across participants. StateFL appears as multiple horizontal lines, each corresponding to a fixed number of participants (10, 50, 100, 200). Gas values are derived from theoretical models calibrated by empirical measurements: about 456k gas per participant for StateFL (from our re-implementation on Perun) and about 63k gas per round for \sys{} (measured on Ethereum-compatible deployment). The curves highlight that \sys{} maintains lower cost in typical regimes and only exceeds StateFL when the number of rounds is very large (e.g., above 200) and the participant set is very small (e.g., fewer than 25).

Figure 11. Gas cost of SettleFL-CC and SettleFL-CC-Sol .

	50 rounds					100 rounds					200 rounds
Circuit	Cnstr.	I-GPU	I-CPU	S-CPU	R-CPU	Cnstr.	I-GPU	I-CPU	S-CPU	R-CPU	Cnstr.	I-GPU	I-CPU	S-CPU	R-CPU
$\operatorname{challenge}$	1.1/1.8	0.6/1.1	26/41	46/79	6.5/11	2.2/3.5	1.2/2.2	46/77	86/147	12/21	4.3/6.9	2.4/11	84/142	165/282	24/41
$\operatorname{transition}$	2.2/3.4	1.2/2.2	47/79	86/146	12/21	4.3/6.8	2.4/11	84/142	163/286	23/40	8.4/13.5	12/AF	161/281	314/585	43/83
$\operatorname{distribute-1s}$	1.1/1.8	0.6/1.1	26/41	46/78	6.6/11	2.2/3.5	1.2/2.2	44/75	85/147	12/21	4.3/6.9	2.4/11	85/141	171/288	23/41
$\operatorname{distribute-ms}$	1.1/1.8	0.6/1.1	26/39	46/78	6.7/12	2.2/3.5	1.2/2.1	46/75	85/148	13/22	4.3/6.9	2.4/11	86/144	164/281	24/41

Table 3. Constraint count and average proof generation time for main circuits across different backends and configurations.

Figure 12. Bytecode size comparison between one-shot and multi-shot variants. The horizontal dashed line marks the 24KB maximum contract size allowed on Ethereum.

Figure 13. Multi-shot variant scalability up to 800

\mathcal{P}

. Per-batch gas is invariant to total

\mathcal{P}

, while total gas scales linearly. Gas cost comparison between one-shot and multi-shot variants across varying batch sizes.

Incentive Mechanisms for Federated Learning

See all 10 papers

SCOPE-FL: A Strategy-proof Chain-based Optimal pareto efficient Federated Learning System
Jun 16, 2026Seyed Salar Ghazi, Kaiwen Zhang, Mehdi feizi +1Hierarchical Federated Learning Mechanism Design
Department of Software and IT Engineering, École de Technologie Supérieure (ÉTS), Montréal, QC H3C 1K3, Canada · Department of Economics, Faculty of Economics and Administrative Sciences, Ferdowsi University of Mashhad, Mashhad, Iran · Department of Electrical and Computer Engineering, University of Toronto, Toronto, ON M5S 3G4, Canada
Knowledge-Free Correlated Agreement for Incentivizing Federated Learning
May 6, 2026Leon Witt, Togrul Abbasli, Kentaroh Toyoda +2Incentive Mechanisms for Federated Learning Federated Learning
SIMIS Shanghai Shanghai, China · Tsinghua University Beijing, China · Keio University Yokohama, Japan +1
Scalable and Verifiable Federated Learning for Cross-Institution Financial Fraud Detection
Apr 25, 2026Prajwal Panth, Nishant NigamFederated Learning Aggregation Communication-Efficient Distributed Training
School of Computer Engineering, KIIT Deemed to be University, Bhubaneswar, India · School of Electronics Engineering, KIIT Deemed to be University, Bhubaneswar, India

Jun 16, 2026J/K move · Enter open · S save

SCOPE-FL: A Strategy-proof Chain-based Optimal pareto efficient Federated Learning System

Seyed Salar Ghazi, Kaiwen Zhang, Mehdi feizi, Hans-Arno Jacobsen

Department of Software and IT Engineering, École de Technologie Supérieure (ÉTS), Montréal, QC H3C 1K3, Canada · Department of Economics, Faculty of Economics and Administrative Sciences, Ferdowsi University of Mashhad, Mashhad, Iran · Department of Electrical and Computer Engineering, University of Toronto, Toronto, ON M5S 3G4, Canada

Hierarchical Federated Learning Mechanism Design Client Selection in Federated Learning Blockchain-Based Federated Learning Federated Learning

Open paper AskPDF arXiv

Hierarchical Federated Learning (HFL) enables scalable collaborative model training across distributed devices while preserving data privacy. However, existing HFL client selection mechanisms suffer from a fundamental strategic inefficiency. By prioritizing stability over Pareto efficiency (PE), they produce suboptimal resource allocations, and without strategy proofness (SP), participants are incentivized to misrepresent their true preferences, both failures degrading system overall welfare in the Pareto sense in practice. To address it, we propose SCOPE-FL (Strategy-proof Chain-based Optimal pareto efficient Federated Learning), a synchronous HFL framework that formulates client selection as a two-sided school choice problem solved through the Top Trading Cycle (TTC) algorithm that simultaneously guarantees PE and SP. For reward distribution, SCOPE-FL employs a scalable Shapley value approximation based on One-Round Reconstruction (OR), ensuring compensation proportional to each client's contribution. The entire mechanism executes via blockchain smart contracts, providing the tamper-proof environment required for the SP guarantees to hold in practice. A comprehensive evaluation on MNIST, Fashion-MNIST, and CIFAR-10 demonstrates that SCOPE-FL outperforms state-of-the-art approaches, including DA, IAS, and other methods across model accuracy, convergence rate, and reward efficiency, while achieving communication latency comparable to DA and blockchain overhead significantly lower than DA at scale.

Abstract

Incentive Mechanisms for Federated Learning

Explore similar work

SCOPE-FL: A Strategy-proof Chain-based Optimal pareto efficient Federated Learning System

Knowledge-Free Correlated Agreement for Incentivizing Federated Learning

Scalable and Verifiable Federated Learning for Cross-Institution Financial Fraud Detection