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" button that runs the whole check in your browser, using Intel's DCAP quote-verification library compiled to WebAssembly:

• Authenticity — the quote's signature chain is verified to the Intel SGX Root CA against Intel-issued collateral, and the platform's TCB status is reported. Collateral is fetched for the platform and the moment the execution ran, so past executions are judged by the material that was current at the time.
• Identity — all five measurements (MRTD + RTMR0–3) are read from the verified quote and checked against the on-chain approved-build list via is_measurements_approved.
• Binding — the Task Hash inside the signed quote commits to this execution's input, output, WASM, commit, caller and payment, so an Intel-signed quote cannot be reused for a different run.

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

OutLayer Verify: Proof That Does Not Depend on Us#

Everything above runs on a page we serve. For an internal review that is the wrong shape of evidence: a vendor's own website asserting the vendor's own trustworthiness is a claim, not an artifact. outlayer-verify is the same three checks as a standalone open-source binary your engineers run on their own machines, so the result does not depend on anything we say, host or sign.

It reaches three places: our public API for the attestation record and the archived Intel collateral, public NEAR RPC for the on-chain approved-build list, and a NEAR archival node for on-chain payloads. Only the first is ours, and the collateral it serves is Intel-signed — altering it breaks the chain, so we cannot influence the verdict through it. Use --collateral to supply your own copy if you would rather not take even that.

Install and run#

cargo install --git https://github.com/out-layer/outlayer-verify outlayer-verify

# a live production execution: Ref Finance calling a price oracle on OutLayer.
# No account, no key, no payment — this works for anyone, right now.
outlayer-verify job 221092 --network mainnet

# an execution you triggered on chain: payloads recovered from the transaction
outlayer-verify tx <near-tx-hash>

# an HTTPS call you made, with the request and response you kept
outlayer-verify call <call-id> --input '{"city":"Paris"}' --output '{"temp":21}'

# or let the tool make the call and prove it in one step
outlayer-verify run owner.near/agent --input '{"city":"Paris"}' --payment-key "$KEY"

The default output shows its working rather than a verdict: the record as published, the measurements and both halves of report_data read out of the quote after the signature was checked, which collateral was used and whether its validity window really covers the execution, and — for every comparison — both values. Exit codes make it usable in a pipeline: 0 proven, 1 a check failed, 2 the proof could not be completed, and --json emits the same values for a control that needs machine evidence.

What a passing verdict does not mean#

Worth reading before it reaches a risk register, because the gaps are the part a technical reviewer will find on their own:

• It does not prove the approved build came from the published source. The attestation identifies which binary ran, not which source it was compiled from. Closing that gap needs a reproducible build and a published digest-to-commit map.
• It does not say who may approve a build. The tool reports which contract it asked. Who controls that account, and under what governance, is a question to put to us — and one you should put to us.
• HTTPS payloads are not recoverable. Only their hashes are stored, so if the caller did not keep the request and response, the bytes of that execution can never be checked again — by anyone, including us. Keep them, or make the call through run.
• Verification is as of the execution's own timestamp. Intel collateral is valid only inside a window, and Intel serves only the current one, so executions are judged against the archived material that was current when they ran. Where no archived window covers an execution, the tool reports it as unproven rather than quietly passing.

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: