Do We Think About Distribution?

So I’ve been asked by a number of interested parties what our distribution strategy is. My answer is a short one: We don’t have one!

The reason for this is that not only are we a decentralised protocol, we’re a low level decentralised protocol. The goal is for Olas to become a base layer for trusted information upon which all manner of publications and other apps from media to social to financial will be built on top. The writers and curators constructing publications from a giant trusted database will be the ones that have to worry about distribution much like writers on Substack do now.

Josh Stark of the Ethereum Foundation is always tweeting “Ethereum doesn’t have a business development team. It has 1000s of business development teams”. I feel the same about Olas. There’ll be many layers above executing various different go-to-market strategies and Olas will benefit from all their endeavours.

The Olas Foundation can of course assist some of these teams getting off the ground with grants, etc when the time comes. This of course is how most decentralised protocols operate now.

4 Likes

While I agree that Olas shouldn’t have a long-term distribution strategy as a decentralized protocol, I think there’s a good case to be made for providing some carefully structured bootstrapping support in the first year or two.

The main issue is we’re facing the classic chicken and egg problem that hits every new platform: writers won’t invest time without readers, and readers won’t show up without quality content. Some early ecosystem support could help break this cycle while still keeping Olas neutral and decentralized.

We’ve seen this work really well with other protocols in the space. Look at Uniswap - they had Uniswap Labs and later the Uniswap Foundation helping bootstrap the ecosystem. ENS did something similar with ENS Labs supporting early integrations. Lens Protocol had AAVE’s ecosystem backing them initially, and The Graph had Edge & Node helping get things off the ground. Chainlink also started by supporting their early node operators. In each case, these protocols remained sufficiently decentralized and neutral while still managing to get strategic early support through separate entities.

For Olas, we could create a separate ecosystem growth entity with a clear sunset clause (say 18-24 months) to help with things like writer onboarding, distribution tools, and integration partnerships. The key is having transparent criteria, equal access to support, and absolutely no editorial control.

The end goal doesn’t change - we want a truly decentralized protocol where writers, curators, and creators handle their own distribution. A bootstrap period would just help us reach critical mass faster and more efficiently, while ensuring we don’t have a false start after launching.

Would love to hear what you all think about this approach. Am I missing any potential issues?

2 Likes

Oh yes I agree and this is precisely what we plan to do - as you know.

Early writing and curation will be directly funded by in-protocol token emissions and the OF will have no say over how it is allocated. Separately the OF can issue grants to teams building on top of Olas as well. It’d have to have clear and as neutral proceses as possible for this.

The token incentives will sunset after a period of maybe 3 years. Grants from the OF could continue indefinitely depending on its funding situation.

1 Like

Interesting to see your train of thought behind building but, as someone considering participating there is a part I’m not very clear on, you mentioned that writers and curators would handle their own distribution. For new users, though, especially those unfamiliar with decentralized protocols, I see some friction in the onboarding process. From what it looks like you guys are not aiming at only crypto savvy users but any user that consumes media. What’s your strategy there?

Hi Nator

So re onboarding and UX it’s a separate question to distribution but we’re going to make sure that the onboarding of journalists will be as close to a web 2 experience as possible. We’re confident it’ll be very close.