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

Proposal type: Ретроактивное финансирование
Review source: AI_DRAFT
Recommendation: Needs revision
Community stance: Needs changes
Exported: 2026-06-25T21:09:12.545Z

> This is generated from the latest AI draft and has not been published by a human reviewer.

## Community Review

Recommendation: Needs revision
Evidence confidence: medium

Summary:
Gonka NOP appears to be a real, open-source CLI that can reduce friction for deploying and maintaining Gonka nodes. That is plausibly valuable to the network. However, the current ask bundles retroactive payment, 6 months of support, and undefined future features into a single 50,000 USDT transfer with no budget breakdown, no tranches, no acceptance criteria, and weak evidence of actual network impact or usage. The fund should not approve this version as a lump-sum retroactive grant, but it could become fundable if reframed as a smaller, milestone-based maintenance and feature grant with verified adoption/impact evidence.

Top reasons:
- Real and relevant open-source tool exists, but the retroactive impact case is not yet evidenced with usage or outcome data.
- The current funding structure is a high-risk lump sum with no budget, tranches, milestones, or acceptance criteria.
- Future support and feature work are bundled into the retroactive request, making scope and accountability hard to verify.

Conditions:
- Separate the ask into: (1) retroactive payment for verified delivered value, (2) 6-month maintenance/support, and (3) future features. Price each separately.
- Provide verifiable usage evidence: number of mainnet operators using NOP, successful deployments, before/after setup time, support issues resolved, operator testimonials or signed attestations, and repository release history.
- Replace the single 50,000 USDT transfer with milestone/tranche payments tied to measurable acceptance criteria, such as release delivery, issue-resolution SLA, documented compatibility with network releases, and adoption targets.
- Add a budget breakdown showing labor categories, estimated hours or FTE assumptions, infrastructure/testing costs if any, and how the retroactive amount was valued.
- Define future-feature scope narrowly: which features, target release dates, acceptance tests, and what is explicitly out of scope.
- Name accountable maintainers and provide support channels, response-time targets, reporting cadence, and post-grant maintenance/handover plan.
- Add security and operational-risk handling appropriate for a node deployment tool, including review/testing process for scripts that install dependencies, configure GPUs, manage keys, and run containers.
- Disclose incentives and conflicts, including whether INC4 or maintainers operate nodes, benefit from onboarding more operators, or have other commercial interests related to NOP.

Blocking issues:
- No measurable outcome (blocker): The only structured success metric in the imported record is a community/tender vote tally, which is not an outcome metric. There are no adoption, operator, node-launch, support-SLA, issue-resolution, or reliability targets.
- No budget or tranche logic (blocker): A 50,000 USDT single payment is requested without budget breakdown, vesting, tranches, retroactive valuation, or milestone logic.
- Retroactive ask without impact evidence (major): The tool exists, but retroactive payment is not supported by verified usage data, operator testimonials, number of successful deployments, support history, or network performance impact. 'Used by some operators' is proposer-stated in the available materials.
- Maintained asset without maintenance owner (major): The proposal funds an operational node-maintenance tool, but it does not identify named maintainers, service expectations, escalation process, or post-6-month handover/maintenance plan.

Team confidence:
The team has relevant evidence because the inc4/gonka-nop repository and documentation exist. Team confidence is still only moderate because the proposal does not name maintainers, quantify capacity, or define an accountability path beyond the public repository.

Team checks:
- Owner - pass: Governance materials identify INC4 as the recipient/entity, while the imported tender lists O D as proposer. That is sufficient to avoid a no-owner failure.
- Relevant proof - pass: The repository and README demonstrate an existing tool with relevant node-deployment functionality. This is stronger than reputation-only evidence.
- Capacity - concern: The proposal does not disclose staffing, time allocation, support coverage, or capacity for both support and future-feature development.
- Accountability path - concern: Using GitHub as a public work surface is helpful, but the proposal has no reporting cadence, issue response expectation, release commitments, acceptance criteria, or escalation path.

Dimension notes:
- Network value 2/4: The tool targets a real network-level friction point: deploying and maintaining Gonka nodes. Repository and README evidence show a documented CLI with setup, status, update, GPU detection, config generation, and multiple topologies. The network-value case is plausible, but concrete impact is not yet verified beyond proposer-stated claims that some mainnet operators use it.
- Plan clarity 1/4: The existing tool is described clearly, and 6 months of support is mentioned in one governance version. But the proposal lacks formal deliverables, exclusions, acceptance criteria, success metrics, milestone schedule, and a verification plan for the retroactive and future-feature portions. The future-feature list is open-ended.
- Team confidence 2/4: INC4 is named in governance materials and the inc4/gonka-nop repository exists with documentation, workflows, MIT license, and recent activity. That is relevant proof for this technical scope. However, the proposal does not provide named maintainers, capacity allocation, response commitments, escalation path, or a maintenance/reporting cadence beyond 'GitHub is the report'.
- Funding discipline 0/4: The proposal asks for 50,000 USDT as a single payment with no vesting, tranches, budget line breakdown, retroactive valuation method, or opportunity-cost comparison. For a retroactive-plus-future grant, this creates high funding risk and a weak precedent: the DAO would be paying for effort and broad usefulness rather than verified outcomes.
- Risk & stewardship 1/4: The repository has some positive hygiene signals, including security workflow and SECURITY.md, and the tool is open source. But the proposal does not adequately handle operational risks, security-review expectations for a node deployment tool, conflict disclosures, maintenance handover, or what happens after the 6-month support period.

## Conditions
- Separate the ask into: (1) retroactive payment for verified delivered value, (2) 6-month maintenance/support, and (3) future features. Price each separately.
- Provide verifiable usage evidence: number of mainnet operators using NOP, successful deployments, before/after setup time, support issues resolved, operator testimonials or signed attestations, and repository release history.
- Replace the single 50,000 USDT transfer with milestone/tranche payments tied to measurable acceptance criteria, such as release delivery, issue-resolution SLA, documented compatibility with network releases, and adoption targets.
- Add a budget breakdown showing labor categories, estimated hours or FTE assumptions, infrastructure/testing costs if any, and how the retroactive amount was valued.
- Define future-feature scope narrowly: which features, target release dates, acceptance tests, and what is explicitly out of scope.
- Name accountable maintainers and provide support channels, response-time targets, reporting cadence, and post-grant maintenance/handover plan.
- Add security and operational-risk handling appropriate for a node deployment tool, including review/testing process for scripts that install dependencies, configure GPUs, manage keys, and run containers.
- Disclose incentives and conflicts, including whether INC4 or maintainers operate nodes, benefit from onboarding more operators, or have other commercial interests related to NOP.

## Blocking Issues
- No measurable outcome (blocker): The only structured success metric in the imported record is a community/tender vote tally, which is not an outcome metric. There are no adoption, operator, node-launch, support-SLA, issue-resolution, or reliability targets.
- No budget or tranche logic (blocker): A 50,000 USDT single payment is requested without budget breakdown, vesting, tranches, retroactive valuation, or milestone logic.
- Retroactive ask without impact evidence (major): The tool exists, but retroactive payment is not supported by verified usage data, operator testimonials, number of successful deployments, support history, or network performance impact. 'Used by some operators' is proposer-stated in the available materials.
- Maintained asset without maintenance owner (major): The proposal funds an operational node-maintenance tool, but it does not identify named maintainers, service expectations, escalation process, or post-6-month handover/maintenance plan.

## Evidence Gaps
- None

## Source Links
- GOVERNANCE 56 (DEFEATED) - https://gonkascan.com/network/proposals/56
- GOVERNANCE 53 (DEFEATED) - https://gonkascan.com/network/proposals/53
- VOTE_GONKA 2cbbe98e-ceff-4f09-a1cd-e8d370e97fde (expired) - https://vote.gonka.vip/tenders/2cbbe98e-ceff-4f09-a1cd-e8d370e97fde

## AI Score
- Model: gpt-5.5
- Prompt: framework-review-v7
- Final score: 37.25
- Detailed recommendation: NO