Skip to content

🔄 Auto-sync: from Discussion #1363 every hour.

OpenBroker - broker for brokers or Devshards as a service.

Автор: @gonkalabs · Категория: 🙌 Show and Tell · Создано: 2026-06-23 22:18 UTC · Обновлено: 2026-07-09 04:25 UTC

📝 Описание

Hey! Gonka Labs here.

We've just shipped OpenBroker, a platform that gives you direct access to gonka inference - pure devshards v1, v2 (and any future version) under wallet that is whitelisted to operate escrows. You get escrow capacity that scales elastically with your load, both devshard versions (and any future one), and throughput limited only by what the network itself can handle.

With OpenBroker - we make a community commitment to the overall observability and monitoring (Protocol-grade observability).

OpenBroker doubles as a live testbed where new devshard versions get exercised at production scale before they reach the wider network, and the observanility metrics we collect goes straight back to the protocol's contributors that we in-touch with to keep improving Gonka.

Full observability means that per-request metrics, public network stats and QOL inference metrics - are part of the product, not an afterthought. We work directly with the protocol's contributors to feed back the statistics, failure modes and performance data we see at real scale, so Gonka keeps getting better. It's also the environment where new devshard versions get shaken out at production load before they ship to everyone. If you've been using node4 to prototype or create your own Broker business and test against Gonka, OpenBroker is the next logical step and same "just hit an endpoint and go" experience, no diffrence (except that you can enroll and get access right away) - with bigger capacity, real telemetry, and both protocol versions available out of the box, all in a managed environment.

Снимок экрана — 2026-06-23 в 23 49 45

The problem

Running inference on Gonka today means either:

  • Using node4 node4 (whitelisted, rate-limited, built for demos not production), or
  • Becoming devshard/escrow operator - enroll your wallet to operate escrows, fund, rotate escrows, handle v1/v2 state roots, handle operator complexities (no settlement, etc). A lot of glue code just to send a chat completion.

So, if you want to become a broker, you need to get whitelisted for escrow operations or get broker key and connect to node4.

Either way makes it very hard for new brokers to start operating, raising the bar and lowering potential inference demand.

The Solution

OpenBroker is "a few devshard containers (v1, v2) + many escrows" system that sits in front of the Gonka network and exposes a plain devshard infra with our whitelisted wallet. Just as inteded to be used by brokers, but without need to whitelist a wallet or enroll to get a broker key.

From the broker's side:

  1. Register at https://openbroker.gonka.gg/register - email, org name, your gonka1… wallet.
  2. Deposit GNK to your generated address (activation kicks in at 100 GNK).
  3. Grab your API key (obk-*) from the dashboard.
  4. Point any OpenAI client at:
https://openbroker.gonka.gg/v1

That's it. /v1/chat/completions, /v1/models, streaming + non-streaming, no rate limits, pure devshards.

Снимок экрана — 2026-06-23 в 23 53 42

What you get

  • Unlimited throughput - as much as network can handle - you can send with OpenBroker's help.
  • GNK billing, NO MARKUP - watch the ledger drain in real time on your dashboard.
  • Fully managed escrows - we fund, register, rotate, secure escrows for you, including proactive replacement before they deplete bellow safe minimum.
  • v1 + v2 (and future) protocol support side-by-side, transparent to the caller, auto-routed.
  • Live, public stats - see your usage and the whole network's at https://openbroker.gonka.gg/stats.
  • OpenAI-compatible - drop-in for LangChain, LlamaIndex, OpenAI SDK, anything that speaks OpenAI. Or just become your own broker and resell inference (you "buy" without any additional costs or markup, OpenBroker deducts ledger 1-to-1 with what escrows cost) 

Scale we've tested

We've load-tested OpenBroker past 1,000,000,000 (1 billion) tokens in a single run (a little over 1 hour total test run time) across Qwen, MiniMax and Kimi models - no node4 fallback, escrows auto-rotating, v1/v2 traffic split live. Production-grade throughput is the goal.

Снимок экрана — 2026-06-23 в 23 54 05

Would love feedback, feature requests, and bug reports. If you build something on top of OpenBroker, drop it in this thread 🙌

💬 Комментарии (1)

Комментарий 1 — @yuritsin-code

2026-07-09 04:25 UTC

Hi @gonkalabs team (cc @tcharchian, @qdanik),

I've been testing OpenBroker (api.openbroker.gonka.gg/v1) with MiniMaxAI/MiniMax-M2.7 (same account/wallet as allowlist request #1397) and found two effects that block production use:

Effect A: fixed ~10s overhead per request. p50 latency is 10.0s for both 100-token and 1623-token prompts — flat, not proportional to size; consistent with an on-chain escrow cycle (~2 blocks × ~5s). Impact: a 30-turn agent pays +5 min of pure overhead.

Effect B: hard prompt-size ceiling at ~1623–1780 prompt_tokens. ≤1623 tokens: stable success. ≥~1780 tokens: the request hangs forever (240s client timeout not enough). 100% reproducible, 7+ tests on each side. Not byte-based — an 8.6KB body with 1523 tokens passes fine.

Questions: (1) is the 10s overhead expected escrow behavior, or optimizable (pooled escrow)? (2) is the token ceiling a known limit, and is there a workaround? (3) are the hanging requests billed (did their escrows execute)? (4) minor: /v1/models returns an empty list — supported model ids are only discoverable via the 400 error text.

Full methodology and raw measurements available on request. Tested 2026-07-08/09.