Retroactive Funding Proposal: Bounty Manager V2.0
Retroactive Funding Proposal: Bounty Manager V2.0
Proponent: galaniprojects GmbH
Address: 143A8aK5Sdiyw8eHMbGKRWz1VdKg75BG2SRVXTFwyHjuujCE
Date: 20/03/2025
Requested Funding: 64,368 USDC (59,600€, 1€ ~ 1.08 USDC on 20/03/2025)
Short description: This is a retroactive funding proposal for development of the second version of Bounty Manager. It includes development of a bounties platform interface, additions and improvements to existing functionalities and a comprehensive visual update and overhaul.
Website: https://bountymanager.io
Project Category/Type: Software Development
Detailed Proposal: Proposal document
Context:
This retroactive proposal outlines the work completed and features introduced in Bounty Manager v2.0, a tool designed to streamline bounty curation processes. In this second version of the Bounty Manager, users can access a single platform that consolidates all bounty information in one convenient location.
Curators benefit from enhanced automation features and quality-of-life improvements, as well as an overhauled UI.
**Payment terms and Budget:
**We ask for payment in USDC. We cannot accept USDT since we are based in Europe and Tether does not meet the criteria for compliance with MiCa regulation.
Total USDC: 64,368
**Who we are:
**Galaniprojects GmbH was established in 2006 and is situated in Berlin, Germany. We offer software development, project management, quality assurance and UI/UX design to clients across various industries, including Media & Publishing, Telecommunication, Automotive and Transport, as well as working as implementors on various projects for the KILT Parachain.
Visit our website here.
Comments (8)
Requested
Proposal Failed
Summary
0%
Aye
0%
Nay
Aye (22)0.0 DOT
Support0.0 DOT
Nay (68)0.0 DOT
We will be voting NAY on retroactive referenda of these characteristics, specifically of high value. To us, it is a better way to outline a plan of action to follow what deliveries were fulfilled and what deliveries were not fulfilled as opposed as this high value retroactive approach which leaves the tokenholders footing the bill
for work that was not approved beforehand. For this referendum in particular, there is a denied precedent with referendum 1325 so any specific changes proposed to OpenGov should have been presented as a non-retroactive referendum presented for approval instead.
So we prefer that well known teams such as these one as well as newcomers to take the non-retroactive route exclusively. This idea will be heavily enforced on our vote starting on cohort 4's term as described on our DV cohort 4 application: https://forum.polkadot.network/t/decentralized-voices-cohort-4-saxemberg/11868
@Saxemberg Governance
Thank you for the feedback and outlining your position.
We'd like to clarify that this proposal is the continuation of the previously approved milestone 1 and not a typical retroactive ask.
Milestone 1 was completed and accepted by the community with the Milestone 2 features outlined in the current proposal, already described in that one.
We initially submitted proposal 1325 as a way to move forward and we appreciate it was rejected because it departed significantly from the original scope.
Taking this feedback very seriously was the reason we returned with the current proposal, having implemented the originally described Milestone 2.
We understand your concern about retroactive proposals and your reasoning as to why they should be avoided, however we believe this is fundamentally different due to:
We fully support OpenGov's move toward planning in advance and accountability and we have outlined our plans for future development at the end of the proposal for this reason, as we want to gather feedback and the community's opinion on how we should continue.
This feedback we then plan to include in further proactive proposals.
We welcome you to provide further feedback and are open to dialog for clarifications.
Referendum 911 didn't entail an explicit retroactive second milestone hence it cannot be treated as a "pre-approved" milestone, specially when the original milestone 2 was already presented to OpenGov as non-retroactive (Ref 1325). It seems it was meant to be approved first and then implemented.
Hopefully it can be agreed by team and referendum advisors that opting for a retroactive bill specially when a non-retroactive referendum continuation was already presented (1325) and the new referendum (1499) was unannounced and un-discussed entailed an enhanced risk for OpenGov and the proposer, which is why these retroactive approaches should be considered high risk and discouraged from being commonplace. So better alternatives that align better with the will of tokenholders should be presented to OpenGov instead.
Our rationale for referendum 911 was that continuation approval would be subject to adoption so,
it will still remain as one of the two reasons for the vote in addition to the other, already discussed fact.
@Saxemberg Governance
Thank you for your continued engagement and explaining your perspective.
We acknowledge that while Referendum 911 did not explicitly include a pre-approved commitment to the second milestone, the scope of work and intended progression were already outlined in the original discussion. The requested funds in this proposal correspond to the originally projected costs accordingly.
The intention was always to follow through with the next phase when the first milestone was successfully delivered. The software is already being used by bounties curators, with whom we have engaged in feedback and coordination to develop the additional features and improvements.
Our continuation attempt with referendum 1325 contained large variations out of that scope and taking the feedback of its rejection seriously, we returned to the originally described specification.
We understand your stance on avoiding retroactive funding approaches and fully understand the concerns about risk in OpenGov decisions. From our perspective, there was inherent risk on our side in delivering this work without upfront funding. However, we believe this poses very low risk for OpenGov, given that the work has already been completed, is fully verifiable and aligns with the originally intended roadmap.
We respect the position that moving forward, a strict non-retroactive approach is preferred, and we are fully committed to adapting accordingly in future proposals. Our intent is not to set a precedent for bypassing approval structures but rather to complete a logical continuation of work that was already outlined.
We appreciate the constructive dialogue and will take all feedback into account for future proposals to ensure better alignment with OpenGov’s evolving best practices.
Looking forward to your further comments and feedback.