AditiSemi Mid Year Learnings
some of them are serious, some of them are silly. all of them are valuable. not ordered in any special way. learned = relearned = sharpened = blahWhen you’re overthinking = write. When you’re anxious = walk. When you’re tired = sleep. When you’re sad = moveHaving a different location to work from vs. live from is a game changerThe key to working through lulls is to keep moving. Get up, get out, go out. I like to end my day at the parkSomeone finally/unironically called me “Sir/Ser” on CT, tha...
AditiShifts in Product Dynamics
There’s been some clear shifts in how product is being built in web3 since the onset of the bear market.Velocity is the new constant: We're not just moving quickly, we're at lightspeed. The pace of what is getting built in the space is a constant change of new technologies & UX patterns (eg. bridging directly into Base on Friendtech, AA/MPC, zkEVMs, etc). Interestingly the platforms where the discourse is taking place is highly fragmented this cycle, especially given the onset of al...
AditiSovereign Rollups - A Brief Intro
In order to fully understand what a sovereign rollup is, we’ll need to first understand the different pieces of a blockchain:Data Availability and Consensus - makes sure data is available and that there is an agreed upon ordering of transactions. Example: CelestiaSettlement - writes transaction data to the DA layer while publishing new state to the settlement layer. Settlement layers maintain state roots and is a place for dispute resolution and proof verification to take placeExecution - pro...
half-baked thoughts: @adeets_22 (twitter) bio: https://aditi.is/
AditiSemi Mid Year Learnings
some of them are serious, some of them are silly. all of them are valuable. not ordered in any special way. learned = relearned = sharpened = blahWhen you’re overthinking = write. When you’re anxious = walk. When you’re tired = sleep. When you’re sad = moveHaving a different location to work from vs. live from is a game changerThe key to working through lulls is to keep moving. Get up, get out, go out. I like to end my day at the parkSomeone finally/unironically called me “Sir/Ser” on CT, tha...
AditiShifts in Product Dynamics
There’s been some clear shifts in how product is being built in web3 since the onset of the bear market.Velocity is the new constant: We're not just moving quickly, we're at lightspeed. The pace of what is getting built in the space is a constant change of new technologies & UX patterns (eg. bridging directly into Base on Friendtech, AA/MPC, zkEVMs, etc). Interestingly the platforms where the discourse is taking place is highly fragmented this cycle, especially given the onset of al...
AditiSovereign Rollups - A Brief Intro
In order to fully understand what a sovereign rollup is, we’ll need to first understand the different pieces of a blockchain:Data Availability and Consensus - makes sure data is available and that there is an agreed upon ordering of transactions. Example: CelestiaSettlement - writes transaction data to the DA layer while publishing new state to the settlement layer. Settlement layers maintain state roots and is a place for dispute resolution and proof verification to take placeExecution - pro...
half-baked thoughts: @adeets_22 (twitter) bio: https://aditi.is/
Share Dialog
Share Dialog
Subscribe to Aditi
Subscribe to Aditi
>200 subscribers
>200 subscribers
First things first, big shoutout to Lisa who collaborated on this post with me and to Christina from Aave, who shared her experience and lessons learned from launching the Lens Grants Program.
Much has been written about the importance of community in web3. A protocol community can support and accelerate decentralized protocol development, integrations, commercialization, user education, or globalization. As they’re forming, communities often need guidance from the protocol core teams to be most effective. Over time, the community can set the direction and lead itself.
In both cases, grants programs are used to engage and reward the community for pushing the protocol forward. While protocols have allocated and deployed significant capital to their communities, grants programs are nascent in documenting best practices. There is no go-to playbook out there that helps early protocol teams bootstrap and launch grants programs. In speaking with protocol teams and grants recipients, there was a clear need to share more about how grants programs work behind the scenes.
In the past year, we were tasked with kicking off the grants programs for our protocols - Aztec and Celestia. In the absence of publicly available information, we tapped our networks and learned the best way to gather these insights were through private channels and 1:1s. So we decided to establish a grants program playbook including our lessons learned that we could share broadly.
We hope that this guide will save you time so you can focus on what’s most important to your protocol - launching and running a grants program that builds and strengthens your community.
So you’ve been asked to start a grants program, a huge and exciting responsibility for the success of your protocol and its community. You may be a developer relations engineer, business development manager, community manager, operations lead, or grants program manager. Regardless of your title, you’ll need the buy-in and support across the company to launch a successful grants program
Establish grants team: Assuming that your grants program will be rewarding the development of the protocol, integrations, or applications using your protocol’s technology, you’ll need a grants program lead and at least one developer relations engineer. The grants program lead will handle operational aspects of the grants program, while the developer relations engineer will provide technical support to grantees.
Operational responsibilities include reviewing and processing applications, setting quarterly priorities for grants, writing RFPs to the community, scoping the milestones, tracking grantee status, and managing grant payments.
Technical support includes answering technical questions, improving documentation, pairing with grantees, reviewing code for applicants, and hosting office hours. It’s imperative to have both the operational lead and the technical lead owning the program – one without the other makes staffing lopsided.
Determine program budget: Budgets allocated for grantee payouts vary significantly. Regardless, it is best to launch a pilot of the grants program to test assumptions and learn about what budgeting makes the most sense before scaling the program. This pilot may last for a few months or quarters, but sufficiently long to gather enough data points on where your team needs more support, how you can better support developers, and establish processes that scale.
When you’re establishing the budget for the grants program, you should consider expenses outside of payouts for grantees. These expenses include but are not limited to legal counsel to establish a template grants agreement, auditing services with an external auditor (you may want to negotiate a special rate for grantees or subsidize/cover the audit costs), and marketing to attract more submissions, which may include hackathon sponsorships and conferences.
Define technical and legal requirements for payouts: While on the topic of budgets and payouts, you’ll need to determine with your operations, finance, and legal teams on what information is needed in order to pay out grantees. For example, if your project is pre-token, you may not want to issue grants with pre-token interests. Similarly, you may want to issue grants in stablecoins which requires multisig management, etc.
While this may sound straight forward, it varies significantly depending on the jurisdiction of your company or DAO and local requirements. We suggest speaking with your legal counsel and finance teams to ensure these payments are compliant.
Determine your grants stack.
Airtable, Typeform, Google Forms, or Notion Forms – these tools can be used to capture inbound. For what it’s worth, these tools may get unwieldy and hard to manage as the grants program scales. ConsenSys, for example, had 3 FTEs managing their Google Doc of inbound.
Submittable – $5k for a basic package, up to $20-30k for customization, may be a better fit for more mature grants programs (Celo uses this, for example).
Template out your responses to people’s submissions so that you do not need to re-write instructions and links to resources.
In the future, we expect this grants stack to change pretty dramatically. Projects like Station are thinking about how to better create bottom-up value creation, reduce friction for the gig economy, and improve the talent acquisition process.
Create a landing page for the grants program. You’ll want a website that has all the information about the grants program including the process, application, program support framework + benefits, and links to documentation. This could either be on your protocol’s website or quickly spun up on Notion.
Set up an announcements channel. Establish a channel on Discord, Twitter, or Medium for people to go to for information about the grants program and application waves. This also helps technical teams review questions or feedback from the community.
Partner with other projects. If your grant program can benefit other projects, promote within those communities and ask those projects to offer a matching grant. Other projects can also help promote via Twitter and Discord, and invite you to their community calls to reach the most engaged community members.
Reward your top contributors! This is easily the most forgotten step. It means a lot to early contributors if you can subsidize their stays at conferences, pay for conference or event tickets, etc. These gestures go a long way + help build up your community of early adopters.
We hope this is a helpful starting point as you establish your projects’ grants program. We welcome any feedback and expect that this piece will be part of a broader and ongoing effort to improve how protocols engage and grow their communities.
First things first, big shoutout to Lisa who collaborated on this post with me and to Christina from Aave, who shared her experience and lessons learned from launching the Lens Grants Program.
Much has been written about the importance of community in web3. A protocol community can support and accelerate decentralized protocol development, integrations, commercialization, user education, or globalization. As they’re forming, communities often need guidance from the protocol core teams to be most effective. Over time, the community can set the direction and lead itself.
In both cases, grants programs are used to engage and reward the community for pushing the protocol forward. While protocols have allocated and deployed significant capital to their communities, grants programs are nascent in documenting best practices. There is no go-to playbook out there that helps early protocol teams bootstrap and launch grants programs. In speaking with protocol teams and grants recipients, there was a clear need to share more about how grants programs work behind the scenes.
In the past year, we were tasked with kicking off the grants programs for our protocols - Aztec and Celestia. In the absence of publicly available information, we tapped our networks and learned the best way to gather these insights were through private channels and 1:1s. So we decided to establish a grants program playbook including our lessons learned that we could share broadly.
We hope that this guide will save you time so you can focus on what’s most important to your protocol - launching and running a grants program that builds and strengthens your community.
So you’ve been asked to start a grants program, a huge and exciting responsibility for the success of your protocol and its community. You may be a developer relations engineer, business development manager, community manager, operations lead, or grants program manager. Regardless of your title, you’ll need the buy-in and support across the company to launch a successful grants program
Establish grants team: Assuming that your grants program will be rewarding the development of the protocol, integrations, or applications using your protocol’s technology, you’ll need a grants program lead and at least one developer relations engineer. The grants program lead will handle operational aspects of the grants program, while the developer relations engineer will provide technical support to grantees.
Operational responsibilities include reviewing and processing applications, setting quarterly priorities for grants, writing RFPs to the community, scoping the milestones, tracking grantee status, and managing grant payments.
Technical support includes answering technical questions, improving documentation, pairing with grantees, reviewing code for applicants, and hosting office hours. It’s imperative to have both the operational lead and the technical lead owning the program – one without the other makes staffing lopsided.
Determine program budget: Budgets allocated for grantee payouts vary significantly. Regardless, it is best to launch a pilot of the grants program to test assumptions and learn about what budgeting makes the most sense before scaling the program. This pilot may last for a few months or quarters, but sufficiently long to gather enough data points on where your team needs more support, how you can better support developers, and establish processes that scale.
When you’re establishing the budget for the grants program, you should consider expenses outside of payouts for grantees. These expenses include but are not limited to legal counsel to establish a template grants agreement, auditing services with an external auditor (you may want to negotiate a special rate for grantees or subsidize/cover the audit costs), and marketing to attract more submissions, which may include hackathon sponsorships and conferences.
Define technical and legal requirements for payouts: While on the topic of budgets and payouts, you’ll need to determine with your operations, finance, and legal teams on what information is needed in order to pay out grantees. For example, if your project is pre-token, you may not want to issue grants with pre-token interests. Similarly, you may want to issue grants in stablecoins which requires multisig management, etc.
While this may sound straight forward, it varies significantly depending on the jurisdiction of your company or DAO and local requirements. We suggest speaking with your legal counsel and finance teams to ensure these payments are compliant.
Determine your grants stack.
Airtable, Typeform, Google Forms, or Notion Forms – these tools can be used to capture inbound. For what it’s worth, these tools may get unwieldy and hard to manage as the grants program scales. ConsenSys, for example, had 3 FTEs managing their Google Doc of inbound.
Submittable – $5k for a basic package, up to $20-30k for customization, may be a better fit for more mature grants programs (Celo uses this, for example).
Template out your responses to people’s submissions so that you do not need to re-write instructions and links to resources.
In the future, we expect this grants stack to change pretty dramatically. Projects like Station are thinking about how to better create bottom-up value creation, reduce friction for the gig economy, and improve the talent acquisition process.
Create a landing page for the grants program. You’ll want a website that has all the information about the grants program including the process, application, program support framework + benefits, and links to documentation. This could either be on your protocol’s website or quickly spun up on Notion.
Set up an announcements channel. Establish a channel on Discord, Twitter, or Medium for people to go to for information about the grants program and application waves. This also helps technical teams review questions or feedback from the community.
Partner with other projects. If your grant program can benefit other projects, promote within those communities and ask those projects to offer a matching grant. Other projects can also help promote via Twitter and Discord, and invite you to their community calls to reach the most engaged community members.
Reward your top contributors! This is easily the most forgotten step. It means a lot to early contributors if you can subsidize their stays at conferences, pay for conference or event tickets, etc. These gestures go a long way + help build up your community of early adopters.
We hope this is a helpful starting point as you establish your projects’ grants program. We welcome any feedback and expect that this piece will be part of a broader and ongoing effort to improve how protocols engage and grow their communities.
Based on this guidance, you can create standard instructions to share with grantees and automate invoice generation using a tool like Request. We also highly suggest creating a payment schedule, like a milestone based payout schedule.
Prepare documentation for external use: While you’re doing the heavy lifting on the operational side, you’re building the developer experience in parallel. Grantee applicants will rely on documentation in order to start building. If your docs aren’t specific or detailed enough, your team will receive many questions - often the same questions - from grantees as they’re building.
Putting in the work upfront will save your team a ton of time in 1:1 support and office hours to answer questions that your docs could easily answer. You’ll want to write clear instructions with sample code that grantees could use as a reference.
If you have an existing developer relations team, they can help you set up clear documentation to support grantees. Additionally, you’ll want to determine the best solution for testing and debugging, and provide guidance on what tests should be done ahead of their final submission.
Outline milestones and expectations for the grants: In your grants documentation, it’s important to clearly identify requirements and milestones for successful grant completion and payment - and beware of scope creep once you’ve announced.
Requirements may include submitting a spec, testing the code across a range of assets and edge cases, demos, and documentation to explain how the code works. If your engineering team is involved in reviewing submissions, incorporate their input to ensure they have what they need for grantee submissions.
Additionally, you may decide that a portion of the grantee’s work should open source versus proprietary. You may also require an audit in case you need to merge community generated technology in the upstream codebase.
Based on this guidance, you can create standard instructions to share with grantees and automate invoice generation using a tool like Request. We also highly suggest creating a payment schedule, like a milestone based payout schedule.
Prepare documentation for external use: While you’re doing the heavy lifting on the operational side, you’re building the developer experience in parallel. Grantee applicants will rely on documentation in order to start building. If your docs aren’t specific or detailed enough, your team will receive many questions - often the same questions - from grantees as they’re building.
Putting in the work upfront will save your team a ton of time in 1:1 support and office hours to answer questions that your docs could easily answer. You’ll want to write clear instructions with sample code that grantees could use as a reference.
If you have an existing developer relations team, they can help you set up clear documentation to support grantees. Additionally, you’ll want to determine the best solution for testing and debugging, and provide guidance on what tests should be done ahead of their final submission.
Outline milestones and expectations for the grants: In your grants documentation, it’s important to clearly identify requirements and milestones for successful grant completion and payment - and beware of scope creep once you’ve announced.
Requirements may include submitting a spec, testing the code across a range of assets and edge cases, demos, and documentation to explain how the code works. If your engineering team is involved in reviewing submissions, incorporate their input to ensure they have what they need for grantee submissions.
Additionally, you may decide that a portion of the grantee’s work should open source versus proprietary. You may also require an audit in case you need to merge community generated technology in the upstream codebase.
No activity yet