Contents
How Sirius works
Sirius is a protocol for confidential data lending on an EVM chain. The provider offers a dataset for model training; the borrower receives the model, not the source CSV. Settlement is denominated in USDC and verifiable on-chain.
Demo and confidentiality
In stub mode (TEE_MODE=stub), there is no hardware enclave: the process running the runner accesses the plaintext CSV and keys. Without RUNNER_URL, this is the Next server process. Use only synthetic or non-sensitive data.
The isolation guarantees described here require a remote Phala runner, verified RA-TLS attestation, and pinned measurements. Vercel’s Production label does not prove this attestation.
The problem
The most valuable data is often the most restricted: health, finance, personal data, or trade secrets. It cannot be shared in plaintext without losing control.
Sirius reverses the flow: the model comes to the data, with hardware isolation of computation when the runner uses an attested TEE. The provider keeps their source data.
The solution at a glance
The browser encrypts the dataset before sending it to the runner. The runner stores the encrypted dataset on IPFS, trains the model, and prepares encrypted delivery. EVM settlement publishes the preimage needed to open the capsule.
After upload, the runner decrypts the CSV to compute. Only attested Phala mode provides hardware isolation for this computation; stub mode does not.
Actors & artifacts
- Provider — publishes an encrypted dataset and receives settlement.
- Borrower — chooses a dataset, funds the loan, and receives the model.
- Runner — opens the dataset, computes, and holds the preimage; hardware attestation depends on the deployment mode.
- Sirius — orchestrates the flow. With a remote attested runner, Next receives neither plaintext CSV nor dataset keys; local stub mode does not provide this guarantee.
- Encrypted dataset — AES-256-GCM blob on IPFS.
- Dataset title — CID hash, Merkle root, size, and training-profile hash registered in `SiriusDatasetRegistry`.
- KYB attestation — EIP-712 credential consented to by the wallet, issued by an external verifier, and required by both the registry and escrow.
- Model capsule — delivery key encrypted for the browser and tied to the preimage.
Dataset training profile
The profile is required at upload: it fixes the algorithm and version. The borrower cannot replace this choice with a different model. The on-chain title, loan, and runner receipt are bound to the same profile hash.
Linear regression
linear_regression · v1.0.0
Continuous numeric target. Metrics: R², RMSE, and MAE.
Binary logistic regression
logistic_regression · v1.0.0
Target strictly encoded as 0 and 1, with both classes present. Metrics: accuracy, precision, recall, and F1.
The CSV must have unique headers. Its last numeric column is the target; other numeric columns are features, up to 31. At least 100 rows and 10 rows per parameter, including the bias, are required.
An incompatible profile is rejected before USDC is locked. To change the profile, upload the dataset again. Self-training on your own data also respects this profile, without a USDC loan.
Delivered model metrics are calculated on the training data. Then evaluate a separate test CSV in the browser: a high training score does not prove performance on new data.
The complete flow
- 01Upload
The provider selects the training profile, then the browser encrypts the CSV for the runner. The runner validates compatibility, computes the Merkle root, and stores the encrypted blob on IPFS.
- 02Publish
The provider registers the title and profile hash in the EVM registry, subject to KYB. The encrypted CSV stays off-chain; the published title fixes the allowed profile.
- 03Lock
The borrower uses the dataset’s fixed profile, approves USDC, and signs lock. Escrow checks the title, profile, and KYB, then fixes the amount, hashlock, and expiry.
- 04Train
The runner cross-checks KYB, title, profile, and escrow terms before decrypting and training. Hardware isolation requires attested Phala mode.
- 05Settle
Once the capsule is ready, the runner calls release: the provider is credited and the preimage is published. The browser can then open the model. USDC credit is withdrawn separately.
Implementation status
SHA-256 hashlock, exact USDC transfers, KYB for both parties, refunds, and pull-only withdrawals.
EIP-712 attestations, expiry, durable revocation, and wallet consent; the issuer is external.
Escrow binds the loan to the title and profile; the runner cross-checks these with KYB and loan terms before decryption.
This distinction is deliberate: the documentation describes deployable code behavior, not just the product target.
Atomic fair exchange
The TEE runner controls release, not either counterparty. The borrower first holds an unusable capsule; its opening preimage is published only when the provider is credited.
`release` is allowed only before expiry. After that, only `refund` can credit the borrower: the escrow can no longer publish a preimage.
| Scenario | Outcome |
|---|---|
| Successful computation | One transaction credits the provider and publishes the preimage. The browser then decrypts the capsule off-chain. |
| Invalid or unsuccessful job | No preimage is revealed; the borrower recovers the funds after expiry. |
| Attempt to obtain the model without paying | Impossible: the capsule requires the preimage published at settlement. |
| Subjective quality dispute | Not resolved by escrow alone; arbitration is a future extension. |
Escrow lifecycle
The borrower signs the lock from their wallet. A created loan is Locked, then Released or Refunded: release and refund are mutually exclusive. Application statuses such as TRAINING are not contract states.
Credits are withdrawn separately with `withdraw` or `withdrawFor`. A provider wallet that rejects a transfer cannot block the loan transition.
| Call | Who can call it | Verifiable effect |
|---|---|---|
| lock | The borrower | Creates a USDC loan bound to the title and training profile, fixing the provider, amount, hashlock, and 1-to-30-day expiry; both KYB attestations must be valid. |
| release | Any address knowing the preimage, before expiry | Reveals the preimage and credits the provider, without an external transfer in this transaction. |
| refund | Any address, after expiry | Credits only the borrower; this call permanently closes the release window. |
| withdrawFor | Any address | Transfers the credit only to the designated account, with reentrancy protection. |
Confidentiality: who sees what
This table describes remote attested Phala mode, without participants voluntarily sharing artifacts. It does not apply to local stub mode, where the server has access to raw data and keys. The public preimage alone cannot open the capsule without the recipient browser’s key.
| Artifact | Provider | Borrower | Sirius | TEE |
|---|---|---|---|---|
| Raw data | yes (their own) | no | no | yes, in the enclave |
| Encrypted dataset | yes | yes | yes | yes |
| Dataset key (DEK) | no | no | no | yes |
| Preimage before release | no | no | no | yes |
| Preimage published on release | yes | yes | yes | yes |
| EVM title and events | yes | yes | yes | yes |
| Decrypted model | no | yes | no | yes, during the job |
Custody: who holds what
- Funds remain in the wallet or `SiriusEscrow`; Sirius cannot move them at its discretion.
- The dataset title remains bound to the provider. The CID hash, Merkle root, size, and training-profile hash are public.
- Keys for datasets remain in the runner; the master key is sealed by dstack in attested Phala mode. In local stub mode, the server process accesses the keys. The preimage becomes public on release.
- Deletion destroys the dataset key and leaves a verifiable tombstone without making the content recoverable.
EVM contracts
No admin, upgrade, or fees. Exact USDC, SHA-256 hashlock, KYB for both parties, strict expiry, and pull-only credits.
EIP-712 attestations with consent, anti-replay nonce, expiry, revocation, and verifier epoch. The admin manages verifiers.
Deterministic title, KYB checks, CID hash, Merkle root, size, immutable training profile, and tombstone after deletion.
The training profile uses SiriusEscrow v5 and SiriusDatasetRegistry v4. Changing contracts requires a coordinated migration of the application, database, and services; this page does not attest to any instance’s configuration.
Security guarantees & limits
What the chain guarantees
- A loan transitions only once from `Locked` to `Released` or `Refunded`.
- The provider cannot be credited without the preimage becoming public, and vice versa.
- Withdrawal cannot alter a loan or redirect a credit to another address.
- The registry treats a destroyed title as inactive and a KYB attestation as invalid after expiry, revocation, or verifier removal.
What remains outside the contracts
- Dataset quality and legality, and model quality, remain outside the scope of the contracts.
- The CID hash, Merkle root, size, and loan identifiers are public and permanent: they must not contain sensitive data.
- The KYB issuer, its signing key, and registry administration are governance points to protect outside Next and the runner.
- A testnet demo is not an independent audit, Phala attestation validation, or approval to use sensitive data or real funds.
An open demo KYB registry accepts every address: it does not verify businesses. A governed registry requires attestations from an external issuer.