Federated Proof Server

• Federated proof servers are systems that issue, verify, and anchor cryptographic proofs for secure aggregation, participation, and state transitions while preserving raw data confidentiality.
• They employ various mechanisms like zero-knowledge proofs, threshold signatures, and secure aggregation protocols to validate complex federated operations.
• Architectural patterns range from single-server secure aggregation to multi-server orchestration, reflecting trade-offs between confidentiality, robustness, and verifiability.

A federated proof server is best understood as a server-side or server-adjacent subsystem in federated computing that issues, verifies, serves, or anchors evidence about cross-boundary execution, aggregation, participation, provenance, or state transitions while keeping raw data local or otherwise hidden. In the current literature, it does not denote a single standardized protocol. Instead, it appears as an architectural role spanning private federated aggregation, zero-knowledge-verified update admission, proof-of-participation, provenance registries, attested state-transition services, and proof-carrying boundary admission (Ma et al., 2023, Ghodsi et al., 2022, İşler et al., 11 Nov 2025, Kasyap et al., 7 Jul 2026, Takagi et al., 10 Sep 2025, C. et al., 30 Jun 2026, Fenoglio et al., 18 Mar 2026).

1. Scope and definitional boundaries

The literature assigns markedly different meanings to “proof” in federated settings. In secure aggregation systems such as Flamingo, the server learns only aggregates across many rounds and remains robust to dropout, but the construction does not provide public verifiability, succinct proofs of correct aggregation, auditable transcripts proving correct model updates, or zero-knowledge proofs that clients followed local training correctly; malicious clients may still submit bogus updates, and input correctness is explicitly out of scope (Ma et al., 2023). In zPROBE, the server verifies zero-knowledge statements about hidden client updates, but the server itself is semi-honest and no proof is provided that it clustered users or computed thresholds correctly (Ghodsi et al., 2022). In FedPoP, the proof object establishes participation in producing a model, not a numerical contribution score or proof of model utility (İşler et al., 11 Nov 2025). In PoFT, “proof” means an auditable record that a model version was legitimately trained, registered, transferred, and reused across blockchain networks, rather than a SNARK- or STARK-style proof of honest training computation (Chakraborty et al., 2022).

A second boundary is between confidentiality and verifiability. Some systems primarily solve the confidentiality layer of federated coordination, as in Flamingo and Armadillo; others attach proof-carrying validation to client updates, as in zPROBE and zkDFL; others certify participation or provenance, as in FedPoP and PoFT; and still others verify process occurrence or boundary admission without disclosing internal records, as in FSTP and FCaC (Ma et al., 14 Nov 2025, Ahmadi et al., 2023, C. et al., 30 Jun 2026, Fenoglio et al., 18 Mar 2026). A plausible implication is that a full federated proof server is not a single primitive but a composite service in which proof semantics must be specified explicitly: privacy proof, aggregation proof, participation proof, provenance proof, or admission proof.

Common misconceptions follow directly from this heterogeneity. A proof of participation is not a proof of beneficial contribution; a secure-aggregation transcript is not automatically a proof of correct model update; a provenance registry is not a proof of honest local training; and a transport-layer proof without exposure is not a proof of numerical aggregation correctness. The concept is therefore best treated as a family resemblance across systems rather than a settled protocol class (İşler et al., 11 Nov 2025, Chakraborty et al., 2022, C. et al., 30 Jun 2026).

2. Recurring architectural patterns

Across the surveyed systems, several stable design patterns recur.

Architectural role	Representative mechanism	Representative papers
Confidentiality-preserving aggregation	single server, reusable setup, threshold decryption, dropout handling	Flamingo, Armadillo
Proof-carrying update admission	zero-knowledge correctness/range proofs before aggregation	zPROBE, zkDFL
Distributed-trust verifiable aggregation	multi-server encrypted aggregation with rule-specific verification	PRoVeFL
Participation and provenance attestation	threshold signatures, OPRF, model-bound assets, CoSi/BLS	FedPoP, PoFT
Stateful or cross-boundary proof service	attested evidence chain; KYO→ECT→PoP; typed EventHash plus Blocklace	(Takagi et al., 10 Sep 2025), FCaC, FSTP
Proof orchestration	cross-backend citation, cross-axis convergence, outsourced proving	(Falda, 1 Jun 2026, Rahimi et al., 2021)

Single-server federated learning remains the dominant systems model. Flamingo keeps the standard federated pattern of a single coordinating server, but amortizes secure aggregation across rounds using a one-time setup followed by report, cross-check, and reconstruction in each round (Ma et al., 2023). Armadillo likewise keeps a single powerful server and many weak clients, but combines a two-layer secure aggregation protocol with proof-based input validation and a helper agreement protocol so that each secure aggregation completes in 3 rounds (Ma et al., 14 Nov 2025). zkDFL adopts a hybrid model in which one centralized server performs FedAvg and proves correctness off-chain, while blockchain smart contracts verify the proof and hash-based inclusion checks (Ahmadi et al., 2023). zPROBE splits each training round into an initial secure aggregation over random clusters, a proof-based robustness check, and a final secure aggregation over accepted clients (Ghodsi et al., 2022).

A second pattern is separation between issuance and verification. FedPoP has Setup, Generate, and Prove phases: proof material is minted during federated training, but later verified in an interactive challenge-response by a service provider (İşler et al., 11 Nov 2025). FCaC explicitly relocates admission logic into local verification of previously issued cryptographic artifacts rather than runtime calls to an online policy server (Fenoglio et al., 18 Mar 2026). FSTP makes the synchronization agent the exclusive egress boundary and restricts outbound traffic to a closed set of typed cryptographic artifacts (C. et al., 30 Jun 2026).

A third pattern is federation by orchestration rather than monolithic proof kernels. “Federated Formal Verification” treats a verification campaign as a polyglot proof system routed across TLA+, TLAPS, Coq, Lean 4, Why3, Apalache, Z3, PRISM, CBMC, Lincheck, and related tools; the build system, not a single proof assistant, becomes the operational meta-layer (Falda, 1 Jun 2026). “Multi-Party Proof Generation in QAP-based zk-SNARKs” similarly distributes heavy proving work across $N$ external servers while preserving threshold privacy against up to $T$ colluding servers (Rahimi et al., 2021).

3. Proof objects and verification semantics

The proof object differs sharply across designs. In zPROBE, the server computes public coordinate-wise reference point $\bm{\lambda}$ and threshold $\bm{\theta}$, then each client proves in zero knowledge that its hidden update satisfies

$|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$

That proof is coupled to an earlier correctness proof for masked update formation, so the hidden update reused in the robustness proof is the same update used in secure aggregation (Ghodsi et al., 2022). zPROBE also uses probabilistic coordinate sampling: if $\mathcal{S}_m$ is the compromised portion of the model and $q$ coordinates are checked, the detection probability is

$$p=1-\binom{l\cdot(1-\mathcal{S}_m)}{q}\Big/\binom{l}{q}.$$

This yields a proof object about robustness and masking consistency, not about local training honesty.

In zkDFL, the proof object is a Groth16 proof over an off-chain FedAvg computation. The server computes

$$N\gets \sum_{k\in M}^{}n_{k}, \qquad w_{t+1}\gets \sum_{k\in M}^{}\frac{n_{k}}{N}w^{k}_{t+1},$$

hashes each client model with MiMC7,

$$H^{k}\gets MiMC7(w_{t+1}^{k}), \qquad w_{hash}\gets MiMC7(w_{t+1}),$$

and proves that the same hidden inputs were both hashed and averaged (Ahmadi et al., 2023). The resulting proof is checked by a proof-verifier smart contract, while a separate contract checks a sum of client-submitted hashes. This gives a proof of aggregation correctness relative to the agreed FedAvg relation, but the server still sees raw client updates.

In FedPoP, the proof object is not an aggregation proof at all. After secure aggregation, each active client creates a threshold-signature share $T$0 on model $T$1, the FL server aggregates them into $T$2, generates a fresh PRF key $T$3, computes

$T$4

and later a claimant proves participation by responding to a verifier challenge $T$5 with $T$6 and presenting $T$7 (İşler et al., 11 Nov 2025). Verification checks both the threshold signature and the OPRF relation. The semantics are: the claimant knows the group witness associated with a valid threshold signature on that model. The proof is therefore model-bound evidence of participation.

In the TEE-based maliciously secure DP-FTRL system, the proof object is an attested state-transition certificate. A genuine enclave attests that it loaded a specific prior state, validated a specific process, obtained quorum approval from selected auditors, and is authorized to extend the evidence chain. The associated privacy guarantee is expressed as

$T$8

with $T$9 capturing the failure probability of probabilistic linearizability under randomized client auditing (Takagi et al., 10 Sep 2025). This is a proof about state continuity and correct stateful execution, not about numerical aggregation alone.

In FCaC, the proof object is a proof-carrying capability. Governance contracts compile into capability tuples

$\bm{\lambda}$0

where $\bm{\lambda}$1 is a protected resource, $\bm{\lambda}$2 an admissible action, $\bm{\lambda}$3 scope qualifiers, and $\bm{\lambda}$4 signed caveats or restrictions; the runtime trust chain is

$\bm{\lambda}$5

Admission is allowed only if issuer trust, token validity, proof of possession, and tuple coverage all verify locally (Fenoglio et al., 18 Mar 2026). In FSTP, the dominant proof object is the signed EventHash envelope

$\bm{\lambda}$6

which proves that a process occurred and later supports selective audit without exposing the original internal record (C. et al., 30 Jun 2026).

4. Confidentiality, robustness, and the aggregation substrate

For federated learning, the confidentiality layer often determines what the proof server can meaningfully verify. Flamingo addresses the multi-round single-server secure aggregation problem with a one-time setup and then $\bm{\lambda}$7 collection rounds. Decryptors run distributed key generation for a threshold ElGamal public key $\bm{\lambda}$8, clients derive long-lived pairwise secrets and fresh per-round seeds via

$\bm{\lambda}$9

and each round executes report, cross-check, and reconstruction (Ma et al., 2023). Communication is star-shaped, client-to-client messages are relayed by the server but end-to-end encrypted, and the main threshold condition in the multi-round protocol is

$\bm{\theta}$0

Flamingo’s formal security theorem states that, assuming a PKI, a trusted randomness source, PRG/PRF, authenticated encryption, asymmetric encryption, and signatures, the $\bm{\theta}$1-round protocol securely realizes its ideal functionality except with probability at most

$\bm{\theta}$2

Operationally, Flamingo reduces interaction complexity from repeated single-round setup to a one-time setup plus 3 round trips per aggregation round, achieves about $\bm{\theta}$3 lower end-to-end runtime than BBGLR on a 10-round, 1K-client summation workload, and in end-to-end training is about $\bm{\theta}$4 faster than BBGLR on EMNIST and $\bm{\theta}$5 faster on CIFAR-100 while preserving accuracy relative to a non-private baseline (Ma et al., 2023).

Armadillo extends this substrate with disruption resistance and input validation. Its outer layer encrypts each client vector as

$\bm{\theta}$6

and the inner layer secret-shares the short key $\bm{\theta}$7 to helpers. The server sums ciphertexts, helpers agree on the accepted client set through verifiable complaints, and the server reconstructs the aggregate decryption key from helper sums (Ma et al., 14 Nov 2025). The protocol validates

$\bm{\theta}$8

and proves algebraic consistency between masked inputs, secret shares, and commitments. The system tolerates

$\bm{\theta}$9

completes in 3 rounds, uses batch verification for inner-product proofs, and reports 3–4x fewer rounds and up to 7x runtime reduction relative to ACORN-robust in the paper’s evaluation (Ma et al., 14 Nov 2025).

PRoVeFL pushes the same problem into a distributed-trust setting. Clients split encrypted model updates across multiple servers under multi-key FHE, servers homomorphically compute robust-statistics intermediates, decrypt only masked values such as $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$0 or $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$1, and verify rule-specific arithmetic using commitment checks such as $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$2 or $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$3 before releasing the final aggregate (Kasyap et al., 7 Jul 2026). It supports Krum, Trimmed Mean, FLTrust, MESAS, and related rules, with the explicit trust assumption that at least one server is honest. For 100k parameters and 200 clients, the paper reports about 2.91 s for $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$4-norm style aggregation, 18.35 s for FLTrust, 404.5 s for Trimmed Mean, and 932.1 s for Krum with 2 servers, with lower runtimes as the number of servers increases (Kasyap et al., 7 Jul 2026). This illustrates a recurring trade-off: stronger verifiability of robust statistics often requires either multiple non-colluding servers or heavy cryptographic structure.

5. Participation, provenance, and inter-organizational proof serving

A federated proof server frequently serves claims that are orthogonal to aggregation correctness. FedPoP is a proof-of-participation layer designed to sit atop securely aggregated federated learning. Its Generate phase produces a threshold signature $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$5 on the model and a group witness $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$6, with public verification token

$|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$7

and the later Prove phase lets a client answer a verifier’s challenge $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$8 with $|\bm{u_i} - \bm{\lambda}| < \bm{\theta}.$9 while presenting $\mathcal{S}_m$0 (İşler et al., 11 Nov 2025). In the reported prototype, FedPoP adds 0.97 seconds of per-round overhead atop secure aggregation and verifies a participation proof in 0.0612 seconds. The paper is explicit that this proves participation in generating a model version, not contribution quality, numerical utility share, or legal ownership allocation (İşler et al., 11 Nov 2025).

PoFT addresses provenance across organizationally separate blockchain networks. It replaces structural model embedding with parameter-based learning assets augmented by metadata, validation dataset pointers, and signatures; cross-network transfer uses a relay plus local blockchain consensus and CoSi/BLS collective signatures, and the receiving side independently verifies both provenance and reproducibility claims (Chakraborty et al., 2022). The paper’s pilot comparison reports structure-based asset sizes of 98.24 MB and 50.01 MB versus 19.9 MB and 4.5 MB for parameter embedding, with insert times of 229.291 s and 102.452 s structurally versus 48.823 s and 9.693 s with parameter embedding. For larger models, ResNet-scale assets require 232.1 MB and 63.079 s for on-chain entry, with retrieval, CoSi, and verification times of 22.051 s, 110.460 s, and 154.705 s respectively (Chakraborty et al., 2022). The resulting proof object is a transferable, independently verifiable learning asset, not a ZK proof of honest training.

FSTP generalizes the same idea to process proofs without disclosure. The synchronization agent is the exclusive federation egress and may emit only a formally closed set of message types, including IdentityEvent, EventHash, VerifiableCredential, and FederationControl; the paper states the confinement property as

$\mathcal{S}_m$1

meaning raw internal data cannot appear in federation messages (C. et al., 30 Jun 2026). Contextual identities are derived per federation relationship,

$\mathcal{S}_m$2

to prevent cross-context linkage, and Blocklace synchronization cost is proportional to the symmetric difference $\mathcal{S}_m$3, with measured sync_delta times such as 5.8 µs for $\mathcal{S}_m$4 and 221.3 µs for $\mathcal{S}_m$5 at $\mathcal{S}_m$6 in the reference benchmarks (C. et al., 30 Jun 2026). Here the federated proof server is essentially a typed transport boundary that exports only cryptographic evidence, never the underlying record.

FedChain applies related proof-serving ideas to blockchain consensus. Mining pools perform federated learning as useful work, commit the resulting model $\mathcal{S}_m$7, and use zkCNN with

$\mathcal{S}_m$8

$\mathcal{S}_m$9

so that validators can check model-performance claims without learning model parameters (Wang, 2023). This is a proof of correct inference under a committed model, repeated to support an accuracy claim, rather than a proof of the full training trajectory.

6. Server-side proving, orchestration, and state verification

Not all federated proof-server roles are cryptographic attestation of aggregation. FedSSO shows a different server-centric pattern: the server reconstructs a gradient-like signal from standard client updates,

$q$0

builds a quasi-Newton approximation $q$1, and updates the global model via

$q$2

while clients remain first-order workers that send only $q$3 (Cao et al., 2022). The paper proves existence of the Lighthouse point, bounded positive-definite curvature approximation, $q$4 convergence in the strongly convex case, and convergence to stationary points in the non-convex case. A plausible implication is that a federated proof server can also be the locus where the “proof-carrying optimization logic” resides, even when the proof is analytical rather than zero-knowledge.

The same server-centric division appears in distributed proving. “Multi-Party Proof Generation in QAP-based zk-SNARKs” delegates the FFT-heavy quotient-polynomial stage of Groth16-style proving to $q$5 external servers and guarantees that up to $q$6 colluding servers learn no information about the secret data, while each server’s computation is less than

$q$7

of the original prover’s primary computation (Rahimi et al., 2021). This is directly relevant to any proof server expected to scale SNARK proving across semi-trusted infrastructure.

“Federated Formal Verification” moves beyond machine learning entirely and treats a verification campaign as a federated proof service over heterogeneous backends. Its two main mechanisms are cross-backend citation and cross-axis convergence; its validation campaign on the Mercury platform reduced a 26-axiom Raft census to zero in 17 active hours of one session, with 18 cited apex axioms and mean convergence of about 4.6 axes per cited axiom (Falda, 1 Jun 2026). The build system becomes the operational proof server: it routes obligations, rechecks cited artifacts, enforces per-obligation agreement gates, and fails the CI pipeline on stale citations or disagreement. This is the strongest current example of a federated proof server in the narrow sense of proof orchestration rather than federated learning.

The TEE-based DP-FTRL system provides a third model: a proof server as a state-transition certifier. A small ephemeral planner enclave validates the evidence chain, chooses auditors, gathers threshold approval, and then authorizes the next transition; clients store evidence_chain_id and signed_digests and refuse to sign conflicting branches (Takagi et al., 10 Sep 2025). The paper reports additional communication sizes of 5038 bytes for audit evidence, 5194 bytes for secure-aggregation evidence, 64 bytes for an audit response, and 144 bytes for secure-aggregation response overhead. This is a proof server for state continuity and auditable liveness, not merely for aggregation.

7. Limitations, trade-offs, and open questions

No surveyed system simultaneously solves confidentiality, robustness, provenance, participation, state continuity, and public verifiability in one uniform construction. Flamingo is explicit that verifiability and input correctness are out of scope, even though it solves the confidentiality and dropout-resilience layer extremely well (Ma et al., 2023). zPROBE verifies client-side robustness predicates, but assumes a semi-honest server and reveals cluster means, while its proof checks are probabilistic rather than exhaustive (Ghodsi et al., 2022). FedPoP gives anonymous, unlinkable proof of participation, but not proof of contribution magnitude, revocation, multi-round accumulation, or malicious-verifier resistance (İşler et al., 11 Nov 2025). PRoVeFL requires at least one honest server and verifies rule-specific intermediate arithmetic rather than providing a single succinct public proof of the entire federated round (Kasyap et al., 7 Jul 2026). zkDFL verifies off-chain FedAvg, but the server still sees raw client updates and inclusion is enforced only through a sum-of-hashes check rather than a stronger commitment structure (Ahmadi et al., 2023).

Governance- and transport-oriented systems expose a different boundary. FCaC compiles only constitutional governance into cryptographic artifacts; procedural governance remains local, stateful, and non-portable by design (Fenoglio et al., 18 Mar 2026). FSTP structurally prevents protocol-level disclosure of raw internal data, but it does not protect against malicious administrators with authorized local access (C. et al., 30 Jun 2026). The TEE-based DP-FTRL design achieves only probabilistic linearizability under corruption and retains delicate recovery and side-channel questions (Takagi et al., 10 Sep 2025). PoFT improves provenance and cross-network verification, but its proof object remains reproducibility- and endorsement-based rather than a proof of honest training computation (Chakraborty et al., 2022).

This suggests that the federated proof server remains a composite systems problem. A plausible synthesis is a layered architecture in which a confidentiality substrate such as Flamingo or Armadillo is combined with proof-carrying client validation as in zPROBE or zkDFL, participation and provenance artifacts as in FedPoP or PoFT, and local boundary verification as in FCaC or FSTP, with stateful components audited by evidence chains or TEEs where necessary. The open research agenda is therefore not only stronger cryptography, but also clearer proof semantics: exactly what proposition the server is certifying, under what trust assumptions, against which adversary, and with what portability across organizational boundaries.