Introduction

A large, fragmented, fast-moving landscape

Modern privacy technologies — FHE, ZK, MPC, PIR, PSI and PQC — and the applications built on them depend on many layers of algorithms, cryptographic operations and mathematical primitives. Those applications already span private AI, confidential payments, secure identity, encrypted search, private analytics and secure data collaboration.

A single system may rely on dozens or hundreds of computational components across several levels of abstraction:

• Mathematical primitives — polynomial multiplication, NTTs, finite-field arithmetic, MSMs, BigInt arithmetic, matrix operations.
• Cryptographic operations — bootstrapping, key switching, commitments, proof generation, secret sharing, private query processing.
• Workflows — these operations combined into complete computations.

For almost every component, there is no single implementation that is best in all settings. The same component has many competing implementations built on different algorithms, representations, hardware targets and optimization strategies, and the set of viable options shifts continuously as new work appears.

Which implementation performs best depends on the exact parameters, workload, hardware, memory constraints, security requirements and performance objective. Across a system, those choices change latency, throughput, memory use, hardware requirements and infrastructure cost — enough, at the system level, to reshape the economics of an application and make some use cases practical that would otherwise stay theoretical.

The implementations are scattered: research papers, cryptographic and mathematical libraries, protocol codebases, hardware-specific projects, public repositories and internal engineering systems. The space for a single system is therefore not only large, but distributed across disconnected sources, each covering different algorithms, parameter regimes, hardware targets and assumptions. Understanding it means discovering what exists, determining what is actually applicable to a given computation and workload, and establishing how approaches compare under the same conditions.

AI changes the economics

Until recently, the cost of producing high-quality implementations limited how fast this landscape could grow: serious implementations required substantial mathematical expertise, systems engineering and optimization work.

AI removes that limit. AI systems can increasingly propose algorithms, turn research ideas into working code, port implementations to new hardware and generate specialized variants for specific parameters, workloads and performance goals. The number of viable implementations for one computation can grow from a handful to dozens or hundreds, and the best option may no longer be the one bundled in the most established library.

This makes implementation decisions continuous rather than one-time:

• Performance and cost move. Competitors can continuously discover and adopt better implementations; across a system of hundreds of components, the differences compound.
• Security moves. Cryptanalysis continuously changes what counts as secure; new attacks and implementation-level weaknesses can invalidate assumptions about algorithms and components previously considered safe.

The bottleneck shifts from producing implementations to continuously discovering, validating, comparing and integrating the ones a system depends on.

The knowledge, evaluation and execution layer

FHERMA is the layer that makes this expanding landscape discoverable, comparable, composable and usable. It organizes the ecosystem around the computation itself rather than the library or repository an implementation happens to live in.

A computation is described once, by a specification: what must be computed, the valid parameter space, the required assumptions and the correctness and security conditions. Around that specification, many independent implementations coexist, and each can be analysed against the others across algorithms, parameters, workloads, hardware architectures, objectives, constraints and security assumptions.

The result is not a single benchmark number but a map: where an implementation is genuinely better, where it is worse, which trade-offs it makes and under which conditions it should be used. Implementations can then be packaged behind common interfaces, executed across heterogeneous hardware — CPUs, GPUs, accelerators and custom infrastructure — composed into larger pipelines and integrated into real systems without every user reproducing the original environment.

This is, for cryptographic computation, the role Hugging Face played for AI models: giving fragmented work a common structure so it can be discovered, compared, reused and deployed instead of staying scattered across papers, repositories and individual frameworks.

FHERMA starts at the privacy-preserving compute frontier because the shift is most acute there — deep computational stacks, specialized algorithms, large parameter spaces, heterogeneous hardware and fast-moving security requirements. The same pattern holds anywhere computation is performance-critical, and the longer-term aim is to be the infrastructure through which such computation is continuously discovered, evaluated, composed and executed.

The model

Everything on the platform hangs off one chain:

A kernel names a computational problem — polynomial multiplication, the sign of an encrypted value, private set intersection — independently of language, library, scheme, hardware or technique. It can exist before any executable implementation of it does.

A specification narrows the kernel into a precisely defined variant that implementations can agree on: the inputs and outputs, their types, the admissible parameter ranges, the conventions, and the correctness rule. It carries the testing bundle submissions are evaluated with.

A point is one exact instance of a specification — a fixed set of parameter values. It is the coordinate at which implementations are measured against one another.

An implementation is one way of solving the kernel: this specification, this mechanism, this code, this coverage of the parameter space. A kernel routinely has several, differing in language, library, hardware and strategy at once.

A measurement is a result that belongs to the code, the machine, the environment and the point it was taken at. Two implementations are comparable when all four agree — the one rule every table on the platform follows.

What the documentation covers

The platform — the object model: the computational stack, kernels, specifications, points, implementations, the performance map, challenges and governance.

FHERMA Kernel Language — the notation signatures are written in. One signature mechanically determines the types a testing bundle is written in, the skeleton an implementation starts from, the size of every buffer and the layout of every file. Adding a kernel touches no language; adding a language touches no kernel.

Benchmarking — how judging works: points, cases, samples, the three verdicts, the bundle's three functions, and the bar that says when a point counts as passed.

The execution layer — how a submission becomes a number: jobs, runners, images, containers, the timing window, and the encrypted-solution contract.

The fherma CLI — the toolchain: scaffolding a specification, building a testing bundle, and submitting an implementation from a repository or an image.

What holds it together

One signature. Everything downstream of a specification is derived from its signature mechanically — nothing is described twice, so nothing can drift.

One source of randomness. Test data is derived from (point, seed) by a generator that must be bit-for-bit deterministic, so data is never shipped — the recipe is — and any result can be reproduced by anybody, at any time, without asking the machine that produced it.

One judge per specification. The verifier travels with the specification's bundle, its code is public, and every implementation is judged by the same code under the same declared bar.

Who does what