The SAFE (Simple Agreement for Future Equity) was introduced by Y Combinator in 2013 to simplify early-stage funding. Its premise is straightforward: an investor provides capital today in exchange for the right to receive shares in the future when the company raises its next equity round. SAFEs became the default instrument for pre-seed and seed rounds due to their simplicity and low legal overhead.

In Web3, the situation is unique: SAFEs are often used not just at the earliest stages but also for large, multi-million-dollar rounds, sometimes even in later stages where complexity and risks are much higher. But behind this simplicity lie significant gaps that can cost investors dearly. Below, we share three real cases that demonstrate why a standard SAFE alone is not enough, and what you can do to close these gaps.

Case 1: Forced Conversion via “Fake” Equity Financing

A company raises $3M in a seed round through standard SAFEs with a valuation cap. Later, the market cools, and the startup struggles to raise the next round at a desirable valuation. Normally, this isn’t catastrophic: SAFEs protect investors by converting at the lower price.

But here’s the loophole: the founder runs a $100K crowdfunding campaign on an equity platform, selling shares at a valuation above the SAFE cap. Technically, this qualifies as an “Equity Financing Event” under the SAFE, so the company converts all SAFEs at the highest allowed valuation, not the actual market price. Investors expecting downside protection suddenly find themselves vulnerable.

✅ Solution:

Define Qualified Equity Financing in the SAFE or side letter. For example:

“Qualified Equity Financing” means an equity financing in which the Company raises at least [$X million] of new money at least in part from new investors on an arm’s length basis in a single transaction or series of related transactions. No other equity issuance shall trigger automatic conversion.”

This prevents small or strategic rounds from being used to manipulate conversion terms.

Case 2: Radical Pivot After Raising Capital

A startup raises Seed round through SAFEs. Two months later, the founders realize the product is failing and decide to pivot to an entirely different industry — one completely outside the mandate of the original investors.

95% of the money is still in the bank, but investors can’t stop the pivot or recover their capital. A standard SAFE gives no governance rights, no consent rights, and no covenants restricting strategic direction. Investors end up funding a project they would never have backed.

✅ Solution:

Include a Company Purpose Definition and change-of-business restriction in a side letter:

“The Company shall conduct its business in accordance with the business plan and field of activity as set forth in [Annex X]. Any material change to the Company’s purpose or principal line of business shall require the prior written consent of holders of SAFEs representing at least [X%] of the Purchase Amount.”

This ensures investors have a say in major strategic shifts.

Case 3: IP Transfer to a New Company

The founder is heavily diluted after the SAFE round and cannot attract new investors on reasonable terms. A new investor offers to fund a new entity, on the condition that the IP is transferred there.

What stops the founder from moving the core IP out of the existing company?

Nothing.

Standard SAFEs have no IP protection provisions. There’s no restriction on asset transfers, and SAFE holders lack veto rights. The IP moves, the original entity becomes an empty shell, and SAFE investors are left with worthless paper.

✅ Solution:

Add an IP & Materials Assets Transfer Restriction in the SAFE or side letter:

“The Company shall not sell, assign, license (other than in the ordinary course of business), pledge, or otherwise transfer all or substantially all of its intellectual property without the prior written consent of holders of SAFEs representing at least [X%] of the aggregate Purchase Amount of all outstanding SAFEs.”

This creates a binding covenant preventing asset stripping.

Conclusion

The SAFE is a brilliant tool for one thing: giving founders fast access to capital with minimal friction. But the standard SAFE agreement does not protect investors from strategic risk, governance issues, or bad-faith actions.

If you are investing significant amounts or backing Web3 projects at later stages, a standard SAFE is not enough.

Use side letters to add:

• Qualified financing definitions

• Business purpose restrictions

• IP & Material Assets transfer covenants

Alternatively, for larger checks, consider transitioning to a full investment agreement with protective provisions.

Today, FHE is rarely discussed without an accompanying lament of its downsides: painfully slow and unwieldy. That being said, we wish to share some interesting developments we’ve come across to mitigate these pains and broaden adoption, all the while introducing some other cool facets of this family of encryption schemes.

We broadly categorize the problem space into four major areas of development: developer experience, compilers, hardware, cryptography. We’ll describe the four areas but spend most time looking at developer experience and compilers as they’re of more interest to us. Before we start, we’ll loosely introduce the cryptography that underpins FHE as a basis for a few of the upcoming points.

Learning-With-Errors (LWE)

Encryption schemes rely on computationally hard problems, problems that computers can’t easily solve at a big enough scale. For a familiar example, RSA security (the asymmetric encryption scheme we use to protect ourselves online) relies on the assumption that we don’t have efficient ways to factor big numbers. The bigger these numbers get, the more secure the messages encoded through them.

There are multiple FHE schemes but most of the modern ones are based on LWE. LWE is a problem that banks on the complexity of solving systems of linear equations that are perturbed by small errors (often called noise). Unless you already know the solution, it’s hard to isolate the noise and recover the content. Under the hood, it’s a rephrasing of Lattice problems which— in case you were wondering— are secure even with quantum computers. We recommend this video for a short intro.

So, for the RSA scheme we owe our security to the size of the number we have to factor. What are the parameters for LWE? Here, we not only have to worry about the dimension of our system of equations but we also need to define how precise we want to be with these small errors and how many possible values we want to be able to encrypt per equation in our system. Put together, these parameters generally present a security, efficiency, and correctness tradeoff.

Now, let’s dive back into the areas of R&D:

Developer Experience (DevX):

FHE has some adoption barriers with the DevX as they introduce a new set of development limitations. For example, developers have to be considerate using branching structures with encrypted information: to avoid any information leakage, both branches of if-else statements have to be evaluated on different copies of the state and then reconciled homomorphically at the end. There are similar concerns with loops: when does the program stop iterating the loop in order to avoid leaking information on the encrypted condition? Existing approaches include running the loop for a fixed and sufficient number of iterations, storing all the different states, and merging them homomorphically at the end. This can lead to massive increases in computation requirements.

Naive solutions crafted without a deep understanding of these constraints are generally orders of magnitude less efficient than those crafted by experts. On this front, we see DevX improvements coming from the development of libraries with high-level, optimized functions for most algorithms and computations. This is analogous to Python libraries like numpy: this library provides out-of-the-box, optimized, high-level mathematical functions and no one needs to care about their compilation in C and the tricks for efficiency like contiguous memory allocation or homogeneous data types; they work and they make code go zoom.

Most FHE libraries have bounty programs or partnerships with universities to crowdsource the development of their offerings but these are small and fragmented communities.

Compiler Improvements:

Exciting developments to look forward to! One notable area of discussion is the potential of hybrid compilations. In this approach, a single program could be compiled into different cryptographic schemes, depending on which scheme offers optimal performance for a given operation. For example, TFHE is well suited to work on exact computations and lots of logic but CKKS is a better choice to handle large dataset and approximate arithmetic (ie. data science tasks).

This type of compilation hinges on the development of two things: efficient transciphering and appropriate Intermediate Representations (IR).

Transciphering is translating from one scheme to another without decrypting the data in the process. Because these schemes each have their set of parameters, and noise structures, it’s complicated to map each characteristic over correctly, and every mapping has to be done individually. Transciphering also introduces a lot of complexity and overhead, particularly with big datasets. Finally, the keys used in the process have to be managed securely. It’s early days on this topic but you can start on existing research with Hermes, Pegasus, and Chimera.

Secondly, IRs are a stack of lower-level languages that can progressively specialize or generalize to optimize the different parts of the codebase into the optimal schemes. Coupled with transciphering, this gives compilers the potential to orchestrate the transitions, optimize at different levels, and for different schemes. The image below shows how a high level language program could first be lowered to a generic FHE IR, before lowering further into specialised IRs that can handle the different schemes, before going down into the  hardware considerations of a compiler.

However, these IRs require standardization across the ecosystem and while it’s still early, there are development and standardization efforts led by HomomorphicEncryption.org that include most of the key players in the space. You can also check out the HEIR paper that describes the implementation of a two-level IR stack like the one sketched out above.

Another interesting space— though not as significant as optimizing programs and compilers in general— is the selection of cryptographic parameters chosen for a FHE program.

As far as we know, finding optimal combinations is an open problem; experts have developed an art more than a science on figuring these parameters out. Most compilers take care of this for users but there’s always work being done on parameter picking: the Zama compiler takes care of this for users by turning circuits into subgraphs with better defined requirements and then finding the best aggregate secure-and-efficient set of parameters. Interestingly, these subgraphs can also be used as benchmarks to find more efficient ways to structure circuits. This is described in detail in their blogpost.

Hardware:

Hardware is another dimension where speedups are anticipated, owing to the promise of FHE itself, but also benefiting from the work being poured into Zero-Knowledge (ZK) hardware as there is some overlap in the calculations that are being optimized.

While advancements in hardware can provide some boosts in performance, they won't address the foundational inefficiencies that arise from non-expertly designed solutions. Additionally, since cryptographic standards for FHE are still evolving, it adds another layer of complexity to the development of dedicated hardware. Without fixed standards, there's added risk in committing to hardware designs that might become obsolete as the cryptographic landscape changes. Fixing standards will also create trade-offs in program efficiency as compilers won’t have as much freedom to optimize the parameters based on the program.

We refer you to HashKey’s article for more on Hardware.

Cryptographic Improvements to schemes:

The world of cryptography witnessed significant advancements in FHE since its conceptualization in 2009. State-of-the-art schemes were gaining orders of magnitudes in efficiency nearly every year until around 2016 (Gm, CKKS and TFHE!). However, there has been diminishing returns on these improvements and we’re focusing on the other areas for more immediate mega speed gainz.

--------------------------------------------

In short, for the better part of the last two decades, FHE research and development was theoretical, in major part due to its limitations. We’re starting to see application-focused research and tooling, increasingly accessible content, and more mindshare. At Polymorphic Capital, we're excited about the future of FHE and its applications. We're eager to collaborate with those pushing this frontier. If you're building in this space, reach out to @romdespoel on X/tg!

The theory was first floated around in the late 70s (notably, by R and A of the RSA encryption team) but the first functional scheme was only proposed in 2009 by Craig Gentry. It was offensively inefficient, with multiplications of two encrypted numbers taking minutes. Since then, the pace of improvements and iterations has been ramping up and FHE has gone from prohibitively expensive to just impractical. With all it promises— whether in privacy-preserving ML, encrypted blockchains, or others— it’s becoming an important part of the conversation on privacy. So, read on!

How does it work?

Traditionally, if an application had to perform some computation on encrypted data, the application would have to decrypt the data first, perform the desired task on the plaintext data, and then re-encrypt the data. When working with trusted third-parties, that works well. However, it introduces issues when you don’t trust the guys on the other side. For example, I’d be all about using my genomic data to further science but I don’t know who’s getting their grubby little hands on my GATTACAs after I dutifully spit in a sample tube.

FHE’s proposal is to remove the application’s need to decrypt anything. This works by finding ways to encrypt data so that you can apply functions +_{enc} and \times_{enc} that maintain the same properties as normal addition and multiplication when you do them over the encrypted data (hence, the name homomorphic— maintaining the same shape). If you can do that, you can work on encrypted data, and, on decryption, get a matching output. For example,

I can encrypt the values $3$ and $5$, and make someone compute $3 + 5$ on those encrypted inputs without them knowing what they’re actually adding. The result to that computation, however, can be decrypted to the plaintext output by whoever has the key.

“Why addition and multiplication?”, you might ask. It turns out these two operations are computationally complete, meaning that any computation can be expressed as combinations of these so that— more generically— for any computation $f$ (and its equivalent on encrypted data, $f_{enc}$) on a message $m$, you get something like this:

I could encrypt my message $m$, send it to some snakey third-party that won’t be able to decipher it but will still be able to produce something useful by applying $f_{enc}$ on it. In this example, if I have the key, I can then decipher what I get back.

Seeing this, we get an idea of how FHE can have an enormous impact on how we understand data privacy. For example, users would be able to offload expensive computations to cloud providers in such a way that the providers would not have access to the plaintext data at all.

Where could this be used?

In a nutshell, this lets multiple parties work collaboratively on data without having to trust each other. Unapologetically, we’ll start with Web3 use cases ¯\(ツ)/¯

Web3

Recently very popular, Zero Knowledge (ZK) has been sold in every shape and form as crypto’s solution to privacy. It will undoubtedly play a huge part in increasing the privacy of distributed systems but has limitations when it comes to shared private states. For example, try to come up with a protocol for private on-chain voting.

This is where FHE shines as no sensitive data has to be decrypted before being aggregated. This unlocks:

• Full composable and programmable private blockchains

• Sealed-bid auctions

• Private on-chain voting

• Dark pools (private exchanges)

• More flavours of on-chain gaming with incomplete information

• Trustless bridges

• All the use cases below are also portable to blockchains

Web2

• Private information retrieval: googling something or querying a database without giving the server any information on what you’re actually looking for

• Machine Learning on private data: you could contribute your sensitive data to training models without revealing anything about yourself. For example, getting privacy-preserving tailored advertising or contributing health data to create more accurate medical models.

• Private AML, KYC: Let someone check you’re not doing anything naughty without having to reveal who you are or what you do!

• Privacy-preserving location based services: Leveraging your location without the current accompanying privacy and security concerns

Challenges

Regardless, there are still major barriers to widespread adoption of FHE, which I will be covering these in more depth soon™. For now, the headlines are:

• It’s performance (both in terms of size and speed), still has major room for improvement

• Expertise is required to write secure and efficient solutions as there are subtleties to converting arbitrary programs into FHE circuits. Code written by non-experts can lag behind expert-written solutions by many orders of magnitude

• User education on the above and documentation is lacking

• Lack of standardisation for the existing schemes to facilitate research and increase security

• FHE is not a silver bullet to privacy. It’s a significant tool in the suite of Privacy Enhancing Technologies (PETs) that will help facilitate privacy across all the webs but a lot of work still needs to be done in other privacy areas like ZK, MPC, mixnets, etc.

• Working assumption that third parties are outputting reliable data. In most of the article, I’ve been assuming an honest-but-curious third party but what if the third party decided to output adversarial data? A lot of work still needs to go into verifiable FHE. A mix of ZK & FHE might be the MVP on this one but there’s a lot of work to be done due to the fundamental mathematical differences on how these systems are built today

The Scenery

A majority of the work being done is still academic. Nevertheless, due to the importance of this emerging paradigm, every major company has FHE on their radar:

• In 2021, Google open-sourced a transpiler, a library that converts arbitrary C++ into code that can work on encrypted inputs

• Microsoft released a lower-level library called SEAL in 2018. It requires more FHE knowledge but is more modular as it supports different FHE schemes and lets you tinker with the scheme parameters (more on this next time). They’ve also leveraged FHE through the Edge browser to work on password monitoring (look at you go, Edge! Good job, buddy)

• Intel is working on hardware acceleration as FHE brings around significant performance challenges

• IBM is providing consulting services and tailored FHE cloud infrastructure

• Ericsson has made noise about leveraging FHE for privacy-preserving AI

You will also find a handful of new companies specialising on the topic:

• Zama is building tools like Concrete and TFHE-rs (compilers to add FHE to Python and Rust), Concrete ML (a framework for privacy-preserving ML) and doing great work on contributing research and fostering a community

• Sunscreen is also building a Rust compiler, but actively focusing on the web3 space

• Secret Network, a privacy-preserving programmable blockchain has historically relied on secure hardware but has been vocal about the development of FHE as a solution to hardware dependency

• Blyss is developing a key-value private retrieval tool, built on one of the co-founder’s research

• Duality Tech and Enveil propose encrypted querying of databases and a suite of privacy-preserving statistical and ML tools

• Inpher works on enterprise privacy preserving ML

• Cornami is an FHE-enabled data pipeline software

• Desilo, Lorica and Decentriq work on securely linking and drawing insights from different siloed datasets

• Private Identity is working on identity using encrypted biometrics

That’s all we have for you today! We are aiming for a series of articles that will demystify everything FHE and if there’s anything you’d like to see, or feedback on the article, please reach out on twitter @romdespoel.

*Hardware is a tough section to categorise. Due to the infancy and lack of standardisation, it’s very early to start focusing on hardware. Nevertheless, some advances in ZK hardware optimise operations like FFTs and MSMs which are also relevant for FHE. Companies working on this have been omitted.