Astar Network Treasury Proposal Guidelines, Rules and Template

[cryptoium]

Hello Astar Community,

To ensure a consistent approach to using the Astar onchain treasury, I propose the following guidelines, rules, and template for both on-chain and community treasury funding proposals. Adhering to this process will enable the community to easily access crucial information needed to evaluate and vote on proposals. The same clarity benefits the Main and Community Councils in their decision-making.

If you believe any elements are missing, please feel free to suggest amendments or improvements to our proposal.

Astar Network Treasury Proposal Guidelines

1. A General Proposal Preparation

When planning to request funding from the on-chain treasury, proposers have two options:

• Public Referendum
• Main Council Proposal

Both options should maintain the same level of transparency, follow a similar proposal framework, and provide consistent information. However, in a Public Referendum, ASTR token holders vote, while in a Main Council Proposal, only the Main Council votes.

The process for creating a proposal on Subsquare varies depending on the option chosen. Please refer to the documentation for more information on Public Proposals and Main Council Treasury Proposals.

1.1. Regular Public Proposal/Referendum

• This follows the standard process for any proposal.

• Proposals should adhere to the established guidelines and use the official template.

• ASTR holders will vote to approve or reject the proposal.

• Incorporate considerations for infrastructure costs, event-related expenses, and system integration requirements when preparing general treasury proposal guidelines.

• Larger Treasury proposals (1M ASTR and above)

1.2. Treasury Proposal to the Main Council

• The proposal is submitted directly to the Main Council, which will decide whether to approve or reject it.

• Thorough Research and Testing:

  • Ensure your idea is well-researched and tested.
  • Provide examples of prior work or prototypes to demonstrate feasibility.

• Open Source Commitment:

  • Align with the community’s ethos by making your proposal is transparente.
  • This transparency allows the community to learn from and build upon your work.

• Team Qualifications:

  • Detail the background of your team members.
  • Highlight relevant experience to instill confidence in your ability to achieve proposed milestones.

• Detailed Proposal with Milestones:

  • Develop a comprehensive proposal with clearly defined milestones.
  • Specify the use of funds for each milestone to ensure transparency and accountability.

• Alignment with Astar’s Principles:

  • Ensure your proposal aligns with Astar’s guiding principles and code of conduct.
  • Demonstrate respect for community values and objectives.

2. Community Engagement

• Forum Discussion:

  • Before formal submission, present your proposal on the Astar Community Forum.
  • Engage with community members to gather feedback and refine your proposal accordingly.

• Feedback Period:

  • Allow a minimum of sevendays for community discussion and feedback.
  • Use this input to make necessary adjustments to your proposal.

3. Proposal Submission

Proposal Bond:

• Submit a proposal bond equivalent to a percentage of the requested funds (e.g., 5%), with a minimum threshold (e.g., 100 ASTR and max 1000 ASTR).

• This bond deters spam and ensures commitment.

• On-Chain Submission:

  • After incorporating community feedback, submit your proposal onchain via the Subsquare.
  • Ensure all details are accurate and complete to facilitate a smooth review process.

4. Review and Approval

• Council Evaluation:

  • The Astar Treasury Council or the ASTR holders will review your proposal, considering community feedback and alignment with network goals.

• Voting Process:

  • Council members will vote on the proposal within a specified period (e.g., 3 days).
  • A majority vote is required for approval.

• Outcome Notification:

  • You will be informed of the decision.
  • If approved, funds will be disbursed after the current spend period.
  • If rejected, the proposal bond may be forfeited.

Treasury Proposal Rules for Astar Network:

Amount requested in ASTR tokens.

To ensure fairness, consistency, and transparency in treasury proposals, the following rules shall be applied when calculating the requested amount for Grants:

1. Use of 30-Day Average Exchange Rate

• Requirement:
  The requested amount in treasury proposals must be calculated using the average Astar/USD exchange rate over the last 30 days.
• Data Source:
  The official source for the exchange rate will be Subscan : Subscan | Astar Chart: Daily ASTR Price
• Calculation Method:
  The 30-day average should be calculated by summing up the daily closing rates over the last 30 days and dividing the total by 30.

2. Transparency in Calculation

• Supporting Documentation:
  • A link to the Subscan data or equivalent source.
• Verification:
  The data must be verifiable through a publicly accessible source.Below is Example Reference of on the day of proposal.

Must be updated on the day of the publication

3. Timeliness of Data

• Cutoff Date:
  The 30-day period for calculating the average must end no more than 3 days prior to the date the proposal is officially submitted.
• Adjustment for Delays:
  If the proposal review process exceeds 7 days, the calculation must be updated to reflect the most recent 30-day period.

4. Exceptions

• Extraordinary Market Conditions:
  During significant market volatility for the ASTR/USD rate, the proposer may request a retroactive refund for any loss incurred once the funds are received, compared to the USD value initially requested. To do so, a new treasury proposal must be submitted to the Main Council, explaining the situation and requesting compensation for the volatility loss.

5. Implementation and Compliance

• Submission Requirements:
  Proposals that fail to follow these rules will be considered invalid, declined by the Main Council or the community and returned for revision.
• Review Process:
  The Main council or designated review team can be requested to verify compliance with these rules before the proposal to proceed to a vote.

These rules aim to promote equitable practices for managing treasury funds while ensuring the process is clear and accountable for all participants.

Astar Network Treasury Proposal Template

1. Proposal Title

• Descriptive Title of the Proposal

2. Proposal Overview

• Project Name: Name of the Project
• Proposer: Your Name or Team Name
• Recipient Address: The ASTR address designated to receive the funds.
• Contact Information: Email Address or Other Contact Details
• Submission Date: Date of Submission

3. Proposal Description

• Objective:

  • Clearly state the goal of the proposal.

• Background:

  • Provide context and relevance to the Astar Network.

• Deliverables:

  • List the expected outcomes and actions.

4. Team Information

• Team Members:

  • Name and Role of Each Member

• Experience:

  • Brief overview of relevant experience and qualifications.

5. Proposal Plan

• Methodology:

  • Describe the approach and techniques to be used.

• Milestones and Timeline:

  • Outline each milestone with an estimated completion date.

6. Budget Breakdown

• Total Funds Requested: Total Amount in ASTR

• Detailed Budget:

  • Itemized list of expenses associated with each milestone.

7. Alignment with Astar’s Principles

• Describe how the proposal aligns with Astar’s guiding principles and code of conduct.

8. Community Engagement

• Forum Discussion Link: URL to the discussion thread

• Feedback Summary:

  • Summarize the feedback received and any changes made to the proposal as a result.

9. Risk Management

• Identify potential risks and mitigation strategies.

10. Conclusion

• Summarize the proposal and express readiness to proceed.

[you425]

Thank you for the proposed guidelines.
This will make it easier to use for various activities, as there has been nothing in the documentation regarding treasury proposals.

Regarding requesting funds, we have talked before in other topics about charging a little extra for variable risk and returning the funds after payment. For example, when organizing an event like the IRL, it is not desirable to put a financial burden on the organizer.
Is it correct to assume that the pattern of “returning the surplus after payment” has the drawback that it requires trusting the biller, which is also the reason for the proposal of “charging an additional amount in case of loss due to price fluctuation” as proposed this time?

[Juminstock]

Hello, @cryptoium! Thanks for adding this important topic to the Astar community forum and for taking the time to create a structure that can work.

I had always thought that we needed a standard and I was just working on coming up with a way that all of us in the Astar community forum could speak the same language, in this case, talking about the proposals. That is why I see value in the structure you propose, I see it as very complete covering the vital points of all community initiatives (such as events) and projects (inclusion in the dapp staking or project funding).

I have taken the time and designed a word document that could serve as our community template for requesting funds from the treasury, in it you will see all the points discussed here and in the header I have included two more points (short description of the proposal and project category) so that when we see the header, we already have an overview of what the proposal is about.

Here I share the document → Astar treasury proposal template

Just open the link and make a copy or download the document to use .

I hope it will be taken as a document that will be useful for new proposals.

[DrCAO]

Thank you for the effort and thoughtfulness in putting together these comprehensive guidelines for Astar Network’s treasury proposals! Establishing clear rules and a structured process will certainly help streamline proposal evaluation and improve transparency for both the community and council members. It’s a crucial step toward fostering consistency in treasury management.

That said, I have a couple of suggestions for further improvement:

1. Proposal Bond Clarification:
   While the bond requirement (5% of requested funds, between 100-1000 ASTR) is outlined, it would be helpful to provide more clarity on the bond’s outcome if a proposal is rejected. Specifically, will the bond be fully forfeited, partially refunded, or returned under certain conditions? Or do you mean that is just deposit and will return back after the proposal is decided?

2. Market Volatility Adjustment:
   The guidelines mention that during extraordinary market conditions, proposers may submit a separate proposal for compensation if they incur losses due to exchange rate fluctuations. I suggest defining clear criteria for what constitutes “extraordinary market conditions” to ensure that such requests remain objective and avoid ambiguity. I guess the price difference between the proposal is submitted and the Astar received may be considered, another idea is to propose the stable coin amount in the budget and it will be converted to Astar when get paid?

[Juminstock]

@DrCAO

Proposal Bond Clarification:
While the bond requirement (5% of requested funds, between 100-1000 ASTR) is outlined, it would be helpful to provide more clarity on the bond’s outcome if a proposal is rejected. Specifically, will the bond be fully forfeited, partially refunded, or returned under certain conditions?

Very good point, mate! You are right that we should define those extraordinary market situations and set guidelines to execute in case it happens. What I raise in this point is that if the additional $ASTR requested in the proposals is used, justify it by attaching the expense supports, otherwise, it should be returned immediately… simple.

@DrCAO

Or do you mean that is just deposit and will return back after the proposal is decided?

No, for me it should be returned once the proposal is made and if it was not used, it is returned, if it was used, justify in what, why and what was the benefit of doing so.

@DrCAO

I suggest defining clear criteria for what constitutes “extraordinary market conditions” to ensure that such requests remain objective and avoid ambiguity. I guess the price difference between the proposal is submitted and the Astar received may be considered, another idea is to propose the stable coin amount in the budget and it will be converted to Astar when get paid?

Now, with respect to retroactive payments, to me an extraordinary situation is if the fluctuation of the $ASTR exceeds the additional 5% that was requested in the proposal to cover that fluctuation, as this will surely end up being covered by the proposer.

[cryptoium]

Thank you @you425.
For the unexpected costs (like price changes or surprises during events) but also for the challenge of trusting proposers to return any unused money.

Maybe adding a Small Buffer:
Proposers can ask for a little extra (say, 10-15% of their total budget) to cover unexpected costs.
After the project or event, they’d return any leftover money to the treasury. This way, they have some flexibility, but the community’s funds are protected.

All Transparent:
After the project, proposers should share a detailed report of how they spent the money, including receipts or proof.
The community or a council can review this to make sure everything adds up. If someone misuses funds or doesn’t return the surplus, they could face consequences, like being blocked from future funding.

[Juminstock]

@cryptoium

Proposers can ask for a little extra (say, 10-15% of their total budget) to cover unexpected costs.

I support this.

@cryptoium

The community or a council can review this to make sure everything adds up. If someone misuses funds or doesn’t return the surplus, they could face consequences, like being blocked from future funding.

One thing we need to work on, and I self-assign the task, is to establish a model that works for global invoices.

Example, all funding in Astar is delivered in $ASTR and is expected to be spent in USD, but for example in my country, Colombia, our local currency is the Colombian peso and very few companies generate you an invoice in USD, so when it comes to justifying those expenses there can be conflicts of interpretation, either because the wrong conversion rate is used or because the community reviews it and does not understand the actual expenses.

That is why I was thinking of building an application with ZK and Attestations technology to generate receipts based on the information that I provide and that we could use as a standard to justify expenses, we can use oracles that help to get the real price of local currencies and thus, transparently, not having to enter this rate but the system itself does it and gives witness that an appropriate action was made.

I propose this

[DrCAO]

Nice, I like what you proposed, it would be great to update the template and include those suggestions to make it more clear

[Juminstock]

@DrCAO
It would be great to include it in the staff, of course! But first we need to work on the template so that anyone who uploads a proposal and has expenses in their local currency can easily validate it and convert it to USD at the market rate.

For me the next actions to execute are:

• Establish a methodology where proposers put the market rate of their local currency/USD and attach it to the report.

• Add this to the template.

• Model a system that can make this easier for users and community members reviewing proposals.

[DrCAO]

@Juminstock
Great idea, really like the idea of the template so that everyone can follow it, that can also save the time of reviewing future proposals. For the currency, would the USD be easier? if they had local currency, maybe better convert it into USD as well, so the final budget would be using USD which would be easier for community members to review.

[Juminstock]

@DrCAO

For the currency, would the USD be easier? if they had local currency, maybe better convert it into USD as well, so the final budget would be using USD which would be easier for community members to review.

Exactly! The idea is to set up a USD based model so that it would be very easy for proponents and community members to review and ensure that all costs were actually covered, it would be very efficient to do it that way.

I commit to upload next week a structure to solve this problem, I will be working on it over the weekend .