Locked public properties vs server-side re-fetching for resource IDs in Livewire v3

Trade-off: client-held locked IDs versus server-side re-fetching

Livewire v3 components often need a stable resource identifier (for example, a post ID) to authorize mutations such as delete() or update(). Two documented patterns exist:

• Expose the ID as a public property marked #[Locked] so the client cannot tamper with it; Livewire's checksum validates integrity on each request.
• Keep the ID only in a protected property and re-fetch the model from the database (or cache) on every server-side request, discarding any client-supplied value.

The first approach avoids an extra query per request but relies on Livewire's tamper-resistance mechanism. The second adds a query but ensures the authoritative record is always loaded fresh, providing defense-in-depth if the checksum logic ever changes or is bypassed.

Both patterns satisfy the requirement that $this->authorize('delete', $post) receives a trusted model instance. The choice affects latency, database load, and the trust boundary between client and server.

Questions

1. In a high-traffic admin panel, does the query overhead of re-fetching outweigh the checksum trust assumption for locked properties?
2. Are there documented failure modes where a locked property's checksum passes but the underlying record has been deleted or reassigned?
3. Does the Form object pattern in Livewire v3 shift this trade-off by centralizing the model resolution?