Astar zkEVM hackathon: retroactive payment

[Juminstock]

Hello community and fellow ambassadors!

Context:

As many of you know, last month we held the Astar zkEVM hybrid hackathon in Mexico, right before Ethereum Mexico, one of the most influential events in all of Latin America, where we even had the participation of Vitalik Buterin and leaders from other L2 protocols. This hackathon also allowed us to inform and involve people in the official launch of Soneium and its testnet, Minato, for which we even hosted a technical workshop, created video tutorials, and provided over 30 hours of support.

In summary, we had 85 registrations on Devpost, 30 Astar hackers, 9 proposed projects for the Astar track, and 2 prize winners.

Winning Project #1: https://forum.astar.network/t/happ3n-xyz-arriving-astar-community
Participating Project: https://forum.astar.network/t/ucg-program-matriz

All the results of this initiative can be found here: Astar zkEVM hackathon - report - Google Docs

Problem:

It is important to note that in the initial proposal, a sum of $ASTR (119,500) equivalent to 8,600 USD was requested to cover all production and logistics costs of the event. However, due to the market situation just days before the funds were released, the price of the $ASTR token experienced a significant drop (the entire crypto market faced this issue), which disrupted the plan’s structure.

$ASTR price in the proposal (EMA 30): 1 USD = 0.072 $ASTR
$ASTR price at the time of receiving and converting the funds by CMC: 1 USD = 0.05251 $ASTR
$ASTR final conversion by Binance: 1 USD = 0.0519001 $ASTR
Difference: 2,397.938 USD = 39,967 $ASTR.

Binance deposit ↓

Final conversation ↓

Proposal:

This proposal is to request retroactive payment for the work and expenses incurred at the most recent event on behalf of Astar zkEVM and Soneium.

Requested amount in USD: 2,397.938 USD
Recipient wallet: ZJKp9fuuQihYopwLEmxZ55zU5WMpeXi95HAPRPUiGcZgZQz

[tksarah]

Hi @Juminstock,

Thank you for your report and additional proposal.
I heard about the issue you faced.

Just to confirm, am I correct in understanding that the fluctuation (downward) occurred before your proposal was approved and the funds were sent to your wallet? If the above is correct, I believe the additional request this time is understandable.
However, there are points for reflection and I think discussing them here would be beneficial for the future.

This is an important issue for raising and settling funds in similar proposals going forward. In the cryptocurrency market, it is normal for rates to fluctuate. It might have been wise to consider this when deciding the budget amount and the timing of receiving the funds in the initial proposal.

Looking ahead, if there is a known delay in the timing of using the funds, I believe there are ways to address it:

Case 1: Instead of receiving ASTR immediately after the proposal is approved, calculate and receive the ASTR based on the rate at the actual settlement time.

Case 2: After receiving ASTR, exchange it for dollars (USDC or other stablecoins).

It would be beneficial to discuss other wise methods here as well. I would like to refer to them when making future proposals.

[you425]

Thank you for your continued support.

I agree with making up this time for the lack of funds due to ASTR price fluctuations.
But as tksarah said, we need to check and set rules for the future.

@tksarah

Case 1: Instead of receiving ASTR immediately after the proposal is approved, calculate and receive the ASTR based on the rate at the actual settlement time.

Case 2: After receiving ASTR, exchange it for dollars (USDC or other stablecoins).

I think a combination of the two is appropriate.

• No need to specify the quantity of ASTRs at the time of proposal, but charge the dollar equivalent.
• The treasury management entity calculates and sends the ASTRs based on the price of ASTRs at the time of offering (should it be about 2% above the price to account for exchange fees, etc.?)
• The proposer exchanges the ASTRs into the payment currency as soon as they are received.

If we had set such a rule, I think cases like this one could have been avoided.
The top-up takes into account the amount of commission, but I do not think that a very small excess is a problem, because the event executor should avoid losing money.

[VasaKing]

I think this is a great place to start discussing and sharing opinions regarding the organization of events. Volatility is and will be an issue to include in the proposal and we can use this case to write down guidelines for next time.
I am in favor of the refund given all the activity and organization done by @Juminstock

On the other hand it should be more on the requester to include these possible scenarios. As mentioned during the discussion for the table blanket I believe that an additional 10/20% can be added to the proposal to be sent back to the treasury in case there are any left.

Actually I also like @you425 idea , this can avoid a lot of problems. Curious to read other comments.

[Juminstock]

Hi @tksarah, thanks for your comments, here my answers:

@tksarah

Just to confirm, am I correct in understanding that the fluctuation (downward) occurred before your proposal was approved and the funds were sent to your wallet? If the above is correct, I believe the additional request this time is understandable.

That’s right! The sharp drop in the market occurred days before the proposal was approved in Townhall. As you can see here I created the proposal on July 15

where the market was in good price, you can notice it here

@tksarah

This is an important issue for raising and settling funds in similar proposals going forward. In the cryptocurrency market, it is normal for rates to fluctuate. It might have been wise to consider this when deciding the budget amount and the timing of receiving the funds in the initial proposal.

I agree with you, I should have anticipated a drop when I generated the initial proposal. In my defense, I have always liked to use only the money needed for events so as not to exceed in requested amounts, but I see that it is now fair and necessary to have an item in mind that can be used in case of fluctuation.

@tksarah

Case 2: After receiving ASTR, exchange it for dollars (USDC or other stablecoins).

Yes of course, on my part I have done this in every proposal and event I have done. I use Binance because it allows me to immediately pay suppliers.

[Juminstock]

Thanks for your input, @you425!

I’m glad this case helps us to improve our treasury management, there are definitely important points to improve.

@you425

I think a combination of the two is appropriate.

I agree with this, a combination of both cases may allow us to move better with the market conditions, it is also favorable because of the fact that many providers only accept USDT or USDC as a means of payment, very few accept other crypto (at least in my context).

@you425

No need to specify the quantity of ASTRs at the time of proposal, but charge the dollar equivalent.

I am 100% in favor of this. Since we do not handle stablecoins in our community treasury, I see it timely and wise for us to implement this change. Requesting $ASTR that will be received 15,16, or 17 days after requesting it is problematic for event management, either because of the price of the token, because we have to send to produce the merch or other things.

@you425

The treasury management entity calculates and sends the ASTRs based on the price of ASTRs at the time of offering (should it be about 2% above the price to account for exchange fees, etc.?)

Usually 2% can be much more than enough, it depends where you exchange them, in DEX the exchange rate is always more favorable compared to a DEX, the advantage of DEX is that it allows you to then make the relevant payments.

[Juminstock]

Thanks for joining the conversation, @VasaKing!

@VasaKing

On the other hand it should be more on the requester to include these possible scenarios.

Definitely yes, I should have foreseen a scenario like this at the time of generating the proposal, again I apologize for not having been the case, I asked for what was necessary for the realization of the event.

@VasaKing

As mentioned during the discussion for the table blanket I believe that an additional 10/20% can be added to the proposal to be sent back to the treasury in case there are any left.

I think that 10% to cover volatility cases could be an immediate solution to problems like this, but I sincerely prefer the scenario proposed by @you425, where we no longer ask for $ASTR but the real cost in USD, so we can make a more accurate and uncomplicated management of the treasury funds.

I will use the experience I have gained in running events to seek to improve this point.

[Sequaja]

Hey.
I agree aswell to make up the for the payment this time but there need to be clear rules in the future.
Anyway thanks for you work!
Glad to see projects building and applying for grants from the hackathon

[sohobiit]

I think fluctuation is part of our days in cryptocurrencies, so maybe there can be a common budget to cover this quickly for future things, I don’t know if there will be now. But if not, I would really like to make a prop to facilitate access and solve it quickly.
Maybe it would be a good topic to bring it up here.

[Matt]

Agreed with this one!

[Juminstock]

@Sequaja

I agree aswell to make up the for the payment this time but there need to be clear rules in the future.

From here, we will propose a structure that will allow us to define these rules and be clear on future occasions .

@sohobiit

maybe there can be a common budget to cover this quickly for future things

This is another possible immediate solution: create a pool to cover future fluctuations of the token. I would think this would be a great solution in case we have to continue to apply for ASTR only.

[GuiGou]

I agree, for such proposal/expenses it would be better to use the ASTR price at the time of sending and not the one at the time of the proposal.

[MrKarahanli-Emre]

Greetings Carlos, having organized an event before, I can understand what a big problem you are facing. I support that just THIS ONCE the difference will be covered from the coffers.

To avoid similar problems in the future, you can take a look at this article I wrote before;
I am sure it will help.
''We had a similar problem and I found a 2nd sponsor due to lack of budget.

What is the solution?

Suggestion 1;

You should ask for 20% extra budget to avoid possible price movements. If there is a surplus after the event, you can send it back to the treasury.

2nd suggestion;

Another suggestion to the Astar community, let’s say in dollar terms you need $3000 for the event and the ASTR equivalent of that is $4000 in ASTR. It takes 15 days for the budget to be approved from the discussion and the ASTR price fluctuates, so the budget in dollar terms is missing (this happened with the event I organized and I found another sponsor)

Astar team on Townhall We should start voting not for 4000 $ASTR.
We need to start asking for a budget of $3000.

Option 1 if the price goes up:
The objective should always be to achieve the dollar equivalent of the cost, it does not matter if you buy more liners or if the price of the ASTR goes up/down.
That is, once the costs in dollar terms are reached, all surpluses should be returned to the treasury.

We do not face such a problem in Option 2.‘’

[pithecus]

Thanks for transparency and I also agree what @you425 suggested that the expected budget + some room to cover unexpected or common costs, etc.

[bao]

I agree with the countermeasures against price fluctuations that others have proposed. Given the timing of cash out, I think it’s reasonable to request about 20% more tokens and return any surplus to the treasury.

[you425]

Certainly there is a way to add 20% to the budget and return the excess.
However, that would create extra trust for the organizer, and that could cause trouble. Therefore, it is recommended that surpluses be kept to a minimum.

[Juminstock]

Hi @MrKarahanli-Emre, thanks for adding your opinions to the discussion.

@MrKarahanli-Emre

Greetings Carlos, having organized an event before, I can understand what a big problem you are facing. I support that just THIS ONCE the difference will be covered from the coffers.

I am aware that you faced a similar situation, I am glad that you can, from your experience, give me options that I assure you I will keep in mind for future events.

@MrKarahanli-Emre

Another suggestion to the Astar community, let’s say in dollar terms you need $3000 for the event and the ASTR equivalent of that is $4000 in ASTR. It takes 15 days for the budget to be approved from the discussion and the ASTR price fluctuates, so the budget in dollar terms is missing (this happened with the event I organized and I found another sponsor)

Astar team on Townhall We should start voting not for 4000 $ASTR.
We need to start asking for a budget of $3000.

That’s right, we have been talking about this since you proposed it and I think it is the most appropriate way to continue working with community proposals, so it will be our new working model.

[Juminstock]

I am in favor of this @you425, I think we should start working under a new model where we contemplate the following:

1. In the proposals where funds are requested from the treasury, make them only and exclusively for the total cost of the proposal in dollars, DO NOT request $ASTR until the proposal has been approved and the funds are going to be released.

2. Request a small surplus to allow the organizers to move around the cost of fees or fluctuations of the dollar itself, I believe that between 5%-10% is sufficient. The surplus should be returned.

3. At the time of showing the results, all invoices should be translated into dollars and thus make a good tracking of expenses.

[Juminstock]

Hello, Astar community and team!

Having spent the time for discussion and raised all possible points of view, I have opened the voting on the Townhall platform, you can do it here: Astar zkEVM hackathon: retroactive payment - Proposal in Townhall House Astar Network

I appreciate your participation in the voting!

[Vangardem]

Market fluctuation problems are always present. Agree that actions should be taken to try to compensate for the mismatch in event budgets due to market fluctuation, this would help a lot for future events.