Gonka Community Fund

Proposal простыми словами

О чем это

Запрос

Governance proposal does not expose a direct transfer ask in the imported messages.

Ответственный

Protocol proposer gonka1m9sf2rpg635efaw59djqlxkqew9sxvmqd6g343; accountable delivery owner not explicitly provided.

Почему это важно

Not provided as a dedicated network-level value field. Source summary: Register IBC token metadata and approve the denomination for trading on Gonka mainnet.

Проблема

Not provided as a dedicated problem/bottleneck field. Source summary: Register IBC token metadata and approve the denomination for trading on Gonka mainnet.

Что должно быть сделано

Unstructured governance deliverable

Нужны правкиAI-черновик

Framework score v2

Простое ревью

This is a bounded protocol-change proposal to register Kava USDT IBC metadata and approve the denomination for trading on Gonka mainnet. The action is plausibly network-relevant and the imported executable-message summary is directionally aligned with the prose, with no direct GNK transfer detected. However, the proposal is too thin for confident approval under the Community Fund framework: it lacks a named accountable technical owner, concrete necessity/why-now rationale, blast-radius analysis, post-execution monitoring or rollback/mitigation plan, measurable success checks, conflict/disclosure context, and full inspectable message parameters in the provided evidence layer. The governance tally shows it passed, but vote outcome is not treated as proposal-quality evidence.

Доказательства

средние

Команда

провал

Блокеры

Почему такое мнение

The action is plausibly network-relevant and bounded, but evidence is too thin for a safe protocol-change approval review.
No direct GNK transfer is detected, so treasury budget risk is low; the main risk is executable protocol safety and asset-listing stewardship.
The proposal lacks accountable technical ownership, measurable post-execution checks, blast-radius analysis, and monitoring/mitigation plan.

Пять публичных проверок

2/4

Ценность для сети

Registering and approving a USDT IBC denomination for trading could create network-level utility by enabling a stablecoin trading asset on Gonka. But the proposal provides only a one-sentence rationale and does not establish demand, urgency, alternatives, or the concrete bottleneck solved.

1/4

Ясность плана

The intended action is bounded at a high level, but the provided material does not expose the full token metadata, denomination, channel/path details, validation criteria, acceptance checks, or measurable post-execution outcomes. The message types are known, but parameters are not fully shown in the evidence snippet.

1/4

Доверие к команде

The proposer address is visible, but no named accountable owner or entity, prior relevant execution proof, capacity statement, contact/reporting path, or maintenance/escalation responsibility is provided for this exact protocol change.

3/4

Дисциплина финансирования

No direct GNK transfer or coin amount is detected, so grant-style budget/tranche concerns are largely not applicable. The main discipline issue is governance opportunity cost and safe execution, not treasury spending.

1/4

Риски и stewardship

Approving an IBC token for trading can affect users, markets, relayers/operators, token metadata assumptions, and asset safety. The proposal does not identify blast radius, validation of the Kava USDT asset path, monitoring, rollback/mitigation, conflict disclosures, or maintenance ownership.

Оценка команды

Team confidence is weak. The on-chain proposer address provides some attribution, but not enough accountability for a technical listing/trading approval. No relevant delivery proof, capacity, maintenance owner, reporting cadence, or escalation path is supplied.

Ответственный

вопрос

A proposer address is present, but no named person/entity or explicit accountable technical owner is provided.

Релевантные доказательства

неясно

No evidence is provided that the proposer has previously executed safe IBC metadata registration, token listing, or trading-approval changes.

Ресурсы и capacity

неясно

No time, resource, monitoring, or operational commitment is stated.

Accountability path

провал

No reporting cadence, contact path, escalation path, or maintenance handover is provided.

Условия

Publish the full executable messages, including exact IBC denom, metadata fields, source/channel/path assumptions, authority fields, and approval parameters, and demonstrate they match the prose.
Provide a named accountable technical owner or entity with contact/escalation path for pre-execution validation and post-execution incident handling.
Add a necessity statement: what problem the listing solves now, expected users/use cases, why Kava USDT specifically, and what alternatives were considered.

Блокирующие проблемы

Нет ответственного owner: The proposer address is known, but accountable technical ownership is not explicitly provided. For a token trading approval, this materially weakens accountability and escalation.
Нет измеримого результата: No baseline, target, measurement method, or post-execution success check is supplied for the listing/trading approval.
Ключевые утверждения не подтверждены: The proposal depends on correct IBC token metadata and safe trading approval, but the provided evidence layer only summarizes message types and does not expose full token metadata/path validation or independent verification.

Register Kava USDT IBC metadata and approve for trading

О чем это

Простое ревью

Источники