Trust Architecture#

OutLayer's security rests on three independently verifiable pillars:

Whatever hardware a worker runs on, these three pillars hold. The next two sections show that the cryptographic guarantee is the same across both deployment methods, and how to verify any individual execution yourself.

Two Ways Workers Run#

OutLayer workers are deployed in two ways. Both are genuine Intel TDX — they differ only in who hosts the hardware and which portal renders the human-readable attestation.

In both cases the worker runs in an Intel TDX confidential VM via dstack and emits a TDX quote that binds the worker's public key in report_data (the raw key for ed25519, or its SHA-256 for post-quantum ml-dsa-65) plus all 5 measurements. Both register on the same on-chain register-contract (worker.outlayer.near on mainnet, worker.outlayer.testnet on testnet), which verifies the Intel TDX quote signature (Intel DCAP) and checks the 5 measurements against an admin allowlist.

Verifying Each Deployment#

Side by side, the two deployment methods are cryptographically identical. Only the last two rows differ.

Verify Any Execution#

Beyond verifying that a worker is genuine, you can verify any individual execution — for both NEAR blockchain and HTTPS calls — directly from the dashboard.

What the Report Shows#

The report includes a "Verify Quote (RTMR3 + Task Hash)" button. Client-side, it extracts RTMR3 (the worker measurement) and the Task Hash from REPORTDATA and checks them. The Task Hash commits to this execution's input, output, WASM, and commit — so the Intel-signed quote cannot be reused for a different run.

For NEAR jobs, a Direct Link opens a shareable standalone page at /attestation/{jobId}.

5-Measurement TDX Verification#

Intel TDX produces 5 cryptographic measurements that together uniquely identify the TEE environment. The register-contract (worker.outlayer.near) verifies all 5 at worker registration, for both deployment methods:

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..."
  }
}'

GitHub Releases & Sigstore#

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

How to Verify a Release#

1. Go to github.com/fastnear/near-outlayer/releases
2. Find the release matching the version running in the TEE
3. Check the Sigstore certification badge on the release
4. Review the source code at that release tag
5. Optionally: rebuild from source and compare the hash

Worker Registration Flow#

Every worker — self-hosted or on Phala Cloud — must prove its TEE identity before it can execute code or access secrets:

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.

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.

What the Operator Cannot Do#

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