# Package net.corda.flows

- Interface Summary
  Interface | Description
  --- | ---
  ServiceRequestMessage | Abstract superclass for request messages sent to services which expect a reply.

- Class Summary
  Class | Description
  --- | ---
  AbstractCashFlow | Initiates a flow that produces an Issue/Move or Exit Cash transaction.
  AbstractStateReplacementFlow | Abstract flow to be used for replacing one state with another, for example when changing the notary of a state. Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these flows.
  BroadcastTransactionFlow | Notify the specified parties about a transaction. The remote peers will download this transaction and its dependency graph, verifying them all. The flow returns when all peers have acknowledged the transactions as valid. Normally you wouldn't use this directly, it would be called via `class FinalityFlow`.
  CashExitFlow | Initiates a flow that produces an cash exit transaction.
  CashFlowCommand | A command to initiate the Cash flow with.
  CashIssueFlow | Initiates a flow that produces cash issuance transaction.
  CashPaymentFlow | Initiates a flow that produces an cash move transaction.
  ContractUpgradeFlow | A flow to be used for upgrading state objects of an old contract to a new contract.
  FetchAttachmentsFlow | Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded attachments are saved to local storage automatically.
  FetchDataFlow<T extends NamedByHash,W> | An abstract flow for fetching typed data from a remote peer.
  FetchTransactionsFlow | Given a set of tx hashes (IDs), either loads them from local disk or asks the remote peer to provide them.
  FinalityFlow | Verifies the given transactions, then sends them to the named notaries. If the notary agrees that the transactions are acceptable then they are from that point onwards committed to the ledger, and will be written through to the vault. Additionally they will be distributed to the parties reflected in the participants list of the states.
  IssuerFlow | This flow enables a client to request issuance of some `interface FungibleAsset` from a server acting as an issuer (see `class Issued`) of FungibleAssets.
  NonValidatingNotaryFlow |
  NotaryChangeFlow | A flow to be used for changing a state's Notary. This is required since all input states to a transaction must point to the same notary.
  NotaryError |
  NotaryFlow |
  ResolveTransactionsFlow | This flow is used to verify the validity of a transaction by recursively checking the validity of all the dependencies. Once a transaction is checked it's inserted into local storage so it can be relayed and won't be checked again.
  ServiceRequestMessageKt |
  TwoPartyDealFlow | Classes for manipulating a two party deal or agreement.
  TwoPartyTradeFlow | This asset trading flow implements a "delivery vs payment" type swap. It has two parties (B and S for buyer and seller) and the following steps:
  ValidatingNotaryFlow | A notary commit flow that makes sure a given transaction is valid before committing it. This does mean that the calling party has to reveal the whole transaction history; however, we avoid complex conflict resolution logic where a party has its input states "blocked" by a transaction from another party, and needs to establish whether that transaction was indeed valid.

- Exception Summary
  Exception | Description
  --- | ---
  CashException |
  NotaryException |
  StateReplacementException |