Bring your network to Shroud

The Shroud gateway can front a third-party blockchain or RPC service the same way it fronts the Midnight node — shroud.us becomes the public URL, callers authenticate with Shroud API keys, billing flows through Credit Units, and the upstream RPC you supply is reachable to authenticated callers via the proxy. This page covers what's possible today and the architectural posture we take when accepting a new network.

This is not a self-service flow. Bring-your-network requires a deployment change on Shroud's side and an explicit agreement; reach out via sales@shroud.us to start.

What's on offer

The integration shape used for our first-party Midnight integration is the template we'd follow for a partner network. Today only the Midnight path is wired through the gateway — the surfaces below describe what we'd stand up for a new network, not what is parameterised and ready to flip on.

Whitelisted JSON-RPC proxy at a deployment-specific URL. The Midnight integration is reachable today at /v1/midnight/rpc; per-network paths like /v1/<network>/rpc are not yet parameterised in the gateway and would land alongside a new integration. Methods are explicitly enumerated with a CU cost per call. Anything not on the list returns -32601 Method Not Found.
Per-key authentication, rate limits, and CU billing — the same API keys that work against Cocoon inference and Midnight RPC would work against your network's RPC. Callers don't manage a second credential. This part is fully built today against the Midnight path; reusing it for a new network is a wiring-and- configuration change rather than new infrastructure.
Discovery — for Midnight, methods are enumerated through the midnight_listMethods MCP tool. A new network's methods would ship as a sibling MCP skill under its own namespace; the per-namespace tool name is hard-coded today rather than generated from a config-driven network identifier.
Optional MCP wrapping — if your RPC has natural read operations that benefit from agent integration, we'd register them as MCP tools via the same skill-server mechanism Midnight uses. The skill interface (pkg/skilliface.SkillServer) is the extension point; today it has one shipped implementation (Midnight) plus the platform and docs read tools.

What we accept and what we don't

We're conservative on what kinds of traffic we put behind a third-party-fronting layer. The defaults are yes for read paths, case-by-case for everything else.

Traffic class	Default posture
Read-only / query / view methods — block lookups, state queries, account balances, event subscriptions	Yes. This is the canonical case. Whitelist the methods, set CU costs, let traffic flow.
Subscription / streaming reads	Case-by-case. Long-lived WebSocket subscriptions affect rate-limit and billing accounting; we want to understand expected concurrency and per-subscription cost before enabling.
Light writes — broadcast a pre-signed transaction the caller built locally	Case-by-case. Each method gets its own assessment for replay protection, idempotency requirements, and what the failure modes look like.
Validator-critical surfaces — block production, signing, consensus participation, validator set changes	No. Putting these behind a third-party privacy-RPC abstraction without a clear understanding of latency, method coverage, auth handling, and failure modes is unsafe even when each piece looks reasonable in isolation. We won't proxy these.
Admin / operator-facing endpoints — node configuration, key management, peer manipulation	No. Same reasoning.

The boundary is intentional: the value Shroud provides on the proxy path is auth + rate limit + billing + a stable URL. Validator-critical paths need different guarantees we don't yet offer (deterministic latency budgets, explicit failure semantics, operator authentication on top of caller authentication). When we do, the policy will broaden — until then, no.

What you need to provide

To bring a network online behind Shroud:

A reachable RPC endpoint. Tier-1 (full or API-serving) node is fine; we don't need a validator. The endpoint must be reachable from Shroud's deployment region and stable enough that upstream-unavailability is the exception rather than the rule.
A method list with CU costs. A first cut from your team plus a back-and-forth on what the gateway should refuse to forward. The Midnight integration's published method table in RPC proxy shows the level of detail we expect.
Method semantics documentation. For each whitelisted method: request shape, response shape, error cases, expected latency range. We need this both to tune timeouts and to write your network's section of the Shroud docs.
A contact for incidents. When the upstream returns 503 or starts failing, we need someone to talk to who can actually read the gateway logs we share.

What we provide

A URL at https://shroud.us/v1/<network>/... (and the same prefix under dev.shroud.us). Callers using your network use Shroud's URL.
API key access. Existing Shroud workspaces can call your network without provisioning a second credential. New workspaces created for your network's audience use the standard signup flow.
Per-network billing routing. CU spent against your network flows through the standard Shroud billing pipeline; we can attribute the share to a partner workspace or split it per-method as part of the deal terms.
A docs page in the Shroud docs modelled on the Midnight RPC proxy page — method list with CU costs, examples, error semantics. We write the first cut and iterate with you.

Roadmap items we don't ship yet

Operator-side attestation. A future version of Shroud's proxy may add an attested upstream channel to your node so the cocoon-bridge style of integrity guarantees applies to RPC fronting too. Out of scope for the initial integration.
Full validator-critical surface. See above. We'll revisit with concrete operator-authentication and latency-SLA primitives.
Self-service bring-your-network. Today every integration is an explicit agreement. A self-service path with automated whitelist provisioning is on the roadmap, gated on the attestation work above.

RPC proxy — the reference for how the Midnight whitelisted proxy works in practice.
Authentication — keys, plans, rate limits, CU.
Production guide — what your callers will need to know about retry / idempotency / error handling.

Last modified: 08 May 2026