net.corda.flows

## Class NonValidatingNotaryFlow

- FlowLogic
- - Service
  - - net.corda.flows.NonValidatingNotaryFlow

-     public class NonValidatingNotaryFlow
      extends Service

- - ### Nested Class Summary

    - ### Nested classes/interfaces inherited from class net.corda.flows.NotaryFlow.Service

      `Service.TransactionParts`

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `NonValidatingNotaryFlow(Party otherSide, TimestampChecker timestampChecker, UniquenessProvider uniquenessProvider)`

  - ### Method Summary

    All Methods Instance Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `Service.TransactionParts` | `receiveAndVerifyTx()` The received transaction is not checked for contract-validity, as that would require fully resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction history chain. As a result, the Notary will commit invalid transactions as well, but as it also records the identity of the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently undo the commit of the input states (the exact mechanism still needs to be worked out).

    - ### Methods inherited from class net.corda.flows.NotaryFlow.Service

      `call, getOtherSide, getTimestampChecker, getUniquenessProvider, receiveAndVerifyTx`

    - ### Methods inherited from class net.corda.core.flows.FlowLogic

      `call, getCounterpartyMarker, getLogger, getProgressTracker, getRunId, getServiceHub, getStateMachine, receive, send, sendAndReceive, setStateMachine, subFlow, subFlow, track, waitForLedgerCommit`

- - ### Constructor Detail

    - #### NonValidatingNotaryFlow

          public NonValidatingNotaryFlow(Party otherSide,
                                         TimestampChecker timestampChecker,
                                         UniquenessProvider uniquenessProvider)

  - ### Method Detail

    - #### receiveAndVerifyTx

          public Service.TransactionParts receiveAndVerifyTx()

      The received transaction is not checked for contract-validity, as that would require fully resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction history chain. As a result, the Notary will commit invalid transactions as well, but as it also records the identity of the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently undo the commit of the input states (the exact mechanism still needs to be worked out).

      See Also:
        TransactionForVerification