Bob Stuart, creator of MQA, talks in detail about this revolutionary British technology that sets a new standard in capturing, delivering and reproducing digital audio.
MQA 16-bit and Provenance in the Last Mile
In a previous post MQA CD: Origami and the Last Mile , we outlined the steps when the recording is ‘folded’ for transmission and ‘unfolded’ for playback.
It also shows how the end-to-end response varies for listeners with: a) No Decoder, b) A Core Decoder, c) A Full Decoder or d) when the stream is limited to 16b in playback (e.g. in Automotive, over some wireless links, or if it was made that way for MQA CD).
We go deeper into this after the next section, but for convenience here we redraw the first Origami steps.
Once the recording has been ‘de-blurred’, MQA uses a process we call ‘Music Origami’ that focuses on maintaining the information in the orange triangle (plus a substantial safety margin below the triangle), thereby making this large, high-resolution file both manageable, and compatible with any service or playback device.
This section reviews the first steps of ‘Origami’ used to make a single-speed (1s MQL) transmission file. As a first step, very high-frequency content C is ‘encapsulated’ and hidden away below the noise floor of B as shown below.
The next diagram shows more detail on how this burying is done.
Preview and Authenticity
The four listening scenarios listed at the start: a) No Decoder, b) A Core Decoder, c) A Full Decoder or d) when the stream is limited to 16b in playback, can each be previewed by Mastering tools, and also (in the supply chain) facilitated by a Pro-MQA Decoder. This enables a rights-holder to be certain of the sound arriving in all four scenarios from the same 24b distribution file and Authenticate it. 
In MQA, the blue or green light indicates Provenance and that the file or stream was losslessly delivered and can provide an approved presentation. If the stream is modified such that none of the four approved listed decodes can be heard, the light will not light.
If we look at the block diagram above, we can see there are three components to the MQA data, broadly described as: i) top 16 bits, ii) MQA signalling and iii) bottom 8 bits.
The decoder will verify checksums and calculate secure hashes of the input audio and data channel.  If the stream has not arrived losslessly then at least one of these checks will fail, the light will not light (or go out) and the decoder will pass the audio undecoded.
If the top 16 bits and signalling are correct but there is an error in the bottom 8 bits, then the decoder will immediately decode the MQA16 (ignoring any and all data below the 16th bit) and if it is successful, will light the Authentication light. Although the MQA decoder knows if there were more bits at encoding, it also knows this is a valid and approved presentation; for simplicity, it does not display this fact (although a Pro decoder may).
When the original source was 16b there are only 16 bits in the MQA stream and the decoder will immediately decode and if it is successful, will light the Authentication light.
Some people have noticed that if you change the data in the bottom 8 bits of a 24b MQA file (e.g. by truncating at 23b, 22b, 20b etc) that the MQA light still comes on and they are puzzled why that Authentication should still be there?
The simple answer is that this is by design.
If anything is wrong in the bottom 8 bits then that region is ignored and the result will be the MQA16 decode so long as the top 16 bits, signature and instructions are correct, failing which the decoder unlocks and the light goes out.
 Authenticating this set of listening options was requested by RIAA and the major record labels in 2014.
 The system uses a cryptographically secure signature verification mechanism. The secure hashes are blake2s and these hashes are signed using RSA signatures. The private keys for this process are stored safely within Hardware Security Modules thus ensuring the provenance of genuine MQA streams.