How it works

The subnet is a TEE-required media-serving network. EveryFrame's coordinator assigns jobs; approved workers inside Intel TDX confidential VMs generate them through a fixed provider endpoint; a hardware-attested key signs a receipt over the input, the job, the provider request and the output bytes. The coordinator verifies the receipt, decodes the output in a sandbox and only then records accepted work.

The signed catalogue reviewed 31 October 2026 contains 100 contracts, 59 priced across 9 providers. Availability also requires compatible worker permissions, fresh attestation, provider access, capacity and current offers. A catalogue listing is not a paid test of every route. See Models & reward targets.

#The trust boundary

EveryFrame coordinator (trusted)
    │  signed + encrypted immutable assignment
    ▼
Approved measured worker inside Phala TDX
    │  fixed provider endpoint, authenticated HTTPS
    ▼
Authorized provider API → returned media
    │  bytes downloaded and hashed INSIDE the TEE
    ▼
Attested-key signature over input ↔ job ↔ request ↔ output hash
    │
    ▼
Coordinator verifies receipt + media bytes → sandbox decode → durable acceptance

#What the TEE proves

• That the approved worker image — digest-pinned, no shell, no HTTP server, no debugger, no generic signing endpoint — is what ran.
• That the quote is UpToDate, has no advisories and is not a debug build. MRTD and RTMR0–2 are pinned; the hardware configuration binds the compose, and RTMR3 is replayed event by event with payload-to-digest verification in an exact expected order. Public admission pins the approved KMS CA identity while allowing its boot-varying runtime probe; it does not trust a new identity on first use.
• That the receipt was signed by a key generated inside that worker session. Keys are never exported or persisted; a restart means a fresh attested session.

#What it does not prove

• The provider's internal model execution or the cinematic quality of the clip. The provider and its authenticated result store remain trusted.
• Resistance to every hardware vulnerability.
• Availability. A miner can stop working, revoke its API key or withhold results. The coordinator handles that with deadlines and refund-required events, not with guesses.
• Protection against a compromised local credential store, malicious approved release or compromised KMS. The workstation, release review and Phala KMS remain trust assumptions; see key protection.

#A job's life

1. Assignment. The coordinator creates a job with a locked quote (miner reward target, provider cost estimate, customer planning price — three independent fields). The assignment is signed and encrypted to the worker's session key; only one job is active per miner.
2. Claim and start. The worker claims the job and asks for a provider-submission grant. The grant is returned exactly once. If the response is lost, the job becomes unknown rather than being resubmitted — the design sacrifices a possible delivery to avoid duplicate provider spend.
3. Render. The worker calls the contract's fixed provider endpoint with the exact signed fields. Studio contracts validate supported duration, resolution, aspect ratio and references; legacy contracts retain their fixed inputs. Arbitrary provider request bodies and model substitution are rejected.
4. Download inside the enclave. Media comes from an authorized provider result, or synchronous response bytes. Caller-selected output URLs and private-network destinations are rejected. Redirects are rejected except for the bounded Google media exception described below. Bytes are hashed inside the TEE.
5. Receipt. The signed completion receipt binds job, attempt, session, original input hash, the one-use grant, provider request ID, provider response hash and the actual output bytes/hash.
6. Acceptance. The coordinator verifies everything, then validates media in a no-network bubblewrap sandbox with CPU, address-space, time and output limits. There is no unsandboxed fallback. Media bytes, receipt, metadata, payable and fulfilment event are committed together. Studio may subsequently remux video or resize images for delivery; the receipt covers the accepted worker output, not those later derivatives.
7. Review and reward. Accepted work is review-held. Only operator-approved, reward-eligible, organic work counts toward the sealed epoch that sets weights. See Rewards & emissions.

#Deadlines and failure

• Each assignment has a contract-specific deadline; duration-capable routes account for the requested generation settings. A deadline is not the requested clip length or a latency guarantee. A timeout emits a single refund-required event; late outputs cannot reopen a refunded job. This does not reverse the provider's charge to the miner.
• A starting job with no durable provider ID becomes unknown on restart. An asynchronous job with a durable provider ID can resume polling, bound to its original provider/model and deadline. Paid submissions are never blindly retried.
• The candidate ElevenLabs path returns synchronous bytes, not a recoverable provider-history job. A restart before acceptance loses that in-memory output; it times out/refunds rather than submitting another paid generation.
• Repeated acceptance of the same result returns the existing record without another payable.

#Video, image and audio validation

All media paths preserve the signed-contract and receipt checks. Studio image and audio routes have priced contracts; some separate legacy adapters remain unpriced. The coordinator uses no-network sandbox decoding with contract-specific checks for dimensions, codecs, sample rate and duration. Output type is determined by the signed contract, not trusted from the miner.

Output URLs must come from the authorized provider result; user-selected URLs and private-network destinations are rejected. Downloads carry no provider authentication headers. The sole redirect exception is Google media GETs, with at most two hops to a narrow Google allowlist and headers stripped at every hop. Paid POSTs never follow redirects.