Today, we hit 100,000+ community members on Discord, 300,000+ total across socials and lately, we have seen exponential growth on the demand side of our network. It's a BIG FEAT for us, so I thought of penning down our 4-year journey, which might be helpful to emerging DePIN entrepreneurs and for people who are interested in what Huddle01 have been up to.

The genesis of Huddle01 Network took place at Hackathon back in 2020, HackFS, which was co-organised by the Ethereum Foundation and Protocol Labs. It was a 4-week hackathon to build some impactful products.

The idea was to build a decentralized network to improve real-time communication. Back then, it wasn’t called DePIN. Cloud infrastructure had already enabled the rise of breakthrough consumer applications we use every day, but it came with serious limitations. Hyperscaler data centers are sparsely distributed across the globe, which creates performance bottlenecks for high-bandwidth tasks like real-time communication, CDNs, real-time finance (HFTs) and more.

For a video call happening in Africa, the audio/video packets get routed to a very far-off data centre via submarine optical fibre cables, leading to heat loss, which in turn leads to jitter, buffer, and latency, aka bad performance. Moreover, this problem of speed and performance goes beyond just real-time communication, to things like CDN, real-time finance (HFTs) and much more.

Moreover, CLOUDS charge HUGE Egress costs. The markups on bandwidth these hyperscalers charge to a client vs what they pay to an ISP are bonkers. There is a 300 %+ markup across regions on these egress costs. This is one of the biggest CASH COWS in the technology business I can think of. Clients like Zoom pay massive Egress costs to these hyperscalers.

This is where DePIN (Decentralised Physical Infrastructure Networks) makes a ton of sense. For any bandwidth-related tasks, rather than relying on hyperscalers, people/small businesses can contribute bandwidth.

This gives a bandwidth-based DePIN network few structural arbitrages: 1) re-usage of existing hardware, 2) virtually non-existent egress costs. In the past, I've had pretty good discussions with Kyle Samani (Managing Partner, Multicoin) on this, who thinks very deeply about DePINs.

Pair that with crypto-incentives, and now you have a very distributed supply side, which can be more performant and cost-effective than hyperscalers. There are a couple of different paths bandwidth-based DePINs have taken to solve various problems that arise due to low bandwidth and high latency. Huddle01 Network started with solving it for real-time communication.

This was an important context to share about Huddle01 and bandwidth-based DePINs before I start writing about how Huddle01 approached the GTM for both the 'supply side' and 'demand side' of the network.

There is a chicken-and-egg problem in DePIN networks. If you are going against hyperscalers, you need to have a very strong supply side of the network. While on the demand side, sooner or later, you need to have a step-function or exponential curve growth for the economics to make sense in the long term (this is a very hard problem to solve). As a DePIN founder/operator/contributor, you need to bootstrap the demand side and supply side yourself for starters.

There is not a big need for building new hardware for creating a decentralised bandwidth network, you can repurpose existing hardware (a home computer, a Raspberry/orange pie, VPS on bare metals, even hardware of existing DePIN networks)

Learning from some of the past DePIN plays, we realised quickly that giving out token emissions for renting their hardware for a virtually non-existent demand can turn out extremely dangerous once the network hits the mainnet. We need to have some form of skin in the game for these node operators (MEDIA Nodes in our case).

We used a novel mechanism called Node Sales (also used by a few DePINs before us), where people who want to run the nodes need to buy the "node keys". Node keys are nothing but software licenses in the form of ERC721 NFT, enabling you to earn rewards by operating a Media Node. One can run these media nodes themselves or give them to a NaaS (Node-as-a-Service) operator for a fixed fee or % commission.

We now have 2200+ media node keys bought by people and nodes running actively in various regions of the Earth.

While the network is still in its infancy, it has already contributed 110,000+ Mbps of bandwidth and 1000+ cores. Since these are high bandwidth nodes and sitting at edges, they can power anything low latency from RTC, CDNs, data transfer to HFTs, with RTC being the beachhead.

The good news is that this network is already at 40% of utilisation because of our native products on the network - and. (More on that in the Demand-side GTM section)

With the network already seeing its good utilisation due to growing demand from our products and developers using our SDKs, we will be moving towards expanding the network and doing a Phase 2 of Node Sales in the upcoming months.

If you are a big network operator with dedicated bandwidth and want to join the network, please DM.

Btw, we have thought pretty deeply about our network, and if you want to nerd out, you'd like this - our whitepaper.

Unlike a lot of other DePINs, before building the network, we took a product-first approach and built an app ourselves to bootstrap demand - much inspired by our conversations with Juan Benet (Founder, Protocol Labs)

in the early days. From first principles, it made perfect sense - because of inherent virality in an audio/video conferencing product + lower latency, better performance, 1080p video quality, end-to-end encrypted, being feature-rich, it could take a small portion from Zoom's/Google Meet's market. Makes sense, right?

Turns out it is really hard to build a scalable video conferencing product (WebApp + iOS + Android), you need a high degree of product chops, extreme depths of distributed systems and computer networking understanding, and once you conquer both of these beasts, you have to defeat the BIGGEST BOSS of them all, DISTRIBUTION.

There are various attack vectors/GTM strategies to go after distribution for your application: product-led marketing, SEO/ASO, performance-based marketing, SMBs/enterprise-grade sales, but one of the best ways for a lower CAC, prosumer-heavy ICP and higher growth is using crypto incentives itself.

We did a simple yet powerful incentive: Reward users for providing network effects to your application."

https://x.com/huddle01com/status/1912170349363667031

This has had a massive top-funnel growth for us.

Zoom was originally built for enterprises, but because a black swan event in the year 2020 gained a massive amount of network effects, which reflected in their stock's price action. Barring the utility of a decent audio/video call, none of the value flowed back to you. This changes with crypto incentives, which rewires the economic value flow.

We are seeing an exponential trend in terms of usage of the Huddle01 Meet Application. Almost 3000 concurrent participants are using the application.

There is a very legitimate point that incentives bring some mercenaries into the system, and there will be drop-offs, but on the flip side, it also solves the discovery problem. If your product is good enough, it will not have a leaky bucket, i.e. there will not be a very big drop off from top funnel to bottom funnel, and you'll see some paying users.

We have been seeing a clear uptrend in the number of people who are paying for Huddle01 Pro and Business licenses. Moreover, a lot of people have started using Huddle01 from GSuite and use it straight from Google Calendar, which essentially shows repeated usage and retention.

IMO, to date, the best utilisation for crypto incentives for a utility application has been BRAVE Browser - Earn BAT for browsing on the Brave browser. That is how I stumbled upon Brave browser - it caught my attention because of the incentives, but I stayed because of the product.

To capture further network effects, we built yet another product, Farhouse which essentially is an audio space for the Farcaster social network.

We even saw a good uptick in people using Huddle01's audio/video API. Though this isn't a core focus for us right now because of low retention amongst developers, the shelf life of products is small, and the sales cycle is very long for SMBs/enterprise clients. Lack of shelf life of newer products and long sales cycles make this a comparatively lesser focus area.

Over the last 4 years, building the DePIN network, there have been some key realisations:

• Build beautiful and scalable products yourself on your network to bootstrap initial demand.

• While trying to get network effects on your application, there will be long periods of lag phase before you start seeing exponential growth. Once you see that, make sure your product doesn't have a big leaky bucket.

• When thinking about emissions of your tokens for growing your network, give more weight towards building the demand side of the network - without that supply side won't make much sense.

• Demarcation between technical teams, the network side of things and the consumer side of things is crucial for faster shipping.

• Be ready for the GRIND, be extremely FRUGAL - like mad FRUGAL.

• You'll not be as much talked about as a new L1, or someone who raised 100s of millions of $ - become comfortable in flying under the RADAR for a long time.

• Build a culture for marathoners who can do decently well in sprints when needed.

• You can attract external developers for a short time frame, but are they quality ones? If yes, will they build long-term on your network? If not, be truthful to yourself and stop spending $$ and energy there, and build it yourself.

• Think deeply about the GTM, sales cycles and ICP (Initial customer persona). If the sales cycles seem>6 months and you are a small startup with less runway, pivot and run as far away from that situation as possible. Try to get demand and traction as fast as possible.

• You need to have economic thinking, incentives are really powerful, use them well.

• Develop systems thinking, you are building a complex system which has a lot of sub-systems, and every sub-system is a world of its own.

• DePIN is a very broad sector; think deeply about positioning, branding and the story you want to tell the world.

• DePIN can be capital-intensive, be creative while fundraising - VCs, community sales, Node Sales - there are various avenues to raise capital from.

• DePIN can thrive with DeFi - using the DeFi primitives in your DePIN-based systems can make your supply-side assets more lucrative.

DePINs are one of the most important pieces of technology that will have an impact on humanity at scale. It is important to have a super long-range view on things.

Moreover, all of these above systems were built in relatively limited capital (<$5M) over the last 4 years with a 20-person team.

This is still Day 0 at Huddle01

The flywheel is now rotating fast. On the supply side, while the network is still in its infancy, it is already a very strong one with 100,000+ Mbps and 1000+ cores. On the demand side, we are seeing exponential growth with 20,000,000+ minutes of meetings, 50,000+ app downloads. Now the focus is on sustained growth.

Onwards.