Make sign and broadcast capabilities truly separate

[SuperstrongBE]

Summary\n\nSeparate transaction signing from transaction broadcasting at the API, authorization, configuration, and implementation layers.\n\n## Security impact\n\nA caller authorized only to obtain a signature must not be able to trigger network submission as a side effect. Conversely, a broadcast capability must not gain access to private-key operations. A shared path makes least-privilege deployment and incident containment unreliable.\n\n## Required changes\n\n- Make sign-only return a signed transaction without sending it to any RPC endpoint.\n- Require a distinct, explicit broadcast operation for network submission.\n- Use separate capability checks and audit events for signing and broadcasting.\n- Ensure configuration flags cannot silently convert sign-only into sign-and-broadcast.\n- Keep retry, duplicate transaction, and ambiguous RPC response handling inside the broadcast boundary.\n- Document ownership of TAPOS generation, serialization, signing, submission, and confirmation.\n- Consider allowing deployments to disable broadcast support entirely.\n\n## Acceptance criteria\n\n- A sign-only request performs no broadcast-related network call.\n- Broadcast authorization cannot invoke the private-key signer.\n- Sign and broadcast permissions can be granted and revoked independently.\n- Tests assert network-call boundaries, retries, duplicate submissions, RPC timeouts, and ambiguous success responses.\n- Audit logs distinguish signed, broadcast, accepted, rejected, and unknown outcomes.\n- API documentation makes side effects explicit.

[SuperstrongBE]

Cross-references

• Chain modules: registry + per-chain boundary (multi-chain foundation) #44 (chain modules): the structural seam already exists (TransactionSigner vs optional TransactionBroadcaster in DaemonDependencies — a deployment can omit the broadcaster entirely). This issue hardens it at the capability/config/audit level; the "distinct, explicit broadcast operation" should be specified in the daemon protocol + ChainModule contract so every chain inherits the separation.

Fundamentals check: no conflict — this IS INV-011 (sign/broadcast separation), promoted from structure to enforced capability. One implementation note: today broadcast is a broadcast: true flag on the sign request (runDecision signs then broadcasts in one pass). Moving to a distinct operation is a protocol change — it must be versioned/explicit, not a silent behavior change for existing callers (which is exactly what this issue's "configuration flags cannot silently convert sign-only into sign-and-broadcast" demands, applied to the migration itself).

🤖 Generated with Claude Code