# Blocks larger than 1MiB?

**URL:** <https://discuss.ipfs.tech/t/blocks-larger-than-1mib/20308>\
**Category:** Uncategorized\
**Created:** [August 5, 2026, 7:42am UTC](https://discuss.ipfs.tech/t/blocks-larger-than-1mib/20308 "2026-08-05T07:42:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![gkraemer](https://avatars.discourse-cdn.com/v4/letter/g/6de8d8/32.png) [@gkraemer](https://discuss.ipfs.tech/u/gkraemer)\
**Post date:** [August 5, 2026, 7:42am UTC](https://discuss.ipfs.tech/t/blocks-larger-than-1mib/20308/1 "2026-08-05T07:42:52Z")

</div>

I just saw this [1]. It says

> raise SoftBlockLimit to 2MiB per the bitswap spec

what are the caveats?

[1] [fix: allow dag import of 1MiB chunks wrapped in dag-pb (#11185) · ipfs/kubo@c6702ea · GitHub](https://github.com/ipfs/kubo/commit/c6702eaf886b434fbe4452b438e277651e8a3b50)

---

<div class="post-metadata">

**Author:** ![lidel](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lidel/32/9853_2.png) [@lidel](https://discuss.ipfs.tech/u/lidel)\
**Post date:** [August 5, 2026, 10:39am UTC](https://discuss.ipfs.tech/t/blocks-larger-than-1mib/20308/2 "2026-08-05T10:39:38Z")

</div>

No caveats for default usage. Nothing changed in defaults, this is necessary fix due to the [IPIP-499](https://specs.ipfs.tech/ipips/ipip-0499/) profiles that allow use of 256KiB and 1MiB [UnixFS](https://specs.ipfs.tech/unixfs/) file chunks.

`SoftBlockLimit` is a local guard on blocks you create (`block put`, `dag put`, `dag import`, custom `--chunker`), not a network change. The old 1MiB value was slightly too low: a 1MiB chunk wrapped in dag-pb ends up just over 1MiB, so `dag import` rejected data that was otherwise fine. That was the fix in [fix: allow dag import of 1MiB chunks wrapped in dag-pb by lidel · Pull Request #11185 · ipfs/kubo · GitHub](https://github.com/ipfs/kubo/pull/11185), shipped in 0.40.

2MiB is also the size every implementation must support per the [bitswap spec](https://specs.ipfs.tech/bitswap-protocol/#block-sizes), so blocks under it stay interop-safe. Older peers can already fetch them; the 1MiB check only ever ran on the create side, never on receive.

The real ceiling is the 4MiB bitswap message limit (libp2p’s `MessageSizeMax`), and 2MiB sits below it with room for framing overhead.

Care is needed above 2MiB, with `--allow-big-block`. Those blocks are outside the spec, other implementations may refuse them, and once block plus overhead crosses 4MiB they cannot move over bitswap at all. Big blocks are also a known open problem: you cannot verify one until you hold all of it, so a peer that trickles it out ties up your memory the way a slowloris attack does.

Longer discussion in [Supporting Large IPLD Blocks](https://discuss.ipfs.tech/t/supporting-large-ipld-blocks/15093/)