Evaluating Chainflip BaaS: a hosted broker option, under review

herrenlos runs its own Chainflip broker today — it's how native cross-chain swaps, including BTC, get quoted and settled (the details are here). This post is about something we're evaluating, not shipping: Chainflip Broker-as-a-Service (BaaS), a hosted broker option that could sit alongside — or behind — the broker we self-host. To be clear up front: this is under evaluation. It is not live, not surfaced, and not part of any swap you can make today.

What Chainflip BaaS is

At a high level, Broker-as-a-Service is hosted broker infrastructure: instead of running and maintaining your own Chainflip broker node, you use broker capabilities — requesting deposit channels, fetching quotes — through a hosted endpoint. It speaks the same Chainflip protocol; the difference is who operates the broker node.

What we run today

Our current integration uses a primary, self-hosted Chainflip broker. It quotes native cross-chain pairs in parallel with the other providers herrenlos aggregates, and you settle either by sending to a deposit address or signing in your own wallet. That path is unchanged by anything here.

Why evaluate BaaS

Running a broker is real operational surface — a node to keep healthy, patched, and reliable. A hosted broker could reduce that burden, and an independent broker source is also just something worth being able to measure against our own. The honest framing is a question, not a conclusion: does a hosted broker meaningfully simplify operations or improve reliability without giving anything up? We don't assume it does — we want to be able to compare.

How it already sits in the code

The evaluation isn't hypothetical hand-waving; the scaffolding is in the repo, deliberately built to be safe to test:

• It's a second, fully independent broker integration (lib/baas-sdk.ts), isolated from the primary broker — its own SDK instance, its own configurable broker URL, its own independent broker commission config.
• It uses the same @chainflip/sdk contract as the primary broker (the same quote / deposit-address / status calls), so a BaaS quote comes back in the same shape as our existing Chainflip quotes.
• It is additive and gated off by default (NEXT_PUBLIC_ENABLE_BAAS). With the flag off, the query stays idle — zero network traffic. With no broker URL configured, it reads as "not configured" and short-circuits gracefully rather than erroring.
• Today it's fetched in parallel for comparison only — it is not merged into the ranked routes and not surfaced as a selectable option. Surfacing it as a real rate-panel card with an execution flow is a separate, deliberate step we haven't taken.

In other words: it's wired up enough to study, and wired carefully enough that studying it changes nothing for users.

What we're weighing

• Custody stays the same. BaaS uses the identical Chainflip flow, so it's the same non-custodial model: you send from your own wallet to a deposit address, or sign in your wallet. A different broker URL does not touch your keys or funds. BaaS would not change custody — that's a requirement, not a hope.
• Routing compatibility. Because a BaaS quote is the same shape as the primary Chainflip quote, it can slot into the existing parallel-quote-and-rank model and be compared by the same best-executable logic as every other provider. The open work is deciding whether and how to merge it into the ranked set.
• Operational ownership. The real trade to understand: what herrenlos keeps running (the app, the aggregation and ranking, the execution UX) versus what a hosted broker would take off our plate — and what we'd depend on it for.
• Failure modes and visibility. The BaaS path has its own circuit breaker, isolated so a problem there can never degrade the primary Chainflip path or the rest of the aggregator. Status uses the same status calls we already rely on. That isolation is the whole point — it lets us evaluate without putting the existing swap experience at risk.

Current status

Under evaluation. Built, isolated, gated off, not surfaced, not ranked, not part of any live swap. Nothing in production behaves differently because this code exists.

What would need to be true before we ship it

Before BaaS could move from "evaluated" to "enabled," we'd want:

1. A configured broker endpoint and an explicit opt-in (the flag flipped by an operator — we don't enable gated flows on autopilot).
2. The remaining integration work done properly: surfaced as a selectable route with a real execution flow, merged into ranking deliberately.
3. Confidence in quote parity and ranking behavior against the self-hosted broker under real conditions.
4. Confidence that the isolation and failure handling hold up — a BaaS hiccup must stay contained.
5. The standing guarantees preserved: non-custodial throughout, honest status, no regressions to the existing Chainflip path or the other providers.

If and when those are true, we'll say so plainly. Until then, this is exactly what it says on the tin: an evaluation. You can follow what's shipped versus planned on the roadmap, and try the swaps we do run today from the swap page.