Class | Description |
---|---|
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.
|
CashKt | |
CommodityContract |
A commodity contract represents an amount of some commodity, tracked on a distributed ledger. The design of this
contract is intentionally similar to the
class Cash contract, and the same commands (issue, move, exit) apply, the
differences are in representation of the underlying commodity. Issuer in this context means the party who has the
commodity, or is otherwise responsible for delivering the commodity on demand, and the deposit reference is use for
internal accounting by the issuer (it might be, for example, a warehouse and/or location within a warehouse). |
CommodityContractKt | |
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.
|