Every signal. Every subscriber.
Provably delivered.

Yes — market impact is real, and any distribution vendor who tells you otherwise is lying. It is a property of the signal — its horizon and the instrument's liquidity — not of the pipe. The magnitude is computable with the standard square-root model: impact ≈ σ_daily × √(Q / ADV), where Q is the aggregate notional your subscribers execute in the window, ADV is the instrument's average daily dollar volume, and σ_daily its daily volatility.

Worked examples. Ten subscribers each executing $1M of a daily-horizon AAPL signal: Q = $10M against roughly $10B of daily turnover, so with ~150 bp daily volatility the footprint is √0.001 × 150 ≈ 5 bp — noise against a multi-day move. The same $10M pushed into a $20M-ADV small cap: √0.5 × 300 ≈ 210 bp — the edge is gone before the last subscriber fills. Two hundred copiers at $50K each in ES futures ($100B+ daily turnover): under 2 bp. Daily-horizon signals on liquid instruments — the relay's target tenants — sit firmly in the manageable region; intraday scalps on thin names are fatal on any pipe.

The relay's contribution is the half of the problem infrastructure can own: fairness and disclosure. Today, the ledger records a dispatch timestamp for every delivery, so who received what, when, is a matter of record rather than trust. On the roadmap: capacity caps with signed attestation (provably no more than N seats on a strategy), randomized fair fan-out so no endpoint is systematically last, and a disclosed release policy per strategy. Aggregate impact itself cannot be repealed — only measured, capped, and fairly distributed.

On a standard strategy the guarantee is contractual and procedural: a written no-trading policy with an information barrier — relay operations personnel do not trade on tenant content — plus least-privilege operator access that is audit-logged, and a standing rule that signal content is never analyzed, aggregated, resold, or used to train models.

For tenants who want that guarantee to be structural rather than contractual, sealed mode is now live: payloads are end-to-end encrypted client-side by the Python SDK with keys held by you and your subscribers, while the relay stores and forwards ciphertext and sees only envelope metadata — IDs, sequence numbers, timestamps, size, recipient count. Not “we promise not to look” but “we cannot look”. Sealed is chosen per strategy at creation and immutable after, and the trade-offs are stated plainly: plaintext features like field-level redaction are structurally unavailable on sealed strategies, and metadata and traffic timing remain visible by design.

Both sides of the pipe assume failure. Publisher side: publishing is idempotent — each signal carries your own client_signal_id, so a retried publish returns the original acknowledgment instead of minting a duplicate — and the SDK queues locally, so a relay-side outage never loses a signal and a publisher-side crash never double-sends one.

Subscriber side: every accepted signal either reaches every entitled endpoint or lands in an explicit dead-letter state visible in the ledger — silent loss is a designed-out bug class, not a tail risk. A webhook endpoint that goes dark walks a six-attempt retry ladder (+30 s, +2 m, +10 m, +1 h, +6 h — roughly seven and a half hours of automatic coverage) before dead-lettering, and resume re-enqueues in sequence order. A WebSocket subscriber reconnects, gap-fills from its cursor, and only then goes live; the replay window is 90 days (design target). Six hours dark or six days, reconciliation is the same arithmetic.

On availability we publish measured targets, not marketing nines, and we advise every tenant to keep an independent emergency channel to clients — a demand you should make of any vendor in this seat.

The design target is under 250 ms at p95 from publisher acknowledgment to same-region WebSocket push, and under 500 ms cross-region. Measured so far: at or under roughly 1.5 seconds publish-to-push in the first production end-to-end run (2026-08-16) — a single run, not a percentile, and we quote it as such. The webhook path adds your receiver's network round-trip and processing time on top of that.

As with availability, latency SLOs get published after there is production percentile data to back them — measured targets, not marketing nines. Delivery speed is part of signal quality — a signal's edge decays with delay — which is why the number is stated hop-honest instead of rounded to zero.

Traceability plus contract. Every delivery carries a unique delivery_id and a per-endpoint HMAC signature computed over the exact bytes that endpoint received — so a leaked payload identifies the seat it was delivered to, with a ledger row as evidence. Per-subscriber payload watermarking is on the roadmap.

Enforcement stays where the client relationship lives: with you. Your subscription agreement prohibits redistribution, the ledger supplies the proof, you terminate the seat. Compare the alternative: a leak from a Telegram channel or an email list is unattributable by construction.

They could — a webhook fan-out is a week of work. What you would actually be committing to is the other 95%: idempotent publish under concurrent retries, a gapless sequence assigned atomically under load, exactly-once processing across subscriber restarts, per-entitlement field redaction that still signs the exact bytes sent, a retry ladder with explicit dead-lettering, 90-day replay, and a per-attempt delivery ledger — then a permanent on-call rotation for a system whose failure mode is your clients missing signals during a market event. That is quarters of senior engineering, forever maintained, in infrastructure that earns you zero basis points.

And the one property no internal build can have at any budget: independence. When an allocator's operational due diligence asks you to prove every client received every signal on time, a delivery log kept by the party under question is self-attestation. A ledger kept by a neutral third party with no stake in the answer is evidence. That is the product.

For moving bytes, generic pub/sub is excellent and 10–30× cheaper — and if transport is genuinely all you need, we are the wrong product and will say so on the first call.

What it does not have is everything an operational due-diligence questionnaire actually asks about: per-client-per-strategy entitlements, a per-attempt delivery ledger, HMAC-signed webhooks, gapless-sequence replay, investor-eligibility gating, or an audit answer better than “the message broker said OK”. The price of this service is set by the compliance and audit layer, not the transport underneath it.

Internal and external research are complements, not substitutes: in Lowenstein Sandler's hedge-fund surveys, 68% of funds sourced data through a combination of in-house and vendor channels, with later mixed-manager samples at 77%. The economic case rests on two documented facts, not on anyone's model being smarter than yours.

First, breadth: Grinold's fundamental law says risk-adjusted active return scales with the square root of the number of independent bets — a genuinely uncorrelated external stream adds breadth that more capital behind your existing ideas cannot. Second, decay: across 97 published return predictors, returns ran 26% lower out of sample and 58% lower after publication (McLean & Pontiff 2016). Any single signal erodes; a renewable pipeline is what compounds, and external sourcing parallelizes discovery.

The honest caveats: an external signal helps only if it is genuinely independent and survives your own validation, cost, and capacity analysis — correlated signals add far less breadth than their count suggests, and cross-asset correlations rise in exactly the left tails where you want diversification most (Kritzman et al. 2018). Diversification reduces concentration risk; it does not prevent drawdowns, and nobody distributing signals should tell you otherwise.

No. The relay is distribution infrastructure: it does not author, score, rank, or recommend signals, route orders, or touch a trading account. Signal content is produced under the publisher's own regulatory permissions, and access is limited to institutional and professional participants with KYB at onboarding.

Regulatory review is ongoing and nothing here is asserted as cleared — see the compliance page for the full posture, stated jurisdiction by jurisdiction.

Signals are stored only to operate the service — sequencing, delivery, retry, replay, audit — and are never analyzed, aggregated, resold, or used to train models. Tenant isolation is structural (your identity comes from your authenticated key, and every query is tenant-scoped), secrets live in a managed key vault, retention is bounded to the replay window, and the service runs in Microsoft Azure in the United States — the relay database in Central US, the API and worker tier in East US, the website in East US 2 — with backups and geo-redundant copies kept inside Azure's US regions.