I extracted a TransactionEnvelope XDR several months ago for testing. It parses fine in the lab and the SDKs.

I've tried parsing it by hand and there's something I don't understand. After the MemoText is finished, the next item should be an int (4 bytes) count of operations. The next 4 bytes are 0, 0, 0, 0, indicating that there's zero operations. But there is actually 1 operation. As the fifth byte is 1, and the bytes that follow it decode to that single operation, it seems that there's an extra 0 byte between the Memo and the operation count.

It's not a string terminator, because the en/decoding of strings clearly uses 4 bytes to count the number of bytes in the string, followed by that quantity of bytes and no trailing bytes.

It's not a Memo terminator, because there isn't one. And it doesn't separate the Transaction data from the operation list, because there's no such separator.

The extra weird bit is when I debug the Java SDK's parsing of this, I can see the extra 0 in the buffer, but when it comes to parse the operation count, this extra byte is "magically" skipped. I can't find the code that is reading it.

Here's the Java SDK parsing code that I used for debugging:




And this is my console output where I'm parsing the data manually, 1 field at a time:

@ s.drop(60).take(23)
res128: Array[Byte] = Array(72, 105, 32, 90, 121, 44, 32, 104, 101, 114, 101, 115, 32, 97, 110, 32, 97, 110, 103, 112, 97, 111, 33)

@ new String(res128)
res129: String = "Hi Zy, heres an angpao!"

@ s.drop(83).take(5)
res130: Array[Byte] = Array(0, 0, 0, 0, 1)

You can see that after the String of the Memo is parsed, the subsequent bytes are 0,0,0,0,1 and not 0,0,0,1 as expected.

My question can be framed in a number of different ways, but the underlying question is the same. Why does this XDR parse OK when it has this extra 0? Why is there an extra 0 when the encoder doesn't write one? Why does the decoder ignore the extra 0?

1 Answer 1


I believe that is the extra padding bytes set so that the length is a multiple of 4. From the RFC 4506 (a.k.a. the XDR Spec):

The standard defines a string of n (numbered 0 through n-1) ASCII bytes to be the number n encoded as an unsigned integer (as described above), and followed by the n bytes of the string. Byte m of the string always precedes byte m+1 of the string, and byte 0 of the string always follows the string's length. If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four.

In this case, the string is 23 bytes long and so we have one extra byte of padding.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.