Transaction Data Types¶
There is a large library of data types used in Corda transactions and contract state objects.
Amount¶
The Amount
class is used to represent an amount of some fungible asset. It is a generic class which wraps around
a type used to define the underlying product, generally represented by an Issued
instance, or this can be a more
complex type such as an obligation contract issuance definition (which in turn contains a token definition for whatever
the obligation is to be settled in).
Note
Fungible is used here to mean that instances of an asset is interchangeable for any other identical instance, and that they can be split/merged. For example a £5 note can reasonably be exchanged for any other £5 note, and a £10 note can be exchanged for two £5 notes, or vice-versa.
Where a contract refers directly to an amount of something, Amount
should wrap Issued
, which in
turn can refer to a Currency
(GBP, USD, CHF, etc.), or any other class. Future work in this area will include
introducing classes to represent non-currency things (such as commodities) that Issued can wrap. For more
complex amounts, Amount
can wrap other types, for example to represent a number of Obligation contracts to be
delivered (themselves referring to a currency), an Amount
such as the following would used:
Amount<Obligation.State<Currency>>
Contract State¶
A Corda contract is composed of three parts; the executable code, the legal prose, and the state objects that represent
the details of the contract (see Data model for further detail). States essentially convert the generic template
(code and legal prose) into a specific instance. In a WireTransaction
, outputs are provided as ContractState
implementations, while the inputs are references to the outputs of a previous transaction. These references are then
stored as StateRef
objects, which are converted to StateAndRef
on demand.
A number of interfaces then extend ContractState
, representing standardised functionality for states:
OwnableState
- A state which has an owner (represented as a
PublicKey
, discussed later). Exposes the owner and a function for replacing the owner.LinearState
- A state which links back to its previous state, creating a thread of states over time. Intended to simplify tracking state versions.
DealState
- A state representing an agreement between two or more parties. Intended to simplify implementing generic protocols that manipulate many agreement types.
FixableDealState
- A deal state, with further functions exposed to support fixing of interest rates.
Things (such as attachments) which are identified by their hash should implement the NamedByHash
interface,
which standardises how the ID is extracted.
FungibleAssets and Cash¶
There is a common FungibleAsset
superclass for contracts which model fungible assets, which also provides a standard
interface for its subclasses’ state objects to implement. The clear use-case is Cash
, however FungibleAsset
is
intended to be readily extensible to cover other assets, for example commodities could be modelled by using a subclass
whose state objects include further details (location of the commodity, origin, grade, etc.) as needed.
Transaction Types¶
The WireTransaction
class contains the core of a transaction without signatures, and with references to attachments
in place of the attachments themselves (see also Data model). Once signed these are encapsulated in the
SignedTransaction
class. For processing a transaction (i.e. to verify it) it is first converted to a
LedgerTransaction
, which involves verifying the signatures and associating them to the relevant command(s), and
resolving the attachment references to the attachments. Commands with valid signatures are encapsulated in the
AuthenticatedObject
type.
Party and PublicKey¶
Identities of parties involved in signing a transaction can be represented simply by their PublicKey
, or by further
information (such as name) using the Party
class. An AuthenticatedObject
contains a list of the public keys
for signatures present on the transaction, as well as list of parties for those public keys (where known).
Note
These types are provisional and are likely to change in future, for example to add additional information to
Party
.
Date Support¶
There are a number of supporting interfaces and classes for use by contract which deal with dates (especially in the
context of deadlines). As contract negotiation typically deals with deadlines in terms such as “overnight”, “T+3”,
etc., it’s desirable to allow conversion of these terms to their equivalent deadline. Tenor
models the interval
before a deadline, such as 3 days, etc., while DateRollConvention
describes how deadlines are modified to take
into account bank holidays or other events that modify normal working days.
Calculating the rollover of a deadline based on working days requires information on the bank holidays involved
(and where a contract’s parties are in different countries, for example, this can involve multiple separate sets of
bank holidays). The BusinessCalendar
class models these calendars of business holidays; currently it loads these
from files on disk, but in future this is likely to involve reference data oracles in order to ensure consensus on the
dates used.