Blockcast is not just another CDN. It's DePIN approach to capacity provides a foundation for an open marketplace where content owners can establish commercial relationships with multiple CDNs and federate traffic across providers.
Decentralized Physical Infrastructure Networks (DePIN) have already transformed sectors such as wireless connectivity and distributed storage, but content delivery has largely remained centralized. By combining open standards, Web3 technologies, community-operated infrastructure, and multicast networking, a new model is emerging that enables anyone from individuals to ISPs to participate in content delivery while improving capacity, geographic reach, and operational efficiency.
While Web3 has been most notably attached to NFTs and Cryptocurrency, there is a much more fundamental change that Web3 has brought to information technologies: community-operated infrastructure, commonly referred to as decentralized physical infrastructure networks (DePIN) .
DePIN has matured significantly over the last few years with networks like Helium Mobile providing cellular offload services to millions of AT&T and T-Mobile users, including all travelers through Baltimore/Washington Airport (BWI) through a crowd sourced network of WiFi and CBRS hotspots. Meanwhile, the Internet Archive trusts IPFS Filecoin to store over a petabyte of humanity’s knowledge using independent storage providers. In both protocols, a network of validators ensure the SLA of the network, signing proofs of coverage or storage.
But even as new DePIN projects launched, like DAWN Internet which is building crowd-sourced broadband, the concept had not made much of an impact in a core, often overlooked category of infrastructure — content delivery.
If you asked most people what a Content Delivery Network was, they probably couldn’t tell you (although Cloudflare has a really nice article describing CDNs). Not like they could tell you what the electricity grid is or about a cellular network. This, despite the fact that so much of the internet’s daily operation depends upon content delivery.
The core tenet behind DePIN is about breaking the control a few corporations might have over the critical technical infrastructure needed for people to live in our modern world like cellular service and broadband. Breaking that control, though, is not accomplished through destruction but, rather, through creating — by providing a means for anyone, whether that’s an individual, a small business, or even another large organization, to host a piece of that infrastructure which makes up the web of the larger whole.
The majority of content delivery (which accounts for about 70–75% of all internet traffic) is controlled by just a handful of companies making it ripe for a DePIN approach, but not just for individuals. When it comes to content delivery, ISPs, IXs, data center operators, and individuals, are outside the system. They are beholden to where CDNs choose to put their caches, who they choose to peer with, and how much capacity they put in any geographic area.
This makes CDN an ideal target for DePIN. By enabling a community to build a delivery network, this would take such a critical piece of infrastructure, content delivery, out of the hands of just a few companies. What was needed, though, was a technology approach that could enable CDNs to be connected together, that could enable a single cache to become part of a larger delivery network whole.
Internet service providers have long complained about the unfair practices of content delivery. Because most CDNs terminate on ISP networks in peering exchanges, ISPs are responsible for backhauling that traffic through their network without any compensation. This issue has even been brought up by government regulators. But it’s not just ISPs complaining about how content delivery is handled, it’s also the content providers. Because CDNs are operated by different companies, they all do things a little differently and that can create operational challenges. To add new CDNs, content providers often have to develop bespoke integrations.
Enter the Streaming Video Technology Alliance’s Open Caching specifications and the IETF CDN Interconnection (CDNi) specifications. Using these specifications, any CDN (whether commercial or DePIN) or cache could “announce” its capacity and become available as part of a larger multi-network network (this is called a “virtual overlay”). This concept of connecting CDNs together also helps to solve a core content provider problem — geting enough capacity in the right geographic areas. While CDNs may say they have coverage in a specific area, it can be a bit misleading as their physical infrastructure, depending on their peering relationship to the local ISP, could be hundreds of miles away. Not only that, but even if there is adequate capacity across multiple delivery networks in a given region, managing multiple networks (and their operators) can make delivering the live event a whole lot more complicated.
But just having a way to connect CDNs together isn’t enough. That process needs to be simple and easy. Blockcast sought to address this by combining the flexibility of the SVTA and IETF standards with the power of Web3. The result? The foundation for a marketplace that enables capacity suppliers to connect their networks through a permissionless system with the added benefit of rev-share incentives for doing so.
The marketplace, though, isn’t a free-for-all. Blockcast, in building the foundation using those industry standards, also recognized that content providers would want assurances from the CDNs they could select. That involved architecting assurances into the very system that connected provider with supplier.
The first assurance is about capacity. While CDNs do a great job of marketing their total throughput and capacity, there is no way for a content provider to really confirm that. So in the marketplace, a cache node operator on Blockcast, called RELAYS, such as ISPs or IXs, can specify a set of claims about how much bandwidth they can willingly provide the network broadly, or to particular internet targets (ASNs or CIDRs). The assurance is how the marketplace verifies that claim. With the goal of keeping it permissionless for suppliers to participate, especially in locations traditional CDNs struggle with, came the challenge of how to ensure a superior quality of service for customers who require an SLA. To address this, Blockcast developed a Trust-free Proof of Bandwidth (PoB) based on a research project at Princeton University. Through a network of BEACONs deployed on the personal devices of retail users, a smart contract orchestrates bandwidth tests to validate the claims periodically.
The second assurance is about delivery. That smart contract is basically an SLA, a promise by the supplier to deliver the provider’s content as they have specified. To assure the content provider, every delivered bit is recorded on-chain based on an IETF draft for CDNi logging, creating immutable privacy compliant delivery records for SLA settlement. In a sense, it’s almost like automated CDN log analysis. Rather than having to verify the delivery themselves, the marketplace tells the content provider what bits were delivered, when, and to which users.
The final assurance is about functionality. In some cases, suppliers may represent alternative capacity such as multicast. The PoB testing that’s done automatically can also verify the size of audiences reachable over multicast through such providers.
But why would people, whether individuals or infrastructure providers, want to participate in a decentralized, community-operated infrastructure? Why would they want to host a Blockcast RELAY or BEACON node?
Like all DePIN projects, participation generates rewards. In the case of CDN, those rewards are for contributed capacity and validated service delivery. But for those wanting to participate in the Blockcast DePIN initiative, there’s more benefit than just rewards. For IPSs, IXs, and data center operators, the benefit is having some deep-edge caches that are multicast enabled. For ordinary people, it’s having a cache in their homes to improve the streaming experience.
The value of a CDN is ultimately the customer traffic it carries. To acquire customers, new entrants and smaller CDNs face a cold start problem whereby they must spend large amounts of capital to deploy infrastructure and market their resources. Customers of CDNs can grow fatigued in evaluating the long tail of suppliers, and know if the offered services will augment their capacity portfolio, or if they share common routes and bottlenecks to their existing providers.
A capacity marketplace which is open for any supplier to connect solves this cold start problem while also making more efficient delivery methods like multicast (through Blockcast RELAY nodes) available to content providers.
Traditional unicast CDN services are a brute force way to address capacity needs. Although caches may get bigger and more numerous, there will always be more traffic than there is CDN capacity during large events, and over wireless networks. Even an open marketplace, aggregating capacity from a variety of different suppliers, can only meet so much of the need.
The answer is multicast. But, multicast isn’t anything new. In fact, the multi-service operators (MSOs) and ISPs have been flirting with multicast for the last two decades, but there’s always been a chicken-and-egg problem: operators don’t want to install the equipment to enable multicast delivery until there are enough endpoints with the software to play it and the device manufacturers don’t want to install the software to play multicast until the operators install the equipment. This stalemate kept multicast confined to closed networks.
Recent standards like TreeDN (RFC 9706) fundamentally change this dynamic. TreeDN enables different community parties — ISPs, CDNs, broadcasters, and even individual node operators — to participate in multicast content delivery by operating pieces of shared infrastructure. By allowing multiple independent parties to collaborate on multicast distribution, TreeDN solves the chicken-and-egg problem that has prevented widespread adoption.
Blockcast’s Multicast Adaptive HTTP Proxy (MAHP) builds on this foundation. MAHP bridges multicast delivery from source to edge, then converts to unicast for final delivery to standard devices. This architecture eliminates the need for specialized endpoint software from content providers while enabling multicast efficiency across network boundaries through tunneling. What makes MAHP even more valuable to operators is that it’s a software package which provides a full multicast server which can be installed on any COTS. By bridging a MAHP upstream (to start the multicast delivery) with a MAHP at the edge of the network or in the home gateway (to convert back to unicast), network operators can free up capacity for other services…or more content delivery. Blockcast then is the first, commercially available multicast enabled CDN. See, not just “another”.
When multiple parties can contribute multicast infrastructure components and be properly rewarded for their participation, the chicken-and-egg problem disappears.
Regardless of the type of capacity, a marketplace also provides another key value for capacity — geographic diversity. The problem with capacity isn’t just about resources (you can only spin up so many caches), it’s also about the geography of those resources.
CDNs peer with operator networks in internet exchanges (IXs) or peering fabrics. This allows a request from a user via their ISP to be returned without having to cross the open internet which means faster round trip time (RTT) and, usually, a better user experience. But for those people who live outside of major metro markets (where most ISPs are Tier 1 and, hence, have peering relationships), their ISP is often too small to interest a CDN in peering. That means that these rural ISPs must backhaul the request through capacity they purchase from larger ISPs to those CDN caches which can sometimes be tens or even hundreds of miles away.
But what if that didn’t have to be the case?
The capacity aggregated in the marketplace, from Blockcast, other CDNs, and ISPs, represents actual caches in specific geographies. Because each cache is connected to the marketplace by an API, the marketplace knows exactly which ASN that cache belongs to and where it is located. This provides content owners a way to specifically request capacity in a geography. And, given that some geographies aren’t served by fixed broadband, those content owners looking for geographic-specific content can even select from non-traditional capacity like ATSC 3.0, satellite, mobile, and, of course, in-home caches.
Remember when we talked about that open marketplace? Well, Blockcast, with the help of Vecima Networks and other founding members, turned that into an industry foundation called the Open Capacity Marketplace.
Rather than being owned by a single entity, the OCM is governed by a board of industry participants who help drive the direction of the marketplace and maintain it as a service (much like any other SaaS offering).
The OCM has a chance to truly change the way content delivery is handled today. While not disintermediating commercial CDNs, it also opens the door for non-traditional capacity providers (such as an individual in their home) to participate. It provides a nearly identical experience for content providers onboarding multicast or unicast capacity, and a way for the market to price services fairly. And because the OCM, like the open marketplace described earlier, is built on Web3 technologies and open standards, all of the permissionless and trustless features are there. Additionally, the marketplace eliminates bilateral sales overhead that prevents small capacity providers from reaching content providers. Smart contracts automate settlement and SLA enforcement, while cryptographic proofs ensure service delivery verification. This reduces overhead, offering better CDN pricing for smaller content providers while opening new revenue streams for diverse infrastructure operators. The OCM really is a platform for the decentralization of content delivery.
Interested in joining the OCM to help shape its direction? Want to see a demo of the OCM at IBC? Need more technical information? Just head on over to the OCM website at https://www.opencapcity.org. There you’ll find a form to express your interest in attending the demo on Saturday, September 13th at IBC in Amsterdam, a technical whitepaper, and an interest form.
If you want to learn more about Blockcast, the first commercial multicast CDN, head on over to https://www.blockcast.com.
Decentralized Physical Infrastructure Networks (DePIN) enable individuals, businesses, and organizations to contribute infrastructure to a shared network and be rewarded for doing so. While DePIN has already proven successful in areas such as cellular connectivity and decentralized storage, Blockcast believes content delivery is another critical infrastructure category that can benefit from a decentralized model. By allowing more participants to contribute delivery capacity, content delivery can become more geographically distributed, resilient, and efficient.
Blockcast leverages industry standards such as the Streaming Video Technology Alliance’s Open Caching specifications and the IETF’s CDN Interconnection (CDNi) standards. These technologies allow commercial CDNs, ISPs, internet exchanges, and decentralized cache operators to advertise capacity and participate in a larger virtual delivery network. This creates a more unified ecosystem where content providers can access capacity from multiple sources through a common framework.
Blockcast uses a Trust-free Proof of Bandwidth (PoB) system that validates bandwidth claims through independent testing. A network of BEACON nodes performs automated measurements and reports results to smart contracts, which verify whether a provider’s advertised capacity matches actual performance. This helps content providers gain confidence that service-level agreements (SLAs) can be met.
Multicast enables a single stream of content to be delivered to many users simultaneously, making it far more efficient than traditional unicast delivery for large-scale events. Blockcast’s Multicast Adaptive HTTP Proxy (MAHP) bridges multicast and standard HTTP delivery, allowing content providers to take advantage of multicast efficiency without requiring specialized software on end-user devices. This can significantly reduce network load while improving scalability.
The Open Capacity Marketplace (OCM) is an industry-led platform created by Blockcast, Vecima Networks, and other partners to connect content providers with traditional and non-traditional capacity suppliers. Through the OCM, commercial CDNs, ISPs, broadcasters, data centers, and even individuals can offer delivery capacity. Smart contracts, cryptographic proofs, and open standards automate capacity procurement, service verification, SLA enforcement, and settlement, creating a more open and efficient marketplace for content delivery.
.png)