![LatticAwaLLLnut's tweet photo. Caution! this post is about why LatticA is fast, and it does contain a bunch of Fully homomorphic encryption, FHE / lattice-crypto stuffs
Hi! We’re finally able to share one of our core research results.
If you’ve seen our Gitbook, one of the mysterious keywords there was “Primitive Gate”.
Paper is now on ePrint: https://t.co/sY44AoasGD
[For the record, we even pre-committed to the name in the docs: SHA256("Primitive Gate") = f321ce2f5032c6d408f553606755b51378366c99adfa37337c95c1a330577139, see: https://t.co/g0ykztlGeW]
Gate FHE doesn’t do fast SIMD like other schemes.
Instead, it shines in low latency for single operations + small evaluation keys (public-key-like).
Let’s call this style latency-first FHE.
In the early days you could only homomorphically evaluate gates (AND/OR/XOR).
Building integer arithmetic by stacking tons of gates was… painfully inefficient.
To fix that, the community moved toward programmable bootstrapping (PBS) and LUT-based approaches:
You “program” a small lookup table (LUT) and evaluate it homomorphically.
Very much like compiling logic with LUTs on an FPGA.
People tried to increase LUT input bits / output bits to make it more powerful.
But as LUTs got more powerful, we started to lose the “latency-first” advantage.
Evaluation keys exploded in size, to the point where some schemes no longer fit comfortably in a web browser.
(Example: big-key FHE stacks end up needing server-side or heavy environments instead of “runs anywhere” crypto.)
We took a step back and asked:
“Is maximizing LUT power really the right direction for latency-first FHE?
Even if LUTs stay small, is there another axis we can push?”
This led us to define a function class called the
blind rotation function family (BRFF) and explore that space instead.
The “oh wow” moment:
Latency-first FHE should be generalized not by LUTs, but by BRFF.
You don’t have to keep making LUTs bigger – you can widen the function class that BRFF can handle.
We call the resulting function family Primitive Gate.
Very informally, Primitive Gate includes:
The usual gate ops from latency-first FHE:
AND, OR, XOR
Mixed gates like:
AND-XOR, OR-XOR
XOR6: a 6-input XOR
(the “6” is generalizable; FHE16 currently uses up to 6 inputs)
MAJ3(x, y, z) = (x AND y) OR (x AND z) OR (y AND z)
– the 3-input majority function
EQ3(x, y, z) = 1 if (x == y == z), else 0
The key punchline:
All of these run in essentially the same latency as a normal gate,
and we don’t blow up key sizes like in PBS-heavy designs.
No “one op is much slower”, no monstrous evaluation keys.
Also important:
This work does not assume a new cryptographic hardness assumption.
it’s a new fact, so you can treat it as “safe to use” even though the paper is on the archive right now.
So what does this mean for LatticA and FHE16?
FHE16 was already fast.
By exploiting the Primitive Gate capability, LatticA can push further:
Faster than state-of-the-art FHE in our target setting
Smaller key sizes at the same time
That’s the core story behind why LatticA can be both fast and browser-friendly.
Next steps / roadmap
A) We’re not done yet
There are still several research results / papers in the pipeline.
We’ve already left cryptographic “commitments” (hashes) to them in the Gitbook and are excited to reveal them one by one.
B) Most FHE research pours effort into hardware acceleration:
GPU, FPGA, ASIC…
But many blockchain folks we spoke to don’t just want “some vendor’s FHE in their data center”.
They want:
“FHE that runs in my browser, on my phone.”
We think that direction is very cool.
So before we rush to build accelerators, our next concrete goal is:
Put FHE16 in the web browser,
so that users can directly compute on ciphertexts in the front end.
Stay tuned :)
@Isley1249 , @thegimsin , @Scarrots93 , @DJShin73](https://pbs.twimg.com/media/G66KYq4bkAMni3a.png)
Olivia
Online
seunghwan lee
@Scarrots93
Joined September 2025
46 Following
12 Followers
26 Posts
@LatticAwaLLLnut Annything already sitting in the page, an extension or some injected script, sees the value before it's encrypted. The Worker is only there to keep the engine off the main thread, not an integrity boundary. Thanks for pushing on this.
@Chris_L_Elliott @LatticAwaLLLnut Yeah, that's right. Moving the compute into the browser gets rid of trusting a server, not trusting the code you just downloaded.
So I went ahead and put the SHA-256 and an SRI hash for fhe16.js in the README. Pin it with the integrity attribute and you're covered on delivery.
FHE16 now runs fully in the browser: key generation, encryption, computation with bootstrapping, decryption — all on the device. No install, no server. Works on your phone.
One file: fhe16.js
https://t.co/KLZdci5RpQ
What runs in the tab
- Boolean gates, 32-bit signed integer arithmetic and comparisons, IEEE 754 float (f32) — every result bit-exact to plaintext
- Bootstrapping inside the browser, so there is no depth limit on what you compute
- One deterministic 16-bit integer spec with zero floating point in the pipeline: browser, server, GPU, FPGA and phone return the identical bits. That is what makes FHE usable for decisions that must be exact — approvals, settlement, sealed-bid auctions
Why it matters
Most browser FHE tooling stops at key generation and encryption and ships the actual computation to a server. Here the computation stays on the device. As far as we can tell, this is the first public build where bootstrapped FHE runs end-to-end in a phone browser.
Why we built it
AI agents are about to decide on payroll, insurance claims, credit and health data. We are building the layer that lets an agent decide on that data without ever seeing it in the clear: the agent, its tools and the model handle only ciphertext, so a prompt injection or a leaky tool can expose nothing but ciphertext. In-browser FHE puts that decision on the user's own device, next to the data. The private-policy demo is a small version of exactly this — rules hidden from the data owner, data hidden from the rule owner, only the verdict comes out.
One note
This is an evaluation build. Same operations, same speed as the secure build, but zero-error test parameters — no cryptographic security. Use it for integration and performance testing. Secure build and SDK: [email protected]
waLLLnut — https://t.co/hjwAOlmWeP
#FHE #HomomorphicEncryption #AIAgents
https://t.co/Gu3b5JRzjs
We’d like to share our team’s latest progress on fully homomorphic encryption (FHE) once again!
https://t.co/srZe2VyfEX
Every time we wrote a paper on FHE, we struggled with error analysis of the GINX-type approach. Each paper presented seemingly plausible formulas, but none of them had ever been properly verified.
When we actually built and ran a simulator ourselves, we realized something surprising: not a single one of them was correct. No one had actually simulated the real errors and checked whether the formulas matched reality.
In particular, whether decryption works correctly is not just a matter of saying, “Oops, sorry, we were wrong.” A number of papers have shown that information from decryption failures can be exploited to recover the secret key in homomorphic encryption schemes (see IND-CPAD).
Therefore, we present an error simulator that can precisely measure the errors arising in blind rotation.
We hope this simulator will contribute to the homomorphic encryption community by enabling accurate error analysis and allowing schemes to be compared fairly within a precise and consistent framework.
A paper, led by @thegimsin (with @Isley1249, @Scarrots93 , and @DJShin73) is currently being prepared for submission to arXiv. We’ll be back with another post as soon as it’s publicly available!
A. FHE schemes that use FFT are not covered. Because they introduce additional floating-point errors, we were not able to provide a rigorous model for those cases.
B. According to our forthcoming paper, it is also possible to reduce the error probability to 2^{-128} or even 2^{-256}.
C. Key switching is not yet included. The blind rotation analysis alone required 60 pages… (The deeper we dug, the more nontrivial formula terms kept appearing. It was almost maddening.)
26.02.10. Pitched at Roundtable – Proof of Building (@SuperteamKorea).
https://t.co/UxLVnbgo34
https://t.co/xxuJEPLkCK
LatticA: we’re building regulation-ready privacy infrastructure for blockchain.
Privacy isn’t just anonymity.
It must coexist with verifiability and compliance.
Finally we figured out how to meet ZK and FHE each other friendly ..
Let's get back to work for optimizing RLWE ( road map to on-boarding FHE) log with noir stack!
@ham379888
Submitted to the @solana Privacy Hack.
A privacy-first, compliance-ready auditable dark pool on Solana, built entirely in Noir during this hackathon. Users deposit encrypted assets into a shielded pool and withdraw anonymously, while every transfer includes a mandatory on-chain verifiable audit proof.
The system uses two custom ZK circuits verified via Solana’s BN254:
Shielded Pool Circuit: Enables private deposits and withdrawals using Poseidon commitments, nullifiers, and a depth-40 Merkle tree (Groth16 via Sunspot).
RLWE Audit Circuit: Proves that a BFV-like ciphertext is correctly encrypted under an auditor’s RLWE public key, ensuring regulatory compliance without revealing amounts or identities.
Demo: https://t.co/flWKjucjyz
GitHub: https://t.co/dHxn2xS74G
It was an incredibly rewarding pitching and feedback session.
I hope LatticA can become the project that leads Mantle’s privacy solutions.
#Mantle #LatticA #AuditablePrivacy
Mantle Mentor Clinic EN Session https://t.co/9KChQpbPf0
Mantle Mentor Clinic EN Session https://t.co/9KChQpbPf0
@Mantle_Official Thoughts after the Mantle Hackathon:
We could really feel how serious and passionate everyone is about blockchain privacy.
Hope there’s strong interest in our compliance-friendly privacy solution using FHE16.
Looking forward to Mantle's great feedback!!
@LatticAwaLLLnut
⤵️
솔라나 생태계 연중 내 가장 큰 행사인 Breakpoint @SolanaConf가 목요일부터 토요일까지 아부다비에서 성대하게 개최될 예정입니다.
코어 기술 발표부터, 비즈니스 성과들까지 모두 공유될 예정이니, 많은 관심 부탁드립니다.
자세한 아젠다는 https://t.co/IqpQb279Fh 에서 확인 가능합니다!
Zama is doing a public sale through a dutch auction. Interesting model as you don’t see other peoples’ bids. Which means you have to bid what you think is the real price.
The floor is $55m FDV, but there is no cap on the price. The lowest price at which a bid gets filled is the clearing price.
To illustrate how it works, let’s say there is only 100 Zama tokens to sell:
- user A places a bid for 70 tokens at a $2 price, and pays 70*2 = $140 for it
- user B places a bid for 30 tokens at a $1 price, and pays 30*1 = $30 for it
- user C places a bid for 80 tokens at a $0.5 price, and pays 80*0.5 = $40 for it
- the clearing price is $1, because the whole supply of 100 tokens will have been taken by bidders at or above $1
- user A then gets his 70 tokens, plus a refund for 70*(2-1) = $70
- user B then gets his 30 tokens, plus a refund for 30*(1-1) = $0
- user C is under the clearing price, and therefore get 0 tokens and a refund for his full $40
I am an early backer of @zama.
Caution! this post is about why LatticA is fast, and it does contain a bunch of Fully homomorphic encryption, FHE / lattice-crypto stuffs
Hi! We’re finally able to share one of our core research results.
If you’ve seen our Gitbook, one of the mysterious keywords there was “Primitive Gate”.
Paper is now on ePrint: https://t.co/sY44AoasGD
[For the record, we even pre-committed to the name in the docs: SHA256("Primitive Gate") = f321ce2f5032c6d408f553606755b51378366c99adfa37337c95c1a330577139, see: https://t.co/g0ykztlGeW]
Gate FHE doesn’t do fast SIMD like other schemes.
Instead, it shines in low latency for single operations + small evaluation keys (public-key-like).
Let’s call this style latency-first FHE.
In the early days you could only homomorphically evaluate gates (AND/OR/XOR).
Building integer arithmetic by stacking tons of gates was… painfully inefficient.
To fix that, the community moved toward programmable bootstrapping (PBS) and LUT-based approaches:
You “program” a small lookup table (LUT) and evaluate it homomorphically.
Very much like compiling logic with LUTs on an FPGA.
People tried to increase LUT input bits / output bits to make it more powerful.
But as LUTs got more powerful, we started to lose the “latency-first” advantage.
Evaluation keys exploded in size, to the point where some schemes no longer fit comfortably in a web browser.
(Example: big-key FHE stacks end up needing server-side or heavy environments instead of “runs anywhere” crypto.)
We took a step back and asked:
“Is maximizing LUT power really the right direction for latency-first FHE?
Even if LUTs stay small, is there another axis we can push?”
This led us to define a function class called the
blind rotation function family (BRFF) and explore that space instead.
The “oh wow” moment:
Latency-first FHE should be generalized not by LUTs, but by BRFF.
You don’t have to keep making LUTs bigger – you can widen the function class that BRFF can handle.
We call the resulting function family Primitive Gate.
Very informally, Primitive Gate includes:
The usual gate ops from latency-first FHE:
AND, OR, XOR
Mixed gates like:
AND-XOR, OR-XOR
XOR6: a 6-input XOR
(the “6” is generalizable; FHE16 currently uses up to 6 inputs)
MAJ3(x, y, z) = (x AND y) OR (x AND z) OR (y AND z)
– the 3-input majority function
EQ3(x, y, z) = 1 if (x == y == z), else 0
The key punchline:
All of these run in essentially the same latency as a normal gate,
and we don’t blow up key sizes like in PBS-heavy designs.
No “one op is much slower”, no monstrous evaluation keys.
Also important:
This work does not assume a new cryptographic hardness assumption.
it’s a new fact, so you can treat it as “safe to use” even though the paper is on the archive right now.
So what does this mean for LatticA and FHE16?
FHE16 was already fast.
By exploiting the Primitive Gate capability, LatticA can push further:
Faster than state-of-the-art FHE in our target setting
Smaller key sizes at the same time
That’s the core story behind why LatticA can be both fast and browser-friendly.
Next steps / roadmap
A) We’re not done yet
There are still several research results / papers in the pipeline.
We’ve already left cryptographic “commitments” (hashes) to them in the Gitbook and are excited to reveal them one by one.
B) Most FHE research pours effort into hardware acceleration:
GPU, FPGA, ASIC…
But many blockchain folks we spoke to don’t just want “some vendor’s FHE in their data center”.
They want:
“FHE that runs in my browser, on my phone.”
We think that direction is very cool.
So before we rush to build accelerators, our next concrete goal is:
Put FHE16 in the web browser,
so that users can directly compute on ciphertexts in the front end.
Stay tuned :)
@Isley1249 , @thegimsin , @Scarrots93 , @DJShin73
![LatticAwaLLLnut's tweet photo. Caution! this post is about why LatticA is fast, and it does contain a bunch of Fully homomorphic encryption, FHE / lattice-crypto stuffs
Hi! We’re finally able to share one of our core research results.
If you’ve seen our Gitbook, one of the mysterious keywords there was “Primitive Gate”.
Paper is now on ePrint: https://t.co/sY44AoasGD
[For the record, we even pre-committed to the name in the docs: SHA256("Primitive Gate") = f321ce2f5032c6d408f553606755b51378366c99adfa37337c95c1a330577139, see: https://t.co/g0ykztlGeW]
Gate FHE doesn’t do fast SIMD like other schemes.
Instead, it shines in low latency for single operations + small evaluation keys (public-key-like).
Let’s call this style latency-first FHE.
In the early days you could only homomorphically evaluate gates (AND/OR/XOR).
Building integer arithmetic by stacking tons of gates was… painfully inefficient.
To fix that, the community moved toward programmable bootstrapping (PBS) and LUT-based approaches:
You “program” a small lookup table (LUT) and evaluate it homomorphically.
Very much like compiling logic with LUTs on an FPGA.
People tried to increase LUT input bits / output bits to make it more powerful.
But as LUTs got more powerful, we started to lose the “latency-first” advantage.
Evaluation keys exploded in size, to the point where some schemes no longer fit comfortably in a web browser.
(Example: big-key FHE stacks end up needing server-side or heavy environments instead of “runs anywhere” crypto.)
We took a step back and asked:
“Is maximizing LUT power really the right direction for latency-first FHE?
Even if LUTs stay small, is there another axis we can push?”
This led us to define a function class called the
blind rotation function family (BRFF) and explore that space instead.
The “oh wow” moment:
Latency-first FHE should be generalized not by LUTs, but by BRFF.
You don’t have to keep making LUTs bigger – you can widen the function class that BRFF can handle.
We call the resulting function family Primitive Gate.
Very informally, Primitive Gate includes:
The usual gate ops from latency-first FHE:
AND, OR, XOR
Mixed gates like:
AND-XOR, OR-XOR
XOR6: a 6-input XOR
(the “6” is generalizable; FHE16 currently uses up to 6 inputs)
MAJ3(x, y, z) = (x AND y) OR (x AND z) OR (y AND z)
– the 3-input majority function
EQ3(x, y, z) = 1 if (x == y == z), else 0
The key punchline:
All of these run in essentially the same latency as a normal gate,
and we don’t blow up key sizes like in PBS-heavy designs.
No “one op is much slower”, no monstrous evaluation keys.
Also important:
This work does not assume a new cryptographic hardness assumption.
it’s a new fact, so you can treat it as “safe to use” even though the paper is on the archive right now.
So what does this mean for LatticA and FHE16?
FHE16 was already fast.
By exploiting the Primitive Gate capability, LatticA can push further:
Faster than state-of-the-art FHE in our target setting
Smaller key sizes at the same time
That’s the core story behind why LatticA can be both fast and browser-friendly.
Next steps / roadmap
A) We’re not done yet
There are still several research results / papers in the pipeline.
We’ve already left cryptographic “commitments” (hashes) to them in the Gitbook and are excited to reveal them one by one.
B) Most FHE research pours effort into hardware acceleration:
GPU, FPGA, ASIC…
But many blockchain folks we spoke to don’t just want “some vendor’s FHE in their data center”.
They want:
“FHE that runs in my browser, on my phone.”
We think that direction is very cool.
So before we rush to build accelerators, our next concrete goal is:
Put FHE16 in the web browser,
so that users can directly compute on ciphertexts in the front end.
Stay tuned :)
@Isley1249 , @thegimsin , @Scarrots93 , @DJShin73](https://pbs.twimg.com/media/G66KZpqbcAAk9ic.png)
@LatticAwaLLLnut Seven years here, every day but Sunday.
Chasing a PhD; somewhere along the way this place became my second home… my bed thinks I moved out.
#LatticA #waLLLnut #FHE16 #HanyangUniversity #CCRL
Wrapping up the Hackathon — Team Walllnut’s in full sprint mode! #Solana #Colosseum #Walllnut #LatticA
@0xtodd @aycp_55 @0x_d07 @TrustlessState @cptn3mox @shanshan521 @jocyiosg @ManoppoMarco @Nomaticcap @YeruiZhang @phtevenstrong @EvansHuangfu @joesph_crypto @51N3P @NPC_Leo @wayne_axia8 @isc_mirana @Bybit_Official Your moment starts here:
Turn ideas into infrastructure. Concepts into companies. Builders into founders.
Join the Mantle Global Hackathon and make your mark.
Sign up now: https://t.co/lzgYCA3rt4
I think encryption always looks best with green text on a black background.
Because that’s the Matrix. #Encryption #Cyperpunk #FHE16 #LatticA #colosseum
There’s about a week left until the Colosseum hackathon deadline.
We’re almost done building our end-to-end encryption and homomorphic computation server-side outsourcing demo
@LatticAwaLLLnut @SuperteamKorea @colosseum
We once actually tested ZAMA’s tfhe-rs by running the exact same ciphertext on AVX2 and AVX512 builds — and the outputs diverged across CPUs. That’s why for FHE16, the goal is crystal clear: bit-for-bit identical results on every device.
#Solana #Colosseum #ZamaFHE #FHE16
Heck, it’s about time. I’m in.
Last Seen Users on Sotwe
tantebecek
Seen from Indonesia
meow
Seen from Malaysia
ลุงบ้านๆ58y.oId🆕♋📍
Seen from Thailand
MST88 ศูนย์รวมคนเซียน
Seen from Thailand
.คู่บ้านๆ ผัวเงี่ยน เมียร่าน
Seen from Thailand
cenk
Seen from Turkey
Jess James
Seen from Turkey
noor ahmed
Seen from Egypt
Saantis
Seen from Mexico
show on public
Seen from Thailand
Most Popular Users
Elon Musk 
@elonmusk
241.7M followers
Barack Obama
@barackobama
119M followers
Cristiano Ronaldo
@cristiano
114.3M followers
Donald J. Trump
@realdonaldtrump
111.9M followers
Narendra Modi
@narendramodi
107.2M followers
Rihanna
@rihanna
98.7M followers
NASA
@nasa
92.4M followers
Justin Bieber
@justinbieber
91.8M followers
KATY PERRY
@katyperry
90M followers
Taylor Swift
@taylorswift13
83.9M followers
Lady Gaga
@ladygaga
75.4M followers
Virat Kohli
@imvkohli
73.3M followers
Kim Kardashian
@kimkardashian
70.9M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
66.3M followers
Bill Gates
@billgates
65.1M followers
Selena Gomez
@selenagomez
63M followers
The Ellen Show
@theellenshow
62.3M followers
CNN
@cnn
61.8M followers
X
@x
60.7M followers