Skip to main content
Do not authorize a code hash from unverified JWT claims. Production proxy configuration must enable attestation, reject magic_pass, require secure boot and disabled-since-boot, and use independently verified code-hash and platform measurements.

​
Request a verifier-chosen challenge

After binding an auction TEE, request a fresh onchain challenge:
Preserve the printed transaction, action ID, challenge, selected TEE, proxy, and registered URL.

​
Verify the result

The verifier defaults to the official Coston2 RPC and FlareTeeManager diamond 0x1a9C4A0f9D76c0b1D91d22E24E573a9b377618aE. It rejects:
  • a non-114 RPC or manager address without code;
  • a non-HTTPS proxy URL;
  • disagreements with the attestation-request receipt;
  • unregistered or inactive TEE/proxy identities;
  • public-key, extension, URL, code-hash, or platform mismatches;
  • unsupported extension code-hash/platform pairs.
It then verifies the FCC TEE/proxy ActionResult domains and signatures, success context, pinned Google Confidential Space root, https://sts.google.com audience, onchain challenge, chain 114, key consistency, independent measurement allowlists, secure boot, disabled-since-boot, five-minute token age, machine-registration signature, and TEE timestamp. The verifier never prints the JWT.
The workflow does not supply certificate-revocation lists, so it does not claim revocation checking. Verification remains dependent on the pinned Google root, official verifier behavior, RPC and HTTPS transport, registry state, independently established measurements, and the build supply chain.
Do not copy the code hash or platform from an unverified response. Obtain them from a separately verified production build record and require agreement with both Confidential Space claims and Flare registry state.