Why Trust OutLayer?

OutLayer runs your code inside Intel TDX confidential VMs where even the operator cannot access your secrets or tamper with execution. Here's how to verify this yourself.

Trust Architecture#

OutLayer's security rests on three independently verifiable pillars:

1. Hardware (Intel TDX)

Confidential VMs with hardware-encrypted memory. Host OS cannot read worker memory.

2. Open Source Code

All worker code is public on GitHub with Sigstore-certified release binaries.

3. On-Chain Verification

NEAR smart contract verifies TDX quotes and stores approved measurements on-chain.

Phala Trust Center#

OutLayer workers run on Phala Cloud, which provides a Trust Center for verifying deployed applications.

How to verify: Visit the Phala Trust Center for the OutLayer apps. The page shows the exact Docker image hash running in the TEE. This hash corresponds to a specific GitHub release.

Worker: dc3959bdba3f3681415a3022590cf434bb599a01
Keystore: 5319e38108c14ed325d1a22e8815527320aa3407

App IDs change when workers are upgraded to a new version.

What the Image Hash Proves#

The Docker image hash shown in Phala Trust Center is a content-addressable identifier. It proves that the exact binary code running inside the TEE matches a specific build. You can verify this by:

Checking the image hash on Phala Trust Center
Finding the corresponding GitHub release with the same hash
Verifying the release has Sigstore certification (see below)
Inspecting the source code at that release tag

GitHub Releases & Sigstore#

OutLayer publishes releases on GitHub with Sigstore certification. Sigstore provides cryptographic proof that a binary was built from specific source code.

What Sigstore proves: The release binary was built by GitHub Actions CI from the exact source code at that git tag. No one — not even the project maintainers — can substitute a different binary without the Sigstore signature failing.

How to Verify a Release#

Go to github.com/fastnear/near-outlayer/releases
Find the release matching the version/hash from Phala Trust Center
Check the Sigstore certification badge on the release
Review the source code at that release tag
Optionally: rebuild from source and compare the hash

5-Measurement TDX Verification#

Intel TDX produces 5 cryptographic measurements that together uniquely identify the TEE environment. The operator contract (worker.outlayer.near) verifies all 5:

Measurement	What It Measures	Size
MRTD	TD (Trust Domain) measurement — code + configuration	48 bytes (96 hex chars)
RTMR0	Firmware measurement	48 bytes (96 hex chars)
RTMR1	OS/kernel measurement	48 bytes (96 hex chars)
RTMR2	Application measurement	48 bytes (96 hex chars)
RTMR3	Runtime measurement	48 bytes (96 hex chars)

Why all 5 matter: Checking only RTMR3 (as some systems do) is not sufficient. A development dstack image with SSH access enabled would have a different MRTD/RTMR0/RTMR1 but could share the same RTMR3. By checking all 5 measurements, OutLayer ensures the entire environment — from firmware to application — matches the approved configuration.

Check Approved Measurements On-Chain#

# View all approved measurement sets
near view worker.outlayer.near get_approved_measurements

# Check if specific measurements are approved
near view worker.outlayer.near is_measurements_approved '{
  "measurements": {
    "mrtd": "abc123...",
    "rtmr0": "def456...",
    "rtmr1": "ghi789...",
    "rtmr2": "jkl012...",
    "rtmr3": "mno345..."
  }
}'

Worker Registration Flow#

Every worker must prove its TEE identity before it can execute code or access secrets:

1
Generate Keypair in TEE
Worker generates an ed25519 keypair inside the TDX confidential VM. The private key never leaves TEE memory.
2
Generate TDX Quote
TDX hardware produces a cryptographic quote with the worker's public key in report_dataand all 5 measurements. The quote is signed by Intel.
3
On-Chain Verification
Worker calls register_worker_key() on the operator contract (worker.outlayer.near). The contract verifies the Intel signature, extracts all 5 measurements, checks them against the approved list, and confirms the public key matches report_data.
4
Scoped Access Key
The contract adds the worker's public key as an access key scoped to specific methods only: resolve_execution, submit_execution_output_and_resolve, resume_topup, resume_delete_payment_key.

Ephemeral Worker Keys & Blockchain Trail#

Worker signing keys are ephemeral — they are generated fresh inside the TEE on every restart and never saved to disk or exported. When a worker restarts, it generates a completely new keypair and re-registers on the blockchain.

Why this matters: Every worker registration leaves a permanent trail on the blockchain. The operator cannot secretly spin up a worker, request a key, or access secrets without it being visible on-chain. If an admin tried to run unauthorized code, it would fail the 5-measurement check during registration — and even if they used legitimate code, the registration transaction would be publicly visible.

Additionally, every worker's WASM code is tracked through GitHub — you can verify exactly which code a worker executed by checking the source repository and commit hash. This means even a backdoor cannot be introduced without leaving a visible trace in the git history.

Deterministic Keystore Secrets (CKD)#

The keystore worker uses Confidential Key Derivation (CKD) via NEAR's MPC network to derive a deterministic master secret. This means that when the keystore restarts or upgrades, it recovers the same master secret — all previously encrypted secrets remain accessible.

1
TEE Startup
Keystore generates a new ephemeral keypair in TEE memory and submits TDX attestation to the DAO contract.
2
DAO Approval
DAO members (dao.outlayer.near) vote to approve the keystore's public key, confirming its TEE attestation.
3
MPC Key Derivation
After approval, keystore requests its master secret from the NEAR MPC network using BLS12-381 key exchange. The derived secret is deterministic — same DAO account + same derivation path always produces the same secret.
4
Secret Recovery
The master secret exists only in TEE memory (never persisted to disk). All per-project keys are derived from it using HMAC-SHA256. On restart, the same master secret is re-derived, so all secrets are automatically recoverable.

What the Operator Cannot Do#

Even if the operator is malicious or compromised, Intel TDX hardware prevents:

Action	Protection
Extract decrypted secrets	TEE memory encryption — host OS cannot read worker memory
Modify execution results	Results signed with TEE-generated key registered on-chain
Run different code	All 5 TDX measurements must match approved set
Forge attestation reports	TDX quotes signed by Intel's private key (hardware-embedded)
Register unauthorized worker	Operator contract verifies TDX quote before adding access key; every registration is visible on-chain

What the operator CAN do: Refuse to execute code (censorship) or shut down infrastructure (availability). These are mitigated by the ability to run multiple independent operators — workers are stateless and can be redeployed anywhere.

OutLayer Documentation