A New Thesis for Network-Level Incentives Programs


In my reflections upon STIP, I touched on a high-level grants philosophy and explored how incentives fit within a greater growth strategy. This post continues the discussion on incentives by exploring alternative distribution methods to existing frameworks (including both STIP and LTIP).

I’ve tried to strike a balance between combating opinions that:

  1. The DAO should invest aggressively in its ecosystem rather than chase perfection and;
  2. Incentives have the highest potential to rapidly waste capital and can be dramatically improved.

I will do my best not to mid-curve this analysis and articulate a complementary approach to the DAO’s current track for Arbitrum incentives. To do so, the following sections will review the existing DAO paths as proposed and present a “direct-to-contract” incentives framework as an alternative.

The point of this post is not to propose an immediate program but rather to lay the groundwork for the Arbitrum DAO to dream a little bigger.

A New Thesis for Network Level grants

Ever since Bitcoin introduced token rewards to incentivize block builders, incentives have been integral to all aspects of crypto. Incentives can be defined as motivating a party to perform an action by giving them a reward. The process is simple: identify a desired outcome, select an action that leads to this outcome, and provide a compelling reward for executing this action.

Blockchains and smart contracts advanced incentivization by establishing trustless ledgers, autonomous execution, transparency, and permissionless access. Ironically, as blockchains decentralized their control to DAOs, these same technologies have seemingly been forgotten. A lack of infrastructure and tooling for network management has left DAOs like Arbitrum dependent on bureaucracy to brute-force trust through checks and balances.

This post envisions a transition from councils towards a bottom-up, contract-based marketplace for incentives. By leveraging smart contracts, we can refocus the extent of human contributions towards where they most excel — creativity and vision. Meanwhile, market mechanics can handle optimization and efficiency, and code can manage transparency and trust. This approach represents not just a technological shift but a philosophical one, realigning the DAO with the principles of its industry.

Traditional Incentives Programs

Blockchain networks have traditionally (exclusively?) followed a pattern of incentive distribution through projects. The general thesis is that empowering projects inherently benefits the network layer.

This approach has a few meaningful benefits:

  • Developer Support: Incentives provide meaningful support to projects and demonstrate a meaningful strategy to further attract developers and projects to the ecosystem.
  • Domain Expertise: Protocol founders inherently maintain expertise over their projects, presumably understanding user behavior and market demands in their specific market.
  • Operational Ease: By putting the operational load of distributing incentives on grantees, the DAO avoids the need for both management of incentive operations and, in some cases, analysis.

*The Arbitrum Incentive Working Group expressed in an informal poll that Arbitrum Projects (47%) should be the primary benefactor of incentives over both Users (32%) and Liquidity (13%).

That said, traditional incentive structure also presents meaningful challenges:

  • Principal-Agent Bias: Projects may prioritize incentives that align with their revenue models rather than the network’s overall goals. This leads to sustainability issues like wash trading or short-term strategies focused on immediate gains.
  • Strategic Misalignment: Relying on projects for incentive distribution can hinder initiatives requiring cross-protocol collaboration and lead to a lack of oversight, potentially allowing for manipulation of funds for personal gain.
  • Competitive Advantage: Projects receiving grants receive distinct competitive advantages versus competitors in the ecosystem.
  • Operational Apathy: A lack of analytical rigor both during and after grant disbursement can lead to misaligned actions going unnoticed or even encouraged; such was the case with a few STIP grants, which presented flawed incentive designs when held against STIP requirements, only some of which were retroactively addressed.

Objective-Based Incentives Programs

While not a solution, I do feel as though it’s worth quickly addressing that the addition of a further bureaucratic layer can bolster a more objective incentives framework (follow-up on this presentation). This borrows heavily from the Optimism Mission and Intents model, which while ambitious is detrimentally confusing and bureaucratic.

Objective-Based Incentives Program

Objective-based incentive programs curb the influence of both councils and projects by structurally requiring alignment with specific objectives and KPIs. At a high level, the foresight to define an objective addresses principal-agent problems’ shortcomings by discouraging applications from embracing an ad-hoc or short-term focus, and instead requiring performance based on predetermined metrics.

  • Structure and Accountability: This program represents a shift from the traditional model, focusing on objective-based campaigns with clear KPIs and iterative performance evaluations.
  • Strategic Alignment: While not entirely replacing current decision-makers and applications, this framework aims to reorient them toward supporting specific, measurable objectives. This ensures alignment, including specific strategic goals such as liquidity, user growth, sector targeting, etc.

Example Implementation: A campaign to enhance stETH liquidity on Arbitrum could involve a mix of administrators, councils, and analysts working with projects that align with the campaign’s goals, ensuring that incentives directly support the network’s strategic objectives.

Objective-based campaigns embrace experimentation by establishing accountability up-front and placing outcomes at the center of the grants themselves. Objective-based campaigns benefit from specific KPIs and Objectives, using iterative performance evaluations to ensure accountability over time.

It’s helpful to think of campaigns themselves as sub-programs, perhaps with a program administrator, a couple of analysts, and an application period for campaign-related projects to apply for sub-grants. Projects that feel as though they could support the mission would apply under the specific campaign goal with their tactical approach to supporting the campaign objective.

For example, if the DAO elected to launch a campaign to support stETH liquidity on Arbitrum, one could imagine:

  • Balancer incentivizes BLP positions in stable pools.
  • Aave boosting yield for wstETH deposits
  • Bridges listing and subsidizing rETH/wstETH bridging to Arbitrum.

As grants are approved, campaign analysts monitor grant efficacy and objectively determine which grants best support the campaign goals and objectives, iterating upon future disbursements over time to optimize per ARB efficacy.

The tradeoff of this model is significantly greater network alignment and DAO control over the outcome at the expense of admin cost, oversight, and greater restrictiveness.

Direct-to-Contract Incentives Programs

The previous solutions are top-heavy, relying on program design to ensure each level of decision-making is informed and accountable. An alternative establishes a permissionless system that allows anyone to direct activity on a chain while producing standardized and easily comparable data for the DAO and community.

By empowering the DAO to incentivize any contract, the DAO enables a much more powerful playground for network-level incentives by creating a three-sided marketplace between users, incentive creators, and user-friendly frontends.

Components would require:

  • Discovery: A frontend for users to find actionable incentive opportunities.
  • Agnostic: A design space that allows for incentivizing most (ideally all) projects and assets.
  • Customizable: Granular control over incentive parameters.
  • Permissionless access for:
    • Contract Integration: Any protocol can integrate with the infrastructure and become eligible to receive incentives.
    • Incentive creation: Any user can create an incentive using any of the available incentive parameters.
    • Users: Any user meeting the criteria of an incentive opportunity can partake in that action to receive the incentive.

This is a meaningful evolution of current programs, which does not deter protocol-based incentive programs but rather opens up the design space to include complimentary programs and campaigns that far exceed the capacity of STIP/LTIPP-styled programs.

At the end of the day, this is a program to give incentives to incentive managers, who under a competitive marketplace, the DAO can potentially hold much more accountable than projects.

While this infrastructure develops, I do think a few examples of what an agnostic infrastructure for permissionless incentives enables are worth exploring:

  • Project Agnostic Incentives
    • Infrastructure enabling one-to-many qualifications allows for market dynamics prioritizing actual objectives rather than projects.
    • Example: Incentivize ARB/WETH Liquidity on Arbitrum
      • Users can claim liquidity incentives across any ARB/WETH LP.
        • DAO does not select winners nor play kingmaker to existing protocols by giving incentives to some dexes and not others. Rather, market dynamics facilitate selection between where capital flows.
  • Network-Wide Campaigns
    • Usage and performance-based (akin to Polynomial) could reward network-level activity by awarding XP levels across the network by rewarding activities across many protocols. To be eligible, participants must collect the required NFT from each of the supported Protocols in the challenge. Incentives could then be distributed based on XP levels held, raffled, etc.
  • Service Provider Control: Driving Objective Functions
    • The LTIPP program has established Advisor roles that have suggested various “objective functions” (1, 2) but do not actually give them control over the incentives themselves. Allowing direct-to-contract incentives enables service providers to independently run campaigns, leveraging both the user funnels from the shared network and the detailed incentive parameters for targeted campaign design.
    • More importantly, this infrastructure discourages a “winner-take-all” dynamic by allowing these functions to compete in the open incentives marketplace, with open data signaling which functions actually perform best.

This vision is ambitious, and an admitted result of disillusionment in grants programs in general. The challenge of instituting systems that are reliant on human decision-making, especially in an environment resistant to empowering individuals, is antithetical to the philosophy of DAOs and can be exhausting. It’s enticing to build everything from the ground up, on code.

This post is an invitation to those interested in developing this infrastructure.

While I think a protocol like Quest Protocol has a role to play in this system (see above), I also believe this is something that must be integrated vertically both across the grants stack (Hedgey, Allo, etc.), and critically integrated horizontally across the ecosystem. In addition, it likely requires hosted frontends, etc. to maintain both operational efficiency on the backend and maximum integrations for users. Lastly, there is sufficient opportunity for data standardization and availability, including a role for analysts and performance monitors to help evauluate incentive managers.

It’s crucial to design contract systems that efficiently distribute incentives and ensure accountability of incentive managers. With easy access to the necessary tools, we can conduct these experiments smoothly and enable open access to creating campaign and incentive initiatives. Simple at first, and growing in complexity over time.

With equal access to tooling, I believe these experiments can be conducted iteratively, with low friction, and provide permissionless access to campaign and incentive campaign creation.


Definitely find the idea innovative and if used as one of the possible incentive models it could definitely be an interested way to directly target our efforts towards specific goals.

In the end the dilemma of people gaming incentives will still exist that was highlighted in protocol based distribution but it will take different shapes. Specifically the ‘bonus’ for using all protocols on a campaign specifically seems the opposite of the goal of letting the marketplace decide, since you are creating a floor even for poorly implemented options.

Of this larger idea the easiest piece I could imagine being incorporated into the wider incentive efforts while this idea develops is incentive managers. If we were to appoint small dedicated teams (maybe self nominated but ratified by the Dao) on specific efforts (stETH adoption) who could then provide the feedback on an area of focus, it would be easier for protocols submitting a grant application to show how their protocol helps reinforce the programs highlighted by an incentive manager. This way protocols can better identify how their campaigns align to chain objectives. Ex. GMX can show that it’s V2 market have helped to bootstrap $20 million of liquidity for the ARB token both for swap and perpetual trading helping to drive on-chain liquidity for the ARB token.


Very fair points. At the end of the day, once the infra is built the tooling is just the tooling, it still needs meaningful design on top!

Think this is spot on. Big fan of strategic objectives being used to guide capital.

Even further at the tactical level, the flexibility of the infrastructure means it could also be used as to test/iterate w/ small budgets and give SPs and protocols a chance to observe, prove (and improve) processes before tying them down into larger ARB grants.

Understand the sentiment here, think the real benefit is quick iterations. A program’s design is what you make it, any requirements in a cross-protocol campaign could be created as needed, the point moreso being that the optionality is there for campaigns that desire such features without the need for coordinating reward distribution between parties (as actions can be verified and rewarded by the tooling itself).

On a side note, would be great for the community to see a high-level overview from both GMX and other protocol teams on the specific use cases and value delivery they were able to provide w/ STIP.

1 Like