Gateway allowlist request: Ancapex #1480
Operator
Ancapex — mining platform for Gonka (https://ancapex.ai/)
Contact:
Ancapex is a platform for mining on the Gonka Network. Launched as a public pool in December 2025, it gives anyone the ability to participate in Gonka mining without running their own node or managing server infrastructure.
Since launch, the platform has attracted over 1,500 deposits with a total volume exceeding $350,000. The team continuously ships new features - most recently, in-platform governance voting, which allows Ancapex users to participate in Gonka Network proposals directly through the platform, with each user's vote counted individually and proportionally to their mining share.
Address
gonka1fnnjn8nr978tzrjknum3kqwdm24gc9sernrpae
Models
Any
Use case
We're building a platform designed to serve both our clients and autonomous agents. This is custom development at the gateway level, which a shared gateway with fixed behavior can't accommodate:
Custom custody schemes — different client types require different custody and payment arrangements; some must settle non-custodially, with no intermediary holding client funds, which a broker ledger can't provide. Agentic payments — agents paying for inference programmatically from accounts they control, with our entities as on-chain payer-of-record where required. Execution lifecycle control — our own management of session/escrow lifecycle, timeouts, retries, and rotation cadence, tuned to agent workloads (we understand routing and per-token pricing are protocol-defined and expect no performance advantage from self-hosting — this is about gateway behavior, not the network). Operator-side protocol work — we'll run our own devshardd v1/v2 integration and keep feeding operator-side issues and fixes back here, which isn't possible from behind a proxy.
Once our development stabilizes, we'll contribute the generalized schemes back to open source, as we've done with our previous work.
💬 Comments (2)
Hi @alancapex ! Can we communicate on this topic in Telegram and discuss potential implementation details needed to be made on openbroker side in order to fulfill the needs for such project?
As we can see, described functionality can be implemented as a product-layer feature set that can be enabled and utilized for your account. For example: host a separate devshard container that will be routable only for your account, etc
🔄 Auto-synced from Issue #1480 every hour.
Hi @alancapex! Probably you already know, there's a GNK-native community broker (OpenBroker https://github.com/gonka-ai/gonka/discussions/1363) with no markup and tested throughput, but it's a shared gateway with a custodial ledger, which is not exactly what you need I believe. So the creator/allowlist path is the correct one for you. That said, @gonkalabs, could you please take a look at whether the needs described in this issue could be maybe partially solved in some new way? Would be great to hear your take.
@alancapex, the strongest thing you can do while you wait is to continue building visibility in the community. These decisions are made with community input, and proposals/candidate addresses get discussed in the community channels, not only in an issue thread. Given your existing footprint and the commitment to contribute back to open source plus the operator-side protocol work you intend to feed back, is the right direction.
Keep this issue updated with anything new that comes up.