{"id":17447,"date":"2026-02-20T00:01:38","date_gmt":"2026-02-20T00:01:38","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/02\/20\/protocol-update-002-scale-blobs\/"},"modified":"2026-02-20T00:01:38","modified_gmt":"2026-02-20T00:01:38","slug":"protocol-update-002-scale-blobs","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/02\/20\/protocol-update-002-scale-blobs\/","title":{"rendered":"Protocol Update 002 &#8211; Scale Blobs"},"content":{"rendered":"<p> <br \/>\n<br \/><img decoding=\"async\" src=\"https:\/\/storage.googleapis.com\/ethereum-hackmd\/upload_270c7c873d5994bd4e47958030e3599c.png\" \/><\/p>\n<div id=\"\">\n<p class=\"chakra-text css-gi02ar\">Following up from <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2025\/08\/05\/protocol-update-001\">Protocol Update 001<\/a>, we\u2019d like to introduce our approach to blob scaling. The L1 serves as a robust foundation for L2 systems to scale Ethereum, and a necessary component of secure L2 solutions is data availability provided by the L1. Data availability ensures that updates L2s make back to the L1 can be verified by anyone. Blobs are the unit of data availability in the protocol today, so scaling the blob count per block is a key requirement to usher in a wave of L2 adoption for use cases like real-time payments, DeFi, social media, gaming, and AI\/agentic applications.<\/p>\n<p class=\"chakra-text css-gi02ar\">Our work is structured as a series of incremental changes to Ethereum\u2019s blob architecture. To accelerate our rate of scaling, we are expanding from a \u201cfork-centric\u201d philosophy to also ship incremental optimizations in non-breaking ways as they become ready. Thus, we have the following projects tied to both network upgrades, but also the periods in between (\u201cinterfork\u201d).<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"tldr\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"tldr permalink\" href=\"#tldr\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>TL;DR<\/h2>\n<ul role=\"list\" class=\"css-1ars4k6\">\n<li class=\"css-0\">Fusaka introduces <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7594\">PeerDAS<\/a>, a new data architecture that allows blob scaling beyond today\u2019s throughput levels from 6 blobs\/block up to 48 blobs\/block<\/li>\n<li class=\"css-0\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/eips.ethereum.org\/EIPS\/eip-7892\">Blob Parameter Only (BPO) forks<\/a> gradually increase mainnet blob count, bolstered by incremental peer-to-peer bandwidth optimizations<\/li>\n<li class=\"css-0\">Advanced networking techniques planned for Glamsterdam iterate on the PeerDAS design to scale even further<\/li>\n<li class=\"css-0\">Mempool sharding preserves <a class=\"chakra-link css-vezwxf\" href=\"https:\/\/blog.ethereum.org\/2025\/04\/28\/ef-vision#stewardship-of-values\">Ethereum\u2019s values<\/a> as data continues to scale<\/li>\n<li class=\"css-0\">Research into the next generation of DAS unlocks an evolution in secure DA scaling<\/li>\n<\/ul>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"peerdas-in-fusaka\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"peerdas in fusaka permalink\" href=\"#peerdas-in-fusaka\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>PeerDAS in Fusaka<\/h2>\n<p class=\"chakra-text css-gi02ar\">The first milestone is the delivery of PeerDAS in the upcoming Fusaka network upgrade. PeerDAS introduces data availability sampling (DAS), where an individual node only downloads a subset of the blob data in a given block. Together with randomized sampling per node, computational load is bounded, even as the total blob count increases. As nodes no longer need to download all the blobs in a block, we can raise the blob count without a commensurate increase in node requirements.<\/p>\n<p class=\"chakra-text css-gi02ar\">Fusaka is expected later this year with implementations in all Ethereum clients. Extensive testing has been performed on development networks (\u201cdevnets\u201d) including non-finality scenarios and adversarial \u201cdata withholding\u201d conditions. At this point in the R&amp;D process, we continue to harden existing devnets and plan deployment to testnets and mainnet. <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/barnabasbusa\">Barnabas Busa<\/a> is leading the charge here to ensure smooth progression through the final stages of the upgrade pipeline.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"peerdas-v1x\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"peerdas v1x permalink\" href=\"#peerdas-v1x\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>PeerDAS v1.x<\/h2>\n<p class=\"chakra-text css-gi02ar\">We have two prongs of non-consensus changes in our strategy to progressively scale blobs in between the Fusaka and Glamsterdam upgrades: BPOs and bandwidth optimizations. These are additive as better bandwidth utilization lets us leverage resources towards higher throughput.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"bpo\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"bpo permalink\" href=\"#bpo\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>BPO<\/h3>\n<p class=\"chakra-text css-gi02ar\">PeerDAS introduced in Fusaka sets the stage for a theoretical increase of 8x from the throughput of Ethereum today (i.e. ~64 KB\/s to ~512 KB\/s). Rather than immediately jump to this theoretical max at the time of Fusaka deployment, core developers have elected for a more gradual increase via <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethereum-magicians.org\/t\/blob-parameter-only-bpo-forks\/22623\">\u201cblob parameter only\u201d hard forks<\/a>. This mechanism lets core developers program automatic increases in blob capacity over time, keeping us on a continuous growth trajectory. BPOs don\u2019t require any manual intervention to activate once programmed, and multiple prescheduled BPO steps can and will be included in the same client release. In between steps, we\u2019ll monitor the network and react to scaling bottlenecks that may only present themselves on mainnet, paving the way for the next increase. Barnabas Busa along with others on the EF PandaOps team work closely with the client teams to distill the correct schedule to achieve the 8x scaling from today.<\/p>\n<h3 class=\"chakra-heading group css-xuzltg\" id=\"bandwidth-optimizations\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"bandwidth optimizations permalink\" href=\"#bandwidth-optimizations\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Bandwidth optimizations<\/h3>\n<p class=\"chakra-text css-gi02ar\">There\u2019s a lot we can do to more efficiently use bandwidth on the network. <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/raulk\">Ra\u00fal Kripalani<\/a> along with <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/marcopolo\">Marco Munizaga<\/a> are leading efforts on this network engineering work. A particularly promising optimization is the introduction of \u201ccell-level messaging\u201d which allows nodes to more intelligently query for parts of the samples introduced in PeerDAS. This change reduces redundant communication on the network, and the bandwidth savings can, in turn, be dedicated to the safe provisioning of even more blob capacity. No consensus or execution protocol changes are needed to unlock this milestone, so they can be shipped interfork before Glamsterdam next year.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"peerdas-v2\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"peerdas v2 permalink\" href=\"#peerdas-v2\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>PeerDAS v2<\/h2>\n<p class=\"chakra-text css-gi02ar\">This project refers to the next generation of the PeerDAS design that affords even more scale while capitalizing on the bandwidth savings realized from pipelining introduced by EIP-7732 (scheduled for inclusion in Glamsterdam). There are further refinements to cell-level messaging and data reconstruction techniques that let nodes more flexibly sample individual parts of blobs so that the core idea of DAS can be expressed in full. These gains, along with the pipelining benefits that allow for more efficient utilization of the time between blocks, set us up to scale beyond the limits of imminent PeerDAS designs. There are many moving pieces, and exact numbers need to be calibrated to both performance of implementations and mainnet analysis as the blob count is actually scaled in a production setting, but this work should give us the final multiples on DA throughput before needing to seek alternative designs.<\/p>\n<p class=\"chakra-text css-gi02ar\">This batch of updates will go into the Glamsterdam upgrade expected in the middle of 2026. <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/x.com\/ralexstokes\">Alex Stokes<\/a> and Ra\u00fal Kripalani are coordinating the R&amp;D here to ensure we can keep scaling blob throughput.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"blobpool-scaling\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"blobpool scaling permalink\" href=\"#blobpool-scaling\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Blobpool scaling<\/h2>\n<p class=\"chakra-text css-gi02ar\">While the benefits of scaling are clear, we must do so while preserving Ethereum\u2019s core values. One of these directly relevant to blob scaling is censorship resistance. The mempool serves as a decentralized network for blob inclusion and directly provides censorship resistance in the face of a centralized builder network producing most blocks on Ethereum. While instances of censorship have improved over time, it is tantamount to the scaling strategy to also ensure the blob mempool scales with it.<\/p>\n<p class=\"chakra-text css-gi02ar\"><a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/github.com\/cskiraly\">Csaba Kiraly<\/a> is leading work here so we can maintain this critical resource. Current implementations support near-term blob throughput with <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethresear.ch\/t\/is-data-available-in-the-el-mempool\/22329\/2\">vigorous<\/a> <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethresear.ch\/t\/a-new-design-for-das-and-sharded-blob-mempools\/22537\">research<\/a> into the best ways to scale the mempool as we get to higher levels unlocked with Fusaka and beyond.<\/p>\n<h2 class=\"chakra-heading group css-1kpzc4q\" id=\"future-of-da\" data-group=\"true\"><a class=\"chakra-link css-128fqrf\" aria-label=\"future of da permalink\" href=\"#future-of-da\"><svg viewbox=\"0 0 24 24\" focusable=\"false\" class=\"chakra-icon css-173jpr1\"><g fill=\"currentColor\"><path d=\"M10.458,18.374,7.721,21.11a2.853,2.853,0,0,1-3.942,0l-.892-.891a2.787,2.787,0,0,1,0-3.941l5.8-5.8a2.789,2.789,0,0,1,3.942,0l.893.892A1,1,0,0,0,14.94,9.952l-.893-.892a4.791,4.791,0,0,0-6.771,0l-5.8,5.8a4.787,4.787,0,0,0,0,6.77l.892.891a4.785,4.785,0,0,0,6.771,0l2.736-2.735a1,1,0,1,0-1.414-1.415Z\"\/><path d=\"M22.526,2.363l-.892-.892a4.8,4.8,0,0,0-6.77,0l-2.905,2.9a1,1,0,0,0,1.414,1.414l2.9-2.9a2.79,2.79,0,0,1,3.941,0l.893.893a2.786,2.786,0,0,1,0,3.942l-5.8,5.8a2.769,2.769,0,0,1-1.971.817h0a2.766,2.766,0,0,1-1.969-.816,1,1,0,1,0-1.415,1.412,4.751,4.751,0,0,0,3.384,1.4h0a4.752,4.752,0,0,0,3.385-1.4l5.8-5.8a4.786,4.786,0,0,0,0-6.771Z\"\/><\/g><\/svg><\/a>Future of DA<\/h2>\n<p class=\"chakra-text css-gi02ar\">Beyond future iterations of PeerDAS, we have a variety of research directions to keep scaling DA while retaining the security properties of Ethereum that make it unique. Proposals generally fall under <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/ethresear.ch\/t\/fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond\/19529\">the moniker FullDAS<\/a> with several flavors under active investigation. A key component of these proposals all involve innovations in peer-to-peer networking that allow for a highly diverse set of participants to shard an increasing number of samples while remaining fault tolerant to adversarial actors. Work such as <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/arxiv.org\/abs\/2504.13757\">Robust Distributed Arrays<\/a> formalizes this notion. Other considerations include low-latency inclusion, censorship resistance, and evolutions of the blob fee market to make it easier to get blobs onchain.<\/p>\n<p class=\"chakra-text css-gi02ar\">Research here is stewarded by <a target=\"_blank\" rel=\"noopener\" class=\"chakra-link css-vezwxf\" href=\"https:\/\/x.com\/fradamt\">Francesco D\u2019Amato<\/a> and is very active \u2013 reach out if you\u2019d like to collaborate!<\/p>\n<\/div>\n<p><br \/>\n<br \/><a href=\"https:\/\/blog.ethereum.org\/en\/2025\/08\/22\/protocol-update-002\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Following up from Protocol Update 001, we\u2019d like to introduce our approach to blob scaling. The L1 serves as a robust foundation for L2 systems to scale Ethereum, and a necessary component of secure L2 solutions is data availability provided by the L1. Data availability ensures that updates L2s make back to the L1 can [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":17403,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[24],"tags":[],"kronos_expire_date":[],"class_list":["post-17447","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ethereum"],"_links":{"self":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/17447","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/comments?post=17447"}],"version-history":[{"count":0,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/17447\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media\/17403"}],"wp:attachment":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media?parent=17447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/categories?post=17447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/tags?post=17447"},{"taxonomy":"kronos_expire_date","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/kronos_expire_date?post=17447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}