# Fidelius: two-party data collaboration inside an Intel SGX enclave > Fidelius is Intel SGX middleware for two-party data collaboration: the provider's raw records never leave its enclave, and a blockchain can serve as an optional trusted third party. The trust is concentrated in the enclave, so the hardware and build path are what to examine first. **YeeZTech/YeeZ-Privacy-Computing** — Fidelius - YeeZ Privacy Computing, a trusted-execution-environment-based privacy computing middleware by YeeZ. - Repository: https://github.com/YeeZTech/YeeZ-Privacy-Computing - Website: http://yeez.tech - Stars: 1,060 · Forks: 137 - Language: C - License: GPL-3.0 - Published: 2026-10-14 · Updated: 2026-10-14 · Language: en - Canonical page: https://hysenlabs.com/projects/yeeztech-yeez-privacy-computing ## Two parties and an enclave boundary that never moves the raw data Fidelius addresses a narrow coordination problem. One party holds records it will not hand over; another wants answers computed from them. The project's shorthand for it is "data availability but not visible." In this design the original data never leaves the Fidelius middleware on the data provider's side, and both the provider and the data user run that middleware themselves. A request travels into the provider's enclave and comes back carrying only the exposed result, never the rows behind it. Fidelius names four guarantees: consistency of the original data, controllability of the computing logic, correctness of the result, and protection of the data itself. Intel SGX supplies the hardware boundary that turns the last of those from a convention into something the processor enforces. The intended user is a data provider who must keep records on premises and still let an outside analyst compute over them. Anyone who only needs an answer, and not a verifiable story that data was never exposed, will find a great deal of machinery here they do not need. ## How the two enclaves and the chain exchange a result The architecture splits the confidentiality boundary from the integrity boundary. Confidentiality comes from the SGX enclave inside the middleware on each machine, while integrity, the claim that the agreed logic actually ran, can be anchored to a trusted third party. Fidelius lets that third party be a blockchain network. It leans on two properties of a chain: a decentralized network and public verifiability. In that arrangement the chain acts as a trusted transmission channel and a data computing verification platform, while the raw records stay inside the provider's enclave the whole time. Nothing in the documentation forces the chain on you. It is one option in the abstract collaboration diagram, and the enclave-to-enclave path stands without it. That distinction matters when you size a deployment: the enclave side cannot be skipped, the chain side can be added later. ## Building Fidelius: Intel SGX, build.sh, and the documented compile path There is no one-line installer, and the project does not pretend otherwise. Before anything compiles, Fidelius wants you to confirm the hardware side: a supported central processing unit, the matching BIOS settings, and the installed drivers and related software, all tied to Intel SGX. Without that machine, the fallback is a debug version. The project states that this debug build can still run once the Intel SGX SDK is installed, even without the required hardware environment. For the compile itself, the README does not paste commands into the page. It routes you to `doc/Release_EN.md` instead, and the repository ships the build scaffolding you would expect for a C project. Those are the build entry points the project exposes: a `build.sh` shell driver, a top-level `CMakeLists.txt`, a `cmake/` directory, and a `CTestConfig.cmake` test configuration. A `.gitmodules` file is also present, which is the hint that some dependencies arrive as submodules and a fresh clone needs them initialised before the build script has everything it expects. Nothing in the repository text spells out the exact compiler flags or the submodule step, so those details come from `doc/Release_EN.md` and the script itself. ## First run through personlist, multi_personlist, and iris A first real run means building against the sample applications the repository carries. They sit under `example/`, where `example/CMakeLists.txt` joins three directories named `example/personlist/`, `example/multi_personlist/`, and `example/iris/`. The directory names are the only signal about what each of those three applications actually computes. Nothing published states the computation inside `personlist` or `iris`, so the names, a single list beside a multi-person one, are as far as the text goes. The thinness matters because these are the entry points a new user tries first, and the build guide does not walk through any of them. The top-level `CTestConfig.cmake` is what CTest reads, wiring the examples into a test configuration. Start by compiling one and watching it run on a small dataset you control, then expand to a real workload. ## Two COPYING files and a label that does not match them Reading the terms closely turns up a detail a skim misses. The project's top-level label is GPL-3.0, yet the terms are split by directory: code outside the `toolkit` directory, which the project calls the library, is offered under the Apache License 2.0 with its text in `COPYING.APACHE`, while code inside `toolkit`, which it calls the binaries, is offered under the GNU General Public License v3.0 with its text in `COPYING`. Leaving legal judgment aside, the consequence for an engineer is concrete: a deployment that ships the `toolkit` binaries carries the copyleft v3.0 terms in `COPYING` with it, whereas building only against the library code outside `toolkit` sits under the permissive 2.0 terms, and the 3.0 obligations travel only with the binaries. Two text files for one project are an odd arrangement. The single top-level label hides it. Which side of that line your product lands on is worth settling before you vendor anything, because the split runs by directory and not by component name. ## Where the trust story thins out: undocumented rollback and upgrades Several operational questions go unanswered, and knowing which ones matters before you commit hardware. Rolling back a deployed middleware is not described anywhere the project publishes. Neither is the upgrade path between a blockchain-assisted deployment and an enclave-only one. The developer guide it points to, `doc/Developer_ZH.md`, is in Chinese, as are the hosted doxygen and wiki pages, so an English-only team reads translated material or reverse engineers the C sources. The hosted documentation also lives on three separate domains: an introduction PDF on `download.yeez.tech`, generated API pages on `doc-fidelius.yeez.tech`, and a wiki on `doc-dianshu.yeez.tech`. Each is a place for the docs to drift from the code. The last push was on 2026-09-02. That is recent enough that the C sources are not abandoned, but it is a single data point rather than a cadence. ## Enclave only or enclave plus chain: the deployment trade-off If you are deciding how to deploy Fidelius, the published material narrows to two topologies, and the difference between them is not cosmetic. The enclave-only path keeps both parties inside the SGX boundary and lets them talk directly, which is the smallest footprint. The enclave-plus-chain path inserts a blockchain network as the trusted third party, chosen for its decentralized network and public verifiability. That buys an external party who can check that a computation ran as agreed. It costs standing up and depending on the chain. For a consortium where members distrust each other's operators, the second topology answers the objection the first cannot, because an enclave protects data while it is in use but does not by itself publish proof of what ran. For a two-party pilot inside one organisation, the chain is extra moving parts with no counterpart on the other side of the trust gap. Pick the topology first, because it decides whether you operate two enclaves and a network connection or two enclaves plus chain infrastructure, and counterparties cannot swap that cheaply once integrated. ## Conclusion Adopt Fidelius if you must show a partner that raw records never left your enclave and Intel SGX hardware is already on the table. Skip it when a query-based or federated arrangement would satisfy the same disclosure requirement at a fraction of the infrastructure cost. First settle which side of the `toolkit` directory split your build actually ships, since that choice follows the code paths and cannot be changed after integration. Then run one `example/` application on real SGX hardware to see whether the stated guarantees hold at your data scale and your latency budget. ## FAQ ### What hardware does Fidelius need in order to run? It targets Intel SGX and expects a supported CPU, matching BIOS settings, and the installed drivers and related software. Without that machine, the project says a debug version can still run once the Intel SGX SDK is installed. ### How do I compile and run Fidelius? The README points to `doc/Release_EN.md` for the compile and run steps. The repository ships `build.sh`, a top-level `CMakeLists.txt`, a `cmake/` directory, and `CTestConfig.cmake` for the test harness. ### Under what terms is Fidelius distributed? The project is labelled GPL-3.0 but splits terms by directory: code outside `toolkit` is offered under the Apache License 2.0 in `COPYING.APACHE`, and code inside `toolkit` under the GNU General Public License v3.0 in `COPYING`. ### Does the raw data ever leave the data provider's machine in Fidelius? No. The original data stays in the Fidelius middleware on the provider's side, and both the provider and the data user run that middleware, so only the exposed result comes back. ### When is the blockchain network needed in Fidelius? It is optional. Fidelius can choose a blockchain network as the trusted third party, using it as a trusted transmission channel and a data computing verification platform for its decentralized network and public verifiability. ## Sources - [Issues](https://github.com/YeeZTech/YeeZ-Privacy-Computing/issues) - [License: GPL-3.0](https://github.com/YeeZTech/YeeZ-Privacy-Computing/blob/master/LICENSE) - [Project website](http://yeez.tech) - [README](https://github.com/YeeZTech/YeeZ-Privacy-Computing/blob/master/README.md) - [YeeZTech/YeeZ-Privacy-Computing on GitHub](https://github.com/YeeZTech/YeeZ-Privacy-Computing) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yeeztech-yeez-privacy-computing