com.r3corda.core.contracts.clauses / ClauseVerifier

# ClauseVerifier

`abstract class ClauseVerifier : Contract`

Abstract superclass for clause-based contracts to extend, which provides a verify() function that delegates to the supplied list of clauses.

### Constructors

<init> | `ClauseVerifier()` Abstract superclass for clause-based contracts to extend, which provides a verify() function that delegates to the supplied list of clauses.

### Properties

clauses | `abstract val clauses: List<SingleClause>`

### Inherited Properties

legalContractReference | `abstract val legalContractReference: SecureHash` Unparsed reference to the natural language contract that this code is supposed to express (usually a hash of the contracts contents).

### Functions

extractCommands | `abstract fun extractCommands(tx: TransactionForContract): Collection<AuthenticatedObject<CommandData>>`
verify | `open fun verify(tx: TransactionForContract): Unit` Takes an object that represents a state transition, and ensures the inputs/outputs/commands make sense. Must throw an exception if theres 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.

### Inheritors

CommercialPaper | `class CommercialPaper : ClauseVerifier`
InterestRateSwap | `class InterestRateSwap : ClauseVerifier` The Interest Rate Swap class. For a quick overview of what an IRS is, see here - http://www.pimco.co.uk/EN/Education/Pages/InterestRateSwapsBasics1-08.aspx (no endorsement). This contract has 4 significant data classes within it, the "Common", "Calculation", "FixedLeg" and "FloatingLeg". It also has 4 commands, "Agree", "Fix", "Pay" and "Mature". Currently, we are not interested (excuse pun) in valuing the swap, calculating the PVs, DFs and all that good stuff (soon though). This is just a representation of a vanilla Fixed vs Floating (same currency) IRS in the R3 prototype model.
Obligation | `class Obligation<P> : ClauseVerifier` 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.
OnLedgerAsset | `abstract class OnLedgerAsset<T : Any, S : FungibleAsset<T>> : ClauseVerifier` 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 couldnt merge outputs of two colours together, but you COULD put them in the same transaction.