1. Modern privacy technologies and advanced cryptography rely on a huge number of fragmented computational building blocks
Modern privacy technologies, including FHE, ZK, MPC, PIR, PSI and PQC, and the applications built on top of them depend on many layers of fragmented state-of-the-art algorithms, cryptographic operations and mathematical primitives. The applications already span areas such as private AI, confidential payments, secure identity, encrypted search, private analytics and secure data access and collaboration.
A single system may rely on dozens or hundreds of computational components across multiple levels of abstraction. At the lower levels, these components include mathematical operations such as polynomial multiplication, NTTs, finite-field arithmetic, MSMs, BigInt arithmetic and matrix operations. Higher in the stack, they include cryptographic operations such as bootstrapping, key switching, commitments, proof generation, secret sharing and private query processing, which are then combined into complete computational workflows.
For almost every such component, there is no single implementation that is best in all settings. The same component may have many competing implementations based on different algorithms, representations, hardware targets and optimization strategies. The landscape is also moving quickly: new algorithms, implementation techniques, hardware-specific optimizations and research ideas appear continuously, making the set of viable options a constantly shifting target.
Which implementation performs best depends on the exact parameters, workload, hardware, memory constraints, security requirements and performance objective. Across a system, using different implementations for its underlying computational components can materially change latency, throughput, memory use, hardware requirements and infrastructure cost. At the system level, these differences can reshape the economics of an application and in some cases make use cases practical that would otherwise remain only theoretical.
This creates a large, multidimensional landscape of possible implementations across the computational stack. And that landscape is highly fragmented.
Relevant implementations and optimization approaches appear in many different forms, from algorithms described in research papers to code in libraries, repositories, protocol codebases, hardware-specific projects and internal engineering systems.
As a result, the implementation space for a single system is not only large, but distributed across many disconnected sources, each covering different algorithms, parameter regimes, hardware targets and assumptions.
Understanding that space means discovering what exists, determining what is actually applicable to a given computation and workload, and establishing how different approaches compare under the same conditions. This landscape is already large, fragmented and constantly evolving. Until recently, however, the cost of producing new high-quality implementations acted as a natural limit on how fast it could expand. Serious implementations required substantial mathematical expertise, systems engineering and optimization work, making highly specialized alternatives expensive to create.
AI is removing that limit.
2. AI changes the economics of this entire ecosystem
AI systems can increasingly propose new algorithms, turn research ideas into working code, port implementations to new hardware and generate highly specialized variants for specific parameters, workloads and performance goals.
As a result, the number of viable implementations for the same computation can grow from a handful to dozens or hundreds. Many of these new implementations will outperform widely used defaults in specific parts of the design space. The best option may no longer be the one available in the most established library, but a newer implementation optimized for a particular workload, parameter set or hardware target. Across a system composed of hundreds of components, these differences can compound into major changes in performance, infrastructure cost and overall unit economics — and materially affect competitive position. This also makes implementation decisions increasingly continuous rather than one-time. A system cannot simply adopt a set of components and assume they will remain the best or even remain safe.
On one side, competitors may continuously discover and adopt better implementations, creating material advantages in performance and cost. On the other, cryptanalysis continuously changes what can be considered secure. New attacks, weaknesses and implementation-level vulnerabilities can invalidate assumptions about algorithms, libraries and components that were previously considered safe. The bottleneck therefore shifts from producing implementations to continuously discovering, validating, comparing and integrating the components that a system depends on.
3. FHERMA is the infrastructure layer for this new computational landscape
FHERMA is building the knowledge, evaluation and execution layer that makes this expanding computational landscape discoverable, comparable, composable and usable.
It turns fragmented algorithms, implementations, benchmarks and hardware-specific optimizations into an active computational infrastructure: one where new approaches can be evaluated against the current frontier, combined into larger systems and executed across heterogeneous hardware environments, including CPUs, GPUs, specialized accelerators and custom compute infrastructure.
FHERMA's execution model, memory model and FHERMA Kernel Language provide the deep technical foundation that makes these otherwise heterogeneous components composable across implementations, workloads and hardware environments.
This gives researchers, engineers and companies a shared layer not just to see what exists, but to continuously improve the underlying computation their systems depend on.
As new algorithms and implementations appear, FHERMA provides a common environment for analyzing how they behave across different parameter regimes, workloads, hardware architectures, security assumptions and system constraints — and for comparing them directly against the best existing alternatives. Rather than reducing evaluation to a single benchmark result, it makes it possible to understand where a new approach is genuinely better, where it is not, and under which conditions those differences matter. FHERMA then provides a standardized path for integrating useful implementations into the broader ecosystem, so improvements can move from papers, repositories or internal experiments into real systems much more quickly.
The result is infrastructure for continuously discovering, evaluating, composing and executing the best available cryptographic computation.
4. NVIDIA Collaboration
Fair Math and NVIDIA are working together to improve the performance of advanced cryptographic computation by developing reusable, GPU-accelerated computational building blocks through open challenges on FHERMA.
The collaboration starts with Fully Homomorphic Encryption, where system performance depends on a number of expensive low-level computations shared across different libraries and implementations.
Our recent paper, Efficient Large-Integer Arithmetic for FHE, is one example of this work. It examines the large-integer arithmetic used across modern RLWE-based FHE libraries and the design choices that determine performance at this layer.
Building on this work, we are launching a series of open challenges on FHERMA focused on performance-critical computations in advanced cryptography.
The first challenge targets high-degree polynomial multiplication over wide integer coefficients. Additional challenge tracks will follow, including CKKS key switching and other computational bottlenecks across privacy-preserving and advanced cryptographic systems.
5. FHERMA is to cryptographic computation what Hugging Face became for AI models
Hugging Face helped transform AI by giving models a common structure: a place where they could be discovered, shared, evaluated, integrated and deployed instead of remaining fragmented across papers, repositories and individual frameworks.
FHERMA brings the same kind of common infrastructure to computational implementations.
Today, implementations of the same underlying computation are distributed across mathematical and cryptographic libraries, research code, hardware-specific projects, papers, repositories and internal systems. They are difficult to discover as a coherent set, difficult to compare under equivalent conditions and difficult to reuse outside the environment in which they were originally built.
FHERMA organizes this landscape around the computation itself.
A computation can have a common specification describing what must be computed, the valid parameter space, required assumptions and correctness or security conditions. Around that specification, many independent implementations can coexist.
Those implementations can then be analyzed against one another across different algorithms, parameters, workloads, hardware architectures, objectives, constraints and security assumptions.
This makes it possible not only to discover that an implementation exists, but to understand where it sits relative to everything that already exists: where it performs better, where it performs worse, which trade-offs it makes and under which conditions it should be used.
And FHERMA goes beyond discovery and evaluation.
Implementations can be packaged behind common interfaces, executed on different hardware, composed into larger computational pipelines and integrated into real systems without every user having to reproduce the original implementation environment.
In this sense, FHERMA plays a role similar to Hugging Face — but for a broader and more heterogeneous computational ecosystem.
It connects specification, implementation, validation, comparative analysis, hardware evaluation, composition and execution in a single shared layer.
One computation. Many implementations. Many environments. A common way to understand, compare and use them.
6. Long-term vision: from libraries to adaptive computational systems
FHERMA starts with privacy technologies and advanced cryptography because this is one of the first areas where the shift is already becoming acute.
These systems combine deep computational stacks, highly specialized algorithms, complex parameter spaces, heterogeneous hardware and rapidly evolving security requirements. Small changes in the underlying computation can have system-level consequences for performance, cost and feasibility.
But we do not believe this dynamic is unique to cryptography.
The same pattern exists anywhere computation is sufficiently performance-critical: AI infrastructure, scientific computing, databases, numerical computing, simulation and other systems where multiple algorithms, implementations and hardware targets can solve the same underlying problem with very different results.
Today, software is still largely organized around libraries: teams select a relatively small number of general-purpose software stacks and inherit the implementations bundled inside them.
We believe that model will become increasingly insufficient.
As AI makes it cheaper to generate, specialize and optimize implementations, computational systems will increasingly be built from much more heterogeneous sets of components — drawn from different sources, optimized for different parts of the workload and executed on different types of hardware.
Instead of asking which library should provide a computation, systems will increasingly ask which implementation is best for this exact operation, parameter set, workload, hardware environment and objective.
FHERMA starts at the privacy-preserving compute frontier, but the long-term opportunity is broader: to become the infrastructure through which performance-critical computation is continuously discovered, evaluated, composed and executed.
From static software stacks to continuously optimized computational systems.