data class BilateralNetState<P : Any> : NetState<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. |
|
class Cash : OnLedgerAsset<Currency, Commands, State>
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. |
|
data class MultilateralNetState<P : Any> : NetState<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 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. |
|
interface NetState<P : Any>
Common interface for the state subsets used when determining nettability of two or more states. Exposes the underlying issued thing. |
|
class Obligation<P : Any> : Contract
An obligation contract commits the obligor to delivering a specified amount of a fungible asset (for example the 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. |
|
abstract class OnLedgerAsset<T : Any, out C : CommandData, S : FungibleAsset<T>> : Contract
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. |
|
data class PartyAndAmount<T : Any>
A simple holder for a (possibly anonymous) AbstractParty and a quantity of tokens |
val Amount<Currency>.CASH: State
An extension property that lets you write 100.DOLLARS.CASH |
|
val Amount<Issued<Currency>>.STATE: State
An extension property that lets you get a cash state from an issued token, under the NULL_PARTY |
infix fun <T : Any> State<T>.at(dueBefore: Instant): State<T> |
|
infix fun <T : Any> State<T>.between(parties: <ERROR CLASS><AbstractParty, AbstractParty>): State<T> |
|
fun <P : Any> extractAmountsDue(product: Terms<P>, states: Iterable<State<P>>): Map<<ERROR CLASS><AbstractParty, AbstractParty>, Amount<Terms<P>>>
Convert a list of settlement states into total from each obligor to a beneficiary. |
|
infix fun <T : Any> State<T>.issued by(party: AbstractParty): State<T> |
|
fun <T : Any> State<T>.issuedBy(party: AnonymousParty): State<T> |
|
fun <P : AbstractParty, T : Any> netAmountsDue(balances: Map<<ERROR CLASS><P, P>, Amount<T>>): Map<<ERROR CLASS><P, P>, Amount<T>>
Net off the amounts due between parties. |
|
infix fun <T : Any> State<T>.owned by(owner: AbstractParty): State<T> |
|
fun <T : Any> State<T>.ownedBy(owner: AbstractParty): State<T> |
|
fun <P : AbstractParty, T : Any> sumAmountsDue(balances: Map<<ERROR CLASS><P, P>, Amount<T>>): Map<P, Long>
Calculate the total balance movement for each party in the transaction, based off a summary of balances between each obligor and beneficiary. |