Gonka Community Fund
Ретроактивное финансированиеsource: vote.gonkagovernance: defeated · 2 attempts

Gonka NOP: ретроактивный грант + финансирование поддержки и новых фич.

Профинансировать gonka-nop — существующий CLI для быстрого развёртывания и обслуживания ноды Gonka: ретроактивно за уже сделанную разработку, за дальнейшую поддержку и за разработку новых функций.

Запрос

50 000 USDT

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

O D

Подано

13 мая 2026 г.

Ballot

ONE_WALLET_ONE_VOTE; 26 мая 2026 г. to 2 июн. 2026 г.

OPEN

Yes

1

No

0

Abstain

0

Source tender signal remains available on the proposal page; this ballot records the local fund vote.

Advanced vote context

Reviewer median

39.75

Нет

Raw score

39.75

Final score

39.75

Reviewer scorecards

CriterionWeightValuePoints

Strategic bottleneck

Node deployment complexity is a credible strategic bottleneck for a network that wants broader operator participation. The score is not 1 because the proposal itself notes current operators are few and mostly managing themselves, and one community comment questions timing until the next miner wave.

Evidence

  • proposal.scopeIncluded:Проблема - "Развёртывание ноды Gonka сегодня — это многошаговый процесс... Это трудоёмко даже для опытного администратора и почти невыполнимо для пол..."
  • proposal.scopeIncluded:Что это дает сети - "Прямо сейчас эффект может казаться неочевидным: операторов немного, и большинство справляется собственными силами."
  • source.comments[2]:body - "$50k многовато имхо. Также возможно быть не своевременно - NOP пригодится при следующей волне новых майнеров."
140.7510.5

Network-level leverage

An open-source deployment tool can leverage network growth by lowering onboarding barriers for many future operators and standardizing automation for experienced ones. The leverage is plausible but unproven without adoption targets or usage data.

Evidence

  • governanceProposal.body:Why this matters for the network - "newcomers can join without diving into the internals, and experienced operators get a consistent foundation for their own automation."
  • governanceProposal.body:What it is - "It is already working, open source, and in use by some operators on mainnet."
130.759.75

Measurable impact

No measurable project impact criteria are supplied. The tender voting tally is not a success metric for the funded work. There are no baselines or targets for deployments, active operators, support response times, release cadence, reliability, or feature completion.

Evidence

  • proposal.successMetrics[0]:metricName/measurementMethod - "Community signal ... vote.gonka.vip tender tally"
1200

Team / execution reliability

15Team module10.25

Scope / deliverables

The scope includes meaningful categories, but future deliverables are broad and illustrative rather than binding. The proposal lacks exclusions, milestones, normalized acceptance criteria, and prioritization for the proposed new features.

Evidence

  • proposal.scopeIncluded:Предложение - "Новые функции — реализация новых возможностей и расширение круга поддерживаемых сценариев (GUI/TUI для новичков, локальный мониторинг, An..."
  • proposal.deliverables[0]:acceptanceCriteria - "Acceptance criteria must be normalized from the source tender before a formal score is published."
100.252.5

Funding structure / tranches

The funding structure is a single payment with no vesting, tranches, milestones, holdbacks, or split between retroactive compensation, support, and future development.

Evidence

  • governanceProposal.body:Terms - "Single payment, no vesting or tranches"
  • proposal.scopeIncluded:Структура вознаграждения - "порядка 50 000 USDT ... пакетом за все три направления"
900

Budget discipline

The amount is stated, but no rationale, market comparison, staffing estimate, line-item allocation, or cost-per-deliverable is provided. Community comments also flag the amount as possibly high. Some partial credit is given because the amount is explicit and open for discussion in the tender text.

Evidence

  • proposal.scopeIncluded:Структура вознаграждения - "Совокупный размер гранта — порядка 50 000 USDT ... стартовая точка с нашей стороны."
  • source.comments[2]:body - "Вещь важная и нужная. Но $50k многовато имхо."
70.251.75

Incentive alignment

Open-source work and 6 months of support are aligned with the network, but the payment is upfront and bundled, includes retroactive compensation and unspecified future work, lacks outcome metrics, and has no structured conflict disclosure. This weakens alignment between payment and delivered network value.

Evidence

  • governanceProposal.body:Terms - "Single payment, no vesting or tranches"
  • governanceProposal.body:Terms - "Work is open on GitHub: code, releases, issues - this is the report to the DAO"
  • proposal.conflicts:conflicts[0] - "Conflict disclosures are not structured in the source tender and must be reviewed manually."
80.252

Sustainability / handover

There is a limited 6-month maintenance promise, but no longer-term sustainability model, handover process, maintainer succession, documentation ownership plan, or plan for what happens after the funded period.

Evidence

  • governanceProposal.body:What the grant covers - "Support for NOP users - 6 months of help, fixes, updates with every network release."
  • proposal.maintenanceHandover:maintenanceHandover - "Imported tender has no mandatory maintenance / handover field."
70.251.75

Governance precedent / opportunity cost

The proposal has no explicit opportunity-cost analysis or alternatives. It sets a precedent for a large single-payment package covering retroactive work, support, and broad future development without milestones, which should be evaluated carefully before approval.

Evidence

  • proposal.alternativesOpportunityCost:alternativesOpportunityCost - "Imported tender has no mandatory opportunity-cost field. Reviewer should add alternatives before publishing a final score."
  • governanceProposal.body:Terms - "Single payment, no vesting or tranches"
50.251.25
Raw score39.75

This proposal has a credible network-relevant purpose: a working open-source CLI that lowers the barrier to running Gonka nodes and could improve operator growth and resilience. There is meaningful execution evidence through the existing tool, documentation, demo, and claimed mainnet use. However, it is not ready for strong Community Fund scoring as written because it combines retroactive compensation, 6 months of support, and broad future feature development into a single 50,000 USDT payment with no budget breakdown, no tranches, no milestones, no project impact metrics, no explicit exclusions, no security review plan, and incomplete conflict/maintenance handover disclosures. The main unresolved concerns are not whether the tool is relevant, but whether the amount, payment structure, future scope, and accountability mechanisms are disciplined enough for CommunityPool funding. Reviewer questions: - What exact portion of the 50,000 USDT is for retroactive development, 6-month support, and each future feature area? - Who are the named technical maintainers and what are their time commitments during the 6-month support period? - What concrete milestones and acceptance criteria will govern future work such as GUI/TUI, local monitoring, and Ansible module support? - What measurable success targets will be used, such as number of successful node deployments, deployment time reduction, active operators onboarded, support response time, resolved issues, or releases supported? - Will the DAO receive any milestone-based reporting beyond GitHub activity, and should payment be split into tranches or holdbacks? - What is the security review plan for a tool that installs dependencies, configures Docker/Gonka components, and registers nodes? - What happens after the 6-month support period: who maintains the tool, under what funding model, and what handover documentation will exist? - Are there any affiliations, compensation relationships, or conflicts involving INC4, proposer O D, major voters, node operators, or Gonka core contributors that should be disclosed? - What evidence can be provided for current usage: number of operators, deployments completed, issues resolved, and production reliability? - What alternatives were considered, such as funding only support, funding only specific features, using bounties, or requiring matching/community maintenance contributions?

Optional voter scorecard

Relevant delivery proof

Weight 4

Domain fit

Weight 3

Technical / operational capability

Weight 3

Commitment / capacity

Weight 2

Governance communication

Weight 2

Maintenance accountability

Weight 1

Strategic bottleneck

Weight 14

Network-level leverage

Weight 13

Measurable impact

Weight 12

Team / execution reliability

Weight 15

Calculated from Team Module

Scope / deliverables

Weight 10

Funding structure / tranches

Weight 9

Budget discipline

Weight 7

Incentive alignment

Weight 8

Sustainability / handover

Weight 7

Governance precedent / opportunity cost

Weight 5