PIP-34: Ecosystem Development and Testing Grant Allocation

Panther Improvement Proposals (PIPs)
1
  1. Title
    1.1 Ecosystem Development and Testing Grant Allocation (April 2026 onward)
  2. Summary
    2.1 This proposal approves the allocation of grant-funded budget to support development and testing activities relating to the Panther Protocol ecosystem.
    2.2 It authorises the DAO Council to engage independent contractors, agree monthly scope, deliverables and budgets, and approve payments within defined limits.
    2.3 The funding supports development and testing only. It does not fund, and must not be construed as funding, the deployment, operation, hosting, monitoring, service provision, or continued availability of any live instance of the protocol or any interface or access point.
  3. Background
    3.1 Ongoing development, testing and quality assurance are desirable to improve protocol quality, security and usability.
    3.2 Consistent with ecosystem roles:
    (a) Panther Protocol Foundation may provide discretionary grant funding and does not direct or control development activity.
    (b) The Panther Protocol DAO determines priorities, engages contributors and coordinates development activity.
    3.3 This proposal aligns funding with that structure while maintaining a clear distinction between development activities and the operation of any live system.
  4. Scope of Activities
    4.1 Grant-funded budget may be used for:
    (a) smart contract and protocol development; (b) testing, quality assurance and validation; (c) bug identification, reproduction and reporting; (d) development, review and implementation of fixes; and (e) technical analysis and design input.
    4.2 All activities are:
    (a) performed by independent contractors engaged by the DAO; (b) coordinated by the DAO Council; and (c) not directed or controlled by the Foundation.
    4.3 For the avoidance of doubt:
    (a) no funding is provided for deployment, operation, hosting, ongoing operational support, monitoring, or service provision in respect of any live system;
    (b) no contractor is obliged to deploy, operate, host, monitor, or provide ongoing operational support for any live instance;
    (c) no contractor is responsible for uptime, availability or performance of any system; and
    (d) any interaction with deployed instances is limited to testing, debugging, validation or observation and does not create responsibility for those deployments.
  5. Nature of Engagement
    5.1 The DAO may engage contributors as independent contractors to perform development and testing services.
    5.2 Contractors are independent and are not employees, agents or partners of the DAO.
    5.3 The DAO may agree objectives, priorities, deliverables and budget caps.
    5.4 The DAO does not assume responsibility for how any third party deploys, publishes, operates or uses software.
    5.5 Contractors are responsible for determining how to perform their services and are not subject to direction or control as to the manner of performance.
  6. Initial Budget (April 2026)
    6.1 Testing (NH): 1,600 United States Dollar Coin (USDC)
    6.2 Development (BP): 60 USDC per hour, capped at 34 hours (2,040 USDC)
    6.3 Development (AI): 37.50 USDC per hour, capped at 60 hours (2,250 USDC)
    6.4 Total initial allocation: 5,890 USDC.
  7. Ongoing Budget Framework
    7.1 Monthly budgets shall be set by the DAO Council.
    7.2 Scope and caps shall be agreed in advance.
    7.3 Adjustments may be made within available funding.
  8. Mandate to the DAO Council
    8.1 The DAO Council is authorised to:
    (a) engage contractors; (b) agree scope, deliverables and budget caps; (c) review work and approve invoices; (d) authorise payments from available funds; (e) manage priorities and contributor relationships; and (f) request and receive discretionary grant funding from Panther Protocol Foundation or other grant providers, and manage such funds in accordance with this proposal.
  9. Funding and Payment
    9.1 Payments are made from grant funding provided at the discretion of Panther Protocol Foundation.
    9.2 No guarantee of current or future funding is given.
    9.3 No allocation creates any obligation on the Foundation to fund or continue funding.
    9.4 The DAO expects to make payments for approved work in the ordinary course, subject to funding.
  10. Reporting
    10.1 The DAO Council shall publish a monthly summary including:
    (a) contributors engaged; (b) work performed; and (c) funds allocated and spent.
  11. No Operational Responsibility
    11.1 For the avoidance of doubt:
    (a) the DAO determines priorities, coordinates development, and may facilitate access to software interfaces or access points;
    (b) the DAO does not provide custody, exchange, brokerage, transmission or other regulated services;
    (c) the DAO does not assume responsibility for uptime, availability or performance of any protocol instance or interface; and
    (d) the DAO does not undertake to operate, maintain or support any system as a service provider to users.
  12. Governance Boundary
    12.1 Nothing in this proposal:
    (a) authorises the Foundation to direct contributors or operate any system; or
    (b) creates responsibility for any live deployment.
  13. Rationale
    13.1 This structure:
    (a) preserves the Foundation’s non-operational role; (b) maintains separation between development and operation; (c) avoids responsibility for uptime or system availability; (d) enables flexible contributor engagement; and (e) aligns funding with DAO-led coordination.
2

Feedback on PIP-34: Ecosystem Development and Testing Grant Allocation

As a ZKP token holder, I have reviewed PIP-34 and the Foundation’s Grant Policy in detail. I would like to share the following feedback for the Council’s consideration before this proposal goes to a vote.

  1. Separation of Budget and Contractor Selection

PIP-34 bundles the funding allocation and the selection of specific contractors into a single proposal. Token holders are asked to vote yes or no on the budget, the individuals, and their rates all at once. If a voter supports the testing work but has concerns about a specific contractor or rate, there is no way to express that. I would recommend separating budget approval from contractor selection to give the DAO more granular decision-making authority.

  1. Open Contractor Selection Process

The proposed contractors are former Panther Ventures Limited (PVL) team members selected based on existing relationships. While their experience with the protocol is valuable, I believe grant-funded positions should be open to applications from any qualified contributor. An open selection process would ensure the best candidates are chosen, give new contributors a path to participate, and align with the decentralized values this project promotes.

  1. Council Approval Process

Through discussion in the community chat, I understand there is no formal voting threshold for the DAO Council to approve a PIP before it goes to token holders. For proposals that establish frameworks for all future grant allocations, I would recommend a more formal DAO Council sign-off process to strengthen governance legitimacy.

  1. Funding Certainty

Section 9.1-9.3 states that payments are made at the discretion of the Foundation and that “no guarantee of current or future funding is given.” Token holders are being asked to approve a plan that the Foundation can withdraw funding from at any time with no obligation. If the DAO votes yes and the Foundation decides not to fund, what happens? How can the DAO plan effectively without funding commitments?

  1. Operational Accountability Gap

Section 11 explicitly states the DAO does not assume responsibility for uptime, availability, or performance. Section 4.3 states contractors have no operational responsibility. The Foundation’s own policies state it is non-operational. As this protocol moves toward mainnet with real user funds, who is accountable for operational security and incident response? This proposal funds development and testing but leaves a gap in operational responsibility that token holders should understand before voting.

  1. Transparency and Governance Clarity

I would appreciate clarification on the following:

  • Do 1, 2, or all 3 DAO Council members need to approve a PIP before it is submitted for a token holder vote? What is the formal process for a PIP to move from draft to vote?

  • Can token holders see which Council members reviewed and approved (or disagreed with) a PIP before being asked to vote on it?

  • I appreciate the confirmation from community discussion that this proposal was drafted independently by the DAO Council.

As it stands, I do not feel I can support this proposal in its current form. The governance concerns outlined above, particularly around contractor selection and the operational accountability gap, need to be addressed. I would encourage the Council to revise the proposal with these considerations in mind.

These are constructive suggestions aimed at strengthening the DAO’s governance as the protocol moves toward mainnet.

Chris

2 Likes
3

Great job, let’s move forward

2 Likes
4

This is a much needed step to prevent development slowdown due to Absolutely incompetent entities! I’m in full ageement…lets get this PIP out!

2 Likes