This venue's process tree — internal. A consumer starts DpExchange.Coinbase and gets this; it never names or reaches into the children.

The venue starts its own rate limiter, and that is the point

Rate limiting is venue-internal under the facade contract, and this is what that means in practice: the ceilings capabilities/0 declares are the ceilings the limiter is configured with. The declaration is not decoration that happens to sit beside the mechanism — it is the mechanism's configuration, so the two cannot drift apart.

It also fixes a real usability trap. Core.HttpClient fails closed when no limiter is running, which is correct — an unmetered package is how a venue answers with HTTP 429 while a budget panel reads comfortable. But it means a venue package that expected someone else to start a limiter answers {:error, "Rate limiter unavailable"} to every call, and the error does not say what is missing. Measured while writing this package's tier-2 tests, which is exactly the tier that catches integration gaps a fake cannot.

A consumer may still supply its own limiter through Core.Config's :rate_limit_module, per process — this is a working default, not a lock.

What is deliberately not here

No aggregate supervisor over multiple venues, and no auto-start. A consumer puts DpExchange.Coinbase in its own tree and chooses restart strategy, shutdown order and naming. A consumer that has not asked for this venue never finds a socket open.