A type representing a transaction (calldata) decoding. As you can see, these come in five types, each of which is documented separately.
This is a type for recording what decoding mode a given decoding was produced in. There are two decoding modes, full mode and ABI mode. In ABI mode, decoding is done purely based on the ABI JSON. Full mode, by contrast, additionally uses AST information to produce a more informative decoding. For more on full mode and ABI mode, see the notes on Decoding modes.
A type representing a log (event) decoding. As you can see, these come in two types, each of which is documented separately.
A type representing a returndata (return value or revert message) decoding. As you can see, these come in six types, each of which is documented separately.
An encoder request; can come in one of three types. It can be either a request to understand a numeric input (integer or decimal), or a request to resolve a contract name. The "kind" field distinguishes.
An encoder response; contains either a numeric value (as a BigInt or Big) or an address.
Specifies a block. Can be given by number, or can be given via the special strings "genesis", "latest", or "pending".
Intended to work like Web3's BlockType.
Warning: Using "pending", while allowed, is not advised, as it may lead to internally inconsistent results. Use of "latest" is safe and will not lead to inconsistent results from a single decoder call due to the decoder's caching system, but pending blocks cannot be cached under this system, which may cause inconsistencies.
Used to indicate whether "extra" event decodings -- event decodings from non-library contracts other than the one that appears to have emitted the event -- should be returned.
"off": Exclude extra decodings (the default)."on": Include extra decodings."necessary": Include extra decodings only if there are no others.Extra decodings will always be returned after other decodings.
Type for access lists
If there are multiple possibilities, they're always returned in the order: return, revert, returnmessage, failure, empty, bytecode, unknownbytecode Moreover, within "revert", builtin ones are put above custom ones
Decodes the return data from a failed call.
The returned data, as a Uint8Array.
An array of possible decodings. At the moment it's impossible for there to be more than one. (If the call didn't actually fail, or failed in a nonstandard way, you may get no decodings at all, though!)
Decodings can either be decodings of revert messages, or decodings indicating that there was no revert message. If somehow both were to be possible, they'd go in that order, although as mentioned, there (at least currently) isn't any way for that to occur.
Generated using TypeDoc
Truffle Codec
This module provides low-level decoding and encoding functionality for Solidity and the Solidity ABI. Many parts of this module are intended primarily for internal use by Truffle and so remain largely undocumented, but some of its types are also output by @truffle/decoder, which provides a higher-level interface to much of this module's functionality.
If you're here from Truffle Decoder or Truffle Encoder
If you're coming here from @truffle/decoder or @truffle/encoder, you probably just want to know about the parts that are relevant to you. These are:
Note that the data category is largely scarce in documentation, although that's because it's largely self-explanatory.
If you're not just here from Truffle Decoder or Encoder, but are actually interested in the lower-level workings, read on.
How this module differs from Truffle Decoder and Encoder
Unlike Truffle Decoder and Encoder, this library makes no network connections and avoids dependencies that do. Instead, its decoding functionality is generator-based; calling one of the decoding functions returns a generator. This generator's
next()function may return a finished result, or it may return a request for more information. It is up to the caller to fulfill these requests -- say, by making a network connection of its own. This is how @truffle/decoder and @truffle/encoder work; @truffle/codec makes requests, while Decoder and Encoder fulfill them by looking up the necessary information on the blockchain.This library also provides additional functionality beyond what's used by Truffle Decoder and Encoder. In particular, this library also exists to support Truffle Debugger, and so it provides decoding functionality not just for transactions, logs, and state variables, but also for Solidity variables during transaction execution, including circularity detection for memroy structures. It includes functionality for decoding Solidity's internal function pointers, which the debugger uses, but which Truffle Decoder currently does not (although this is planned for the future).
There is also functionality for decoding return values and revert messages that goes beyond what's currently available in @truffle/decoder; this may get a better interface in the future.
How to use
You should probably use @truffle/decoder or @truffle/encoder instead, if your use case doesn't preclude it. This module has little documentation, where it has any at all, and it's likely that parts of its interface may change (particularly regarding allocation). That said, if you truly need the functionality here, Truffle Decoder and Truffle Encoder can perhaps serve as something of a reference implementation (and perhaps Truffle Debugger as well, though that code is much harder to read or copy).