flare-fcc

Start from the fce-extension-scaffold repository, a runnable Hello World extension in Go with contracts, deploy tooling, and a types server. You modify the config constants, request/response types, action handlers, and the InstructionSender contract, then follow the pre-build, start-services, post-build, and test scripts to deploy on Coston2.

OPType selects an operation group and OPCommand sub-routes within it, and both must match exactly across the Solidity contract, Go config constants, and the extension router. They are bytes32 identifiers, so keep them under 31 bytes; mismatches fall through to unsupported op type or op command errors.

MODE=0 is the production attestation backend whose results Flare data providers accept on testnet and mainnet. MODE=1 produces simulated attestation for local development only and is rejected on live networks, so production images must bake MODE=0 with SIMULATED_TEE=false.

The attestation challenge issued during register-tee has expired before completion. Re-run post-build.sh and ensure register-tee uses the -command rRap flag, which issues a fresh attestation challenge on each run.

Yes, the fce-sign example ships in Go, Python, and TypeScript, selected via the LANGUAGE variable in .env. Python and TypeScript use a Framework class that registers handlers by opType and opCommand pair, though only the Go build is bit-for-bit reproducible across machines.

No, storing encrypted secrets on-chain is not safe for production because on-chain data is public and encryption weakens over time. The fce-sign repo demonstrates this pattern for demo purposes only; use off-chain channels for secret delivery in real applications.