Non-Constitutional
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).
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 (https://forum.arbitrum.foundation/t/hackathon-continuation-program/27492/149), 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.
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.
No additional funds from the DAO are needed. Just the authorisation to use the leftover from Domain Allocator season 1.
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
Non-Constitutional
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).
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 (https://forum.arbitrum.foundation/t/hackathon-continuation-program/27492/149), 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.
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.
No additional funds from the DAO are needed. Just the authorisation to use the leftover from Domain Allocator season 1.
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
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/61?u=princetonblockchain
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/60
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/61?u=princetonblockchain
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/60
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/57
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/52?u=ocandocrypto
The Event Horizon Community voted YES TO BOTH on this proposal (ehARB-98): EventHorizon.vote/vote/arbitrum/ehARB-98
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/55?u=0x_ultra
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/54
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/18?u=tekr0x.eth
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/49?u=griff
I like rubber stamping things that didn’t actually need to happen and contribute to achieving an imaginary quorum of 130,752,756.914717982009274266 ARB as of the ETH block 22375793 at the timestamp of the start of this offchain vote. https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/48?u=paulofonseca
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/17?u=castlecapital
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/46?u=danielm
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/45?u=mcfly
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/22?u=maxlomu
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/34?u=hawheik
Voted in favor of both & looking forward to OpCo taking on a more holistic treasury management approach
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/13?u=gabriel
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/36
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/35?u=euphoria
- Supports builders we already committed to - Uses leftover funds, no new spending
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/32?u=bruce
voting on both. did organize the consolidation of funds + personally proposed to send leftover to tmc, think both makes sense from an operational standpoint
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/29?u=0xalex
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/57
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/52?u=ocandocrypto
The Event Horizon Community voted YES TO BOTH on this proposal (ehARB-98): EventHorizon.vote/vote/arbitrum/ehARB-98
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/55?u=0x_ultra
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/54
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/18?u=tekr0x.eth
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/49?u=griff
I like rubber stamping things that didn’t actually need to happen and contribute to achieving an imaginary quorum of 130,752,756.914717982009274266 ARB as of the ETH block 22375793 at the timestamp of the start of this offchain vote. https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/48?u=paulofonseca
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/17?u=castlecapital
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/46?u=danielm
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/45?u=mcfly
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/22?u=maxlomu
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/34?u=hawheik
Voted in favor of both & looking forward to OpCo taking on a more holistic treasury management approach
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/13?u=gabriel
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/36
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/35?u=euphoria
- Supports builders we already committed to - Uses leftover funds, no new spending
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/32?u=bruce
voting on both. did organize the consolidation of funds + personally proposed to send leftover to tmc, think both makes sense from an operational standpoint
https://forum.arbitrum.foundation/t/proposal-non-consitutional-top-up-for-hackathon-continuation-program/29064/29?u=0xalex
The following reflects the views of GMX’s Governance Committee:
We acknowledge the challenges service providers face in managing funds in ARB, including the fluctuations in ARB token price and the conversion to stablecoins. While some of these fluctuations and potential shortfalls might be somewhat anticipated, we recognize the complexities and constraints that come with this process.
The following reflects the views of GMX’s Governance Committee:
We acknowledge the challenges service providers face in managing funds in ARB, including the fluctuations in ARB token price and the conversion to stablecoins. While some of these fluctuations and potential shortfalls might be somewhat anticipated, we recognize the complexities and constraints that come with this process.
The delay here appears to have primarily been a result of the desire to work with the Arbitrum Foundation on an improved fund management system for the DAO. So there’s a good rationale for the delay, shortfall, and this request for a budget top-up.
The need for timely funding for the involved HCP projects is genuine. A lot rests on these distributions, they are time-sensitive, and further delays could have very negative and unjust consequences.
Given the limited budget and the urgency of the situation, we’re in favour of authorising the one-time use of the leftover funds from Domain Allocator season 1. We'll vote for Option A.
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.
The following reflects the views of GMX’s Governance Committee:
We acknowledge the challenges service providers face in managing funds in ARB, including the fluctuations in ARB token price and the conversion to stablecoins. While some of these fluctuations and potential shortfalls might be somewhat anticipated, we recognize the complexities and constraints that come with this process.
The following reflects the views of GMX’s Governance Committee:
We acknowledge the challenges service providers face in managing funds in ARB, including the fluctuations in ARB token price and the conversion to stablecoins. While some of these fluctuations and potential shortfalls might be somewhat anticipated, we recognize the complexities and constraints that come with this process.
The delay here appears to have primarily been a result of the desire to work with the Arbitrum Foundation on an improved fund management system for the DAO. So there’s a good rationale for the delay, shortfall, and this request for a budget top-up.
The need for timely funding for the involved HCP projects is genuine. A lot rests on these distributions, they are time-sensitive, and further delays could have very negative and unjust consequences.
Given the limited budget and the urgency of the situation, we’re in favour of authorising the one-time use of the leftover funds from Domain Allocator season 1. We'll vote for Option A.
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.
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.
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.
I’ve voted in favour of this proposal because it directly addresses a funding shortfall in the programme, which happened because of a delay in converting ARB to stablecoins during market drop. IMO it's practical to use leftover funds which were anyway due to be returned to the DAO from the Domain Allocator's 1st season. Re:precedent, I don't think it's a strong precedent because the approach is clearly described as a one-time action to prevent immediate project disruption, and all delegates are clearly in agreement on this point. Incorporating the FND's comment and feedback on why the ARB conversion process got delayed I think it'd be a good experience both for the hackaton team and for future programmes for the ideation and planning-ahead of the moving and conversion of funds. I think the path laid here is OK.
Voted abstain due to conflict of interest (a bit grey zone but anyhow)
I’ve voted in favour of this proposal because it directly addresses a funding shortfall in the programme, which happened because of a delay in converting ARB to stablecoins during market drop. IMO it's practical to use leftover funds which were anyway due to be returned to the DAO from the Domain Allocator's 1st season. Re:precedent, I don't think it's a strong precedent because the approach is clearly described as a one-time action to prevent immediate project disruption, and all delegates are clearly in agreement on this point. Incorporating the FND's comment and feedback on why the ARB conversion process got delayed I think it'd be a good experience both for the hackaton team and for future programmes for the ideation and planning-ahead of the moving and conversion of funds. I think the path laid here is OK.
Voted abstain due to conflict of interest (a bit grey zone but anyhow)
100% agree on this, the only viable option IMO.
Voted FOR
After consideration, the @SEEDgov delegation decided to vote “YES TO BOTH” on this proposal at the Snapshot Vote.
Rationale
We view this proposal as a one-time, transitional fix to address the issue stemming from the lack of sufficient funds to fulfill the Hackathon Continuation Program (HCP).
After consideration, the @SEEDgov delegation decided to vote “YES TO BOTH” on this proposal at the Snapshot Vote.
Rationale
We view this proposal as a one-time, transitional fix to address the issue stemming from the lack of sufficient funds to fulfill the Hackathon Continuation Program (HCP).
The funding gap was caused by market fluctuations in the ARB price, and the delay in conversion is not attributable to the proposer.
This proposal addresses the issue by reallocating leftover funds from Season 1 of the Questbook program to the HCP, allowing it to proceed as originally approved by the DAO. It accomplishes this without requiring additional funds from the DAO and only needs a Snapshot vote meeting the non-constitutional quorum.
We also supported redirecting the remaining funds from the Season 1 Domain Allocator program to the TMC, rather than returning them to the DAO, to strengthen the TMC’s stablecoin reserve for service provider payments shortfalls.
Additionally, SEEDGov believes a framework should be established to manage surplus funds from multisigs that are not denominated in ARB. We highlight this need because it is likely we will continue to find leftover funds in USDC and other tokens—for instance, in Questbook Season 2—and currently there is no clear procedure outlining how such funds should be handled. @Entropy tagging for visibility on this.
Thanks for your comments.
A public summary with basic metrics would help justify this exception.
DAOplomats voted FOR this proposal on Snapshot.
We were in favor of both the top-up and sending the extra funds to the TMC.
Sending the leftover funds from the D.A.O Season 1 program as a top-up for the hackathon was the most optimal path forward, and Jojo's suggestion to send the remainder of the funds to the TMC was great.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the top-up, as well as for moving the extra funds to the TMC.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the top-up, as well as for moving the extra funds to the TMC.
Per our previous comment, we support the proposed solution to the HCP's shortfall. It’s a relatively easy way to address the problem without creating new ones for the DAO.
We're not opposed to routing the remaining funds from Questbook’s S1 to the TMC, as the amount is relatively small and it would be easier to mobilize through the TMC than it would be if they were sent back to the treasury.
The PBC Governance team is voting FOR both topping up the HCP and sending the extra funds to the TMC, as it's a effective one-time fix for the funding shortfall.
We voted "Yes to both" for this proposal. Our feeling is that this works as effectively as a one-time solution to an unfortunate situation and we would like to see the HCP to be fully executed as originally intended by the DAO. Also, thanks to @danielo / RnDAO for leading the effort on this:
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.
We’re curious to better understand how this system works and it would be great to get more details here. If indeed there is now a system in place that works, then we should consider potentially formalising it for future investment programs.
We’re curious to better understand how this system works and it would be great to get more details here. If indeed there is now a system in place that works, then we should consider potentially formalising it for future investment programs.
We have developed 2/3 key pieces that can inform future proposals:
I’ve voted in favour of this proposal because it directly addresses a funding shortfall in the programme, which happened because of a delay in converting ARB to stablecoins during market drop. IMO it's practical to use leftover funds which were anyway due to be returned to the DAO from the Domain Allocator's 1st season. Re:precedent, I don't think it's a strong precedent because the approach is clearly described as a one-time action to prevent immediate project disruption, and all delegates are clearly in agreement on this point. Incorporating the FND's comment and feedback on why the ARB conversion process got delayed I think it'd be a good experience both for the hackaton team and for future programmes for the ideation and planning-ahead of the moving and conversion of funds. I think the path laid here is OK.
Voted abstain due to conflict of interest (a bit grey zone but anyhow)
I’ve voted in favour of this proposal because it directly addresses a funding shortfall in the programme, which happened because of a delay in converting ARB to stablecoins during market drop. IMO it's practical to use leftover funds which were anyway due to be returned to the DAO from the Domain Allocator's 1st season. Re:precedent, I don't think it's a strong precedent because the approach is clearly described as a one-time action to prevent immediate project disruption, and all delegates are clearly in agreement on this point. Incorporating the FND's comment and feedback on why the ARB conversion process got delayed I think it'd be a good experience both for the hackaton team and for future programmes for the ideation and planning-ahead of the moving and conversion of funds. I think the path laid here is OK.
Voted abstain due to conflict of interest (a bit grey zone but anyhow)
100% agree on this, the only viable option IMO.
Voted FOR
After consideration, the @SEEDgov delegation decided to vote “YES TO BOTH” on this proposal at the Snapshot Vote.
Rationale
We view this proposal as a one-time, transitional fix to address the issue stemming from the lack of sufficient funds to fulfill the Hackathon Continuation Program (HCP).
After consideration, the @SEEDgov delegation decided to vote “YES TO BOTH” on this proposal at the Snapshot Vote.
Rationale
We view this proposal as a one-time, transitional fix to address the issue stemming from the lack of sufficient funds to fulfill the Hackathon Continuation Program (HCP).
The funding gap was caused by market fluctuations in the ARB price, and the delay in conversion is not attributable to the proposer.
This proposal addresses the issue by reallocating leftover funds from Season 1 of the Questbook program to the HCP, allowing it to proceed as originally approved by the DAO. It accomplishes this without requiring additional funds from the DAO and only needs a Snapshot vote meeting the non-constitutional quorum.
We also supported redirecting the remaining funds from the Season 1 Domain Allocator program to the TMC, rather than returning them to the DAO, to strengthen the TMC’s stablecoin reserve for service provider payments shortfalls.
Additionally, SEEDGov believes a framework should be established to manage surplus funds from multisigs that are not denominated in ARB. We highlight this need because it is likely we will continue to find leftover funds in USDC and other tokens—for instance, in Questbook Season 2—and currently there is no clear procedure outlining how such funds should be handled. @Entropy tagging for visibility on this.
Thanks for your comments.
A public summary with basic metrics would help justify this exception.
DAOplomats voted FOR this proposal on Snapshot.
We were in favor of both the top-up and sending the extra funds to the TMC.
Sending the leftover funds from the D.A.O Season 1 program as a top-up for the hackathon was the most optimal path forward, and Jojo's suggestion to send the remainder of the funds to the TMC was great.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the top-up, as well as for moving the extra funds to the TMC.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the top-up, as well as for moving the extra funds to the TMC.
Per our previous comment, we support the proposed solution to the HCP's shortfall. It’s a relatively easy way to address the problem without creating new ones for the DAO.
We're not opposed to routing the remaining funds from Questbook’s S1 to the TMC, as the amount is relatively small and it would be easier to mobilize through the TMC than it would be if they were sent back to the treasury.
The PBC Governance team is voting FOR both topping up the HCP and sending the extra funds to the TMC, as it's a effective one-time fix for the funding shortfall.
We voted "Yes to both" for this proposal. Our feeling is that this works as effectively as a one-time solution to an unfortunate situation and we would like to see the HCP to be fully executed as originally intended by the DAO. Also, thanks to @danielo / RnDAO for leading the effort on this:
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.
We’re curious to better understand how this system works and it would be great to get more details here. If indeed there is now a system in place that works, then we should consider potentially formalising it for future investment programs.
We’re curious to better understand how this system works and it would be great to get more details here. If indeed there is now a system in place that works, then we should consider potentially formalising it for future investment programs.
We have developed 2/3 key pieces that can inform future proposals:
As AranaDigital, we are voting FOR the top-up for the Hackathon Continuation Program. We support using a portion of the Domain Allocator funds left over from Season 1 to top up the Hackathon Continuation Program. However, we argue that this one-time instance should not become the norm and that funds should be returned to the DAO without disruption in the future. It is important for the Arbitrum DAO to maintain trust with developers, so we are in favor of using DAO funds as reimbursement this time; however, such a situation should have been avoided in the first place. An important question is who will cover any future shortfalls like this if there is no leftover funding.
We also support sending the remaining funds from Domain Allocator Season 1 to the Treasury Management Committee to increase its stablecoin pool, ensuring that the DAO always has liquid, low-risk, yield-generating capital to cover dollar-denominated expenses and service-provider contract shortfalls. This approach prevents the need to sell ARB for immediate actions like this case, as it provides deep USD liquidity for DAO operations.
I'm voting “yes to both” as I believe this is the most efficient way to address the immediate funding needs and prevent these projects from leaving the ecosystem. I think that the delay happened for valid reasons and don’t see a strong case to vote against this solution. I also agree with other delegates on the need to find a better long-term approach for situations like this, and I'm happy to see that alternative solutions are already being discussed. I will participate in those conversations, but for now, I support this short-term solution to ensure continuity.
we voting Yes to both, as we mentioned:
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.
we voting Yes to both, as we mentioned:
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.
but we’d love to see a comprehensive framework that enables us to deploy unspent funds for greater benefit in other areas.
This proposal addresses an immediate issue, but highlights the need to better design how we manage risks from the outset.
Before allocating additional funds, it would be important to have a clear evaluation of what has been achieved so far in the Hackathon Continuation Program. A public summary with basic metrics would help justify this exception.
This proposal addresses an immediate issue, but highlights the need to better design how we manage risks from the outset.
Before allocating additional funds, it would be important to have a clear evaluation of what has been achieved so far in the Hackathon Continuation Program. A public summary with basic metrics would help justify this exception.
It is also worth discussing how to incorporate operational buffers into future proposals. An additional 10 to 15 percent in stablecoins, for example, included from the start as a contingency measure, could help absorb deviations caused by market fluctuations without requiring new DAO votes. This amount would only be activated in specific situations, such as a significant drop in the value of ARB, and if unused, should be returned to the treasury.
In addition, any proposal involving token management should include a basic sensitivity analysis, outlining how a negative price shift, such as a 20 percent drop in ARB, could affect execution. This would help anticipate risks and provide voters with the necessary context to make more informed decisions.
I support this proposal as an exception and here's why: https://forum.arbitrum.foundation/t/cp0x-delegate-communication-thread/22217/181?u=cp0x
Voting Yes to Only top-up the HCP.
I'm voting only to top-up the HCP, I'm against spending the remaining funds elsewhere.
For Ospina's situation, I fully support the allocation. I've been in that exact position myself multiple times - receiving a grant denominated in tokens, watching the token price depreciate before disbursement, and then being unable to deliver what was promised to other stakeholders. It's good practice to ask for a buffer amount, for future grants. Supporting Daniel here helps him fulfill the promises and expectations from the original approved proposal, and hopefully we can add buffer amounts to future proposals (ALPHA LEAK: I'm doing that for q/acc for sure.)
Initially, I thought I was fully supportive of everything. The continuation of the Hackathlon is definitely something I want to see happen. As I’ve mentioned in previous rationale statements, completing each project is of utmost importance in my view, as it contributes significantly to the long-term sustainability of the DAO.
The transfer to the TMC wasn’t something I was originally against. However, since the TMC will be completed as well, I don’t fully understand why the funds need to be moved there now, only to be transferred again once the TMC concludes. Of course, if any amount remains in the TMC, it will be transferred regardless.
Voting Yes to both.
Realistically, the tokens are fungible so there isn't really a reason to add an extra step. Both just for simplicity but also technically one less chance for an operational error. Either option is effectively the same.
Voting Yes to both.
Realistically, the tokens are fungible so there isn't really a reason to add an extra step. Both just for simplicity but also technically one less chance for an operational error. Either option is effectively the same.
I will echo others (as well as some comments I've made when past issues have come up relating to fluctuating price) - changes in ARB price continue to be a sticky/pain point in terms of operation within the DAO and should be addressed.
voting Yes to both on the current offchain vote because I like rubber stamping things that didn't actually need to happen and contribute to achieving an imaginary quorum of 130,752,756.914717982009274266 ARB as of the ETH block 22375793 at the timestamp of the start of this offchain vote.
I voted "Yes for both". It is a reasonable approach to the issue at hand, and sending the stables to the TMC to put it for use is the best chaoice in this scenario, IMO.
Hey, I’m voting for option B because it gives the Hackathon Continuation Program the $89,980 it needs to keep running smoothly. Plus, it sends the extra funds to the Treasury Management Committee to build a stablecoin pool for future projects. It’s a solid way to support Arbitrum and manage our money better!
Voting YES FOR BOTH to make it whole. Hopefully, a better funding system can be designed for future programs.
As in @web3citizenxyz representation. Voting YES, to both.
Below the rationale:
As AranaDigital, we are voting FOR the top-up for the Hackathon Continuation Program. We support using a portion of the Domain Allocator funds left over from Season 1 to top up the Hackathon Continuation Program. However, we argue that this one-time instance should not become the norm and that funds should be returned to the DAO without disruption in the future. It is important for the Arbitrum DAO to maintain trust with developers, so we are in favor of using DAO funds as reimbursement this time; however, such a situation should have been avoided in the first place. An important question is who will cover any future shortfalls like this if there is no leftover funding.
We also support sending the remaining funds from Domain Allocator Season 1 to the Treasury Management Committee to increase its stablecoin pool, ensuring that the DAO always has liquid, low-risk, yield-generating capital to cover dollar-denominated expenses and service-provider contract shortfalls. This approach prevents the need to sell ARB for immediate actions like this case, as it provides deep USD liquidity for DAO operations.
I'm voting “yes to both” as I believe this is the most efficient way to address the immediate funding needs and prevent these projects from leaving the ecosystem. I think that the delay happened for valid reasons and don’t see a strong case to vote against this solution. I also agree with other delegates on the need to find a better long-term approach for situations like this, and I'm happy to see that alternative solutions are already being discussed. I will participate in those conversations, but for now, I support this short-term solution to ensure continuity.
we voting Yes to both, as we mentioned:
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.
we voting Yes to both, as we mentioned:
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.
but we’d love to see a comprehensive framework that enables us to deploy unspent funds for greater benefit in other areas.
This proposal addresses an immediate issue, but highlights the need to better design how we manage risks from the outset.
Before allocating additional funds, it would be important to have a clear evaluation of what has been achieved so far in the Hackathon Continuation Program. A public summary with basic metrics would help justify this exception.
This proposal addresses an immediate issue, but highlights the need to better design how we manage risks from the outset.
Before allocating additional funds, it would be important to have a clear evaluation of what has been achieved so far in the Hackathon Continuation Program. A public summary with basic metrics would help justify this exception.
It is also worth discussing how to incorporate operational buffers into future proposals. An additional 10 to 15 percent in stablecoins, for example, included from the start as a contingency measure, could help absorb deviations caused by market fluctuations without requiring new DAO votes. This amount would only be activated in specific situations, such as a significant drop in the value of ARB, and if unused, should be returned to the treasury.
In addition, any proposal involving token management should include a basic sensitivity analysis, outlining how a negative price shift, such as a 20 percent drop in ARB, could affect execution. This would help anticipate risks and provide voters with the necessary context to make more informed decisions.
I support this proposal as an exception and here's why: https://forum.arbitrum.foundation/t/cp0x-delegate-communication-thread/22217/181?u=cp0x
Voting Yes to Only top-up the HCP.
I'm voting only to top-up the HCP, I'm against spending the remaining funds elsewhere.
For Ospina's situation, I fully support the allocation. I've been in that exact position myself multiple times - receiving a grant denominated in tokens, watching the token price depreciate before disbursement, and then being unable to deliver what was promised to other stakeholders. It's good practice to ask for a buffer amount, for future grants. Supporting Daniel here helps him fulfill the promises and expectations from the original approved proposal, and hopefully we can add buffer amounts to future proposals (ALPHA LEAK: I'm doing that for q/acc for sure.)
Initially, I thought I was fully supportive of everything. The continuation of the Hackathlon is definitely something I want to see happen. As I’ve mentioned in previous rationale statements, completing each project is of utmost importance in my view, as it contributes significantly to the long-term sustainability of the DAO.
The transfer to the TMC wasn’t something I was originally against. However, since the TMC will be completed as well, I don’t fully understand why the funds need to be moved there now, only to be transferred again once the TMC concludes. Of course, if any amount remains in the TMC, it will be transferred regardless.
Voting Yes to both.
Realistically, the tokens are fungible so there isn't really a reason to add an extra step. Both just for simplicity but also technically one less chance for an operational error. Either option is effectively the same.
Voting Yes to both.
Realistically, the tokens are fungible so there isn't really a reason to add an extra step. Both just for simplicity but also technically one less chance for an operational error. Either option is effectively the same.
I will echo others (as well as some comments I've made when past issues have come up relating to fluctuating price) - changes in ARB price continue to be a sticky/pain point in terms of operation within the DAO and should be addressed.
voting Yes to both on the current offchain vote because I like rubber stamping things that didn't actually need to happen and contribute to achieving an imaginary quorum of 130,752,756.914717982009274266 ARB as of the ETH block 22375793 at the timestamp of the start of this offchain vote.
I voted "Yes for both". It is a reasonable approach to the issue at hand, and sending the stables to the TMC to put it for use is the best chaoice in this scenario, IMO.
Hey, I’m voting for option B because it gives the Hackathon Continuation Program the $89,980 it needs to keep running smoothly. Plus, it sends the extra funds to the Treasury Management Committee to build a stablecoin pool for future projects. It’s a solid way to support Arbitrum and manage our money better!
Voting YES FOR BOTH to make it whole. Hopefully, a better funding system can be designed for future programs.
As in @web3citizenxyz representation. Voting YES, to both.
Below the rationale:
I'm voting only to top-up the HCP, I'm against spending the remaining funds elsewhere.
For Ospina's situation, I fully support the allocation. I've been in that exact position myself multiple times - receiving a grant denominated in tokens, watching the token price depreciate before disbursement, and then being unable to deliver what was promised to other stakeholders. It's good practice to ask for a buffer amount, for future grants. Supporting Daniel here helps him fulfill the promises and expectations from the original approved proposal, and hopefully we can add buffer amounts to future proposals (ALPHA LEAK: I'm doing that for q/acc for sure.)
However,
This sets a dangerous precedent. When funds aren't used for their approved purpose, the default should be returning them to the treasury. We can't normalize this!
This approach of "we have leftover money, let's find ways to spend it" is honestly just classic government sh*t that we shouldn't fall into the trap of. If we have money unspent, sending it back to the DAO needs be the norm that we try to proliferate.
Otherwise, we're no better than governments that pass a tax to fund a bridge or something, and then when the bridge is built, the tax just stays and they use it for other things because "there's more things we can do with this money" and "oh, we don't have to pass another proposal." That's such bullsh*t. We need to strive to be better than governments.
Initially, I thought I was fully supportive of everything. The continuation of the Hackathlon is definitely something I want to see happen. As I’ve mentioned in previous rationale statements, completing each project is of utmost importance in my view, as it contributes significantly to the long-term sustainability of the DAO.
The transfer to the TMC wasn’t something I was originally against. However, since the TMC will be completed as well, I don’t fully understand why the funds need to be moved there now, only to be transferred again once the TMC concludes. Of course, if any amount remains in the TMC, it will be transferred regardless.
In the end, I remain skeptical about the need to transfer funds to the TMC at this point, and for this specific part of the proposal, I will vote Only top-up the HCP
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.
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.
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.
I support this proposal to top-up the HCP and transfer the remaining funds to the TMC on snapshot.
This is a flexible, one time solution to address the current shortfall and ensure developers’ projects continue without disruption.
We will resolve the immediate issue, but also will serve as an important learning moment for improving risk management practices in the future.
gm, voted YES TO BOTH for the reasons outlined above: promises to builders must be prioritized.
As Daniel clarified, the remaining tokens must be converted into USDC and the most frictionless way to do it is to bring it to the TMC.
Thanks
The TMC could convert these tokens to the new USDC easily, while the DAO would need a forum post, snapshot vote, then onchain vote… so a lot of work
Reducing that bureaucracy work is something I would vote for. The thing is, that's not what the vote says—it states that TMC Stables will serve as a reserve for service providers (and yields). And I believe in not creating precedents; that's something the OpCo should manage. There is a reason we have processes.
@Zeptimus please see above for comment.
Thanks for your vote and rationale
Thanks Hawheik for your vote and comments
Adding another diversion of the remaining funds into to the TMC, for which a much much larger portion of funds is earmarked through another proposal, adds complexity to this proposal and housekeeping to TMC that doesn’t seem “worth it”. Returning the leftover funds to the DAO keeps things simple and makes it easier to track what funds went where, for what reason.
Thanks Hawheik for your vote and comments
Adding another diversion of the remaining funds into to the TMC, for which a much much larger portion of funds is earmarked through another proposal, adds complexity to this proposal and housekeeping to TMC that doesn’t seem “worth it”. Returning the leftover funds to the DAO keeps things simple and makes it easier to track what funds went where, for what reason.
Voting YES. The amount if fairly low but contined hacking is needed to identify problems or risks. Its making this space safer.
LobbyFi’s rationale on the price and making the voting power available for sale for this proposal:
We regard this proposal as one potentially benefiting more than one party + there are no new funds that would leave the DAO treasury - so the auction will be on.
The instant buy price will be set at 1% of the $233k that are subject of the proposal—1.3 ETH.
I'm voting "Only top-up the HCP". The original agreement was made in stables, and with ARB's value fluctuation, it's only fair to honor that commitment to get to see the results after the experiment. As Klaus pointed out, we're creating too many parallel funding processes when we should be optimizing through OPCO. We need to focus on the long-term governance solutions coming with OPCO rather than creating more bureaucratic layers.
Voted abstain due to conflict of interest (a bit grey zone but anyhow)
I voted "Only top-up the HCP", for two reasons:
I appreciate and support the idea of covering the shortfall in the Hackathon budget.
Adding another diversion of the remaining funds into to the TMC, for which a much much larger portion of funds is earmarked through another proposal, adds complexity to this proposal and housekeeping to TMC that doesn't seem "worth it". Returning the leftover funds to the DAO keeps things simple and makes it easier to track what funds went where, for what reason.
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 are voting “Yes to both” in the Snapshot voting.
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 are voting “Yes to both” in the Snapshot voting.
We are in favour of both topping up and moving leftover funds into the hands of TMC. As we’ve previously expressed, we view this reallocation as a practical response to a time-sensitive funding shortfall, made even more reasonable by the fact that it utilizes unspent, already-allocated funds, avoiding the need to convert additional DAO capital in a volatile market.
That said, this proposal highlights an important operational lesson, the need for standardized, pre-approved mechanisms, such as those that can potentially be handled via the TMC, to address minor or urgent funding gaps without requiring full governance cycles.
After reading the proposal and valuable comments provided, I am voting for option B (top-up the HCP and leftover funds to the TMC). Nothing to add beyond what’s been said.
I support option B (yes to both: top-up the HCP and leftover funds to the TMC). My reasons are as follows:
Addressing Short-Term Needs and Long-Term Reserves: Currently, the HCP projects face a shortfall, and it is crucial to replenish these funds promptly to prevent builders in our ecosystem from migrating to other ecosystems. Simultaneously, allocating the remaining funds to the TMC stablecoin pool would establish a buffer mechanism for similar future risks, enhancing the DAO's financial resilience.
Happy to support this with my votes as no extra funds are needed from the DAO, however, regardless of the AF's clarification on past ARB conversion, I think @Tane makes a fair point to consider moving forward to streamline all decision-making problems highlighted in the proposal.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
From our perspective, the proposed solution is likely the most frictionless way to provide the already approved initiative with the necessary resources to continue as originally planned. While we can understand any concerns about setting a precedent with such a move, we are more concerned with the DAO spending the next two months debating what the right solution is.
I'm voting only to top-up the HCP, I'm against spending the remaining funds elsewhere.
For Ospina's situation, I fully support the allocation. I've been in that exact position myself multiple times - receiving a grant denominated in tokens, watching the token price depreciate before disbursement, and then being unable to deliver what was promised to other stakeholders. It's good practice to ask for a buffer amount, for future grants. Supporting Daniel here helps him fulfill the promises and expectations from the original approved proposal, and hopefully we can add buffer amounts to future proposals (ALPHA LEAK: I'm doing that for q/acc for sure.)
However,
This sets a dangerous precedent. When funds aren't used for their approved purpose, the default should be returning them to the treasury. We can't normalize this!
This approach of "we have leftover money, let's find ways to spend it" is honestly just classic government sh*t that we shouldn't fall into the trap of. If we have money unspent, sending it back to the DAO needs be the norm that we try to proliferate.
Otherwise, we're no better than governments that pass a tax to fund a bridge or something, and then when the bridge is built, the tax just stays and they use it for other things because "there's more things we can do with this money" and "oh, we don't have to pass another proposal." That's such bullsh*t. We need to strive to be better than governments.
Initially, I thought I was fully supportive of everything. The continuation of the Hackathlon is definitely something I want to see happen. As I’ve mentioned in previous rationale statements, completing each project is of utmost importance in my view, as it contributes significantly to the long-term sustainability of the DAO.
The transfer to the TMC wasn’t something I was originally against. However, since the TMC will be completed as well, I don’t fully understand why the funds need to be moved there now, only to be transferred again once the TMC concludes. Of course, if any amount remains in the TMC, it will be transferred regardless.
In the end, I remain skeptical about the need to transfer funds to the TMC at this point, and for this specific part of the proposal, I will vote Only top-up the HCP
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.
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.
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.
I support this proposal to top-up the HCP and transfer the remaining funds to the TMC on snapshot.
This is a flexible, one time solution to address the current shortfall and ensure developers’ projects continue without disruption.
We will resolve the immediate issue, but also will serve as an important learning moment for improving risk management practices in the future.
gm, voted YES TO BOTH for the reasons outlined above: promises to builders must be prioritized.
As Daniel clarified, the remaining tokens must be converted into USDC and the most frictionless way to do it is to bring it to the TMC.
Thanks
The TMC could convert these tokens to the new USDC easily, while the DAO would need a forum post, snapshot vote, then onchain vote… so a lot of work
Reducing that bureaucracy work is something I would vote for. The thing is, that's not what the vote says—it states that TMC Stables will serve as a reserve for service providers (and yields). And I believe in not creating precedents; that's something the OpCo should manage. There is a reason we have processes.
@Zeptimus please see above for comment.
Thanks for your vote and rationale
Thanks Hawheik for your vote and comments
Adding another diversion of the remaining funds into to the TMC, for which a much much larger portion of funds is earmarked through another proposal, adds complexity to this proposal and housekeeping to TMC that doesn’t seem “worth it”. Returning the leftover funds to the DAO keeps things simple and makes it easier to track what funds went where, for what reason.
Thanks Hawheik for your vote and comments
Adding another diversion of the remaining funds into to the TMC, for which a much much larger portion of funds is earmarked through another proposal, adds complexity to this proposal and housekeeping to TMC that doesn’t seem “worth it”. Returning the leftover funds to the DAO keeps things simple and makes it easier to track what funds went where, for what reason.
Voting YES. The amount if fairly low but contined hacking is needed to identify problems or risks. Its making this space safer.
LobbyFi’s rationale on the price and making the voting power available for sale for this proposal:
We regard this proposal as one potentially benefiting more than one party + there are no new funds that would leave the DAO treasury - so the auction will be on.
The instant buy price will be set at 1% of the $233k that are subject of the proposal—1.3 ETH.
I'm voting "Only top-up the HCP". The original agreement was made in stables, and with ARB's value fluctuation, it's only fair to honor that commitment to get to see the results after the experiment. As Klaus pointed out, we're creating too many parallel funding processes when we should be optimizing through OPCO. We need to focus on the long-term governance solutions coming with OPCO rather than creating more bureaucratic layers.
Voted abstain due to conflict of interest (a bit grey zone but anyhow)
I voted "Only top-up the HCP", for two reasons:
I appreciate and support the idea of covering the shortfall in the Hackathon budget.
Adding another diversion of the remaining funds into to the TMC, for which a much much larger portion of funds is earmarked through another proposal, adds complexity to this proposal and housekeeping to TMC that doesn't seem "worth it". Returning the leftover funds to the DAO keeps things simple and makes it easier to track what funds went where, for what reason.
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 are voting “Yes to both” in the Snapshot voting.
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 are voting “Yes to both” in the Snapshot voting.
We are in favour of both topping up and moving leftover funds into the hands of TMC. As we’ve previously expressed, we view this reallocation as a practical response to a time-sensitive funding shortfall, made even more reasonable by the fact that it utilizes unspent, already-allocated funds, avoiding the need to convert additional DAO capital in a volatile market.
That said, this proposal highlights an important operational lesson, the need for standardized, pre-approved mechanisms, such as those that can potentially be handled via the TMC, to address minor or urgent funding gaps without requiring full governance cycles.
After reading the proposal and valuable comments provided, I am voting for option B (top-up the HCP and leftover funds to the TMC). Nothing to add beyond what’s been said.
I support option B (yes to both: top-up the HCP and leftover funds to the TMC). My reasons are as follows:
Addressing Short-Term Needs and Long-Term Reserves: Currently, the HCP projects face a shortfall, and it is crucial to replenish these funds promptly to prevent builders in our ecosystem from migrating to other ecosystems. Simultaneously, allocating the remaining funds to the TMC stablecoin pool would establish a buffer mechanism for similar future risks, enhancing the DAO's financial resilience.
Happy to support this with my votes as no extra funds are needed from the DAO, however, regardless of the AF's clarification on past ARB conversion, I think @Tane makes a fair point to consider moving forward to streamline all decision-making problems highlighted in the proposal.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
From our perspective, the proposed solution is likely the most frictionless way to provide the already approved initiative with the necessary resources to continue as originally planned. While we can understand any concerns about setting a precedent with such a move, we are more concerned with the DAO spending the next two months debating what the right solution is.
I support option B (yes to both: top-up the HCP and leftover funds to the TMC). My reasons are as follows:
Addressing Short-Term Needs and Long-Term Reserves: Currently, the HCP projects face a shortfall, and it is crucial to replenish these funds promptly to prevent builders in our ecosystem from migrating to other ecosystems. Simultaneously, allocating the remaining funds to the TMC stablecoin pool would establish a buffer mechanism for similar future risks, enhancing the DAO's financial resilience.
Optimizing Capital Efficiency: The mechanism proposed by the TMC, "based on using the yield of this reserve" to cover service provider shortfalls, will require time for yield to accrue. Option B accelerates this process through a one-time capital injection while avoiding the inefficient operation of returning idle funds to the DAO.
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.
For the reasons mentioned above, voting in favor of both topping up and moving remaining funds in hands of TMC. I think we remove friction, allocate spare funds to a treasury program, and also avoid to devote any more mindshare to issues that are in my opinion secondary to other important things we need to achieve.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
From our perspective, the proposed solution is likely the most frictionless way to provide the already approved initiative with the necessary resources to continue as originally planned. While we can understand any concerns about setting a precedent with such a move, we are more concerned with the DAO spending the next two months debating what the right solution is.
If anything, the fact that the program needs a top-up in the first place is an excellent example of the operational inefficiencies the DAO is facing. There’s no need to compound those by spending a lot of time and mind share on a problem when there’s an easy way to address it.
Hopefully, once it is established, the Opco will be able to address these kinds of situations and ideally help prevent them from happening in the first place.
Thanks danielo, this proposal makes sense to keep supporting builders and ensure operations for the program. We support this proposal.
I have voted "YES to both " as I support this proposal. I hope in the future the new structure involving OpCo, TMC, and greater AF involvement in the DAO will address these inefficiencies. Ideally, Service Providers could be paid in stablecoins for dollar-denominated proposals to prevent such issues.
I'm in favour of approving this proposal as an interim solution and not a setting of precedent.
The balance of risk sharing between counterparties is not correct imo, this needs to get solved DAO wide with a long-term solution. At minimum for now proposal authors can protect themselves by defining their proposals in USD equivalent and procedure for conversation, however my preference is this gets solved with policy and procedure by Arbitrum Foundation to ensure proposals can viably and reliably fulfill their mandate.
While we voted against the original proposal, this operational shortcoming should not have occurred and occurred on behalf of the Arbitrum Foundation and MSS operations rather than the grantee's failure to convert ARB in a meaningful manner. As such, we support the grant's funding to completion as agreed upon in the post.
gm, reasonable solution to the current issue. Making sure we keep our promise with builders on a reasonable timeline should be the priority.
Thanks
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.
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.
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.
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.
Is there a standard and comprehensive approach that is guaranteed to eliminate this problem?
Is there a standard and comprehensive approach that is guaranteed to eliminate this problem?
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.
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.
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.
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.
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
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Supportive of allocating the leftover funds in this way
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.
I support option B (yes to both: top-up the HCP and leftover funds to the TMC). My reasons are as follows:
Addressing Short-Term Needs and Long-Term Reserves: Currently, the HCP projects face a shortfall, and it is crucial to replenish these funds promptly to prevent builders in our ecosystem from migrating to other ecosystems. Simultaneously, allocating the remaining funds to the TMC stablecoin pool would establish a buffer mechanism for similar future risks, enhancing the DAO's financial resilience.
Optimizing Capital Efficiency: The mechanism proposed by the TMC, "based on using the yield of this reserve" to cover service provider shortfalls, will require time for yield to accrue. Option B accelerates this process through a one-time capital injection while avoiding the inefficient operation of returning idle funds to the DAO.
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.
For the reasons mentioned above, voting in favor of both topping up and moving remaining funds in hands of TMC. I think we remove friction, allocate spare funds to a treasury program, and also avoid to devote any more mindshare to issues that are in my opinion secondary to other important things we need to achieve.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
From our perspective, the proposed solution is likely the most frictionless way to provide the already approved initiative with the necessary resources to continue as originally planned. While we can understand any concerns about setting a precedent with such a move, we are more concerned with the DAO spending the next two months debating what the right solution is.
If anything, the fact that the program needs a top-up in the first place is an excellent example of the operational inefficiencies the DAO is facing. There’s no need to compound those by spending a lot of time and mind share on a problem when there’s an easy way to address it.
Hopefully, once it is established, the Opco will be able to address these kinds of situations and ideally help prevent them from happening in the first place.
Thanks danielo, this proposal makes sense to keep supporting builders and ensure operations for the program. We support this proposal.
I have voted "YES to both " as I support this proposal. I hope in the future the new structure involving OpCo, TMC, and greater AF involvement in the DAO will address these inefficiencies. Ideally, Service Providers could be paid in stablecoins for dollar-denominated proposals to prevent such issues.
I'm in favour of approving this proposal as an interim solution and not a setting of precedent.
The balance of risk sharing between counterparties is not correct imo, this needs to get solved DAO wide with a long-term solution. At minimum for now proposal authors can protect themselves by defining their proposals in USD equivalent and procedure for conversation, however my preference is this gets solved with policy and procedure by Arbitrum Foundation to ensure proposals can viably and reliably fulfill their mandate.
While we voted against the original proposal, this operational shortcoming should not have occurred and occurred on behalf of the Arbitrum Foundation and MSS operations rather than the grantee's failure to convert ARB in a meaningful manner. As such, we support the grant's funding to completion as agreed upon in the post.
gm, reasonable solution to the current issue. Making sure we keep our promise with builders on a reasonable timeline should be the priority.
Thanks
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.
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.
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.
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.
Is there a standard and comprehensive approach that is guaranteed to eliminate this problem?
Is there a standard and comprehensive approach that is guaranteed to eliminate this problem?
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.
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.
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.
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.
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
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Supportive of allocating the leftover funds in this way
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
