De belangrijkste reden waarom Monad besloot om EVM-compatibel te zijn, was omdat EVM al een heleboel ontwikkelaarstools en -bronnen heeft. Er is niets bijzonders aan EVM zelf, en er is ook niets dat bijzonder gebrekkig is. Het is een standaard (maar beetje raar met 32 byte woorden) stack-gebaseerde VM, met een kleine, goed gedefinieerde runtime. De implementatie is niet veel anders dan wat je zou vinden in een niet-gegradueerde compiler/interpreter-klas. Het heeft dus geen zin om opnieuw te beginnen. Je zou alle bronnen/tools/community/etc helemaal opnieuw moeten opbouwen. Sommigen denken er duidelijk anders over toen ze besloten nieuwe VM's te bouwen, maar ik ben niet overtuigd. Dit wil niet zeggen dat Monad niet zal innoveren op dit gebied - dat zal het absoluut doen. @category_xyz heeft een geweldig "compiler"-team met eersteklas ontwikkelaars en onderzoekers. Je zult de output van dat team in de toekomst zien. Een ding dat ik met @zen_llama besprak toen hij werd aangenomen, was dat ik me moest concentreren op dev-ondersteuning. Monad en/of Category kunnen dat zeker beter doen, en we zijn daar recentelijk mee begonnen. De focus ligt voorlopig op de meest prestatiegevoelige apps. Veel apps hebben nooit begeleiding nodig vanwege de EVM-compatibiliteit, sommige apps hebben een beetje nodig en een klein aantal apps heeft veel hulp nodig. Ons team leert en verbetert ook van deze samenwerkingen - ze zijn voor beide partijen voordelig. re gemeenschap, ik verwelkom elke vorm van onenigheid en feedback die oprecht is. Ik heb het gevoel dat ik dit punt al vele malen eerder heb gemaakt.
ZenLlama
ZenLlama9 jun 2025
1) I disagree with the approach Monad is taking to build its developer ecosystem. A three-person DevRel team vs. a 30+ person eco team is a problem. Dev support >>> growth and marketing support, and ex-VC advice is not helpful to early-stage builders—it’s distracting. Furthermore, I don’t think you should optimize for raw top-of-funnel numbers, and I don’t think marketing attracts the builders you actually want. You should make focused bets on people and novel tech, prioritizing native builders over migrating incumbents. Raw talent >>> pedigree, every day in my book. When you allow incumbents to come into the ecosystem early, it does bring legitimacy to your chain, but it disincentivizes builders from innovating in those product categories because the competition is hard to overcome. Toly talked about this on the recent a16z podcast on why Solana was successful, and I fully agree. You need to find the builders willing to chew glass and rebuild existing things in new ways, because that’s how you find the ones willing to cut their teeth alongside you. 2) Full EVM compatibility is a mistake. You want to expose your tech in ways that open new frontiers and provide a forcing function for builders to build things that literally can’t be built anywhere else. Making things easy for builders should not come at the cost of having an undifferentiated tech stack. You can do both, but you need to prioritize dev support over growth and marketing support. “Faster, cheaper EVM” was a novel idea four years ago—the times have changed. You need to offer more than raw speed now. The writing was on the wall for years. I still think Monad should build a “Monad Standard Library”—something I advocated for on day one of my job there but could never get any resources allocated toward. My fear has always been that you needed to start building this years in advance and have it ready so that infrastructure providers could adopt it before mainnet. 3) Homogenous communities are not actually healthy. It may seem great to have a community that is always happy-go-lucky when all you see is your echo chamber, but from the outside looking in, it’s not inviting—it feels fake. I know it’s not fake because I’ve met the Monad community in person, and it’s the most vibrant, cheerful, supportive, and lovely community I’ve ever had the privilege to be part of—but it’s very curated. Life is not curated. It’s messy. People fight, they cause drama, they say things you don’t like, and that muddies the waters. When you enter a community without that, it’s heaven to some but hell for others. You need a mix of both. You need fewer surface-level interactions and more deep questioning. You need people in the community willing to get in fights on your behalf. Most importantly, the community needs to form an identity independent of the founder. 4) MegaETH correctly identified that VC backing is not a benchmark that normal people view as success and has leveraged that to their benefit in a populist movement. This wasn’t done explicitly, but implicitly—and I believe it’s a side effect of not being more upfront with teams about launch timelines. The team will likely disagree with me on this, but look, I’m a vibes guy—and that was the vibe. When you run founders’ events pre-launch and put yourself on a stage talking about how to build a successful company pre-launch while only having a large raise to show for it—this is the natural conclusion people draw. When you make VC funding of ecosystem projects pre-mainnet a regular occurrence, this is the conclusion people draw. I’m not saying this is a bad thing. If anything, it gives teams more runway to build with you for the long term. I’m saying it’s a perception issue that flows from a timing mismatch between when the chain was expected to launch and when it is actually launching. 5) Let your team have a real voice. 99% sure I’d have been fired for writing this while still there. That’s a problem.
41,91K