Inspiration

The average healthcare data breach costs $7.42 million. 66 cases of large healthcare breaches were reported in the United States alone in the month of June 2026.

So hospitals do the only thing that makes sense: they lock it away.

But what these statistics do not tell you is that the information that could train algorithms to detect cancer at an earlier stage, predict outbreaks before they start or detect fraudulent activity in real-time is sitting on servers right now, both in hospital and bank databases.

It is valuable data, but it is also a liability. The moment it leaves, it is a breach and vulnerable to attack. So, it is better to keep it locked up and never use it.

Meanwhile, the researchers who could use it to develop new treatments or detect diseases early are not able to access it, or check if there is anything of value in there worth paying for.

We asked ourselves: what if the data never left?

No copies of it are made, no movement of it. Only the algorithm goes to the data, and only the result comes back.

And that question led to the creation of StayVault.

What it does

The StayVault platform is an innovative marketplace built around data owners who wish to profit from the value of their databases while retaining control over it.

At the core of the idea is the principle of computation reaching out to the data, not the other way around, with researchers only ever interacting with the results of computations run in isolation on the data owner's machine.

A hospital posts their database on the StayVault marketplace, but the database never leaves their server, only the metadata describing it does.
A researcher discovers a database they want to use.
Before sending any money to the hospital, they can ask to privately run a test algorithm of their choosing (perhaps a quality assurance algorithm) over the database to confirm that it suits their needs, without ever seeing any of the data themselves.
The researcher prepares their algorithm and sends it alongside the payment (ideally frozen in a smart contract using stablecoins, e.g. USD Coin) to the hospital, which is kept in escrow until the results are delivered.
The researcher's algorithm is run in an encrypted container on the private server of the hospital, where it only has access to the database it was permitted to see, and outputs the results of its computations.
The researcher receives the results of their algorithm in whatever format they requested. The payment is unfrozen and transferred to the balance of the hospital.

How we built it

Smart Contracts (Solidity ^0.8.20)

For registry, access control, and escrow functionalities we used OpenZeppelin contracts:

DatasetRegistry : on-chain registry which stores metadata about datasets and their ownership information
ComputeLicense : access pass granting rights for algorithm execution against a certain dataset
ComputeJobEscrow : smart contract for publishing algorithm jobs with an escrow-locked payment
AccessControl : contract governing the compute access control and job authorizations

Backend (Python 3.11)

REST API server exposing algorithm publication and dataset registration endpoints, built with FastAPI framework. Other features:

Docker SDK based pipeline for executing algorithm jobs in an isolated environment
JobAuthorized event listener
Storage of algorithm packages and metadata in IPFS via Pinata gateway

Frontend (React + Vite)

The application consists of a marketplace and an algorithm publisher module:

Embedded Wallet (Polygon Amoy testnet)
Dataset browsing capabilities
Algorithm publisher module
Job tracking dashboard

Privacy Layer

The algorithm execution takes place in a Docker container which is subject to the following isolation and integrity checks:

CSV files are mounted in read-only mode
Execution timeout is set to 30 seconds
All computation results are hashed with SHA256
No access to logs, stdout, or network from the container is allowed

This is a prototype implementation – the Docker-based isolation layer will be replaced with a trusted execution environment in production. For now, it approximates the behavior of the TEE described in our architecture document. In future releases we plan to employ the verifiable compute stack (combination of SMPC and ZKP protocols) for the production environment.

Challenges we ran into

Trust, but not in hardware.

Initially, we considered Trusted Execution Environments. But that is an unreliable single point of failure and involves vendor lock-in. We turned to Federated Learning, Secure Multi-Party Computation and Zero-Knowledge Proofs.

Blind buying.

In short, a buyer should not be paying for data that he cannot evaluate. On the other hand, an owner should not be allowed to evaluate it himself. We identified PrivaDE – an innovative technology that allows calculating the usefulness of the model without knowing the model parameters.

What about payments?

Both parties must be able to use the payment infrastructure. Volatile coins are out of the question. Traditional banking infrastructure is not suitable for small amounts. We chose the x402 standard for its ability to instantly settle USDC using HTTP 402 without human intervention.

How to reconcile the immutability of the blockchain with the right to forget?

The ability to delete information contradicts the essence of blockchain. We set about solving this problem by introducing a key shredding algorithm based on Shamir’s Secret Sharing. All the keys on the blockchain are burned, making all subsequent transactions inaccessible.

Front-end crypto-invisibility

By declaring that crypto is not suitable for hospitals, we set the goal to make it invisible. We have developed embedded wallets and automated USDC conversion solutions to keep crypto transactions out of the sight of hospital staff.

Front-end crypto-invisibility

By declaring that crypto is not suitable for hospitals, we set the goal to make it invisible. We have developed embedded wallets and automated USDC conversion solutions to keep crypto transactions out of the sight of hospital staff.

Accomplishments that we're proud of

We've envisioned every aspect of the system, from the process by which datasets are registered, paid for, and stored, to the computation architecture (both trusted and untrusted) and delivery mechanism. Solves concrete problems with the status quo, which is a general-purpose blockchain-based data marketplace (Ocean Protocol): focused on addressing particular gaps.
Our design for PrivaDE integration allows buyers to evaluate the utility of a dataset for their application without revealing either the data or their algorithm to the seller. An important capability that existing marketplaces do not provide.
A different approach to achieving security guarantees than the one proposed by Ocean, which relies on specialized hardware (Intel SGX, AMD SEV). We're pursuing a “software-only” stack based on Federated Learning, SMPC, and ZKP. Removes the risks associated with vendor lock-in and single points of failure while providing equivalent levels of privacy and data integrity.
Compliance and security guarantees that follow from (3): the design incorporates safeguards inspired by HIPAA regulations and the GDPR's right to be forgotten, including a concrete implementation (Shamir's Secret Sharing) of the latter that doesn't exist in other blockchains due to their inability to support post-quantum cryptography.
We've used 2026 x402 pricing data to formulate a set of assumptions under which the micro-economy of a data marketplace would be self-sustaining. Evaluated the viability of the micro-economy under several scenarios, and concluded that it has no path to profitability under the current design. Adjusted the strategic outlook to focus on enterprise sales instead.

What we learned

1. Security doesn't require specialized hardware.

You can achieve strong security without Intel SGX or AMD SEV. Both create a single point of failure and vendor lock-in. Our approach uses Federated Learning, SMPC, and Zero-Knowledge Proofs instead — no specialized hardware needed.

2. Enterprise adoption requires hiding the crypto.

We first designed the system so users interact directly with wallets, tokens, and smart contracts. Then we asked: "Would a hospital's legal team approve this?" The answer was no. The guarantees were fine — the complexity wasn't.

3. Most marketplaces misunderstand trust.

Staking is easy to game. You can put money behind bad data and fake a trust signal. We learned that trust has to come from verifiable outcomes, not from how much someone locked up.

4. Realistic revenue models beat theoretical ones.

Using real x402 transaction data, we found that micropayments alone can't sustain the ecosystem. So we shifted our strategy from micro-economy toward enterprise adoption.

What's next for Stay-Vault

Production-grade verifiable compute

Replace the Docker isolation layer with a full SMPC + Zero Knowledge Proof stack to realize the software-only security model described in our architecture, removing reliance on any specific hardware.

PrivaDE "Try-Before-You-Buy"

Implement the ACM ASIACCS 2026 protocol so that buyers can evaluate the utility of a data asset within 15 minutes, without seeing any data.

x402 + USDC payments

Replace the Datatoken ERC20 with HTTP 402 payments in USDC to allow for microtransactions in fractions of a cent while removing exposure to crypto price swings.

SMPC federated learning

Implement multi-party computation protocols to allow multiple data providers to jointly train a machine learning model on their aggregated data, without sharing any individual dataset with the other providers.