CORE TECHNOLOGY

EC-FHE: compute on data that stays encrypted.

Elliptic-curve homomorphic encryption computes directly on encrypted data. It never decrypts, even in use. The In-Use gap every other approach leaves open is closed by design.

The Problem

Every breach happens in the same place: the In-Use plaintext gap.

Data at rest and in transit is already encrypted. The exposure is the moment it is decrypted to be used, and AI makes that moment constant.

At Rest
stored

AES-256 / KMS: disk & storage-level encryption

Protected
In Transit
moving

TLS / HTTPS: network-layer encryption

Protected
In Use
computing

None. Plaintext & keys exposed in memory during compute

Exposed

What AI adds

LLM data input

Customer data leaks PII / IP the moment it is fed to a model.

AI pipeline exposure

Decryption windows open across training and inference.

Data silos

Security fears block sharing between partners and institutions.

Regulatory risk

GDPR, the AI Act, and privacy law are all tightening at once.

Our Solution

EC-FHE computes without decryption, structurally closing the gap.

Legacy
Store (encrypted)Decrypt (plaintext exposed)Compute (plaintext)Re-encrypt

A decryption window every time data is used.

4Chains (EC-FHE)
Store (encrypted)Compute while encrypted, no decryptionReturn result (encrypted)

Exposure eliminated at the source.

USE

Run analytics and ML inference directly on encrypted data; results come back encrypted.

ANALYZE

Power dashboards, model training, and decisions on regulated datasets.

SHARE

Collaborate across teams and partners without handing over the raw data.

SCALE

Fast enough for production. Encrypted computation runs at speed, so it works for every enterprise, not just a few.

Security core
  • Never decrypted at any stage: at rest, in transit, or in use.
  • No public key, evaluation key, or secret key ever lives on the server.

Even if breached, there is nothing to take. Everything is ciphertext.

Technology Core

EC-FHE solves speed and quantum-resistance at two separate layers.

Core tech #1

Deep Circuit

Problem

Classic elliptic-curve (EC) encryption supports only addition and subtraction. That is too limited for real DB queries, machine learning, or statistics.

4Chains' solution

A proprietary algorithm implements multiplication and division, enabling deep computational circuits.

Result: performance unlocked
  • SQL JOIN · GROUP BY · ML inference
  • No noise, so no bootstrapping required
  • Practical at low overhead vs plaintext
Core tech #2

No-Key Protocol

Problem

EC math leaves a theoretical opening: a quantum Shor attack could derive the private key from a public key.

4Chains' solution

Public and evaluation keys are removed from the server entirely. There is no target left to attack.

Result: server-boundary quantum safety (information-theoretic by design)
  • No public, evaluation, or secret key on the server
  • Designed so the server view is information-theoretically independent of the plaintext (I(M;V) = 0)
  • Designed to stay unexposed even to a computationally unbounded adversary (quantum included)

Lattice-based FHE earned quantum resistance through its algorithm but lost speed. 4Chains earned it through protocol, and kept the speed.

Proven Performance

1.13ms encrypted queries. The speed ceiling of homomorphic encryption, removed by design.

52,000ops/s
Single-core encryption
41,000+ops/s
WHERE comparison
1.13ms
Encrypted query (E2E)
~1,700TPScore
Throughput, linear-scaling

Measured on Ubuntu 22.04 / coincurve (single core); throughput is per-core, derived from a 2-core end-to-end run (3,400 TPS) and scales linearly with cores. ops/s = homomorphic operations; TPS = end-to-end transactions.

Why it is structurally fast

01
Elliptic curve = no noise

Bootstrapping, lattice FHE's biggest bottleneck, is simply unnecessary.

02
No-Key = no eval-key overhead

With no keys on the server, key management and compute overhead approach zero.

03
Drop-in replacement

Connects straight into Oracle, PostgreSQL, and SAP HANA. No re-platforming.

Competitive Advantage

The value of FHE, on standard CPUs, without the GPUs.

Same capability. A different cost structure.

Aspect
Lattice-based FHE
4Chains TorusDB (EC-FHE)
Foundation
Ring-LWE · bootstrapping
Elliptic curve + No-Key delegation protocol
Design target
General-purpose arbitrary compute (research-oriented)
The operations a database actually runs, at practical speed
Hardware
GPU acceleration effectively required for practical throughput
Standard CPU
Hardware cost (CapEx)
Capital-heavy multi-GPU build
Commodity server, ~0 added when reusing existing
Power & ops (OpEx)
High-power GPUs + cooling
Standard-server class
Air-gapped deployment
GPU procurement & setup constraints make it hard to deploy
Drop-in (Oracle · PostgreSQL · SAP HANA)
Server-resident keys
Public + evaluation keys resident
No-Key: no keys on the server
Quantum-safety basis
Rests on LWE hardness assumption
Information-theoretic by design (quantum included)
Speed
High latency: ms to tens of ms per op (bootstrapping)
1.13ms · ~1,700 TPS/core (linear)

Working and being usable are not the same thing. Lattice FHE effectively needs GPU acceleration to reach practical throughput, which is why it often can't enter the air-gapped networks of banks, government, and enterprises. 4Chains runs on the standard CPUs you already operate, with no new hardware.

Cost figures are illustrative. Actuals vary by workload, configuration, and timing; GPU pricing and power assume typical data-center GPUs.

Security & Compliance

Trust earned by architecture, not by promises.

We don't ask you to trust a perimeter. Data stays encrypted even while it's used, keys are never exposed, and every computation can be proven correct without revealing the data behind it.

Encrypted in use

Data is never decrypted, whether at rest, in transit, or during computation. There is no plaintext window to attack.

No-Key Architecture

No public, evaluation, or secret key ever lives on the server, and there is no master copy of the data to steal.

Quantum-resistant by design

Built on post-quantum foundations engineered to hold against tomorrow's threats, not just today's.

Verifiable & auditable

Through Moduli Chain, security, compliance, and partners can verify outcomes without ever seeing the underlying data.

Data stays in place

Compute where the data lives. Nothing is pooled, copied, or moved, which supports residency and data-minimization obligations.

Built for regulated sectors

Designed around the privacy obligations of finance, healthcare, and the public sector from the start.

We're glad to walk your security team through the architecture and controls in a technical review.

The full stack

Two layers, each secured by the method that fits.

Data and identity face different threats, so 4Chains secures each with the approach built for it. One platform, two layers.

Data layerNo-Key architecture

TorusDB · EC-FHE

Compute directly on encrypted data. With no keys on the server, the server's view is designed to be information-theoretically independent of the plaintext, so there is nothing to derive, even for a quantum adversary.

Identity & signing layerNIST FIPS 204 · Module-LWE

PrivID for PQC · CRYSTALS-Dilithium

Authenticate and sign with lattice signatures that stay unforgeable even against a full-scale quantum adversary. Passing a check proves the signature is valid and bound to the right user-service context.

Post-quantum unforgeability applies to PrivID's signing. Its identifier-privacy layer rests on classical assumptions today; full post-quantum privacy is on the roadmap.

See EC-FHE in action.

From encrypted storage to ML inference: the whole pipeline, never decrypted.