| Interface | Description |
|---|---|
| NetState<P> |
Common interface for the state subsets used when determining nettability of two or more states. Exposes the
underlying issued thing.
|
| Class | Description |
|---|---|
| BilateralNetState<P> |
Subset of state, containing the elements which must match for two obligation transactions to be nettable.
If two obligation state objects produce equal bilateral net states, they are considered safe to net directly.
Bilateral states are used in close-out netting.
|
| Cash |
A cash transaction may split and merge money represented by a set of (issuer, depositRef) pairs, across multiple
input and output states. Imagine a Bitcoin transaction but in which all UTXOs had a colour
(a blend of issuer+depositRef) and you couldn't merge outputs of two colours together, but you COULD put them in
the same transaction.
|
| CashUtilities | |
| MultilateralNetState<P> |
Subset of state, containing the elements which must match for two or more obligation transactions to be candidates
for netting (this does not include the checks to enforce that everyone's amounts received are the same at the end,
which is handled under the verify() function).
In comparison to
class BilateralNetState, this doesn't include the parties' keys, as ensuring balances match on
input and output is handled elsewhere.
Used in cases where all parties (or their proxies) are signing, such as central clearing. |
| Obligation<P> |
An obligation contract commits the obligor to delivering a specified amount of a fungible asset (for example the
class Cash contract) at a specified future point in time. Settlement transactions may split and merge contracts across
multiple input and output states. The goal of this design is to handle amounts owed, and these contracts are expected
to be netted/merged, with settlement only for any remainder amount. |
| ObligationKt | |
| OnLedgerAsset<T,C extends CommandData,S extends FungibleAsset<T>> |
An asset transaction may split and merge assets represented by a set of (issuer, depositRef) pairs, across multiple
input and output states. Imagine a Bitcoin transaction but in which all UTXOs had a colour (a blend of
issuer+depositRef) and you couldn't merge outputs of two colours together, but you COULD put them in the same
transaction.
|
| PartyAndAmount<T> |
A simple holder for a (possibly anonymous)
class AbstractParty and a quantity of tokens |