How to build a grant‑backed DAO: the Envelop case

How do you find a reliable grantor to fund your DAO, why the amount raised is not the main thing, and how do you draw positive lessons even from failure? Using Envelop as a case study, Web3 entrepreneur Vladimir Menaskop explains.

Author’s note

This article is for anyone who wants to understand how grants really work, rather than trawling the web to sift sound advice from unverified noise.

It analyses more than three years of Envelop DAO’s work—its successes and missteps—in securing grants.

The organisation went public in October 2021. Shortly before, it won a grant from Rarible after placing in the top ten at a Binance hackathon. Since then the project has received several similar payouts—and missed several others.

I have distilled that experience into practical advice. A checklist at the end should prove useful to anyone planning to work with grant programmes.

All examples are drawn from my own practice and from projects I worked with between 2014 and 2024.

Where to look for grants?

Three basic avenues:

1. The least reliable but simplest—open databases. They are not always up to date and require careful verification.
2. The most reliable but not simple—official websites of grantors or landing pages on specialist resources. The list grows constantly—look no further than the L2s that appeared between 2022 and 2024.
3. Fairly reliable for the attentive—events: calendars of hackathons, conferences and so on, where grants may be awarded either directly or via special selection.

For those choosing the first route, see links here. Examples of the second follow:

• Immunefi;
• HackenProof;
• Gitcoin Grants;
• Builders Knowledge Hub.

A note on the third route. Meetups, conferences, exhibitions and hackathons are where many investors scout talent and expand their networks. You may not win a grant there, but you can prepare the ground. Sometimes you can do both, especially at large events around which plenty happens.

One of Envelop’s first micro‑grants arrived even before the official launch—in spring 2021.

Rarible and originality

Rarible is one of the leading NFT platforms. It returned to form in 2023 when Blur and OpenSea toyed with royalties. Rarible took a clear, public stance: creators would be rewarded.

As for Envelop DAO’s experience, originality mattered most in securing the first, albeit small, grant. Even in Web3, few projects want to research markets and originate ideas. It is easier to take off‑the‑shelf models and reproduce them.

Copying works for quick entry into testnets and new networks in general (see, for instance, Blast). But originality is what lets new services appear where the field looks settled: witness Pendel or Maverick, which learned to work with bits of Uniswap rather than fighting for liquidity as SushiSwap, Pancake and many other forks did.

There is nothing wrong with not innovating; but if innovation is your aim, it can become a useful asset and a plus in external assessments—especially early on. The grant may be small; what matters is to start quickly and keep going (for example, ship an MVP).

At any rate, with the DAOs I have worked with over the past five to seven years this happened repeatedly, including with the first grant: the search for novel solutions is one of my main vectors as an advisor.

Innovation is the foundation on which to build the edifice of technology; but technology without a community is useless. The next step is to enter ecosystems through the community you build as a project.

Polygon: network and community

Polygon is one of the most developed yet unpredictable networks—tricky and fascinating in equal measure. Envelop’s protocol was implemented first in Goerli, then in Ethereum and subsequently, thanks to a Polygon grant, in that network too.

The support was modest ($10,000), but enough to cover developer work that delivered not only a backend implementation but also a frontend—in other words, a full dapp.

Moreover, you can use the project’s oracle in this network, even though Polygon is among the most congested for NFTs. The reason is simple: cheap gas (especially versus Ethereum) enabled collections of thousands, hundreds of thousands and even millions of NFTs.

Later, the project’s own collections on Polygon were created and left to the community. The NIFTSY token also started trading in this network straight from an IDO, and its holder count has not declined. Triple or even quadruple benefits from a single grant are not to be sniffed at.

Which suggests a conclusion: the size of a grant matters less than the depth and vitality of the grantor’s community. Envelop also entered Polygon’s ecosystem—never a wasted link, and a free dose of crowd marketing and SEO.

This approach is not limited to headline networks. One such case was an IPFS analogue that was among the first ICOs.

SWARM—elegant simplicity

Vitalik Buterin once wrote about SWARM as one of three pillars of the Ethereum ecosystem. The project now has its own token, BZZ.

DAO‑led implementations included:

1. Using SWARM as storage for NFTs in the minting app.
2. Later, a proposal to develop Unstoppable NFT, which for various reasons remains on ice.

Another lesson: even if your initial proposal changes or has to change, do not despair. Talk to the grantor’s team. It may accept some changes and reject others, but that is no reason to halt delivery.

Markets change; you change; products change—especially in Web 3.0 / Web3. It is normal for outcomes to diverge from early plans.

The key is to stay in constant, honest and open contact—explain your thinking and why you need to do things a certain way. It will not always work, but it will at least reduce the risk of failure and certainly of unfounded accusations after audits.

Failures do happen. One episode reads like an IT thriller—with setup, suspense, climax and denouement.

Harmony, or Failure one

Why did this fail? It was 2021; the DAO’s bizdev team had rosy hopes and little experience, so neither advisors’ persistence nor our own pragmatism helped.

Harmony is a sharded EVM blockchain—an inviting target for Envelop’s protocol. The grant’s conditions were:

• $10,000 after launching a full‑function product in testnet;
• $10,000 after creating a special multisig (5‑of‑9);
• $10,000 after mainnet launch (with audit);
• $10,000 after reaching 1,000 daily active users (plus a launch video and full PR push);
• $10,000 after reaching 10,000 daily active users (plus a detailed roadmap and full governance description).

Payouts were in One tokens rather than dollars. The bizdev team reasoned thus: if the market falls, by delaying payouts a bit the project will ultimately receive more tokens than at a high price. Later the token would recover—Harmony looked an interesting bet—and Envelop’s assets (in One versus the dollar) would rise.

Reality intervened. While the bizdev team gazed into the coffee grounds, the well‑known bridge hack tied to Harmony happened, and hopes evaporated faster than an inert gas in an open system. Work by the technical team was effectively nullified by several factors, not least “deliberately slowing processes on the part of the bizdev team”.

All development proofs became useless: we even had to redeploy smart contracts in testnet because a fork made them vanish. Yes, vanish. Such is blockchain. A harmful precedent for the industry—but not unprecedented after the ETH/ETC split.

There was no self‑flagellation. The team took the hit and admitted defeat. Contact was also lost with the grant’s original manager: the war in Ukraine started and, as a citizen, he had more urgent concerns.

The takeaway is simple and practical: do not dawdle—move fast but without haste, take what is offered and expect no more. You are building a product first; you are not speculating on grants. Grants are a bonus, not a base.

At least that is my sincere hope. My colleagues’ too. And do study the public correspondence on this grant: “December 2021” and “November 2022” mark a crazily long period in which the world changed. It will change again. Do not assume “this won’t happen to you”. Ever.

WAX and home‑grown closed systems

The next two failed cases reflect what is well described in a Cosmos report: systems that brand themselves as open are often the opposite.

At least in our experience with WAX and Arbitrum Nova. The latter involved no grant, only listing an NFT collection that “underwent moderation” for months while cobbled‑together “competitors” were approved within minutes. We will leave that aside and focus on WAX.

The app itself is still alive and easy to find. But few use it because the WAX ecosystem prefers NFT trading to stay on its own products. That stance ultimately hurt WAX. It had plenty of users, but low purchasing power led to app spam and a perpetual fight for scraps of margin.

One could have avoided seeking mutual PR in such a project. But options were limited at the time, and the deciding factor was a developer who understood WAX’s internals and how to port the protocol to this legacy of the BitShares family.

Zilliqa before EVM

Zilliqa initially looked the leanest of the systems we applied to. Yet there was an important “but”: an active community member, Synergis, who was also in the Zilliqa community. He assembled a bundle of assurances that a grant could be obtained. No guarantees—but worth trying, for three reasons:

• an entry point into the community via a specific person (a Zilliqa ambassador);
• a developer who could grasp the chain’s architecture relatively quickly (within a month);
• a financial buffer to test the hypothesis.

The product was built, but the grant never came. In 2023 Zilliqa shipped EVM compatibility, which killed hope of any grant. Still, the project entered the ecosystem, and the dapp remains functional.

Subsequent grants were chosen not only by community presence but also by statistics. Near and Solana emerged. Solana was hard then for lack of NFT standards; Near was easier thanks to Aurora, which connected to the EVM world and allowed us to reuse existing work.

Near with Aurora

This case shows grantors can spring surprises. The initial documentation and verbal agreements defined three milestones linked to Near via Aurora’s EVM solution. After closing the first two stages, it turned out this was insufficient: a full‑function solution on “pure” Near was required.

That was a problem: a different programming language and a different stack. NFTs in the EVM world and outside it are two very different beasts.

We either had to abandon the grant—wasting time and effort—or solve two problems:

• find a Near developer;
• find a QA tester for that network.

The second solved itself: the DAO’s QA chose to upskill and master Near testing. It took time but was the better long‑term bet.

Finding the developer was harder. We did, eventually, but it took time and money. The net take‑home from the grant shrank sharply, as expenses rose due to paying an external programmer.

Since then the DAO has scrutinised grant agreements and accompanying documents far more closely—and, even after preliminary approval, asks clarifying questions that may determine the fate of the solution.

Aptos and hype with an NDA

Aptos has been the latest test of the DAO’s grant playbook. Reasons:

• to receive the grant we had to accept a detailed NDA that, for example, forbade developing in Move for other blockchains for one year after the grant closed. The grant was paid in tranches; the final payment is effectively expected only by 2025;
• we needed an engineer versed in the Aptos stack, very different from our prior work. We had to estimate timelines to meet grant windows without blowing the budget on developer pay;
• we needed the first payment and confirmation of the second, because the developer could not wait too long—so engineering and bizdev had to act in lockstep.

It worked. A first PR push was set for 2 May 2024, proving that negative experience can be turned to positive effect: the developer for Aptos, Igor Belousov, had helped the DAO with Zilliqa and already knew the protocol’s architecture at a high level of abstraction.

Now to summarise.

What value do grants provide?

The obvious plus is money—more precisely, staged financing. Grants help to:

1. Start with an MVP and develop it into a full beta without tapping other funding (VC rounds, ICOs, IDOs).
2. Assemble an initial community of testers, bounty hunters and other participants.
3. Identify strengths and weaknesses on both the technical and bizdev sides.

Another obvious plus is entry into ecosystems. Examples from this project:

• Near (Aurora);
• Zilliqa;
• Polygon;
• BSC (BNB Chain);
• Blast;
• Arbitrum.

Note that no funds have yet been received from Blast, Arbitrum or BSC, but links and traffic exist. You also get free PR from ecosystems when a grant is awarded—saving, at minimum, hundreds of dollars.

A few examples:

1. An article about integration with a Zilliqa project that would not have appeared without that chain’s implementation;
2. A post from Aurora and its invitation to engage with the project;
3. A post on NFT 2.0 at the SWARM forum;
4. Aptos even offers a whole package of activities under the Aptos Ecosystem Marketing Playbook.

Another benefit: learning to handle rejection.

What if you are rejected?

A non‑exhaustive list of those who said no: Ethereum, Solana (Neon), EvmOS, Tron, Cronos, Metis and others. There were also indirect refusals—no replies—from Avalanche, Web3Foundation, WAX, Zilliqa and many more.

In the latter case, submit a second, third, fourth application. Managers change, teams’ states change and markets change: applying in the 2021 bull, the 2023 slump or the mini‑hype of 2024 are three different things.

First, ideally before applying, assess the system’s technical and organisational state. Our Zilliqa and WAX bets failed for the same reason: practice did not match promises. Their stats still diverge. WAX, in particular, prioritised its own marketplaces and semi‑closed solutions, so external development is likely to be rejected.

Second, financial health. A system may be sound technically and have a community, but funds may be dwindling—or gone (Harmony, Zilliqa, WAX are examples). Do not count on grants then. That was the case with Harmony after the infamous hack. It can happen to any L1 or L2, any ecosystem and especially to specialist DAOs.

Due diligence takes time but pays off: you learn not to waste effort. Think of it as training for an ultramarathon, not a sprint. Too many treat the grant game as many sprints, not one ultramarathon.

Third, sometimes your idea is not as simple as it seems or outside the protocol’s priorities. That is fine. Were crypto and blockchain development uniform, we would see decay, not growth. Accept it and move on. Miracles happen, but they do not define a project’s evolution.

Fourth, your own misses. Sloppy applications; vague process descriptions; weak technical documentation; thin bizdev engagement—these and more are like a dripping tap: one drop a second is three or four litres a day, enough for two adults. Most startups fail to count those drops once first money arrives.

Fifth: the ideal grant is a micro‑project that helps you advance your technology. Focus on that even before applying. At least sketch the project’s stack and architecture. Otherwise you may repeat Envelop’s Near/Aurora experience: the grant’s conditions were met, but at great cost in team energy.

You will understand the system better regardless

Few realise grants can fund your own research, which you can then apply to a class of similar systems.

Consider Igor Belousov’s notes on Zilliqa. Its core concepts mirror Ethereum’s. Account addresses are a function of the public key. Contract addresses are new with each deploy. Contracts closely resemble Ethereum’s: there is contract code and a contract state that can be accessed by contract address.

Then the differences start. The Scilla contract language was designed to reduce coding errors. It is highly idiosyncratic, requiring great formality in constructing statements. One big surprise is the lack of classic loops.

Iteration over the built‑in data type (list) is possible via forall or special recursive structures. To quote the developer:

“However, I often failed to get these structures to yield the equivalent of ordinary loops—let alone nested ones.”

Another unusual feature is working with user‑defined structures:

“To obtain the data of a structure’s field, you must unpack the variable of that structure into a tuple of variables; then you can use the variable at the required position in code. Yes, one amusing bit: a boolean variable inside is also a structure. Therefore, when forming transactions you must send not just true or false but a string representation of the structure.”

The if operator is absent. Instead there is a match construct. The result is bulky, hard‑to‑read code where a few lines would otherwise suffice.

More issues arise because, unlike Solidity—where referencing a non‑existent variable simply returns 0 or false—in Scilla you must always check if a variable exists. So a simple Solidity comparison, if a==b, becomes three nested matches: first to check that a exists, then that b exists, and only then to compare them.

Perhaps the most important Zilliqa feature is sharding. Because of it, inter‑contract calls work differently from Solidity. Each time you need to modify another contract’s state, you must create a transaction to call that contract’s function. Conversely, reading contract state in Zilliqa is done not via get functions but via direct access to state variables.

Because interaction is transaction‑based, there is a limit on the number of internal transaction calls. As of May 2024, it is 20. Yet the NFT standard in Zilliqa provides for callback checks. So each token transfer triggers at least two transactions.

Another quirk: code is not compiled and is written to the blockchain explicitly. “This let me inspect implementations of standard algorithms I could not find in the documentation of large production projects,” says Igor Belousov.

Thus, even without the desired financial result we gained three large positives:

• we confirmed the developer has excellent analytical instincts and can study similar systems in future (as shown on the Aptos grant);
• we found weak spots in Zilliqa. Should the ecosystem revive, we could propose useful upgrades (especially relevant for DAO‑run grants such as Arbitrum’s);
• we became a team that knows Zilliqa’s NFT architecture better than most (and Wax’s, Near’s, Aptos’s and that of the vast majority of EVM blockchains).

Not a bad haul, on reflection.

Grant checklists

Where to look?

• in general lists;
• in analytical reports (an example);
• via general search with specialised queries.

Who pays?

• DAOs—especially large ones (Arbitrum, Optimism);
• networks—both L1 and L2 (Blast, Mode, Polygon);
• new projects with large raises (Crunchbase helps).

What to use grants for?

• to launch an MVP quickly;
• to enter an ecosystem;
• for PR.

What if you are not a developer?

• try grants for non‑technical contributors: the podcast about the Cosmos ecosystem by Sergey Simonovsky is one such success;
• hunt competitions and enter them: my article made the Web3 top‑10 on Hackernoon. A large‑budget contest also ran on Exploit.in;
• find a technical team that needs bizdev: start with those event calendars.

Conclusion

Even a long article cannot cover every facet of grant‑seeking from the recipient’s side. But the basics here should help you find the foundations and, from there, build your own Web3—or Web 3.0—project.