public class Cash
extends OnLedgerAsset
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.
The goal of this design is to ensure that money can be withdrawn from the ledger easily: if you receive some money 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 money and don't care much who is currently holding it in their vaults can ignore the issuer/depositRefs and just examine the amount fields.
Modifier and Type | Class and Description |
---|---|
static class |
Cash.State
A state representing a cash claim against some party.
|
Constructor and 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.
|
Modifier and Type | Method and Description |
---|---|
TransactionState<net.corda.contracts.asset.Cash.State> |
deriveState(TransactionState<net.corda.contracts.asset.Cash.State> txState,
Amount<net.corda.core.contracts.Issued> amount,
CompositeKey owner)
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.
|
java.util.List<net.corda.core.contracts.AuthenticatedObject> |
extractCommands(java.util.Collection<? extends net.corda.core.contracts.AuthenticatedObject<? extends net.corda.core.contracts.CommandData>> commands) |
Commands.Exit |
generateExitCommand(Amount<net.corda.core.contracts.Issued> amount) |
void |
generateIssue(TransactionBuilder tx,
Issued<java.util.Currency> tokenDef,
long pennies,
CompositeKey owner,
Party notary)
Puts together an issuance transaction from the given template, that starts out being owned by the given pubkey.
|
void |
generateIssue(TransactionBuilder tx,
Amount<net.corda.core.contracts.Issued> amount,
CompositeKey owner,
Party notary)
Puts together an issuance transaction for the specified amount that starts out being owned by the given pubkey.
|
Commands.Issue |
generateIssueCommand() |
Commands.Move |
generateMoveCommand() |
AbstractConserveAmount<net.corda.contracts.asset.Cash.State,net.corda.contracts.asset.Cash.Commands,java.util.Currency> |
getConserveClause() |
SecureHash |
getLegalContractReference()
TODO:
|
void |
verify(TransactionForContract tx)
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.
|
deriveState, extractCommands, generateExit, generateExitCommand, generateIssueCommand, generateMoveCommand, getConserveClause
getLegalContractReference, verify
public 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.
The goal of this design is to ensure that money can be withdrawn from the ledger easily: if you receive some money 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 money and don't care much who is currently holding it in their vaults can ignore the issuer/depositRefs and just examine the amount fields.
public SecureHash getLegalContractReference()
TODO:
hash should be of the contents, not the URI
allow the content to be specified at time of instance creation?
Motivation: it's the difference between a state object referencing a programRef, which references a legalContractReference and a state object which directly references both. The latter allows the legal wording to evolve without requiring code changes. But creates a risk that users create objects governed by a program that is inconsistent with the legal contract.
public AbstractConserveAmount<net.corda.contracts.asset.Cash.State,net.corda.contracts.asset.Cash.Commands,java.util.Currency> getConserveClause()
public java.util.List<net.corda.core.contracts.AuthenticatedObject> extractCommands(java.util.Collection<? extends net.corda.core.contracts.AuthenticatedObject<? extends net.corda.core.contracts.CommandData>> commands)
public void generateIssue(TransactionBuilder tx, Issued<java.util.Currency> tokenDef, long pennies, CompositeKey owner, Party notary)
Puts together an issuance transaction from the given template, that starts out being owned by the given pubkey.
public void generateIssue(TransactionBuilder tx, Amount<net.corda.core.contracts.Issued> amount, CompositeKey owner, Party notary)
Puts together an issuance transaction for the specified amount that starts out being owned by the given pubkey.
public TransactionState<net.corda.contracts.asset.Cash.State> deriveState(TransactionState<net.corda.contracts.asset.Cash.State> txState, Amount<net.corda.core.contracts.Issued> amount, CompositeKey owner)
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.
public Commands.Exit generateExitCommand(Amount<net.corda.core.contracts.Issued> amount)
public Commands.Issue generateIssueCommand()
public Commands.Move generateMoveCommand()
public void verify(TransactionForContract tx)
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.