From ab044fd2e7427bf0664d666ba552794849b76d83 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:24:34 +0100 Subject: [PATCH 1/7] feat(blog): publish post 08, who actually needs a network like this Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 87 +++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 content/blog/08-who-actually-needs-this.mdx diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx new file mode 100644 index 0000000..50c1152 --- /dev/null +++ b/content/blog/08-who-actually-needs-this.mdx @@ -0,0 +1,87 @@ +--- +title: "Who Actually Needs a Network Like This?" +slug: who-actually-needs-this +date: 2026-09-24 +summary: "Three things decdn does that a normal CDN cannot: verify every byte as it arrives, take any single vendor out of your pricing and uptime, and pull one download from many machines at once. Each one grounded in a real incident, and an honest list of who it is for." +bucket: publisher +tags: [publishers, security, supply-chain, cdn] +--- + +Most posts about decentralized infrastructure start with why the technology is clever. This one starts with the harder question: **does anyone actually need it?** + +The honest answer is: not always. If your files are public, low-stakes, and you do not care which machine hands them over, a normal CDN is the right tool and always will be. Use one, with our blessing. + +But that describes a lot less traffic than people assume. What follows is three things decdn does that a normal CDN cannot, and for each one, a real situation where a company needed exactly that. + +## 1. you never keep a corrupt byte + +A normal CDN works like this. You ask a web address for a file. A computer you do not own answers. You get bytes back. Your only real guarantee is that the connection was encrypted, which proves you talked to the right server. It does not prove the server sent you the right thing. + +A fingerprint proves it, but only if you check, and most tools check at the end, after the whole file has already landed. decdn checks as the download runs. Every file is named by a fingerprint of its own contents, and decdn verifies that fingerprint piece by piece, the instant each piece arrives. A piece that fails is thrown out on the spot and refetched from another machine, so corruption is caught the moment it appears, not after the whole file has landed. Nothing bad ever reaches your file. + +**When this actually mattered:** In May 2017, one of the mirror servers that handed out HandBrake, a popular Mac video tool, was broken into. For four days it served some downloaders a copy of the app with a remote-access trojan stitched in. The program was fine. The developers were fine. The copy on the main mirror was fine. One machine in the delivery path had been compromised and was quietly serving different bytes. The only way to catch it was to compare the download against the fingerprint the project published, and the poisoned copy did not match. + +That comparison is exactly the check decdn runs for you, on every byte, while the download is still arriving, against the fingerprint you asked for. A machine that serves you the wrong bytes is caught the instant it tries, so you never have to trust it. On a normal CDN you are trusting the edge to hand you what the origin meant to send. decdn takes that trust out of the loop. + +The same shape keeps recurring, and the bigger the network, the bigger the blast radius. In June 2024, polyfill.io, a script more than 100,000 sites loaded straight from a shared CDN, changed hands and began serving altered, malicious code to every site that trusted it. The web's defense against exactly this is Subresource Integrity: pin the fingerprint of the file you expect, and the browser throws out anything else. Package managers do the same, checking every download against a fingerprint from a signed index instead of trusting the mirror it came from. The industry already agrees you should not trust the server. decdn just makes the check automatic and unavoidable instead of something you have to remember to turn on. + +One honest limit: this proves you got the file the publisher named, not that the publisher named a good one. A backdoor the author ships themselves is a job for code signing and reproducible builds, not for delivery. What decdn guarantees is that nothing between them and you changed a byte. + +## 2. no single vendor can reprice you or cut you off + +This is the one people underrate, so it gets the most examples. + +Cheap pricing is a business decision, not a contract. Cloudflare can reprice a loss leader whenever it wants. The Bandwidth Alliance is a pact between rivals, and any of them can walk out; Cloudflare, a member, now points customers at its own product instead. Either way, you are buying total dependence on one company's pricing, terms, uptime, and mood. + +decdn has no such company in the middle. Files are served by independent operators competing on price, so no single vendor can reprice you, throttle you, or cut you off to make a point. Removal is not gone, but it is not one company's call either: a file comes down only through open, on-chain governance and only for unlawful content, the kind every operator is legally bound to drop anyway, with a public reason on every entry and a delay built into the standard path. That is a different thing from a support agent deciding on a Tuesday that your account is more trouble than it is worth. + +**When this actually mattered, three ways:** + +**The price changed.** In late 2020 Docker Hub started limiting how many times you could download images for free. Overnight, build pipelines at companies all over the world began failing, because everyone had quietly built on the assumption that pulls were unlimited and free. Nothing was broken. The terms just changed. After Broadcom acquired VMware, licensing was restructured toward subscriptions and many customers faced large, sudden cost increases with no realistic way to leave quickly. Free and cheap are only as durable as the vendor's current strategy. + +**The vendor switched someone off.** In January 2021, AWS removed Parler from its infrastructure and the service went dark within days. Cloudflare has cut off customers before, and said publicly it was uncomfortable doing so precisely because it showed one company could. You do not have to agree with any of those decisions to notice what they proved: the ability exists, it is used, and it is fast. + +**Everyone went down together.** Big outages at AWS and Cloudflare have repeatedly taken large parts of the internet offline at the same moment, because so many unrelated services sit behind the same few providers. If your delivery, your competitor's delivery, and your status page are all behind one vendor, they all fail on the same afternoon. + +## 3. one download pulls from many machines at once + +On a normal CDN your download is one connection to one location. However fast that one machine is, that is your ceiling. If it is having a bad day, so are you. + +decdn splits a file into pieces and pulls them from several machines at the same time. Fast machines naturally get handed more pieces. Slow ones get handed fewer. + +This is basically BitTorrent, and that is the point. Splitting a file across many sources and checking each piece against a hash is a model that has moved a huge share of the internet's bytes for twenty years. It works, and it is exactly right for big files. + +What decdn changes is who the sources are: paid operators competing to serve you, not a volunteer swarm that may not have a seeder online when you need one. You get the proven model with a paid network's reliability behind it. + +**When this actually mattered:** This is the one where the incumbents have already proved the need, by building it themselves. Microsoft ships peer-to-peer distribution inside Windows Update, so machines on the same network pull updates from each other instead of all hammering Microsoft. Game companies have used peer-assisted downloads for large patches for years, because launch day for a big title moves more data than a normal CDN plan is sized for. Hugging Face built a dedicated high-speed download tool because ordinary single-connection downloads were too slow for people fetching multi-gigabyte AI models, and many of those users reach for multi-connection download tools anyway. + +Every one of those is the same admission: for big files, one connection to one server is not enough, and the fix is to pull from more than one place at once. + +## so who needs it? + +Three capabilities, and the buyer who feels each one hardest: + +**Pulling from many machines at once.** Microsoft, game publishers, and Hugging Face all built their own version of this because one connection was not enough. The need is proven. We turn it into something you can buy instead of build. + +**Not depending on one vendor.** The incidents are real, recent, and repeated. We win exactly where a second CDN cannot help you: price shocks, terms changes, and being switched off, because a second vendor holds the same powers as the first. + +**You never keep a corrupt byte.** The threat is real and the industry is spending heavily on it. We make the check unavoidable rather than optional, run it during the download rather than after, and keep it trustworthy even when you do not trust the machine that served you. + +## who this is for + +In order of fit: + +1. **Anyone shipping AI models or large datasets.** Big, fixed, valuable, spiky on release day, and expensive enough that fixed monthly allowances are always the wrong size. +2. **Anyone whose software downloads are a supply-chain risk.** Installers, container images, packages, firmware. This is where automatic verification is worth more than any price. +3. **Game patches and large updates.** Exactly the workload multi-machine downloading was designed for. +4. **Anyone paying enormous cloud bills to publish data.** Big egress and CDN invoices for pushing large files out to the world, where paying per delivered byte on an open market is simply cheaper. The one case where cost alone makes the argument. + +If you are serving small images on a normal website, use a normal CDN. It is better at that and always will be. What decdn is for is big, valuable files where being certain of the bytes matters, and where you do not want one company deciding next quarter what delivery costs. + +## want to see it on your own files? + +If your workload is anywhere on that list, we want to hear from you. The network runs on a public testnet today, and we are taking pilots now. Email us at [info@decdn.org](mailto:info@decdn.org), and we will help you put a real catalog on it and measure what you get. + +--- + +_Incident and pricing references are public reporting: the HandBrake mirror-server compromise (May 2017), the polyfill.io CDN supply-chain attack (June 2024), Docker Hub's pull-rate limits (November 2020), Broadcom's post-acquisition VMware licensing changes, AWS's removal of Parler (January 2021), and published AWS and Cloudflare pricing pages._ From 33c8ea91802f55c1445f630adfd44eff757ffd24 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:28:51 +0100 Subject: [PATCH 2/7] feat(blog): tighten post 08 close, source its incidents Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx index 50c1152..5435579 100644 --- a/content/blog/08-who-actually-needs-this.mdx +++ b/content/blog/08-who-actually-needs-this.mdx @@ -31,7 +31,7 @@ One honest limit: this proves you got the file the publisher named, not that the This is the one people underrate, so it gets the most examples. -Cheap pricing is a business decision, not a contract. Cloudflare can reprice a loss leader whenever it wants. The Bandwidth Alliance is a pact between rivals, and any of them can walk out; Cloudflare, a member, now points customers at its own product instead. Either way, you are buying total dependence on one company's pricing, terms, uptime, and mood. +Cheap pricing is a business decision, not a contract. Cloudflare can reprice a loss leader whenever it wants. The Bandwidth Alliance, the pact that waives egress fees between member clouds, is a voluntary agreement between rivals, and any member can walk out. Either way, you are buying total dependence on one company's pricing, terms, uptime, and mood. decdn has no such company in the middle. Files are served by independent operators competing on price, so no single vendor can reprice you, throttle you, or cut you off to make a point. Removal is not gone, but it is not one company's call either: a file comes down only through open, on-chain governance and only for unlawful content, the kind every operator is legally bound to drop anyway, with a public reason on every entry and a delay built into the standard path. That is a different thing from a support agent deciding on a Tuesday that your account is more trouble than it is worth. @@ -43,6 +43,8 @@ decdn has no such company in the middle. Files are served by independent operato **Everyone went down together.** Big outages at AWS and Cloudflare have repeatedly taken large parts of the internet offline at the same moment, because so many unrelated services sit behind the same few providers. If your delivery, your competitor's delivery, and your status page are all behind one vendor, they all fail on the same afternoon. +A second CDN helps with that last one. It does nothing for the first two, because a second vendor holds the same powers as the first. + ## 3. one download pulls from many machines at once On a normal CDN your download is one connection to one location. However fast that one machine is, that is your ceiling. If it is having a bad day, so are you. @@ -55,17 +57,7 @@ What decdn changes is who the sources are: paid operators competing to serve you **When this actually mattered:** This is the one where the incumbents have already proved the need, by building it themselves. Microsoft ships peer-to-peer distribution inside Windows Update, so machines on the same network pull updates from each other instead of all hammering Microsoft. Game companies have used peer-assisted downloads for large patches for years, because launch day for a big title moves more data than a normal CDN plan is sized for. Hugging Face built a dedicated high-speed download tool because ordinary single-connection downloads were too slow for people fetching multi-gigabyte AI models, and many of those users reach for multi-connection download tools anyway. -Every one of those is the same admission: for big files, one connection to one server is not enough, and the fix is to pull from more than one place at once. - -## so who needs it? - -Three capabilities, and the buyer who feels each one hardest: - -**Pulling from many machines at once.** Microsoft, game publishers, and Hugging Face all built their own version of this because one connection was not enough. The need is proven. We turn it into something you can buy instead of build. - -**Not depending on one vendor.** The incidents are real, recent, and repeated. We win exactly where a second CDN cannot help you: price shocks, terms changes, and being switched off, because a second vendor holds the same powers as the first. - -**You never keep a corrupt byte.** The threat is real and the industry is spending heavily on it. We make the check unavoidable rather than optional, run it during the download rather than after, and keep it trustworthy even when you do not trust the machine that served you. +Every one of those is the same admission: for big files, one connection to one server is not enough, and the fix is to pull from more than one place at once. The need is proven. decdn turns it into something you can buy instead of build. ## who this is for @@ -84,4 +76,4 @@ If your workload is anywhere on that list, we want to hear from you. The network --- -_Incident and pricing references are public reporting: the HandBrake mirror-server compromise (May 2017), the polyfill.io CDN supply-chain attack (June 2024), Docker Hub's pull-rate limits (November 2020), Broadcom's post-acquisition VMware licensing changes, AWS's removal of Parler (January 2021), and published AWS and Cloudflare pricing pages._ +_Incident references are public reporting: [ESET WeLiveSecurity](https://www.welivesecurity.com/2017/05/08/malware-warning-mac-users-handbrake-mirror-download-server-hacked/) on the HandBrake mirror-server compromise (May 2017), [Sansec](https://sansec.io/research/polyfill-supply-chain-attack) on the polyfill.io CDN supply-chain attack (June 2024), [The Register](https://www.theregister.com/2020/10/28/docker_pull_rate_limit_1_november/) on Docker Hub's pull-rate limits (November 2020), [The Register](https://www.theregister.com/software/2024/10/01/att-claims-vmware-offered-it-a-1050-percent-price-rise/511969) on Broadcom's post-acquisition VMware pricing, and [TechCrunch](https://techcrunch.com/2021/01/09/amazon-web-services-gives-parler-24-hour-notice-that-it-will-suspend-services-to-the-company/) on AWS's removal of Parler (January 2021)._ From e345eb11f20f3249c543134297f0e712ffd7a0e1 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:34:54 +0100 Subject: [PATCH 3/7] feat(blog): post 08 drops Parler, adds adoption section and pilot CTA Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx index 5435579..763efb1 100644 --- a/content/blog/08-who-actually-needs-this.mdx +++ b/content/blog/08-who-actually-needs-this.mdx @@ -29,21 +29,17 @@ One honest limit: this proves you got the file the publisher named, not that the ## 2. no single vendor can reprice you or cut you off -This is the one people underrate, so it gets the most examples. - Cheap pricing is a business decision, not a contract. Cloudflare can reprice a loss leader whenever it wants. The Bandwidth Alliance, the pact that waives egress fees between member clouds, is a voluntary agreement between rivals, and any member can walk out. Either way, you are buying total dependence on one company's pricing, terms, uptime, and mood. decdn has no such company in the middle. Files are served by independent operators competing on price, so no single vendor can reprice you, throttle you, or cut you off to make a point. Removal is not gone, but it is not one company's call either: a file comes down only through open, on-chain governance and only for unlawful content, the kind every operator is legally bound to drop anyway, with a public reason on every entry and a delay built into the standard path. That is a different thing from a support agent deciding on a Tuesday that your account is more trouble than it is worth. -**When this actually mattered, three ways:** +**When this actually mattered, two ways:** **The price changed.** In late 2020 Docker Hub started limiting how many times you could download images for free. Overnight, build pipelines at companies all over the world began failing, because everyone had quietly built on the assumption that pulls were unlimited and free. Nothing was broken. The terms just changed. After Broadcom acquired VMware, licensing was restructured toward subscriptions and many customers faced large, sudden cost increases with no realistic way to leave quickly. Free and cheap are only as durable as the vendor's current strategy. -**The vendor switched someone off.** In January 2021, AWS removed Parler from its infrastructure and the service went dark within days. Cloudflare has cut off customers before, and said publicly it was uncomfortable doing so precisely because it showed one company could. You do not have to agree with any of those decisions to notice what they proved: the ability exists, it is used, and it is fast. - **Everyone went down together.** Big outages at AWS and Cloudflare have repeatedly taken large parts of the internet offline at the same moment, because so many unrelated services sit behind the same few providers. If your delivery, your competitor's delivery, and your status page are all behind one vendor, they all fail on the same afternoon. -A second CDN helps with that last one. It does nothing for the first two, because a second vendor holds the same powers as the first. +A second CDN helps with the outage. It does nothing for the price change, because a second vendor can reprice you just as easily as the first. ## 3. one download pulls from many machines at once @@ -70,10 +66,18 @@ In order of fit: If you are serving small images on a normal website, use a normal CDN. It is better at that and always will be. What decdn is for is big, valuable files where being certain of the bytes matters, and where you do not want one company deciding next quarter what delivery costs. +## what adopting it looks like + +Your files stay where they are. An origin node reads them straight from the storage you already use, whether that is S3, R2, B2, or a local disk, and that storage is never exposed to the network. Each file is fingerprinted once when you publish it, and that fingerprint becomes the address people download it by. + +On the download side, your app fetches through the decdn client SDK, a Rust library that finds nodes, pays them per megabyte in USDC, and runs the byte-by-byte check from section 1. By default the downloader pays for what it receives. A publisher can choose to cover that for its own users instead. + ## want to see it on your own files? -If your workload is anywhere on that list, we want to hear from you. The network runs on a public testnet today, and we are taking pilots now. Email us at [info@decdn.org](mailto:info@decdn.org), and we will help you put a real catalog on it and measure what you get. +If your workload is anywhere on that list, a pilot is the fastest way to find out. The network runs on a public testnet today. In a pilot we set up an origin node in front of your storage with you, publish a real catalog from it using our tooling, and wire the client SDK into whatever does your downloading, so you measure the result on your own files rather than on our benchmarks. Email us at [info@decdn.org](mailto:info@decdn.org) to start one. + +Not ready to talk yet? [The docs](https://docs.decdn.org/overview/introduction) explain how the network works, from content addressing to payments. --- -_Incident references are public reporting: [ESET WeLiveSecurity](https://www.welivesecurity.com/2017/05/08/malware-warning-mac-users-handbrake-mirror-download-server-hacked/) on the HandBrake mirror-server compromise (May 2017), [Sansec](https://sansec.io/research/polyfill-supply-chain-attack) on the polyfill.io CDN supply-chain attack (June 2024), [The Register](https://www.theregister.com/2020/10/28/docker_pull_rate_limit_1_november/) on Docker Hub's pull-rate limits (November 2020), [The Register](https://www.theregister.com/software/2024/10/01/att-claims-vmware-offered-it-a-1050-percent-price-rise/511969) on Broadcom's post-acquisition VMware pricing, and [TechCrunch](https://techcrunch.com/2021/01/09/amazon-web-services-gives-parler-24-hour-notice-that-it-will-suspend-services-to-the-company/) on AWS's removal of Parler (January 2021)._ +_Incident references are public reporting: [ESET WeLiveSecurity](https://www.welivesecurity.com/2017/05/08/malware-warning-mac-users-handbrake-mirror-download-server-hacked/) on the HandBrake mirror-server compromise (May 2017), [Sansec](https://sansec.io/research/polyfill-supply-chain-attack) on the polyfill.io CDN supply-chain attack (June 2024), [The Register](https://www.theregister.com/2020/10/28/docker_pull_rate_limit_1_november/) on Docker Hub's pull-rate limits (November 2020), and [The Register](https://www.theregister.com/software/2024/10/01/att-claims-vmware-offered-it-a-1050-percent-price-rise/511969) on Broadcom's post-acquisition VMware pricing._ From a3fc093e93f8ce9230817a2b47c6c6b6bca10246 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:37:03 +0100 Subject: [PATCH 4/7] feat(blog): post 08 frames delivery as publisher-paid Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx index 763efb1..3d13f7c 100644 --- a/content/blog/08-who-actually-needs-this.mdx +++ b/content/blog/08-who-actually-needs-this.mdx @@ -70,7 +70,7 @@ If you are serving small images on a normal website, use a normal CDN. It is bet Your files stay where they are. An origin node reads them straight from the storage you already use, whether that is S3, R2, B2, or a local disk, and that storage is never exposed to the network. Each file is fingerprinted once when you publish it, and that fingerprint becomes the address people download it by. -On the download side, your app fetches through the decdn client SDK, a Rust library that finds nodes, pays them per megabyte in USDC, and runs the byte-by-byte check from section 1. By default the downloader pays for what it receives. A publisher can choose to cover that for its own users instead. +On the download side, your app fetches through the decdn client SDK, a Rust library that finds nodes and runs the byte-by-byte check from section 1. You pay for delivery: you fund one pool in USDC, nodes are paid from it per megabyte they serve, and your users' downloads draw from it. Your users never see a wallet or a bill. To them, it is just a download. ## want to see it on your own files? From 7145708e796576d8d1bde4df188bfe2e08101119 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:37:38 +0100 Subject: [PATCH 5/7] feat(blog): post 08 pilot delivery is funded by decdn Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx index 3d13f7c..9c38b68 100644 --- a/content/blog/08-who-actually-needs-this.mdx +++ b/content/blog/08-who-actually-needs-this.mdx @@ -74,7 +74,7 @@ On the download side, your app fetches through the decdn client SDK, a Rust libr ## want to see it on your own files? -If your workload is anywhere on that list, a pilot is the fastest way to find out. The network runs on a public testnet today. In a pilot we set up an origin node in front of your storage with you, publish a real catalog from it using our tooling, and wire the client SDK into whatever does your downloading, so you measure the result on your own files rather than on our benchmarks. Email us at [info@decdn.org](mailto:info@decdn.org) to start one. +If your workload is anywhere on that list, a pilot is the fastest way to find out. The network runs on a public testnet today. In a pilot we set up an origin node in front of your storage with you, publish a real catalog from it using our tooling, and wire the client SDK into whatever does your downloading, so you measure the result on your own files rather than on our benchmarks. Delivery during the pilot is on us: your users' downloads draw from a pool we fund, so there is nothing for you to pay for or set up on that side. Email us at [info@decdn.org](mailto:info@decdn.org) to start one. Not ready to talk yet? [The docs](https://docs.decdn.org/overview/introduction) explain how the network works, from content addressing to payments. From 0d90715c68277d3e122a96c9cbff4400957b97d0 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:38:56 +0100 Subject: [PATCH 6/7] fix(blog): sentence-case post 08 headings to match other posts Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx index 9c38b68..75e663f 100644 --- a/content/blog/08-who-actually-needs-this.mdx +++ b/content/blog/08-who-actually-needs-this.mdx @@ -13,7 +13,7 @@ The honest answer is: not always. If your files are public, low-stakes, and you But that describes a lot less traffic than people assume. What follows is three things decdn does that a normal CDN cannot, and for each one, a real situation where a company needed exactly that. -## 1. you never keep a corrupt byte +## 1. You never keep a corrupt byte A normal CDN works like this. You ask a web address for a file. A computer you do not own answers. You get bytes back. Your only real guarantee is that the connection was encrypted, which proves you talked to the right server. It does not prove the server sent you the right thing. @@ -27,7 +27,7 @@ The same shape keeps recurring, and the bigger the network, the bigger the blast One honest limit: this proves you got the file the publisher named, not that the publisher named a good one. A backdoor the author ships themselves is a job for code signing and reproducible builds, not for delivery. What decdn guarantees is that nothing between them and you changed a byte. -## 2. no single vendor can reprice you or cut you off +## 2. No single vendor can reprice you or cut you off Cheap pricing is a business decision, not a contract. Cloudflare can reprice a loss leader whenever it wants. The Bandwidth Alliance, the pact that waives egress fees between member clouds, is a voluntary agreement between rivals, and any member can walk out. Either way, you are buying total dependence on one company's pricing, terms, uptime, and mood. @@ -41,7 +41,7 @@ decdn has no such company in the middle. Files are served by independent operato A second CDN helps with the outage. It does nothing for the price change, because a second vendor can reprice you just as easily as the first. -## 3. one download pulls from many machines at once +## 3. One download pulls from many machines at once On a normal CDN your download is one connection to one location. However fast that one machine is, that is your ceiling. If it is having a bad day, so are you. @@ -55,7 +55,7 @@ What decdn changes is who the sources are: paid operators competing to serve you Every one of those is the same admission: for big files, one connection to one server is not enough, and the fix is to pull from more than one place at once. The need is proven. decdn turns it into something you can buy instead of build. -## who this is for +## Who this is for In order of fit: @@ -66,13 +66,13 @@ In order of fit: If you are serving small images on a normal website, use a normal CDN. It is better at that and always will be. What decdn is for is big, valuable files where being certain of the bytes matters, and where you do not want one company deciding next quarter what delivery costs. -## what adopting it looks like +## What adopting it looks like Your files stay where they are. An origin node reads them straight from the storage you already use, whether that is S3, R2, B2, or a local disk, and that storage is never exposed to the network. Each file is fingerprinted once when you publish it, and that fingerprint becomes the address people download it by. On the download side, your app fetches through the decdn client SDK, a Rust library that finds nodes and runs the byte-by-byte check from section 1. You pay for delivery: you fund one pool in USDC, nodes are paid from it per megabyte they serve, and your users' downloads draw from it. Your users never see a wallet or a bill. To them, it is just a download. -## want to see it on your own files? +## Want to see it on your own files? If your workload is anywhere on that list, a pilot is the fastest way to find out. The network runs on a public testnet today. In a pilot we set up an origin node in front of your storage with you, publish a real catalog from it using our tooling, and wire the client SDK into whatever does your downloading, so you measure the result on your own files rather than on our benchmarks. Delivery during the pilot is on us: your users' downloads draw from a pool we fund, so there is nothing for you to pay for or set up on that side. Email us at [info@decdn.org](mailto:info@decdn.org) to start one. From 1f96b422e08758ba643a854ade2840fc2ceecc36 Mon Sep 17 00:00:00 2001 From: Alper Gundogdu Date: Thu, 24 Sep 2026 13:41:11 +0100 Subject: [PATCH 7/7] fix(blog): post 08 drops the file-size claim from its closing line Co-Authored-By: Claude Opus 5.5 --- content/blog/08-who-actually-needs-this.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/08-who-actually-needs-this.mdx b/content/blog/08-who-actually-needs-this.mdx index 75e663f..3706a5f 100644 --- a/content/blog/08-who-actually-needs-this.mdx +++ b/content/blog/08-who-actually-needs-this.mdx @@ -64,7 +64,7 @@ In order of fit: 3. **Game patches and large updates.** Exactly the workload multi-machine downloading was designed for. 4. **Anyone paying enormous cloud bills to publish data.** Big egress and CDN invoices for pushing large files out to the world, where paying per delivered byte on an open market is simply cheaper. The one case where cost alone makes the argument. -If you are serving small images on a normal website, use a normal CDN. It is better at that and always will be. What decdn is for is big, valuable files where being certain of the bytes matters, and where you do not want one company deciding next quarter what delivery costs. +What decdn is for is valuable files where being certain of the bytes matters, and where you do not want one company deciding next quarter what delivery costs. ## What adopting it looks like