Skip to content

Feature: Expose lightweight ParticipantWeight query to CosmWasm (AcceptedGrpcQueries) #1867

Open @DmitriyVoronov00 opened 2026-09-28 11:12 UTC 1 comment Updated 2026-09-28 14:39 UTC

Summary

I am working on an open-source compute weight swap and escrow mechanism for the Gonka network (GonkaWeightSwap), which allows node operators and capital providers to trustlessly agree on compute weight delivery in exchange for USDT, completely within the Gonka protocol (no external oracles or trusted off-chain relayers).

To enable CosmWasm contracts to verify performance on-chain, contracts need to read two core metrics: 1. The current / completed epoch number. 2. The weight achieved by a specific participant address in a given epoch.

To introduce the concept, the motivation, and how this expands the Gonka ecosystem, I have prepared a video pitch: 🎥 Video Pitch & Concept Overview: https://youtu.be/L3RNyd-STwo

Motivation & Use Case

Currently, connecting hardware operators with outside capital relies heavily on off-chain trust, manual settlements, or complex legal agreements.

An on-chain escrow contract solves this by locking investor funds and releasing them dynamically as node operators deliver verified weight to the investor's designated address. However, CosmWasm currently cannot query the inference module's epoch/weight state directly.

Why Not Just Allowlist EpochGroupData?

While /inference.inference.Query/EpochGroupData exists, having a CosmWasm contract query and deserialize the entire participant array has major drawbacks: - O(N) Gas & Memory Overhead: As the network grows to hundreds or thousands of participants, passing the full array into the WASM runtime will exceed contract gas limits or cause out-of-memory errors. - Contract Complexity: Parsing huge protobuf messages inside CosmWasm contracts creates unnecessary friction and gas waste for end users.

Proposed Solution: Targeted O(1) Query

I propose adding a lightweight, gas-efficient endpoint to the inference query service and exposing it to CosmWasm:

  1. New query method in x/inference:
  2. Method: rpc ParticipantWeight(QueryParticipantWeightRequest) returns (QueryParticipantWeightResponse);
  3. Request: uint64 epoch, string participant
  4. Response: uint64 weight, bool found

  5. Implementation detail: This directly looks up the participant in the epoch's KV store in O(1) time without serializing the rest of the network's participants.

  6. Allowlist in x/wasm (AcceptedGrpcQueries):

  7. /inference.inference.Query/GetCurrentEpoch
  8. /inference.inference.Query/ParticipantWeight

Benefits to Gonka

  • Zero Security Risk: Both queries are strictly read-only against already finalized KV storage.
  • Gas & Network Safe: Constant-time execution prevents block bloat and gas exhaustion attacks.
  • Ecosystem Growth: Unlocks a decentralized market for compute rentals, attracts external capital into node operations, and encourages hardware competition.

Next Steps

I would love to get your feedback on this approach!

I am happy to collaborate with the core team, share more details on the product mechanics, and discuss how this feature solves real liquidity and compute allocation challenges for Gonka participants.

💬 Comments (1)

@DmitriyVoronov00 commented 2026-09-28 14:39 UTC

Following up on this: I noticed that PR #1758, merged into upgrade-v0.2.16, already exposes GetCurrentEpoch and EpochPerformanceSummaryByParticipant to CosmWasm. This is a very important step for marketplace and escrow-style contracts.

Looking at the current protobuf definition, EpochPerformanceSummary already provides per-participant stats for a completed epoch, including inference counts, rewards, missed requests, and claim status. However, it does not currently include the participant's finalized compute weight.

Proposed option

Instead of introducing a completely new query endpoint, would it be feasible to extend the existing EpochPerformanceSummary with a weight field?

uint64 weight = 11;

This would allow a CosmWasm contract to read, through the already exposed EpochPerformanceSummaryByParticipant query:

  • the completed epoch;
  • the specific participant;
  • performance and reward-related statistics;
  • the participant's finalized compute weight for that epoch.

Why this may be the simplest approach

  1. No additional public query endpoint: the contract-facing query is already exposed in PR #1758.
  2. Low overhead: EpochPerformanceSummaryByParticipant is already a targeted per-participant, per-epoch lookup rather than a full-network participant list.
  3. Consistent settlement data: contracts can evaluate performance, reward status, and delivered compute weight from one authoritative epoch summary.
  4. Useful beyond one application: this could support escrow agreements, compute marketplaces, reward accounting, and other contracts based on completed epoch outcomes.

For GonkaWeightSwap specifically, the contract needs the finalized weight of the configured reward-recipient address in order to determine whether the host met the agreed delivery conditions.

Would adding weight to EpochPerformanceSummary be feasible for an upcoming upgrade? I would be very interested in the view on whether this fits the intended meaning and lifecycle of this record.

cc @niktverd

🔄 Auto-synced from Issue #1867 every hour.