I’m voting AGAINST this proposal. I acknowledge the importance of user acquisition and appreciate @Kamilgorski initiative to address this need. However, this type of funding should go through a proper grant program, and not waste the DAO’s time. What we need is an competitive process where multiple teams can apply and the best bid wins. Let’s build mechanisms that get us the best offers rather than approving individual requests directly thru the DAO.
voting For on the current offchain vote because I think this proposal, in it’s current form, is safe to try. @kamilgorski has been super responsive here on the forum, showing up on calls, timing the move of the proposal to a vote to cater to the DAO, incorporating almost all feedback on the proposal, honestly doing everything correctly, from my point of view, including being super detailed about the costs, etc… so I still don’t understand why this proposal is being voted down by the DAO at this offchain temperature check stage. I think this is safe to try, and we need a user acquisition program for the dApps and protocols in Arbitrum so it might as well be this one from the Patterns team.
2 Likes
I will be voting “Against” on the temp check. I understand the importance of attracting users, but I simply think the cost is too high and I think this is going about it backwards. Paying other dapps marketing budget for 3 months I don’t believe will be a good ROI
I think this would work better as a service the DAO provides, with a small pool of funds to subsidize a portion of funds. i.e., small projects can come to the DAO asking for our expertise in marketing. And while we may offer some funds, it would be more prudent to do so with something like matching. I fear this is just going to turn into already established programs just looking for free marketing and the DAO is not a position to do so.
As in @web3citizenxyz representation. Voting FOR. Below the rationale:
We vote AGAINST the proposal on Snapshot.
While acknowledging the team’s effort and direction of the proposal, we believe we should evaluate this proposal (and others if any) with Entropy’s sponsored program, and can’t vote for it at this point.
We vote against this proposal. To clarify, Michigan Blockchain is not opposed to the notion that user acquisition is an important objective that Arbitrum should be working to improve upon. However, the major hurdle that arises is the proposed cost. A $3 million request is an incredibly high price tag for the end objective of bringing in more users. We believe that the counter proposition of a smaller budget for one grant or a competitive selection process to pick a few viable candidates for a smaller pool would not only be safer, but a more cost-effective way to establish higher rates of user acquisition and utilization.
*BoredApe90
We are voting FOR and support this grant proposal. Thank you @kamilgorski for putting in a huge effort for this proposal, with strong commitment to refining it, and making adjustments based on community input.
The requested grant amount is reasonable and well within a ‘worth trying’ range. The potential benefits, especially in attracting off-chain users to the Arbitrum ecosystem, make it a valuable investment. What has been most compelling is the emphasis on metric-based tracking for marketing efforts. This addresses a common concern in previous STIP and LTIPP distributions, where clear accountability and performance measurement were often lacking.
The focus on measurable results makes this a worthwhile proposal that we believe will positively contribute to Arbitrum’s growth.
1 Like
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
We appreciate the effort put in by the Patterns team to bring this proposal forward. The absence of an incentive program has been a concern for many builders in the ecosystem. While we support the idea of an incentive program, we do not believe this proposal is the ideal approach.
The concept of driving growth through off-chain marketing is valuable, but starting with a $3 million budget introduces significant risk. Additionally, the program does not improve upon previous incentive initiatives such as STIP and LTIPP. More importantly, most Arbitrum protocols are not yet set up for optimal off-chain user acquisition both in terms of protocol readiness and the necessary staffing to oversee a large-scale campaign efficiently. This lack of preparedness would likely lead to inefficient budget utilization.
Even for well-capitalized and well-staffed projects like GMX, a large off-chain user acquisition campaign would not be practical at this stage. Capacity is limited, bigger priorities exist in the coming months, and the current onboarding flow for mainstream users is not yet optimal. If this is the case for GMX, it is likely even more so for other involved protocols.
A more effective approach would be to position this as a marketing initiative supporting a future incentives program. Past programs struggled with visibility, and a focused marketing effort could help bridge that gap. Such a campaign would be far more impactful once essential Web2-friendly solutions like wallet abstraction, passkeys, and email logins are readily available on Arbitrum. Until then, we believe a smaller, more targeted grant for marketing would be a more sustainable and effective approach.
For this reasons we would be voting against the proposal.
I voted for this proposal. Despite thinking that the budget could be lower, it was well strucutured, the team willing to adapt when changes made change and the proposal is touching uncharted waters in incentives program on Arbitrum. It would be interesting at least to gather more data around how to advertise/do proper marketing web3 protocols.
1 Like
After consideration, the @SEEDgov delegation has decided to vote “AGAINST” on this proposal at the Snapshot Vote.
Rationale
We feel that this proposal is somewhat disconnected from the discussions that have taken place over the past few months as part of the detox process. While it is true that the proponents have presented their case during calls, we believe there are certain pre-existing issues that remain unresolved by this proposal.
In this regard, we align with other delegates in recognizing the difficulty of evaluating a wide variety of strategies, making it evident that a program with clearer guidelines for applicants is needed.
We see value in Patterns as part of a broader program that aligns with the DAO’s overall objectives and strategy. Additionally, we believe that any future incentive program should at least consider encouraging projects to invest more in off-chain marketing efforts to expand the pie, as it is clear that current programs tend to attract Web3-native users seeking yields rather than onboarding new users.
Per previous comments and concerns, Gauntlet has voted Against this proposal.
Voting FOR as per the reasons outlined above
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 voted ABSTAIN.
This proposal evolved from the earlier incentive detox ideas impulsed by L2BEAT, and we were involved with a lot of discussions with Kamil around this proposal. That said, we do see the potential benefits of off- and on-chain user acquisition strategies as a way to strengthen Arbitrum’s network effects. However, in our view, the proposal would benefit from more concrete criteria for measuring user lifetime value (LTV) and return on investment (ROI), as well as a clearer explanation of how the committee will function and decide on applications. We also think that it would be much more valuable if in the future the proposal would be under the responsibility of Arbitrum Foundation or OpCo (or another organization) to ensure that Arbitrum’s interests are always the main factors in evaluating the performance and achievements.
Despite these reservations, we appreciate the spirit of experimentation that underlies this proposal and its attempt to address problems with short-lived incentive programs. We hope that the DAO and related entities will be able to work with the proposer to develop a proposal that would be more broadly accepted.
We voted against this, but for different reasons than other delegates. While we appreciate the general direction of this proposal and think it could work given a narrow enough scope, we don’t think the design works for a larger ecosystem with many kinds of projects in it.
The biggest problem is that the proposal assumes a standardized approach to CAC across DeFi projects, which doesn’t align with the reality of how conversions are defined and measured in the industry. In DeFi, conversions are bespoke and vary widely depending on the type of the app and its goals, with every project using a different method across a spectrum for what classifies as a conversion.
For Vertex, we qualify a full conversion as someone that fills a trade order, reflected by the event it emits, and is trackable both internally and via Spindl who is integrated with our SDK. Comparatively, many projects simply use deposits as qualifying for a conversion, and ad publishers such as Coinbase Wallet use a significantly lower bar for conversions, which is just whether or not someone clicked on the link and landed on the app domain.
If we pay for ad clicks that don’t result in trades but are counted as conversions by a publisher, our CAC appears artificially low, while our actual cost per meaningful user is much higher. This also becomes easily manipulated by projects using low thresholds for conversions. When you scale this problem out to multiple projects, you end up with distorted data, painting a inaccurate picture of the success of each campaign.
The primary way we see to fix this would be to set a universal conversion methodology for every participant, but that would again require an extremely narrow focus as we don’t think there’s a methodology that could be widely applied here. If conversions aren’t aligned with the stated KPI outcomes like TVL / maximizing trade volume, the program risks misallocating its budget on shallow user interactions.
Separately, we also have concerns around the application process itself. While we don’t mind sharing some information, we’re not sure that we would want to reveal all details of marketing we’ve done in the past year, as this quickly ends up in areas where one strategy is a competitive advantage over another, and in the end projects are still trying to draw the most users to themselves.
Hey @Vertex_Protocol, you raised an important methodology argument and I’d like to clear it up:
-
Conversions - As stated in the proposal, Patterns measures on-chain conversions based on smart contract events - not the ones declared by ad publishers. Exactly as you said - it wouldn’t make sense to count these. That’s why we limited the program to 15-20 projects only and charge a somewhat significant fee to calculate these.
-
Application process - It doesn’t require to share all details about past campaigns. The program does only require to share access to tracking tools for campaigns financed by it - which we believe is a reasonable requirement (the DAO pays for the campaigns so it has a right to preview their results).
To all who voted on Snapshot - thank you for your votes and feedback! 
Let us collect all of it and try to make some coherent changes to the proposal. It seems like the budget size was the main reason for the proposal not to pass on Snapshot and we’ll try to come up with an alternative but comprehensive solution for that!
Best,
Kamil
2 Likes
Hi
Here is an approach works.
Every 6 months, ask the DAO the forever question. Then identify the top responses (SimScore is an option).. For each of the top responses, write an RFP. Ensure that developers see the top RFPs so they can propose solutions.
In 6 months run the forever question again. If the proposals offered were effective, new types of replies will emerge. If the proposals were not effective, the same responses would be in future forever question rounds.
This is iterative and continuous improvement