Transactions in chainqueue are chain-agnostic. Their representation should only presume a generalized concept of a chain transaction. Interpretation of what a transaction acutally contains or means is left to the client code of the queue to process.
In storage each record is divided into two parts: A @emph{mandatory} part, and a @emph{cache} part.
@subsection Mandatory record
This consists of the data required to order transactions, and to actually them to the network. Specifically, it contains:
@item the @strong{block number} of a confirmed transaction
@end itemize
@subsection Cache record
With exception of the @emph{nonce}, the @emph{cache} part of the record contains deserialized fields of the transaction, all of which can be reconstructed by the client code intepreting the transaction payload in the @emph{mandatory} part.
The primary purpose of the @emph{cache} record is performance improvement. By keeping cached records of the expanded and interpreted properties of a transaction, fewer cycles need to be spent later on when needing to access these derived properties.
Keeping the cache also more easily enables conditional ordering and execution when querying data sets, e.g. @emph{@guillemetleft{}the first unsent transaction nonce from sender S.@guillemetright{}}
Additionally, the cache records curates some additional token semantics, defining in essence a transaction as @emph{@guillemetleft{}sender S sends X amount of token A as Y amount of token B to recipient R@guillemetright{}}.
