Rent out valuable data without ever exposing it
A data owner has two bad options today: keep the data and earn nothing, or sell it and lose control forever. Sirius opens a third one — rent it. The encrypted dataset never leaves the owner's control. The borrower submits a training job that runs inside a hardware enclave and gets back only the trained model. Settlement and audit happen on Robinhood Chain.
What makes it work
The most useful data is the data nobody shares
Health records, transaction histories, industrial telemetry — the datasets with the highest value are the ones under the tightest legal and commercial constraints. They are never shared in the clear, so they stay idle.
Why the existing answers fail
| Approach | Why it breaks |
|---|---|
| Sell the dataset | Control is lost at the first download. Data copies perfectly and forever. |
| Contracts and NDAs | Legal recourse after the fact, not technical prevention. You find out once the damage is done. |
| Watermarking | A perturbation small enough to preserve utility is small enough to be stripped or lost in noise. |
| A trusted intermediary | Recreates exactly the risk you were trying to remove, and adds a rent. |
Sirius inverts the problem: the data does not travel to the model, the model travels to the data — inside an enclave where nobody, Sirius included, can read it.
Five steps, from upload to settlement
A full cycle: the provider publishes a dataset, a borrower locks funds and submits a job, the enclave trains and produces proof, and one transaction closes the trade.
Who can read what
| Artifact | Provider | Borrower | Sirius | Enclave |
|---|---|---|---|---|
| Raw data | yes (their own) | no | no | yes |
| Encrypted blob on IPFS | yes | yes | yes | yes |
| Decryption key | no | no | no | yes |
| Public metrics and sample | yes | yes | yes | yes |
| Trained model | no | yes, after payment | no | yes |
| Escrow fulfillment | no | only once published on-chain | no | yes |
Payment and delivery become one event
This is the core of the protocol. A time-based escrow only protects the buyer. Here the release is controlled by neither party — the secret that unlocks the model is held by the enclave and revealed only by the transaction that pays.
The double lock
After a successful job, the runner encrypts the model key under two factors that must both be present. The first is a private key generated in the borrower's browser, non-exportable and never transmitted — so nobody else can ever open the capsule. The second is the escrow fulfillment, which exists only inside the enclave. The borrower receives and stores this capsule before any payment. It is useless until the fulfillment is published, and the only thing that publishes it is the EscrowFinish transaction that pays the provider.
Every outcome
| Scenario | Result |
|---|---|
| Everything works | One transaction pays the provider and unlocks the capsule the borrower already holds. |
| Dataset is unusable | The job fails, no fulfillment is ever produced, CancelAfter refunds the borrower. |
| Borrower tries to get the model without paying | Impossible. The capsule needs a secret that only the payment transaction publishes. |
| Sirius is compromised | The fulfillment and the master key live in the enclave. A compromised server can stall the trade, not steal from it. |
| Dispute over data quality | Not resolved by escrow alone. Challenge period and arbitration are on the roadmap. |
Settlement where the assets are
Robinhood Chain is an Arbitrum Orbit L2 that settles on Ethereum, live on mainnet since 1 July 2026, with a public permissionless testnet open since February. Gas is paid in ETH, contract deployment needs no allowlist and no KYC, and the chain exists to carry tokenised real-world assets — which is the market Sirius sells into.
What the chain gives us
What we accept in exchange
Stating this plainly is more useful than a case that only favours us.
Three contracts, deployed and verified
Three contracts carry the protocol on-chain. Each is deliberately small, has no administrator on the settlement path, and has its source verified on the explorer — so it can be audited without asking us.
| Contract | Role | What it does |
|---|---|---|
| SiriusEscrow | Settlement | SHA-256 hashlock escrow. Publishing the preimage and entitling the provider happen in one transaction that makes no external call at all. |
| SiriusKybRegistry | Identity | Per-entity KYB with explicit subject consent, revocation, expiry and multiple verifiers. |
| SiriusDatasetRegistry | Provenance | Non-transferable dataset title with a deterministic identifier, and a tombstone rather than deletion after crypto-shredding. |
Live on testnet, chain 46630
SiriusEscrow · 0xf2f8f5ba5c16c780179af0da2f250deceaf0064fSiriusKybRegistry · 0xc88346fc152c1a2de065bd9a29c18321db8abb01SiriusDatasetRegistry · 0x7d9efc6abdbb6d898aea4ce775ca95b483dffdb8
Source code is verified on Blockscout for all three. Total deployment cost was 3,497,006 gas. A full escrow cycle — lock, release, payout — costs roughly 0.000005 ETH and has been executed against these contracts on the live chain.
The gap in on-chain compliance
Robinhood Chain applies compliance controls at the network layer, and they work. They are also unavailable to the applications running on it — which is where a registry belongs, and where we happen to have built one. This section states exactly what we checked, and where our claim stops.
What exists, and what does not
Transactions from sanctioned addresses are filtered at the sequencer, and an analytics partner provides monitoring on top. Those controls are part of why the chain is credible for regulated assets.
They are also opaque to applications. A contract cannot query them. A dApp has no way to ask, on-chain, whether the counterparty it is about to serve is a verified business, and therefore no way to build its own logic on top.
We checked for the standard building block: EAS, the ecosystem's attestation layer, is not deployed at its canonical addresses, and the chain's documented protocol contracts include no identity or registry contract of any kind.
This produces a real tension on a chain built for regulated finance: anyone can deploy a contract without any KYC whatsoever, while the assets being tokenised are securities.
Why ours generalises
SiriusKybRegistry was written for our own gating requirement. It attests that an address belongs to a verified business, requires the subject's explicit consent, supports revocation and expiry, and allows several independent verifiers under a two-step admin.
Nothing about it is specific to data lending. Any application on the chain could read isKybValid(address) and gate on the result.
Network-level filtering and off-chain monitoring do exist, and we are not disputing them. What is missing is more specific: none of it is callable from a contract, which is what an application needs in order to gate its own logic.
Nor is this an argument for identity at the protocol level. Permissionless deployment is what draws builders to a chain, and a registry that everyone must pass through would remove it. Ours is opt-in: a contract other applications may call when their own counterparties require it, and ignore entirely when they do not. If a composable registry already exists or is planned, we would rather build on it than beside it.
Four layers, one trust boundary
The browser, the application server and the database are all treated as untrusted. Only the runner inside the confidential VM sits within the trust boundary, and it is deliberately small.
A working application, screen by screen
Not a mockup. The full path — deposit data, tokenize it, borrow it, train in the enclave, retrieve the model — is navigable end to end today.
Sirius
Your data, put to work without ever exposing it.
| age | stay_days | readmit | score |
|---|---|---|---|
| 67 | 4 | 0 | 0.82 |
| 54 | 9 | 1 | 0.41 |
| 73 | 2 | 0 | 0.95 |
The design stance
Technical depth is optional. A Simple/Advanced toggle hides transaction hashes, CIDs and Merkle roots by default, and appears only where it changes something. First-time visitors are detected by reading the ledger rather than writing to a database. Sign-in offers a Google login backed by MPC key shares before it offers an external wallet — the target user is a data owner in a hospital or a bank, not a crypto native.
What runs, and what does not yet
The settlement layer is deployed and exercised on-chain. The application is not yet wired to it, and the enclave has never run on real hardware. Those two gaps matter more than anything else in this document, so they are stated before the rest.
On-chain
| Component | Status | Evidence |
|---|---|---|
| Escrow, KYB registry and dataset registry | Shipped | Deployed and source-verified on testnet 46630 · 49 contract tests |
| Fair-exchange cycle on the live chain | Shipped | Lock, release and payout executed against the deployed contracts |
| Confidential core adapted — chain-bound key derivation, versioned capsule | Code complete | 84 unit tests; not yet exercised end to end |
| Runner operations against the contracts | Code complete | Wired to the deployed addresses |
| Training inside the on-chain cycle | Not demonstrated | The validated cycle covers settlement only |
| Application wired to the contracts | Not started | Interface, database and orchestrators still target the previous rail |
Product
| Component | Status | Evidence |
|---|---|---|
| Provider pipeline — encrypt, IPFS, Merkle, dataset title, KYB | Shipped | Validated end to end on testnet |
| Marketplace and conditional escrow | Shipped | Validated end to end on testnet |
| Confidential training and atomic settlement | Shipped | Run, release and model decryption validated on testnet |
| Non-custodial embedded wallet, API authentication, fiat on-ramp | Shipped | Client-signed escrow, MPC key shares, no key export |
| Per-dataset keys, crypto-shredding, visibility controls | Shipped | Core validated; on-chain destroy still to confirm |
Enclave
| Component | Status | Evidence |
|---|---|---|
| Enclave-sealed master key and TDX attestation | Code complete | Validated against a real quote fixture and a local simulator only |
| Isolated confidential runner as an HTTP service | Code complete | Wired end to end; not yet deployed to a real CVM |
| Deployment to a real Phala CVM | Not started | The decisive milestone |
| Full code-identity verification | Not started | Requires a real CVM |
Current capability is deliberately narrow: deterministic linear regression on CSV, files up to 50 MB, synchronous jobs with a 60-second timeout, CPU only. Arbitrary borrower code and long training runs are post-MVP and will require an async job queue, sandboxing and differential privacy before they can be safe.
What comes next, and why it matters
Five phases. The first is not optional — until it lands, the central claim of the protocol is an assertion rather than a proof.
Two people, and a verifiable execution trail
Ali Ben Yezza on business and partnerships, Noé Wales on the protocol, out of the DeVinci Blockchain association. Small team, narrow scope, documented decisions.
The repository carries 27 dated architecture decisions, each with its rationale and the alternatives that were rejected. Every increment ends with a security review whose findings are written down and closed in the next one. Where the code is more honest than a pitch would be, the code wins: the rate limiter is commented in the source as friction rather than a hard bound, and this document says the same thing.