No wallet identity has been requested.
Release activation.
A checked release is the evidence bundle the release pipeline produces to prove exactly which code a deployment runs. You drop that bundle's files below; the console checks them against the Registry and the code actually loaded on chain, and builds the activation packets only when every identity agrees. Every file and every chain answer is treated as hostile until it proves itself.
The chain, the Registry, and who pays
Everything below is checked against this chain. The console never reads a wallet on its own; the payer is a public key whose signature stays outside this page.
Sign the walk with a browser wallet
Connecting reads identity only. Signing opens for exactly one reason: the activation plan built in step 02 went green against this chain, and the connected wallet is the fee payer that plan declares. Each role is a separate explicit wallet request, and submission stays outside this page.
No Wallet Standard registry exists in this runtime. Browser wallet discovery is unavailable here.
Connecting reads a public address only. Requesting a signature is always a separate explicit action, and stays unavailable wherever a checked release does not recognize the outer.
Only wallets that register through the Wallet Standard are listed. A wallet that exposes nothing but a legacy injected page provider is not discoverable here and is not silently probed for.
No activation plan is green against this chain. Signing stays closed. It opens only when one activation plan is green against this chain and the connected wallet is exactly that plan’s declared fee payer.
No activation plan has gone green against this chain, so there is nothing a signature could mean here. Build one in step 02 first.
There is no submit path here, signed or unsigned. A signed packet leaves this application as bytes for an external submitter, and the finalized blockhash it was compiled against will expire.