watchtower: no autonomous claim is reachable on ANY chain — track the three gates that would arm it

[Zyrtnin]

src/pyrxd/gravity/watch/README.md states it plainly:

NOT REACHABLE FROM ANY ENTRYPOINT — there is no way to arm it today. watchtower_run.py builds only the RefundExecutor; no --arm-claim / --claim-rxd-wallet flag exists anywhere in the repo (this README previously documented both, which was wrong).

This is a deliberate deferral, not an oversight, and the mechanism itself is built, tested and correct — typed discriminator, dormancy, value-vs-reorg cap, low_corroboration hard-stop, and a fresh assess_claim_finality SAFE re-assert plus covenant-still-unspent check immediately before broadcasting.

Why this needs an issue rather than a README paragraph

Arming is gated on three preconditions that today live only in prose:

1. an independent ≥2-source RXD quorum deployment (not just the code path — the actual endpoints)
2. a dust proof (P3)
3. the external audit (P4)

A precondition recorded only in a README is a claim that can decay, and this repo has now produced three instances of exactly that in one review: is_debug documented as wired while the code read the global directly; a coverage exemption whose stated rationale had become false; and this README, which previously documented both executors as wired when neither claim held.

Scope note that matters for the release story

decide() sets autonomous_asset_claim only on the BTC↔RXD SAFE branch, never on ETH. But since nothing can arm the executor on either chain, the accurate statement today is "there is no autonomous claim on any chain" — the BTC/ETH split gates a path nothing reaches. Worth stating that way in release notes, because "the watchtower will catch it" reads stronger than what ships.

Current exposure

Alert-only. On a two-party ERC-20 swap: the maker claims the counter leg, p becomes public, and the taker must claim the RXD covenant before the maker's CSV refund matures. A human has to act inside t_rxd. That is a legitimate design — but a two-party run conducted this way proves the protocol, not the unattended safety story, and the distinction should be explicit in whatever that run reports.

What would close this

Either arm it behind an explicit flag once the three gates are met, or record a decision that it stays dormant and adjust the docs that lean on it. ETH parity looks structurally cheap if it is armed at all — the RXD covenant spend is identical, and _taker_claim_eth_from_vulnerable already scrapes p from an ETH claim tx.

[Zyrtnin]

Tracker audit — still OPEN and accurate, with two corrections to where the reader should look. Verified against origin/main (558e49e).

Still true

No --arm-claim / --claim-rxd-wallet flag exists anywhere in the tree. The runner builds a RefundExecutor and only that (src/pyrxd/gravity/watch/run.py:163); ClaimExecutor appears in watch/__init__.py, claim_executor.py, decide.py and adapters.py, and in no runner. There is still no way to arm an autonomous claim on any chain.

Correction 1 — the file this issue points at is now a shim

The body cites watchtower_run.py. scripts/watchtower_run.py is now a 29-line back-compat shim; the runner ships in the package as src/pyrxd/gravity/watch/run.py (console script pyrxd-watchtower). The finding is unchanged — that is where to check it.

Correction 2 — gate 1's status is now split

Precondition 1 was written as one thing. It is now two, and only the first has moved:

• code path — MultiSourceRxdChainSource is wired, --rxd-quorum defaults to 2, and the runner refuses to start with fewer independent sources than the quorum (run.py:266-272). rxd_corroborated is True only behind a real quorum.
• deployment — the actual independent endpoints. Not assertable from this repo, so it stays a gate.

Preconditions 2 (dust proof) and 3 (external audit) are unchanged. 3 alone keeps this closed for real value, so nothing here is actionable yet.

Cross-reference

#520 is the other half of the same gap for the two-party run: this issue is "no unattended actor can recover", #520 is "the harness cannot even drive an attended recovery". A run that evidences the safety argument needs both.

[Zyrtnin]

Decision: ARM it, behind an explicit flag. (Maintainer, 2026-09-01.)

Taking the first of the two closing options this issue names. One qualification, stated here so it is on the record rather than discovered later.

This issue gates arming on three preconditions, and gate 3 (external audit) is not met. So --arm-claim will be built and reachable, and it will refuse unless the operator explicitly acknowledges that the swap stack is UNAUDITED — the flag makes the capability exist and makes the operator state what they are accepting. It will not be on by default, and nothing about this changes the audit gate for real value.

That is the honest reading of "arm it behind an explicit flag": the mechanism stops being unreachable, without the release quietly acquiring an autonomous fund-moving path on an unaudited stack.

Gate 1 has split per the audit above — the ≥2-source RXD quorum code path is wired and defaults to 2; the deployment is still the operator's. The flag will surface that too rather than assume it.

If the intent was to arm it without the acknowledgement gate, say so and I will drop it.

[Zyrtnin]

Confirmed (maintainer, 2026-09-01): the acknowledgement gate stays. Not arming without it until there is more testing behind it.

So --arm-claim will be built, reachable, and will refuse unless the operator explicitly acknowledges the swap stack is UNAUDITED. Off by default.