OnLedgerAsset

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.

The goal of this design is to ensure that assets can be withdrawn from the ledger easily: if you receive some asset via this contract, you always know where to go in order to extract it from the R3 ledger, no matter how many hands it has passed through in the intervening time.

At the same time, other contracts that just want assets and don't care much who is currently holding it can ignore the issuer/depositRefs and just examine the amount fields.

Inheritors

Constructors

Link copied to clipboard
constructor()

Types

Link copied to clipboard
object Companion

Functions

Link copied to clipboard
abstract fun deriveState(txState: TransactionState<S>, amount: Amount<Issued<T>>, owner: AbstractParty): TransactionState<S>

Derive a new transaction state based on the given example, with amount and owner modified. This allows concrete implementations to have fields in their state which we don't know about here, and we simply leave them untouched when sending out "change" from spending/exiting.

Link copied to clipboard
fun generateExit(tx: TransactionBuilder, amountIssued: Amount<Issued<T>>, assetStates: List<StateAndRef<S>>): Set<PublicKey>
fun generateExit(tx: TransactionBuilder, amountIssued: Amount<Issued<T>>, assetStates: List<StateAndRef<S>>, payChangeTo: AbstractParty): Set<PublicKey>

Generate an transaction exiting assets from the ledger.

Link copied to clipboard
abstract fun generateExitCommand(amount: Amount<Issued<T>>): CommandData
Link copied to clipboard
Link copied to clipboard
abstract fun verify(tx: LedgerTransaction)

Takes an object that represents a state transition, and ensures the inputs/outputs/commands make sense. Must throw an exception if there's a problem that should prevent state transition. Takes a single object rather than an argument so that additional data can be added without breaking binary compatibility with existing contract code.