15 releases (1 stable)

1.0.0 Sep 26, 2022
1.0.0-alpha.1 Jul 15, 2022
0.6.0 Apr 12, 2022
0.5.2 Nov 19, 2021
0.3.1-alpha Jul 23, 2020

#2649 in Magic Beans

Download history 163/week @ 2023-11-01 187/week @ 2023-11-08 134/week @ 2023-11-15 163/week @ 2023-11-22 152/week @ 2023-11-29 174/week @ 2023-12-06 185/week @ 2023-12-13 197/week @ 2023-12-20 127/week @ 2023-12-27 192/week @ 2024-01-03 178/week @ 2024-01-10 172/week @ 2024-01-17 192/week @ 2024-01-24 125/week @ 2024-01-31 152/week @ 2024-02-07 220/week @ 2024-02-14

718 downloads per month
Used in 12 crates (6 directly)





A general-purpose ternary manipulation, translation and encoding crate.


  • Creation of trit and tryte buffers with multiple encodings
  • Safe encoding API that allows the efficient manipulation and sharing of trit and tryte buffers and slices
  • Mutation of trit buffers and slices
  • Ternary BigInt implementation
  • Balanced and unbalanced ternary
  • serde support


This crate includes support for many different trit encodings. Encodings allow the trading off of different features against each other.

T1B1 is the canonical default encoding and represents every trit with a single byte of memory. It is the fastest encoding to manipulate since no bitwise operations are necessary to pack and unpack it from memory during manipulation. As a result of this, it also permits certain extra features like mutable chunking and accessing its contents through ordinary slices.

T3B1 is also commonly used. It provides good compression and has the advantage that it has an identical bit representation as a Tryte slice. For this reason, it is the only encoding that can be converted to a tryte slice with no overhead.

T5B1 is the most compressed encoding. It provides very high storage densities (almost optimal, in fact) and is the densest encoding supported by this crate.

It is likely that one of the 3 encodings above will suit your requirements. In addition, this crate also supports T2B1 and T4B1 for completeness.

Byte Alignment

This crate supports creating sub-slices of trit slices. To enable this, it stores extra metadata along with a trit slice in order to correct identify the index of a buffer it starts on. With compressed encodings, such as T3B1, that starting index (and, indeed, the end index) may not fall exactly on a byte boundary.

This crate makes a best attempt at avoiding the negative ramifications of this fact, but sadly some still leak through into the API. For example, some methods may panic if a slice does not have a byte-aligned starting index or otherwise does not fulfil certain invariants. However, all panicking behaviours are documented on each method such that you can easily avoid circumstances like this.

When the documentation refers to 'byte alignment', it is referring specifically to whether the starting index is a multiple of the compression factor. For example a byte-aligned T3B1 buffer will always start on an index of the original buffer that is a multiple of 3.