Bincode, the Rust ecosystem's most downloaded binary serialization crate with over 162 million downloads, is permanently unmaintained as of December 2025. The project was abandoned after a doxxing and harassment campaign against its maintainer. Bincode 2.0 stable had been released just nine months earlier in March 2025, ending a 3.5-year development cycle — only for the entire project to cease shortly after. A RUSTSEC advisory (RUSTSEC-2025-0141) was issued in January 2026, and the maintainer's recommended replacements are postcard, rkyv, bitcode, and a new wire-compatible crate called wincode. This situation has reshaped the Rust binary serialization landscape and exposed governance gaps in the crates.io infrastructure.
Bincode 2.0 arrived as a significant reimagining of the library. The stable 2.0.0 release on March 6, 2025 introduced custom Encode and Decode traits, making serde an optional dependency rather than a requirement. The new API replaced bincode::serialize() / bincode::deserialize() with bincode::encode_to_vec() / bincode::decode_from_slice(), and configuration became mandatory through bincode::config::standard(). Variable-length integer encoding was enabled by default, and backward compatibility with 1.x wire format was preserved via config::legacy().
The 2.0 journey was unusually long. Alpha releases began in October 2021, release candidates appeared through March 2023, and then nearly two years of silence preceded the stable release. A patch release (2.0.1, March 10, 2025) followed four days later. That was the last functional version.
In August 2025, the GitHub repository was archived and migrated to SourceHut by user "stygianentity," citing opposition to GitHub's AI integration. The migration raised immediate red flags: the entire Git history was rewritten into a single commit, no issue tracker was created, and the new identity had no prior online presence. Community investigation into these suspicious circumstances escalated into doxxing and harassment of the maintainer (ZoeyR on crates.io). On December 16, 2025, version 3.0.0 was published as a tombstone — containing only a README and a lib.rs with a deliberate compiler error.
The v1-to-v2 migration proved challenging for many users. Several common serde attributes — including #[serde(flatten)], #[serde(skip)], and #[serde(untagged)] — silently cause data loss with bincode, a longstanding footgun that caught many developers off guard. Users wanting serde compatibility had to explicitly enable the serde feature flag and use bincode::serde::* functions or annotate fields with #[bincode(with_serde)].
Early bincode 2 release candidates also suffered severe performance regressions. GitHub issue #618 documented the native Encode/Decode traits running up to 100x slower for serialization and 5–8x slower for deserialization compared to v1's serde path. These issues were largely resolved by the stable release, where bincode 2.0.1 showed roughly 2x faster serialization and 6x faster deserialization than 1.3.3 on mesh benchmarks.
Other long-standing criticisms applied to both versions: no schema evolution support (adding struct fields breaks old data), no data versioning or file headers, and confusing default configuration in v1 where DefaultOptions and bincode::serialize() used different integer encoding defaults.
The rust_serialization_benchmark (run with rustc 1.94.0-nightly, January 2026) provides a clear picture of the competitive landscape. Performance figures below are relative to the best performer (higher is better):
| Crate | Version | Serialize | Deserialize | Encoded size | Total downloads | Serde? |
|---|---|---|---|---|---|---|
| bitcode | 0.6.9 | 100% | 56% | 100% | ~1.3M | Optional |
| rkyv | 0.8.12 | 56% | 53%† | 98% (zlib) | ~70M | No (own) |
| speedy | 0.8.7 | 69% | 46% | ~80% | ~559K | No (own) |
| bincode | 2.0.1 | 36% | 34% | 95% | ~162.5M | Optional |
| borsh | 1.6.0 | 25% | 37% | 79% | ~7.8M | No (own) |
| postcard | 1.1.3 | ~25% | ~30% | ~70% of bincode | ~22.7M | Yes |
| rmp-serde | 1.3.0 | 13% | 20% | 74–92% | ~63.3M | Yes |
| prost | 0.14.x | 15% | 6% | moderate | very high | No (own) |
| ciborium | 0.2.2 | 3.5% | 7% | moderate | moderate | Yes |
†rkyv's zero-copy access is essentially free (~1.2 ns), making deserialization comparison misleading.
Bitcode dominates benchmarks across both speed and size, producing the smallest output while being the fastest serializer. Its bitwise-level encoding and field-grouping strategy produce output that compresses exceptionally well under Zstd and LZ4. The tradeoff: bitcode does not guarantee format stability across versions, making it unsuitable for persistent storage or cross-version communication.
rkyv takes a fundamentally different approach — serialized data is directly accessible as native Rust types without any deserialization step. This makes it ideal for mmap-based data stores, intra-process message passing, and large payloads where deserialization cost dominates. The bincode maintainer explicitly called rkyv "honestly the best option for many of the usecases that bincode was intended for." With 70 million downloads, rkyv has massive ecosystem adoption and very active maintenance by David Koloski.
postcard is the closest spiritual successor to bincode. Fully serde-based, #![no_std] compatible, and focused on embedded systems, it produces output roughly 30% smaller than bincode while being slightly slower. It has a documented, stable wire format since v1.0.0, active maintenance by James Munns with Mozilla sponsorship, and a growing ecosystem including postcard-rpc for embedded communication. Multiple projects migrating away from bincode — including libsql — are choosing postcard as the drop-in replacement.
borsh serves a distinct niche in blockchain ecosystems (Solana, NEAR Protocol). Its key differentiator is bijective serialization: no two binary representations can deserialize to the same object, making it essential for deterministic hashing. It trades raw speed for security guarantees.
For cross-language needs, prost (Protocol Buffers, part of the tokio-rs ecosystem) and rmp-serde (MessagePack, 63M downloads) remain the standard choices, while flatbuffers and Cap'n Proto offer zero-copy cross-language formats with schema evolution support.
The bincode discontinuation triggered immediate action across the Rust ecosystem. Major projects opened migration issues within days:
Community forks appeared quickly. bincode-next (by Apich Organisation) published a 3.0.0-rc.1 in February 2026, forking from bincode 2.0.1 and adding nested zero-copy support, schema fingerprinting, and bit-level packing with claimed 10–15% performance improvements. cu-bincode is another hard fork. A wire-format-compatible crate called wincode (v0.2.1, first published September 2025) produces identical bytes to bincode's default configuration, offering the smoothest migration path for projects needing byte-level compatibility.
The incident also exposed crates.io infrastructure gaps that the maintainer highlighted in the tombstone release: no mechanism to mark packages as unmaintained, no ownership transfer process for abandoned crates, no ability to edit crate metadata without publishing a new version, and no way for the last maintainer to remove themselves.
The right bincode replacement depends entirely on what bincode was being used for. For Rust-only transient data (IPC, caching, message passing), rkyv's zero-copy deserialization offers the best performance characteristics and is the maintainer's own top recommendation. For embedded systems or projects already using serde throughout, postcard provides the most familiar API and smallest migration surface. For maximum raw performance where format stability isn't required, bitcode is the undisputed benchmark champion. For persistent storage needing cross-language support, prost or rmp-serde remain the pragmatic choices. And for byte-for-byte bincode compatibility during a gradual migration, wincode is the only option.
The bincode saga is ultimately a cautionary tale about open-source sustainability. A crate with 162 million downloads and deep ecosystem integration was maintained by essentially one person. When harassment drove that person away, the entire dependency chain shuddered. The Rust community's response — rapid forking, clear migration guidance, and honest reflection on governance gaps — demonstrates resilience, but the underlying problem of maintainer burnout and abuse in open source remains unresolved.