I tried to analyze the HF with Claude. Some questions came up from that...

1. Oracle data source. The consensus evaluator is deterministic, but the input isn't — each witness polls "the SVM feed." Is every witness expected to run a full SVM node and validate independently, or is this polling a shared RPC endpoint? If it's a shared endpoint, the trust boundary hasn't been removed, just moved behind 21 signatures. What are the node requirements?

2. SVM-side reorg. The 22-block delay covers Steem-side finality. What covers the SVM side? If a burn tx is reorged out after witnesses have attested, svm.bank pays out against a burn that no longer exists. Is there a required confirmation depth on the SVM before an oracle should attest, and is it enforced or just convention in the daemon?

3. Signing key. Which key signs bridge_submit_operation — the block signing key, the active key, or a dedicated one? If the daemon needs an active key on a hot machine, that's a meaningful new attack surface for every witness in the top 21.

4. 17/21 liveness. That threshold means 5 non-participating witnesses halt the bridge. With the rotating timeshare slot, the scheduled set changes every round. If a witness attests and then drops out of the schedule before consensus is reached, does its attestation still count, or can the confirmation count decrease? And what's the realistic plan if fewer than 17 witnesses actually run the daemon at launch?

5. No correction path. One attestation per witness per (tx_hash, payload). If an oracle attests to a bad payload because of stale data or a bug, is that witness permanently excluded from that withdrawal? With only a 4-witness margin, two buggy oracles could brick a legitimate withdrawal.

6. Spam amplification. Every withdrawal costs up to 21 signed on-chain transactions. Is there a minimum withdrawal amount or fee? Otherwise micro-withdrawal spam on the SVM burns RC across all top witnesses at 21x.

7. svm.bank key nullification. Is this enforced in consensus code at hardfork activation, or is it an account whose authorities were manually set to a null key? If it's the latter, whoever holds the current keys can act before HF24 ships.

8. Inbound direction. This covers SVM → Steem only. Is the lock-and-mint side specified anywhere? Supply neutrality depends on both halves being equally rigorous.

I hope it will be useful for the project to answer these questions, also to generate more trust from other Steem users.