This venue's WebSocket connection — internal. A consumer never sees this module, never holds this pid, and cannot tell from the facade that it exists.

The venue dials its own socket

This used to be injected: shared code opened the connection and handed the adapter an open/subscribe pair, because the connection machinery lived in a boundary the adapters could not reference. That constraint was an artefact of one application's module layout, and it cost more than it saved — shared code was making transport decisions with information only the venue has.

The venue keeps the policy either way: how many connections, which channels, how many pairs each carries, in what order and at what pace. What changed is that it now also owns the mechanism, so there is no seam for the two to disagree across.

Public channels take no JWT, and attaching one is actively harmful

Coinbase answers a bogus token with {"type":"error","message":"authentication failure"} — measured 2026-08-07. An earlier version attached a token to every channel on the theory that it could not hurt. It could: the token was a stub returning the raw API key, so level2 produced nothing while ticker, which is public, worked fine. A venue half-delivering looks like a quiet market rather than a broken credential.

Authenticated channels get a real JWT from DpExchange.Coinbase.Auth, built fresh per subscribe rather than cached — its window is two minutes, and a token that outlives it fails the same silent way.

Every frame goes through FrameSender

Never WebSockex.send_frame/2 directly. See that module for why; the short version is that it exits rather than returning, and the exit kills this connection.