Serialization
Serialization of consensus-relevant data types
Amounts
Amounts may take any integral value between 0 and 2^64 - 1. Amount serialization takes into account the fact that assets are often manipulated in quantities that are multiples of powers of ten.
Amount serialization has the following properties:
Every value with 3 or fewer significant decimal figures has a two-byte representation.
Every value with 8 or fewer significant decimal figures has a four-byte representation.
Every value less than 2^56 has an eight-byte representation.
Every value up to 2^64 - 1 has a nine-byte representation.
This compares to an uncompressed uint64 occupying eight bytes.
Two byte/16 bit representation: up to 3 significant figures
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Value
Notes
0
1
1
1
1
1
0
x
x
x
x
x
x
x
x
x
NaN
"quiet" NaN
0
1
1
1
1
0
x
x
x
x
x
x
x
x
x
x
Infinity
Or overflow, underflow. Causes deserialization failure.
0
a
b
e
e
e
t
t
t
t
t
t
t
t
t
t
tttttttttt_2 * 10^(abeee_2)
Subject to ab != 11 (base 2)
0
1
1
a
b
e
e
e
t
t
t
t
t
t
t
t
100tttttttt_2 * 10^(abeee_2)
Subject to ab != 11 (base 2). This is a non-canonical representation (the client will not make it).
Four byte/32 bit representation: up to 8 significant figures
31
30
29
28
27
26
25
24
Value
Notes
1
1
1
1
1
1
0
x
NaN
quiet NaN
1
1
1
1
1
0
x
x
Infinity
Or overflow/underflow. Deserialization error.
1
0
e
e
e
e
t
t
((tt_2)*2^24 + L) * 10^(eeee_2)
'L' is the unsigned big-endian value of the next 3 bytes.
1
1
1
a
b
e
e
t
((10t_2)*2^24 + L) * 10^(abee_2)
Subject to ab != 11 (base 2). This is a non-canonical representation (the client will not make it).
1
1
0
e
e
e
e
t
((10t_2)*2^24 + L) * 10^(eeee_2)
Canonical representation of values with large significands (>= 2^26 and less than 10^8).
Eight byte/64 bit representation: up to 2^56 - 1
Highest byte
Seven lower bytes
Value
Notes
0x7E/0x7F
L
L
'L' is a 7-byte unsigned big-endian value
Nine byte/72 bit representation: at least 2^56
Highest byte
Eight lower bytes
Value
Notes
0xFE/0xFF
L
L
'L' is an 8-byte unsigned big-endian value
Examples
Assets
Assets have a version, a contract hash and a subtype. The version and contract hash together form the contract id. The version may take any uint32 value, the contract hash any 32-byte array value, and the subtype any 32-byte array value.
As a special case, the Zen native token has version 0, contract hash with all bytes set to zero, and subtype with all bytes set to zero.
Asset serialization is optimized to represent the Zen native token efficiently, as well as to efficiently represent assets with low version numbers and with subtypes that have many trailing zero bytes. As the subtype is under the control of the contract generating the asset, contract writers can gain some efficiency for the assets their contracts make, by giving them short subtypes.
Serialized assets use between one and 65 bytes. The first byte uses two bits for signalling, and six to encode the version. Between zero and four more bytes encode the rest of the version, followed by either zero or 32 bytes to represent the contract hash, followed by between zero and 32 bytes to represent the subtype.
First byte
7
6
Rest of byte
Uncompressed representation?
Subtype present?
Version or upper part of version
First byte (base 2)
Version
Contract Hash
Subtype
More bytes?
Notes
00000000
Zero
Zero
Zero
No
Zen native token
10000000
Zero
Non-zero
Zero
Yes, 32 more
Contract's default asset
11000000
Zero
Any
Non-zero
Yes, 64 more
Uncompressed subtype (32 bytes). Canonical iff the uncompressed subtype has 0 or 1 trailing zero bytes.
01000000
Zero
Any
Non-zero
Yes, between 34 and 63 more
Compressed subtype (< 32 bytes). Canonical iff the uncompressed subtype has at least two trailing zero bytes.
xy0abcde
abcde (base 2)
As above
As above
Only if x <> 0 or y <> 0
Represents versions between 0 and 31.
xy1abcde
>=32
As above
As above
Yes
Represents versions greater than or equal to 32. See below.
Version bytes
If the version is between 0 and 31, inclusive, there are no additional version bytes. The third most significant bit of the first byte is set to 0, and the lower five bits represent the version.
Versions are serialized by an algorithm similar to that used for protocol buffers' varint type. Between one and five bytes are used to represent the 32-bit version, including the first byte described above.
Bit patterns
Version range
Big-endian uncompressed version
Bytes
0 <= v < 32
000xxxxx
??0xxxxx
32 <= v < 2^12
0000xxxx xyyyyyyy
??1xxxxx 0yyyyyyy
2^12 <= v < 2^19
00000xxx xxyyyyyy yzzzzzzz
??1xxxxx 1yyyyyyy 0zzzzzzz
2^19 <= v < 2^26
000000xx xxxyyyyy yyzzzzzz zwwwwwww
??1xxxxx 1yyyyyyy 1zzzzzzz 1wwwwwww
2^26 <= v
xxxxyyyy yyyzzzzz zzwwwwww wvvvvvvv
??10xxxx 1yyyyyyy 1zzzzzzz 1wwwwwww 1vvvvvvv
The two most significant bits of the first byte, marked above as ??, signal the type of compression used for the contract hash and subtype.
Remaining bytes
Zen native asset – contract hash and subtype both zero
There are no further bytes. The top two bits of the first byte are set to zero.
Default contract asset – subtype is zero
The two first bits of the first (version) byte are set to 10. After the version bytes, the next 32 bytes encode the contract hash.
Uncompressed subtype – subtype has at most one trailing zero byte
The first two bits of the first byte are set to 11. After the version bytes, the next 32 bytes encode the contract hash, and a further 32 bytes encode the subtype.
Compressed subtype – subtype has at least two trailing zero bytes.
The first two bits of the first byte are set to 01. After the version bytes, the next 32 bytes encode the contract hash. One byte encodes the 'size' of the subtype – i.e., 32 minus the number of trailing zero bytes. A further size bytes encode the leading bytes of the subtype.
Examples
Versions are written as integers (decimal). The contract hash and subtype are written as arrays of bytes, of length 32.
Last updated