Proposal [Non-consitutional]: Top-up for Hackathon Continuation Program

Proposals
1

Non-Constitutional

Abstract

Arbitrum lacks an efficient mechanism to swap funds for projects, which has led to multiple challenges for service providers around token price changes. Specifically, the Hackathon Continuation Program is currently underfunded by $89,980 USD due to token price drop before RnDAO received any funds.

Beyond usual market risks, the program faced prolonged market risks due to delays as we worked with the Arbitrum Foundation on an improved fund management system for DAO-led investments, creating a valuable process template for the Arbitrum ecosystem, but exposing us to this situation.

This proposal suggests using a portion of the Domain Allocator (i.e. Questbook grant program) funds left over from the season 1 (a bit over $200k, due to be returned to the DAO) to “top up” the Hackathon Continuation Program and allow it to continue as approved by the DAO.

We’ll also propose an option in the vote for the remaining funds from the Domain Allocator season 1, to be sent to the Treasury Management Committee to increase their stablecoin pool. Said pool could be used by service providers in the future to cover shortfalls as per a process to be designed by the TMC (see their first draft here).

Rationale

What’s the current status and why did the shortfall happen?
The Hackathon Continuation Program is divided into two phases, with separate payments for each. The MSS holds enough funds to complete payments for projects in Phase 1 of the program and has some USDC remaining for Phase 2 but not enough to complete the program.

The complexity of this specific initiative (the first investment program setup via the DAO) meant we needed to figure out a system for fund management for investments. The initial approach proposed would have required additional bureaucracy (register RnDAO signers and the RnDAO multisig setup for project investments as part of the AF) and so, in cooperation with the Foundation, we devised an improved approach that would see RnDAO scheduling payments directly on the MSS while the MSS signers would approve payments.

The system devised can be used moving forward to facilitate future investment programs, unlocking a valuable milestone for the DAO to test investments and improve the ROI of ecosystem development programs. However, the money requested was to be paid in stables, and the conversion didn’t happen immediately.
Seeing the market drop, in coordination with the AF, RnDAO tried to delay the swapping of funds as long as possible to allow for a market recovery; unfortunately, the price didn’t recover in time, and it was required to swap at a reduced token price to meet the program obligations for Phase 1. Leading to a budget shortfall for Phase 2.

Advancing the program is time-sensitive, as the projects are now expecting the funding and support to progress. Any further delays could cause them to fail or migrate to other ecosystems.

Is this a precedent?

The funds left over from Season 1 of the Domain Allocator programs are due to be returned to the DAO. Authorising a transfer to the MSS for usage in the Hackathon Continuation Program (HCP) (while the rest of the funds are sent to the DAO/AF) would be a one-time action that would provide timely reassurance to the HCP projects. Given that the rest of the funds would be returned, this approach would not become a recurring mechanism in the DAO.

What about the Domain Allocator programs?

Both programs follow the same objective of supporting builders in Arbitrum.

The approach proposed in this proposal was suggested by @jojo as a viable route, given the small sums needed and the availability of the funds.

What about the Treasury Management Committee and the checking account?

The TMC V 1.2 proposal sets $ 15 million USD equivalent to be converted to Stables and serve as a reserve for service providers. The TMC has proposed a mechanism based on using the yield of this reserve, which will take time to accrue. As such, the proposed strategy can cover a short-term gap in the proposed mechanism.

Calculation of the exact amount:

As per the AF post (Hackathon Continuation Program - #149 by Arbitrum), 2 Arb were left after Phase 1. However, having eliminated one project that underdelivered from Phase 1, we have saed an additional $12k (held in the MSS). Bringing the shortfall for Phase 2 to: $101,980 - $12,000 = $89,980 USD.

Specifications

This proposal authorises the transfer of $89,980 USD of the leftover funds from the Season 1 Domain Allocator program’s SAFE, to the Arbitrum Foundation, and from the AF to the MSS for the Hackathon Continuation Program.
This transfer route was selected for compliance reasons.

Addtionally, an option to send the leftover funds (after covering the 89k needed for the Hackathon Continuation program) to the Arbiturm Foundation and from there to the Treasury Management Committee.

Budget

No additional funds from the DAO are needed. Just the authorisation to use the leftover from Domain Allocator season 1.

Voting options

A. only top-up the HCP: top-up the HCP and leftover funds to the DAO
B. yes to both: top-up the HCP and leftover funds to the TMC
C. againts:all funds to the DAO (don’t top-up the HCP nor TMC)
D. abstain

5 Likes
2

This seems very reasonable.

It also is a moment to remember this would normally be a job for the TMC assets, and is why a smooth process needs to be built out so smaller requests don’t require navigating through votes for already authorized expenses.

We encourage others to please head over to that related thread and comment; the current plan proposed needs more fleshing out and optimizing. It would be a good idea to get that done sooner rather than later, since the current TMC process isn’t yet ready for a vote in our view.

5 Likes
3

It makes sense to use the leftover funds from the Domain Allocator (Questbook) Season 1 program, especially since those funds were meant to support Arbitrum projects in the first place. That said, we do have some concerns about setting a precedent for this kind of reallocation. While it’s needed in this case, we wouldn’t want this to become a regular thing. It’s important to make sure the DAO sticks to its usual process of returning unused funds to the treasury, and we think there’s room to improve the overall process for handling such situations in the future. Overall, we’re on board with this proposal as a one-time fix, but we’d like to see clearer guidelines going forward.

1 Like
4

Hey

Full agree we need a process for toping up programs after this proposal. It’s really a pain to have to go through this process as a service provider.

Part of the goal of the TMC v1.2 proposal was to address this need but to date we dont have a good solution in place.

Then, there’s also a general objective in the DAO to increse the stables allocation. And these two objectives are competing when it comes to thr TMC.

Having a repeatable process is of course a bigger discussion and we ask the DAO to approve the proposal above as a short term measure to ensure the program doesn’t default and leaves the builders stranded.

We’ll continue supporting the conversation to develop an effective mechanism that replaces service providers directly having to ask the DAO to repurpose unused funds every time (which is a pain for everyone).

2 Likes
5

Supportive of allocating the leftover funds in this way

1 Like
6

I agree with this. It’s not about setting a precedent, I think it’s flexible solution to a situation no one wanted. The most important thing here is maintaining Arbitrum DAO’s trust with developers.

But let’s circle back, this happened because funds were in ARB while expenses were in USD. No stablecoin conversion was done. That delay felt more like speculation than risk management, tbh.

Going forward, I think DAO should require that X% of any USD based grant be swapped to stable within Y days of receiving funds. That’s risk control I think will work.

I also wonder, what if there’s no leftover fund next time? Who covers the shortfall?

Maybe it’s time we set up an emergency reserve fund. We got lucky this time with unused Domain Allocator funds, but we can’t rely on luck forever.

I support this proposal, just let’s make sure it’s a one time solution, and a learning moment to tighten how we handle funding risks.

5 Likes
7

hello, let me chim in. I was reached out first from @Brick that mentioned to me this problem Daniel had, and if it was viable to utilize old funds.
We were in the (rather slow) process of gather leftover funds from Season 1 regardless, to send them back to the DAO, and took a while due to the setup of the safes of each domain. As of today, this is the current situation of the aforementioned safe

image
image1928Ă—656 52.2 KB

Being that these funds were either assigned to protocols that didn’t complete their grant path, or did forfeit that grant, or just unassigned, reallocating to other projects doesn’t affect in any chance any operation.

I don’t think this is should be framed as a “precedent”: the amount the Hackaton need is rather small for the amount the DAO is used to handle to initiative, and at the same time is key for them to finish the initiative and for us to understand if this type of new initiative is viable (grant as investment with intermediate judgment from commission).
Personally would say that not allocating some of these leftover funds to the Hackaton would indeed create more disruption than doing it. So totally in favor of the initiative.

Quite unrelated, it could make sense to pass the net remaining part of stablecoins, after funding the hackaton, directly to the TMC for the stablecoin management: we have assets such as bridged usdc, nowadays kinda deprecated, that would need a conversion regardless. At this point let’s just put it to use. Food for thoughts.

6 Likes
8

Thank you for the proposal, @danielo!

We support this top‑up because the shortfall has already occurred and, while the amount is far from negligible, we believe it is a reasonable cost to keep a DAO‑approved initiative on track.

At the same time, the way funds are distributed clearly needs streamlining as some already pointed out. We believe it would be effective to introduce an optimistic governance approval process similar to Lido’s Easy Track and a portion of the proposal by ImmutableLawyer, in which if a request stays within a preset budget and matches its stated purpose, it could progress without a full DAO vote. The process is such as below; simply post a forum notice, allow a short veto period for a few days, and treat the request as approved if no objections arise.

Looking ahead, although this measure would not fix the current shortfall, each future budget should set, in addition to its USD‑denominated amount, a hard ceiling on the number of ARB tokens that can be paid if prices fall sharply. This is already implemented in the delegate reward structure. This safeguard would let prevent the DAO from overspending relative to its treasury during periods of extreme volatility.

For example, imagine a grant budgeted at $5,000 with an ARB cap of 25k ARB. If, at the time of payment, 25k ARB is still worth at least $5,000, the grantee receives the full $5,000. If the market has dropped so far that 25k ARB is worth less than $5,000, the grantee receives the capped amount of 25k ARB instead.

4 Likes
9

Thank you for putting up this proposal. It seems like a good one-time solution due to market volatility. We should honor the projects that participated in the program. In the future, we should prioritize the timely selling of Arb over Arb price speculation to meet the funding requirements when they are denominated in dollars.

2 Likes
11

We fully support this reassignment request, as the projects participating in the hackathon should not lose the support already approved by the DAO. However, as a clarification, it might be helpful to add to the proposal a list of the projects that would be affected if Phase 2 is not completed. We believe this information is crucial for everyone to understand the value we risk losing if these projects fail or migrate to other protocols, as indicated in the proposal.

Furthermore, we do not believe this sets a bad precedent, rather a positive one, as it is a unique solution that has proven to be both viable and timely.

We also fully support the development of a faster mechanism that removes the need to submit full proposals to request funds in such situations. We endorse the suggestion of implementing a program similar to Lido’s, as it offers a quick way to address these issues or allows the TMC to handle such cases in the near future.

1 Like
12

We support this proposal and appreciate the team’s transparency around the shortfall. Ensuring the continuity of support for early-stage projects coming out of the hackathon continuation program is important—not just for the builders involved but for sustaining long-term credibility with the broader developer community.

That said, this type of post-hoc top-up should remain the exception, not the norm. While we agree with the use of unallocated funds in this particular case, it’s important that we evolve toward more proactive financial practices. We agree with suggestions from @Tane around potentially implementing a hard cap on budgets similar to DIP as well as @GFXlabs on working to streamline a process to pull from TMC accrued yield.

1 Like
13

i think supporting this proposal is a no‑brainer if we care about keeping being congruent with what we already approved and our strategy to support builders. This are some of my thoughts:

  1. We’ve already done the “heavy lifting”. We have alrredy approved the initial proposal and we should continue to do to enshure the golas are met. OFC we dont want to be toppoing lack of funds but we can do a one time and desing future payments in a way they can be fastly converted.

  2. Zero extra spend. By redirecting just $89,980 of those leftover Domain Allocator funds to top up the Hackathon Continuation Program, we can immediately put to use left over funds that were alrready allocated to building and to the projects that have invested their sweat and ideas in Arbitrum. It’s a one‑off tweak that doesn’t change our budget or create a recurring drain—everything else still returns to the DAO as planned.

  3. Exception. I think we should make it clear we will not be doing this for other programs and this is a unique time since the market has suffered a lot and they had no way of converting the funds.

3 Likes
14

I support the proposal. This is a pragmatic, one-time fix to keep a DAO-approved initiative on track and maintain trust with builders, especially given the time-sensitive nature of these projects.

However, I share @‌Curia’s concern about adhering to the DAO’s process of returning unused funds to the treasury. Beside, the month-long proposal process for shortfall requests, as seen here, is a significant hurdle for service providers facing ARB volatility.

The TMC’s proposed stablecoin withdrawal process is a step forward but falls short for urgent cases like HCP. I proposed a suggestion here to add on TMC’s proposal.

TMC’s proposed process aims to streamline the procedure for projects with budget shortfalls to request additional stablecoins from TMC. However, we believe that it’s necessary for the DAO, AF, and TMC to have better visibility over the budget status of all the live projects so as to how much has been spent, how much will be spent, if there’s going to be any shortfall, and how much will be left to prevent the situation HCP is facing from happening again.

The suggestions I’ve made adding on TMC’s proposed process and make it compulsory for projects to report to TMC monthly regarding budget status so that the DAO, AF, and TMC can keep track of the budgets approved, move proactively in case any shortfalls, and be aware of any unspent budgets that need to be clawed back.

15

Overall, we agree that using a portion of the excess funds from Questbook’s grant program is a sensible option.

However, we would like to clarify the point made around delays in converting the ARB. The Arbitrum Foundation uses the same process to convert funds for every proposal that requires it. As there was no conversion process specified in the original proposal, we offered to convert the funds on behalf of the initiative once it passed. By the time we received the funds from the MSS, market conditions meant that the requirement could not be met. At that time, there was a hope that the market might soon recover to achieve the desired conversion. Unfortunately, this has not yet happened and the Hackathon Continuation Program requires a top up of funds for Phase 2.

It might also be worth including that as this proposal does not require any additional funds from the DAO Treasury, it would only require a Snapshot vote that meets Non-Constitutional quorum, to pass.

8 Likes
16

I support the distribution of funds allocated to other programs that have already ended.

I understand that the current program is important and there is no point in leaving it halfway.

However, I would like to understand what we are going to do. The problem could have arisen for any program with a sharp decrease in the cost of the ARB.
So - how are we going to solve this problem? Is there a standard and comprehensive approach that is guaranteed to eliminate this problem? Why did the AF coordinators expect some increase in the cost of the ARB with an obvious downward trend?

In general, the main thing that I would like to resolve in this proposal is how to eliminate this in the future

2 Likes
17

Hi @danielo, we support the utilization of funds from S1 of the Domain Allocator program for the Hackathon Continuation.

However, echoing @Curia’s earlier comment, this should not become precedent in the way requests for topping up of funds should be handled in future. We consider this a one-off request and are agreeing to it on the basis of providing necessary funds in a timely manner in support of the teams participating in the program.

1 Like
18

The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.

We support this reallocation as a practical solution to a time-sensitive need, especially since it avoids requiring converting fresh capital from the DAO. That said, as other delegates mentioned, we see this as a clear reminder that smoother, predefined processes, especially through vehicles like the TMC, are essential for smaller or urgent top-ups. It would benefit the DAO to build clearer operational guidelines for how such contingencies can be handled in the future without relying on exceptional proposals.

We also suggest that, as HCP gets funded for Phase 2, a short report or lessons-learned summary be shared afterward by @danielo. This would help us all better plan for volatility-related gaps and avoid repeating the same issues in future builder-focused programs.

2 Likes
19

The TMC is charged with working on said approach and has posted a suggested process: TMC - Stablecoin Withdrawal Process

It will take some time to converge on the process, hence the proposal above as a short-term fix. We’re committed to working with the DAO by helping the TMC to devise a robust process moving forward.

1 Like
20

Happy to provide this. The TLDR of our learnings is that for investment programs (outside of any future CapCo or so), the fund management process should include the MSS directly holding the funds and transferring to the investees. Our original proposal included RnDAO mnagaing a separate multisig for said funds and executing the investment schedule.

As the @arbitrum.foundation is getting more involved in providing feedback to proposals, I’m hoping they can also advise on compliance and fund management procesess moving forward. This si of course up to them to decide but having this proactive advice form them instead of relying on the service providers to devise a good process feels like an improvement.

Finally, I think the DAO should setup a double tier strcuture for funding requests, where small asks by small service providers are always paid in stables. Small providers don’t have robust in-house capabilities for treasury management and so it would be more cost efficient for Arbitrum to handle swaps to stables directly.
The foundation is currnetly providing a helpful hand in swaping stables for small programs, but this mechanism is not ideal and hurt us badly. We’d prefer having a specialised team (within the foundation or separate) that can provide such service and be made a default (akin to how the MSS has been setup).
This would mean the creation of a stables fund for small service providers (e.g. requests below $250k), say $5mn where the Arb can be converted proactively during favourable market conditions by a team of traders charged with said responsibility.

Meanwhile, large programs can have custom treasury management or add budget to the service providers fund.

The TMC has also a “checking-account” setup for emergencies. But I wouldn’t try to use said account for all smalls ervic eprovider payments.

3 Likes
21

The proposal has been updated to incorporate the option to send the funds (left after topping-up the Hackathon Contiuation Pogram) to the Treasury Management Committee to increase the stabelcoins allocation available for future service provider shortfalls as per the process that the TMC is mandated with designing.

1 Like