Disclaimers:

• The content of this post is my personal opinion and not necessarily that of my employer. 

• The examples below are related to projects building their first web3 platform and not of web3 native established projects.

Lack of Product Definition

Most, if not all, projects are successfully delivered when there’s a well defined scope, requirements and product definition in general. Some clients would want a quote produced from a pitch deck, mockup or google doc with a vague description and some bullet points. 

When it comes to web3, or software development in general, the Product Definition phase of the project is perhaps the most critical. By skipping PD, there’s always surprises that end up with scope creep, blown-out budgets and delayed delivery. Spending time on User Journeys, defining (and prioritizing!) requirements, and having a complete set of User Stories (plus other techniques) will set the foundation of the platform. 

Interestingly, it’s often the case that, while going through this phase, disagreements between project team members (usually founders) arise and, needless to say, it’s better to iron out things at the beginning instead of in the middle of the project.

Build the platform around a Token

I’ll start by saying that not every single web3 platform needs a token. And those platforms where a token is required, should spend a great deal of time defining the token economics (aka tokenomics).

Let’s see how bad tokenomics can cripple a project:

• Lack of token utility: in order to justify the existence of a token, some projects force demand with use cases such as “buy my product/service with my $TOKEN” and then they get into this scenario:

In this scenario, the users looking to procure the platform’s product or service only need to obtain the token just so they can spend it (often right away) without needing to hold it, which means the token demand is temporary at best.

Another inefficient token use case is “Staking”. The original purpose of staking was to secure POS networks, validate blocks and be rewarded for doing so. These days, a lot of platforms have “staking programs” with the sole objective of reducing circulation, guaranteeing team and early investors the possibility of selling their tokens with less sell pressure. Good read on the topic here.

• Unfair Token Distribution: some teams issue a token (before having a platform) with distributions not only skewed in favor of the team and early investors but also badly designed Vest Schedules which typically generate the below price action:

While this might be good for early investors and founders, now you have a community pissed off and that will probably not only give the project bad marketing on social media but also not use the platform at all. We recommend our clients to spend time defining their token economics with specialized teams.

Good resources in terms of Optimizing Token Distribution here, and Optimal Token Vest Schedule here.

To wrap this one up:

→  If the platform needs a token, founders must make sure the tokenomics are designed correctly;

→ If the platform does not need a token (at least from the get-go), it’s always better to first find product-market fit, and launch the token at a later stage. This way, the team has the opportunity to reward early adopters with airdrops, which by the way is a great way to market the project and grow the community organically.

Build a bigger-than-needed platform

While it is important to have a product roadmap, some teams are tempted to include way too many features on their initial product release. Web3 is a highly experimental industry which moves at a neck-breaking speed and by wanting to build platforms with all the bells and whistles founders could end up burning a lot of money for a platform that might not end up finding product-market fit.

The best approach is to build either a Proof-of-Concept or a Minimum Viable Product in an Agile fashion and release it to market to see what the reception is. Most platforms will require several iterations and some of them will end up pivoting to different use cases down the track. 

Let’s define these concepts so everyone is on the same page:

POC: aims to demonstrate the feasibility or potential value of your idea or approach to validate it before committing significant resources to its development. 

• Ultra low cost entry to validate product concept

• Usually best for early-stage and self-funded teams

• Tool to secure venture funding or demonstrate product value to stakeholders

MVP: a cost-effective way to validate market demand and gather feedback on your product or service, it's a great way to showcase your value proposition to target customers and improve chances of success.

• Suitable for teams with seed funding, ready to launch their first live product

• Low cost strategy for quickly bringing a product to market

• Establish a foundation for future iterations

Only then teams should focus on a fully fledged Production platform that is released at scale.

Conclusion

If you are part of a team building a web3 platform, put some consideration into these topics in order to maximize the chances of success of your product. Questions and feedback are always welcomed, feel free to reach out.

Courtesy of @hildobby_, we can see below that gas fees are almost at all-time lows. Generally speaking, gas fees are a good indicator of network activity.

Let's have a look at the transaction count. There's been a clear downturn since June, from 11m to 8m weekly transactions. During the bull, transaction declines much smaller than this one were simply attributed to the high cost of executing transactions in Ethereum (remember alt-L1 season?).

If we look at L2BEAT, we can see that over 80% of Ethereum’s L2s' TVL is shared among the 2 most prevalent optimistic roll-ups, Arbitrum and Optimism.

So, how does TVL translate into transaction count?

For the scope of this blog entry, I’m going to look at Arbitrum and Optimism transactions during Q3-2022, and compare it to Ethereum’s.

We can clearly see that the trends for both rollups is up-only:

If we look at the chart below, the sum of L2s transactions as a % of Ethereum’s (green line), at the beginning of July, they only represented 11%. In the 3rd week of Sept this figure represented almost 60%, which means it will not take long for the L2s to flippen Ethereum’s in terms of transaction count.

Clearly L2s have onboarded many users during Q3 but one could also argue that, given Ethereum’s downtrend, users are moving their transaction activity from Ethereum to its L2s.

And this is exactly the ultimate goal of Ethereum’s modular & rollup-centric approach.

Now, this begs some questions:

• If some Ethereum users prefer to transact in L2s while gas in mainnet is extremely cheap, what is going to happen when mainnet gas returns to… let’s say 100 gwei?

• What happens when the retail masses come back ? Some of them will probably never need to transact in mainnet, they will be onboarded directly to its L2s.

Additionally, soon we’ll have a new breed of scaling solutions enter the scene → zkEVM rollups, which will bring further optimisations both in terms of fees, speed and security.

The future is bright for L2s.

Rollups will drive the industry towards a thriving and competitive multi-chain future. Ethereum mainnet will be used by humans less and less as it becomes a storage and settlement layer for the rollups (and likely for other blockchains too), where individual users will interact and execute transactions. Fees will be negligible, security will be unparalleled and decentralisation unmatched.

And then we’ll have Proto-Danksharding (EIP-4844), which is scheduled to be included in the first hard-fork post-merge but that’s a topic for another day.

Fin.