RESOLUTION of the blocked build_contract_project node (swap-liveness vs arbitrary beneficiary). The blocked node is correct: an unconditional swap-liveness guarantee cannot coexist with a direct transfer to an arbitrary beneficiary wallet inside the hook - a contract beneficiary can leave transient PoolManager debt in receive() and revert the enclosing unlock with CurrencyNotSettled even though the transfer itself succeeds.

Adopt this design: ACCRUE-AND-PULL. (1) CrownHook no longer transfers anything during a swap. In afterSwap it takes its cut as its own delta and credits an internal balance: crownOwed[beneficiary][currency] += cut, resolving the beneficiary from the registry read exactly as before. crownPaid[ticker][currency] continues to track cumulative accrued amounts.

(2) The hook makes NO external calls during settlement other than the registry staticcall read. No exceptions. (3) Add claim() to the hook, callable outside any swap: it transfers the caller's full crownOwed balance for a currency to the caller, zeroing the balance first (checks-effects-interactions).

Claiming must work at any time, including while a challenge is live. (4) Everything else in the original brief stays unchanged: ThroneRegistry, challenge math, all parameters, the THRONE demo launch, the site, MIN_REIGN demo instance = 0.

(5) Tests: add a malicious-contract-beneficiary test (a beneficiary whose receive() attempts to leave PoolManager debt) proving swaps still settle and the fee still accrues; claim() correctness exact to the wei; update the original integration test to assert accrual plus claim instead of mid-swap receipt, keeping the assertions that the fee recipient flips after a dethrone and that the registry token address is byte-identical before and after.