Interfolded: Crit in the Interfold
2026 Sep 06
See all posts
Thanks to Auryn
and Hamza from The Interfold for getting
this issue patched.
Context
The
Interfold is a coordinated computation protocol that makes use of
distributed key generation (DKG), zero-knowledge proofs (ZKPs), and
fully homomorphic encryption (FHE) to enable trustless computation over
an encrypted piece of data whose decryption key is distributed.
To achieve this, a user can request a committee of "ciphernodes",
which will jointly generate a key using a PV-TBFV protocol. The user
will then encrypt sensitive data under this joint committee public key,
and that data will be processed using FHE, with correctness proven by
ZKPs. This final result will be published back on-chain for a final
decryption ceremony performed by the ciphernode committee. If a
threshold number of the ciphernodes for that selected committee collude,
they can combine their key shares to decrypt user inputs, which breaks a
core security property of the protocol.
To combat this, the system uses a complex node selection system
involving tickets and scoring, and winning ciphernodes register their
key shares on chain. The specifics of the protocol aren't important, but
the protocol itself is seeded by randomness generated by the contract
and its randomness oracle. 
Initial Finding
On July 8th, while The Interfold was live on testnets only, I
identified an issue with the security of randomness that enables
sortition selection. 
In
this case, e3Id is simply a counter which increments upon
every request and prevrandao is data from the consensus
layer's RANDAO selection algorithm, which is known at block
construction time.
Utilising these two facts, an attacker could use a frontrunning
attack to include many requests just before an honest request, bumping
the ID until one gave them a committee selection seed which gave them a
colluding threshold. There is a limit to this, however, given that each
request uses ~1.1m gas and a block (at the time of writing) has a limit
of 60M gas. An attacker can only bump the ID up to 53 times in a single
block. They could also however delay the request into another block by
bribing MEV-Boost relays with high-value blocks.
We can model the probability (and cost) of the attacker successfully
manipulating a request into selecting a dangerous committee using
Bernoulli trials, with the variables being
- Attacker stake (\(V_{own}\))
- Total stake (\(V_{total}\))
- Selected committee threshold (\(T_m\) / \(T_n\))
- Gas per request (\(C_g\))
- Gas price (\(C_{gp}\))
- Block gas limit (\(G_{limit}\))
- Max requests (\(M_{max} =
53\))
You can play with these variables in a calculator here, where
\(P(x)\) and \(C(x)\) are the probability and cost of
successful attack, respectively. \(P(M_{max})\) represents a realistic
probability of attack success given the Ethereum mainnet block gas
limit. As this uses MEV mechanics, there is no cost for a failed attack,
only for successful ones.
The results are pretty bad, showing that with just 10% of the stake,
you can corrupt a 2/3 committee with a >77% chance. With just 20% of
the stake, a 10/19 committee (the highest security setting) can be
attacked ~7% of the time.
Escalation
After contacting Auryn
with my findings, he told me they were aware of the issue but hadn't
modeled it very extensively, that the randomness was always going to be
replaced with something more robust before mainnet, and that they were
expecting to undergo an audit shortly.
A couple months later, after I saw news that the Interfold had
launched on mainnet and went back to check on their contracts, what I
saw shocked me: 
The system relied on the entropy of the block hash of a future block
after the request is submitted. The block hash of a future block is
incredibly easy to manipulate simply by using a MEV-Boost relay and
bidding a high value within a block. You can then manipulate that
submitted block's hash. As with PoW, you can build many slightly
different blocks until you get one with a favourable hash.
Using this simple fact, you can manipulate committee selection,
sortition, into choosing your subset of nodes with almost 100% success.
The only limiting factor here being that ~5% of all blocks aren't built
using MEV-Boost. This could be useful for thieving revenue, but it's
much more dangerous for breaking protocol invariants and decrypting
sensitive data.
Audit
I immediately reached out to Auryn again, who gave me my favourite
response to a disclosure, ever
I was puzzled as to how this wasn't picked up in the audit, and so I
checked out the report.
The protocol was audited by a tier-one firm, Zenith, which was founded by
legends such as samczsun and obront.
In the report, they had identified the same initial issue I did, but
from a slightly different perspective of an attacking requester waiting
for a favourable sortition seed. 
What they then recommend, "obtain randomness from a later
block", however, is a little shocking, given it only makes the
problem worse. 
The Interfold team then implemented the fix using the dangerous
blockhash randomness pattern, which was subsequently audited and
verified by Zenith. 
Fixed
The issue was remediated in this pull
request, switching seeding to chainlink VRF, which has since been
deployed to mainnet.
Fin
If you want to discuss MEV, security, privacy, cryptography, or
general blockchain engineering, please reach out via the channels on
this site. I'm always on the lookout for opportunities, both contracts
and roles, so if it sounds like I could help with your project, let me
know.
Interfolded: Crit in the Interfold
2026 Sep 06 See all postsThanks to Auryn and Hamza from The Interfold for getting this issue patched.
Context
The Interfold is a coordinated computation protocol that makes use of distributed key generation (DKG), zero-knowledge proofs (ZKPs), and fully homomorphic encryption (FHE) to enable trustless computation over an encrypted piece of data whose decryption key is distributed.
To achieve this, a user can request a committee of "ciphernodes", which will jointly generate a key using a PV-TBFV protocol. The user will then encrypt sensitive data under this joint committee public key, and that data will be processed using FHE, with correctness proven by ZKPs. This final result will be published back on-chain for a final decryption ceremony performed by the ciphernode committee. If a threshold number of the ciphernodes for that selected committee collude, they can combine their key shares to decrypt user inputs, which breaks a core security property of the protocol.
To combat this, the system uses a complex node selection system involving tickets and scoring, and winning ciphernodes register their key shares on chain. The specifics of the protocol aren't important, but the protocol itself is seeded by randomness generated by the contract and its randomness oracle.
Initial Finding
On July 8th, while The Interfold was live on testnets only, I identified an issue with the security of randomness that enables sortition selection.
In
this case,
e3Idis simply a counter which increments upon every request andprevrandaois data from the consensus layer'sRANDAOselection algorithm, which is known at block construction time.Utilising these two facts, an attacker could use a frontrunning attack to include many requests just before an honest request, bumping the ID until one gave them a committee selection seed which gave them a colluding threshold. There is a limit to this, however, given that each request uses ~1.1m gas and a block (at the time of writing) has a limit of 60M gas. An attacker can only bump the ID up to 53 times in a single block. They could also however delay the request into another block by bribing MEV-Boost relays with high-value blocks.
We can model the probability (and cost) of the attacker successfully manipulating a request into selecting a dangerous committee using Bernoulli trials, with the variables being
You can play with these variables in a calculator here, where \(P(x)\) and \(C(x)\) are the probability and cost of successful attack, respectively. \(P(M_{max})\) represents a realistic probability of attack success given the Ethereum mainnet block gas limit. As this uses MEV mechanics, there is no cost for a failed attack, only for successful ones.
The results are pretty bad, showing that with just 10% of the stake, you can corrupt a 2/3 committee with a >77% chance. With just 20% of the stake, a 10/19 committee (the highest security setting) can be attacked ~7% of the time.
Escalation
After contacting Auryn with my findings, he told me they were aware of the issue but hadn't modeled it very extensively, that the randomness was always going to be replaced with something more robust before mainnet, and that they were expecting to undergo an audit shortly.
A couple months later, after I saw news that the Interfold had launched on mainnet and went back to check on their contracts, what I saw shocked me:
The system relied on the entropy of the block hash of a future block after the request is submitted. The block hash of a future block is incredibly easy to manipulate simply by using a MEV-Boost relay and bidding a high value within a block. You can then manipulate that submitted block's hash. As with PoW, you can build many slightly different blocks until you get one with a favourable hash.
Using this simple fact, you can manipulate committee selection, sortition, into choosing your subset of nodes with almost 100% success. The only limiting factor here being that ~5% of all blocks aren't built using MEV-Boost. This could be useful for thieving revenue, but it's much more dangerous for breaking protocol invariants and decrypting sensitive data.
Audit
I immediately reached out to Auryn again, who gave me my favourite response to a disclosure, ever
I was puzzled as to how this wasn't picked up in the audit, and so I checked out the report. The protocol was audited by a tier-one firm, Zenith, which was founded by legends such as samczsun and obront.
In the report, they had identified the same initial issue I did, but from a slightly different perspective of an attacking requester waiting for a favourable sortition seed.
What they then recommend, "obtain randomness from a later block", however, is a little shocking, given it only makes the problem worse.
The Interfold team then implemented the fix using the dangerous blockhash randomness pattern, which was subsequently audited and verified by Zenith.
Fixed
The issue was remediated in this pull request, switching seeding to chainlink VRF, which has since been deployed to mainnet.
Fin
If you want to discuss MEV, security, privacy, cryptography, or general blockchain engineering, please reach out via the channels on this site. I'm always on the lookout for opportunities, both contracts and roles, so if it sounds like I could help with your project, let me know.