com.r3corda.core.contracts / Contract

# Contract

`interface Contract`

Implemented by a program that implements business logic on the shared ledger. All participants run this code for every LedgerTransaction they see on the network, for every input and output state. All contracts must accept the transaction for it to be accepted: failure of any aborts the entire thing. The time is taken from a trusted timestamp attached to the transaction itself i.e. it is NOT necessarily the current time.

### 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

verify | `abstract 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 : Contract`
CommercialPaperLegacy | `class CommercialPaperLegacy : Contract`
DummyContract | `class DummyContract : Contract`
InterestRateSwap | `class InterestRateSwap : Contract` 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> : 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.
OnLedgerAsset | `abstract class OnLedgerAsset<T : Any, 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 couldnt merge outputs of two colours together, but you COULD put them in the same transaction.