# 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.