All Types

Initiates a flow that produces an Issue/Move or Exit Cash transaction.

Pluggable interface to allow for different cash selection provider implementations Default implementation in finance workflow module uses H2 database and a custom function within H2 to perform aggregation. Custom implementations must implement this interface and declare their implementation in META-INF/services/


An AbstractParty contains the common elements of Party and AnonymousParty, specifically the owning key of the party. In most cases Party or AnonymousParty should be used, depending on use-case.


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.


Models an initiator in Corda, can be a user, a service, etc.

A special base class for the set of all possible recipients, without having to identify who they all are.


An AttachmentConstraint where isSatisfiedBy always returns true.


Amount represents a positive quantity of some token (currency, asset, etc.), measured in quantity of the smallest representable units. The nominal quantity represented by each individual token is equal to the displayTokenSize. The scale property of the displayTokenSize should correctly reflect the displayed decimal places and is used when rounding conversions from indicative/displayed amounts in BigDecimal to Amount occur via the Amount.fromDecimal method.


This class represents a possibly negative transfer of tokens from one vault state to another, possibly at a future date.


The AnonymousParty class contains enough information to uniquely identify a Party while excluding private information such as name. It is intended to represent a party on the distributed ledger.

kotlin.Any (extensions in package net.corda.core.utilities)

A CordaService annotated class requires a constructor taking a single parameter of type AppServiceHub. With the AppServiceHub parameter a CordaService is able to access to privileged operations. In particular such a CordaService can initiate and track flows marked with net.corda.core.flows.StartableByService.


An attachment is a ZIP (or an optionally signed JAR) that contains one or more files. Attachments are meant to contain public static data which can be referenced from transactions and utilised from contracts. Good examples of how attachments are meant to be used include:


Constrain which contract-code-containing attachment can be used with a Contract.

The node asked a remote peer for the attachment identified by hash because it is a dependency of a transaction being resolved, but the remote peer would not provide it.


An attachment store records potentially large binary objects, identified by their hash.

Authentication / Authorisation Service ID.


Tagging a network parameter with this annotation signifies that any update which modifies the parameter could be accepted without the need for the node operator to run a manual accept command. If the update contains changes for any non-auto-acceptable parameter or the behaviour is switched off via configuration then it will not be auto-accepted


This AttachmentConstraint is a convenience class that acts as a placeholder and will be automatically resolved by the platform when set on an output state. It is the default constraint of all output states.

An abstract class defining fields shared by all transaction types in the system.


This annotation is required by any ContractState which needs to ensure that it is only ever processed as part of a TransactionState referencing the specified Contract. It may be omitted in the case that the ContractState class is defined as an inner class of its owning Contract class, in which case the "X belongs to Y" relationship is taken to be implicitly declared.
java.sql.Blob (extensions in package net.corda.core.serialization)
kotlin.ByteArray (extensions in package net.corda.core.crypto)
kotlin.ByteArray (extensions in package net.corda.core.serialization)
kotlin.ByteArray (extensions in package net.corda.core.utilities)

An abstraction of a byte array, with offset and size that does no copying of bytes unless asked to.

Initiates a flow that produces an cash exit transaction.

Initiates a flow that self-issues cash and then send this to a recipient.

Initiates a flow that self-issues cash (which should then be sent to recipient(s) using a payment transaction).

Initiates a flow that sends cash to a recipient.

An object used to fully qualify the CashSchema family name (i.e. independent of version).

Allows an implementing Throwable to be propagated to clients.


As an RPC Client, use this class to point to the truststore that contains the RPC SSL certificate provided by the node admin


Abstract class specifying information about the consensus algorithm used for a cluster of nodes.


Get and check the required signature.


The CollectSignaturesFlow is used to automate the collection of counterparty signatures for a given transaction.

kotlin.collections.Collection (extensions in package net.corda.core.contracts)
kotlin.collections.Collection (extensions in package net.corda.core.utilities)
kotlin.collections.Collection (extensions in package net.corda.testing.core)

Command data/content plus pubkey pair: the signature is stored at the end of the serialized bytes


Return structure for OwnableState.withNewOwner


Marker interface for classes that represent commands


A Command where the signing parties have been looked up if they have a well known/recognised institutional key.

JPA representation of the common schema entities


First version of the Vault ORM schema


A ComponentGroup is used to store the full list of transaction components of the same type in serialised form. Practically, a group per component type of a transaction is required; thus, there will be a group for input states, a group for all attachments (if there are any) etc.


An enum, for which each property corresponds to a transaction component group. The position in the enum class declaration (ordinal) is used for component-leaf ordering when computing the Merkle tree.


Thrown when checking for visibility of all-components in a group in FilteredTransaction.checkAllComponentsVisible.


A tree data structure that enables the representation of composite public keys, which are used to represent the signing requirements for multi-signature scenarios such as RAFT notary services. A composite key is a list of leaf keys and their contributing weight, and each leaf can be a conventional single key or a composite key. Keys contribute their weight to the total if they are matched by the signature.


Factory for generating composite keys from ASN.1 format key specifications. This is used by CordaSecurityProvider.


Dedicated class for storing a set of signatures that comprise CompositeKey.


Custom class for holding signature data. This exists for later extension work to provide a standardised cross-platform serialization format.


Signals that the underlying RPCConnection dropped.


Annotation indicating a constructor to be used to reconstruct instances of a class during deserialization.


Set of well known properties that may be set on a serialization context. This doesn't preclude others being set that aren't keyed on this enumeration, but for general use properties adding a well known key here is preferred.


Implemented by a program that implements business logic on the shared ledger. All participants run this code for every net.corda.core.transactions.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 time-window attached to the transaction itself i.e. it is NOT necessarily the current time.


An Attachment which represents a contract JAR.


A contract state (or just "state") contains opaque data used by a contract program. It can be thought of as a disk file that the program can use to persist data across transactions. States are immutable: once created they are never updated, instead, any changes must generate a new successor state. States can be updated (consumed) only once: the notary is responsible for ensuring there is no "double spending" by only signing a transaction if the input states are all free.


A filtered version of the ContractUpgradeWireTransaction. In comparison with a regular FilteredTransaction, there is no flexibility on what parts of the transaction to reveal – the inputs, notary and network parameters hash fields are always visible and the rest of the transaction is always hidden. Its only purpose is to hide transaction data when using a non-validating notary.


A flow to be used for authorising and upgrading state objects of an old contract to a new contract.


A contract upgrade transaction with fully resolved inputs and signatures. Contract upgrade transactions are separate to regular transactions because their validation logic is specialised; the original contract by definition cannot be aware of the upgraded contract (it was written after the original contract was developed), so its validation logic cannot succeed. Instead alternative verification logic is used which verifies that the outputs correspond to the inputs after upgrading.

The ContractUpgradeService is responsible for securely upgrading contract state objects according to a specified and mutually agreed (amongst participants) contract version. See also ContractUpgradeFlow to understand the workflow associated with contract upgrades.


A special transaction for upgrading the contract of a state.


Same as Future with additional methods to provide some of the features of java.util.concurrent.CompletableFuture while minimising the API surface area. In Kotlin, to avoid compile errors, whenever CordaFuture is used in a parameter or extension method receiver type, its type parameter should be specified with out variance.


These methods and annotations are not part of Corda's API compatibility guarantee and applications should not use them.


OIDs used for the Corda platform. All entries MUST be defined in this file only and they MUST NOT be removed. If an OID is incorrectly assigned, it should be marked deprecated and NEVER be reused again.


An RPC client connects to the specified server and allows you to make calls to the server that perform various useful tasks. Please see the Client RPC section of to learn more about how this API works. A brief description is provided here.


Can be used to configure the RPC client connection.


This class is essentially just a wrapper for an RPCConnection and can be treated identically.


RPC operations that the node exposes to clients.


This annotation is a marker to indicate that a class is permitted and intended to be serialized as part of Node messaging.


This annotation is used to mark an enumerated type as having had a new constant appended to it. For each additional constant added a new annotation should be appended to the class. If more than one is required the wrapper annotation CordaSerializationTransformEnumDefaults should be used to encapsulate them


This annotation is used to mark an enumerated type as having had multiple members added, It acts as a container annotation for instances of CordaSerializationTransformEnumDefault, each of which details individual additions.


This annotation is used to mark a class has having had a property element. It is used by the AMQP deserializer to allow instances with different versions of the class on their Class Path to successfully deserialize the object.


This annotation is used to mark a class as having had multiple elements renamed as a container annotation for instances of CordaSerializationTransformRename, each of which details an individual rename.

Annotate any class that needs to be a long-lived service within the node, such as an oracle, with this annotation. Such a class needs to have a constructor with a single parameter of type AppServiceHub. This constructor will be invoked during node start to initialise the service. The service hub provided can be used to get information about the node that may be necessary for the service. Corda services are created as singletons within the node and are available to flows via ServiceHub.cordaService.


X.500 distinguished name data type customised to how Corda uses names. This restricts the attributes to those Corda supports, and requires that organisation, locality and country attributes are specified. See also RFC 4519 for the underlying attribute type definitions


Represents a cordapp by registering the JAR that contains it and all important classes for Corda. Instances of this class are generated automatically at startup of a node and can get retrieved from CordappProvider.getAppContext from the CordappContext it returns.


Provides access to cordapp configuration independent of the configuration provider.


Thrown if an exception occurs in accessing or parsing cordapp configuration


An app context provides information about where an app was loaded from, access to its classloader, and (in the included Cordapp object) lists of annotated classes discovered via scanning the JAR.


Provides access to what the node knows about loaded applications.


A transaction with the minimal amount of information required to compute the unique transaction id, and resolve a FullTransaction. This type of transaction, wrapped in SignedTransaction, gets transferred across the wire and recorded to storage.

This object controls and provides the available and supported signature schemes for Corda. Any implemented SignatureScheme should be strictly defined here. However, only the schemes returned by {@link #listSupportedSignatureSchemes()} are supported. Note that Corda currently supports the following signature schemes by their code names:

java.util.Currency (extensions in package

The Data feed contains a snapshot of the requested data and an Observable of future updates.


Declare the annotated element to unsuitable for the deterministic version of Corda.


This annotation is a marker to indicate which secondary constructors should be considered, and in which order, for evolving objects during their deserialization.


A wrapper around a digital signature.


Marker interface to denote a persistable Corda state entity that exposes the transaction id and index as composite key called stateRef.


This annotation is for interfaces and abstract classes that provide Corda functionality to user applications. Future versions of Corda may add new methods to such interfaces and classes, but will not remove or modify existing methods.

kotlin.Double (extensions in package

Underlying interface for the driver DSL. Do not instantiate directly, instead use the driver function.


Builder for configuring a driver.


Trivial implementation of TypeOnlyCommandData for test purposes


Dummy contract for testing purposes. Doesn't do anything useful.


Dummy contract state for testing of the upgrade process.


Dummy contract state for testing of the upgrade process.


Dummy state for use in testing. Not part of any contract, not even the DummyContract.


If you jumped here from a compiler error make sure the last line of your test tests for a transaction verify or fail. This is a dummy type that can only be instantiated by functions in this module. This way we can ensure that all tests will have as the last line either an accept or a failure test. The name is deliberately long to help make sense of the triggered diagnostic.

SQL Server / SQL Azure

Part of the Expectation DSL

Contains information about a field from an entity class. Used as part of query criteria construction through Builder, produced by function getField. The constructor should not be invoked manually.


A FilteredComponentGroup is used to store the filtered list of transaction components of the same type in serialised form. This is similar to ComponentGroup, but it also includes the corresponding nonce per component.


Class representing merkleized filtered transaction.


Thrown when FilteredTransaction.verify fails.


Verifies the given transaction, then sends it to the named notary. If the notary agrees that the transaction is acceptable then it is from that point onwards committed to the ledger, and will be written through to the vault. Additionally it will be distributed to the parties reflected in the participants list of the states.


Exception which can be thrown by a FlowLogic at any point in its logic to unexpectedly bring it to a permanent end. The exception will propagate to all counterparty flows and will be thrown on their end the next time they wait on a FlowSession.receive or FlowSession.sendAndReceive. Any flow which no longer needs to do a receive, or has already ended, will not receive the exception (if this is required then have them wait for a confirmation message).


FlowHandle is a serialisable handle for the started flow, parameterised by the type of the flow's return value.


Version and name of the CorDapp hosting the other side of the flow.


An alias for StateMachineInfo which uses more modern terminology.


Please note that FlowInitiator has been superceded by net.corda.core.context.InvocationContext, which offers more detail for the same event.


A sub-class of FlowLogic implements a flow using direct, straight line blocking code. Thus you can write complex flow logic in an ordinary fashion, without having to think about callbacks, restarting after a node crash, how many instances of your flow there are running and so on.


A handle interface representing a FlowLogic instance which would be possible to safely pass out of the contract sandbox. Use FlowLogicRefFactory to construct a concrete security checked instance.


The public factory interface for creating validated FlowLogicRef instances as part of the scheduling framework.


FlowProgressHandle is a serialisable handle for the started flow, parameterised by the type of the flow's return value.


A FlowSession is a handle on a communication sequence between two paired flows, possibly running on separate nodes. It is used to send and receive messages between the flows as well as to query information about the counter-flow.


Main data object representing snapshot of the flow stack, extracted from the Quasar stack.


A transaction with fully resolved components, such as input states.


Interface for contract states representing assets which are fungible, countable and issued by a specific party. States contain assets which are equivalent (such as cash of the same currency), so records of their existence can be merged or split as needed where the issuer is the same. For instance, dollars issued by the Fed are fungible and countable (in cents), barrels of West Texas crude are fungible and countable (oil from two small containers can be poured into one large container), shares of the same class in a specific company are fungible and countable, and so on.


Interface to represent things which are fungible, this means that there is an expectation that these things can be split and merged. That's the only assumption made by this interface.

java.util.concurrent.Future (extensions in package net.corda.core.concurrent)
java.util.concurrent.Future (extensions in package net.corda.core.utilities)

An AttachmentConstraint that verifies by hash. The state protected by this constraint can only be used in a transaction created with that version of the jar. And a receiving node will only accept it if a cordapp with that hash has (is) been deployed on the node.


A small set of utilities for making HttpCalls, aimed at demos and tests.

Represents a unique, timestamped id.

An identity service maintains a directory of parties by their associated distinguished name/public keys and thus supports lookup of a party given its key, or name. The service also manages the certificates linking confidential identities back to the well known identity.


Thrown if the structure of a class implementing a flow is not correct. There can be several causes for this such as not inheriting from FlowLogic, not having a valid constructor and so on.


An in-memory network allows you to manufacture MockNodeMessagingServices for a set of participants. Each MockNodeMessagingService maintains a queue of messages it has received, and a background thread that dispatches messages one by one to registered handlers. Alternatively, a messaging system may be manually pumped, in which case no thread is created and a caller is expected to force delivery one at a time (this is useful for unit testing).


Interface which represents an in process node and exposes available services.


Marker interface to denote a persistable Corda state entity that exposes the transaction id and index as a nested composite key called compositeKey that is itself a DirectStatePersistable. i.e. exposes a stateRef.


This annotation is required by any FlowLogic that is designed to be initiated by a counterparty flow. The class must have at least a constructor which takes in a single net.corda.core.identity.Party parameter which represents the initiating counterparty. The FlowLogic that does the initiating is specified by the value property and itself must be annotated with InitiatingFlow.


This annotation is required by any FlowLogic which has been designated to initiate communication with a counterparty and request they start their side of the flow communication.


Thrown if a request is made to spend an amount of a FungibleAsset but there aren't enough tokens in the vault.

kotlin.Int (extensions in package net.corda.core.utilities)
kotlin.Int (extensions in package

Models the information needed to trace an invocation in Corda. Includes initiating actor, origin, trace information, and optional external trace information to correlate clients' IDs.


Represents the source of an action such as a flow start, an RPC, a shell command etc.


The Issued data class holds the details of an on ledger digital asset. In particular it gives the public credentials of the entity that created these digital tokens and the particular product represented.

kotlin.collections.Iterable (extensions in package net.corda.core.contracts)
kotlin.collections.Iterable (extensions in package net.corda.core.crypto)
kotlin.collections.Iterable (extensions in package net.corda.testing.core)

Utilities and serialisers for working with JSON representations of basic types. This adds Jackson support for the java.time API, some core types, and Kotlin data classes.


A class containing configuration information for Jolokia JMX, to be used when creating a node via the driver.


This annotates a class or file that we want to include into the deterministic version of Corda Core. We don't expect everything within that class/file to be deterministic; those non-deterministic elements need to be annotated with either DeleteForDJVM or StubOutForDJVM so that they can be deleted.

The KMS is responsible for storing and using private keys to sign things. An implementation of this may, for example, call out to a hardware security module that enforces various auditing and frequency-of-use requirements. (extensions in package net.corda.core.crypto)

This is the class that defines the syntactic sugar of the ledger Test DSL and delegates to the contained interpreter, and what is actually used in ledger { (...) }. Add convenience functions here, or if you want to extend the DSL functionality then first add your primitive to LedgerDSLInterpreter and then add the convenience defaults/extension methods here.


This interface defines the bare bone functionality that a Ledger DSL interpreter should implement.


A LedgerTransaction is derived from a WireTransaction. It is the result of doing the following operations:


The annotated Contract implements the legal prose identified by the given URI.

LinearPointer allows a ContractState to "point" to another LinearState creating a "many-to-one" relationship between all the states containing the pointer to a particular LinearState and the LinearState being pointed to. Using the LinearPointer is useful when one state depends on the data contained within another state that evolves independently. When using LinearPointer it is worth noting:


A state that evolves by superseding itself, all of which share the common "linearId".

org.slf4j.Logger (extensions in package net.corda.core.utilities)
kotlin.Long (extensions in package net.corda.core.utilities)
kotlin.Long (extensions in package

A database schema that might be configured for this node. As well as a name and version for identifying the schema, also list the classes that may be used in the generated object graph in order to configure the ORM tool.


Creation and verification of a Merkle tree for a WireTransaction.


A base class for a set of recipients specifically identified by the sender.


The interface for a group of message recipients (which may contain only one recipient)


Thrown during deserialization to indicate that an attachment needed to construct the WireTransaction is not found.


A contract attachment was missing when trying to automatically attach all known contract attachments

A mock implementation of AttachmentStorage for use within tests


MockNetFlowTimeOut can be used to configure flow time out settings for a node via the mock network API.


MockNetNotaryConfig can be used to configure a node to be a notary via the mock network API. Internally this will be translated into a NotaryConfiguration and passed to the respective node.


A mock node brings up a suite of in-memory services in a fast manner suitable for unit testing. Components that do IO are either swapped out for mocks, or pointed to a Jimfs in memory filesystem or an in memory H2 database instance.


The spec for a notary which will used by the MockNetwork to automatically start a notary node. This notary will become part of the network parameters used by all the nodes.


Immutable builder for configuring a MockNetwork.


This is a data class to configure overrides to the node configuration used in the mock network without having to expose/use the actual (internal) node configuration interface on the API. When passing one of these to createNode or createUnstartedNode functions, the bits that are set will be injected into the node configuration for the node to be created.


Immutable builder for configuring a StartedMockNode or an UnstartedMockNode via MockNetwork.createNode and MockNetwork.createUnstartedNode. Kotlin users can also use the named parameters overloads of those methods which are more convenient.


An implementation of ServiceHub that is designed for in-memory unit tests of contract validation logic. It has enough functionality to do tests of code that queries the vault, inserts to the vault, and constructs/checks transactions. However it isn't enough to test flows and other aspects of an app that require a network. For that you should investigate MockNetwork.


A common move command for contract states which can change owner.


Implemented by anything that can be named by a secure hash value (e.g. transactions, attachments).


Tuple of host and port. Use NetworkHostAndPort.parse on untrusted data.

A network map contains lists of nodes on the network along with information about their identity keys, services they provide and host names or IP addresses where they can be connected to. The cache wraps around a map fetched from an authoritative service, and adds easy lookup of the data stored within it. Generally it would be initialised with a specified network map service, which it fetches data from and then subscribes to updates of.

Subset of NetworkMapCache that doesn't depend on an IdentityService.


Network parameters are a set of values that every node participating in the zone needs to agree on and use to correctly interoperate with each other.


Wrapper over SecureHash to be used when filtering network parameters hash.

Service for retrieving network parameters used for resolving transactions according to parameters that were historically in force in the network.


This annotation should only be added to Contract classes. If the annotation is present, then we assume that Contract.verify will ensure that the output states have an acceptable constraint. If the annotation is missing, then the default - secure - constraint propagation logic is enforced by the platform.


A base interface which represents a node as part of the driver dsl, extended by InProcess and OutOfProcess


Information about a network node that acts on behalf of some party. NodeInfos can be found via the network map cache, accessible from a They are also available via RPC using the net.corda.core.messaging.CordaRPCOps.networkMapSnapshot method.


Parameters for creating a node for DriverDSL.startNode.


An immutable ordered non-empty set.


Container for the transaction and notarisation request signature. This is the payload that gets sent by a client to a notary service for committing the input states of the transaction.


A notarisation request specifies a list of states to consume and the id of the consuming transaction. Its primary purpose is for notarisation traceability – a signature over the notarisation request, NotarisationRequestSignature, allows a notary to prove that a certain party requested the consumption of a particular state.


A wrapper around a digital signature used for notarisation requests.


Payload returned by the notary service flow to the client.


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.


A notary change transaction with fully resolved inputs and signatures. In contrast with a regular transaction, signatures are checked against the signers specified by input states' participants fields, so full resolution is needed for signature verification.


A special transaction for changing the notary of a state. It only needs specifying the state(s) as input(s), old and new notaries. Output states can be computed by applying the notary modification to corresponding inputs on the fly.


Specifies the cause for notarisation request failure.


Exception thrown by the notary service if any issues are encountered while trying to commit a transaction. The underlying error specifies the cause of failure.


Object ecapsulating a notary started automatically by the driver.


Data class storing information about notaries available in the network.


A notary spec for describing a notary which will be started automatically by the driver and which will be part of the network parameters used by all the nodes.

rx.Observable (extensions in package net.corda.client.rpc)
rx.Observable (extensions in package net.corda.core)
rx.Observable (extensions in package net.corda.testing.core)

A simple class that wraps a byte array and makes the equals/hashCode/toString methods work as you actually expect. In an ideal JVM this would be a value type and be completely overhead free. Project Valhalla is adding such functionality to Java, but it won't arrive for a few years yet!


Class is public for serialization purposes.

Interface which represents an out of process node and exposes its process handle.


This interface defines output state lookup by label. It is split from the interpreter interfaces so that outputs may be looked up both in ledger{..} and transaction{..} blocks.


A contract state that can have a single owner.

PageSpecification allows specification of a page number (starting from DEFAULT_PAGE_NUM) and page size (defaulting to DEFAULT_PAGE_SIZE with a maximum page size of MAX_PAGE_SIZE) Note: we default the page number to DEFAULT_PAGE_SIZE to enable queries without requiring a page specification but enabling detection of large results sets that fall out of the DEFAULT_PAGE_SIZE requirement. MAX_PAGE_SIZE should be used with extreme caution as results may exceed your JVM memory footprint.


Data class containing information about the scheduled network parameters update. The info is emitted every time node receives network map with ParametersUpdate which wasn't seen before. For more information see: CordaRPCOps.networkParametersFeed and CordaRPCOps.acceptNewNetworkParameters.


Building and verification of Partial Merkle Tree. Partial Merkle Tree is a minimal tree needed to check that a given set of leaves belongs to a full Merkle Tree.


The Party class represents an entity on the network, which is typically identified by a legal name and public key that it can sign transactions under. As parties may use multiple keys for signing and, for example, have offline backup keys, the "public key" of a party can be represented by a composite construct – a CompositeKey, which combines multiple cryptographic public key primitives into a tree structure.


A full party plus the X.509 certificate and path linking the party back to a trust root. Equality of PartyAndCertificate instances is based on the party only, as certificate and path are data associated with the party, not part of the identifier themselves.


Reference to something being stored or issued by a party e.g. in a vault or (more likely) on their normal ledger. The reference is intended to be encrypted so it's meaningless to anyone other than the party.

Holds information about a Party, which may refer to either a specific node or a service.


Thrown to indicate that the calling user does not have permission for something they have requested (for example calling a method).


A super class for all mapped states exported to a schema that ensures the StateRef appears on the database row. The StateRef will be set to the correct value by the framework (there's no need to set during mapping generation by the state itself).


Embedded StateRef representation used in state mapping.


An abstract helper class which is used within the driver to allocate unused ports for testing.


A privacy salt is required to compute nonces per transaction component in order to ensure that an adversary cannot use brute force techniques and reveal the content of a Merkle-leaf hashed value. Because this salt serves the role of the seed to compute nonces, its size and entropy should be equal to the underlying hash function used for Merkle tree generation, currently SecureHash.SHA256, which has an output of 32 bytes. There are two constructors, one that generates a new 32-bytes random salt, and another that takes a ByteArray input. The latter is required in cases where the salt value needs to be pre-generated (agreed between transacting parties), but it is highlighted that one should always ensure it has sufficient entropy. (extensions in package net.corda.core.crypto)

A progress tracker helps surface information about the progress of an operation to a user interface or API of some kind. It lets you define a set of steps that represent an operation. A step is represented by an object (typically a singleton).


Simple interface encapsulating the implicit Kotlin contract for immutable property delegates. (extensions in package net.corda.core.crypto) (extensions in package net.corda.core.utilities)

Indexing assumptions: QueryCriteria assumes underlying schema tables are correctly indexed for performance.


A contract state that may be mapped to database schemas configured for this node to support querying for, or filtering of, states.


Holds a proxy object implementing I that forwards requests to the RPC server. The server version can be queried via this interface.


Thrown to indicate a fatal error in the RPC system itself, as opposed to an error generated by the invoked method.


Base interface that all RPC servers must implement. Note: in Corda there's only one RPC interface. This base interface is here in case we split the RPC system out into a separate library one day.


If an RPC is tagged with this annotation it may return one or more observables anywhere in its response graph. Calling such a method comes with consequences: it's slower, and consumes server side resources as observations will buffer up on the server until they're consumed by the client.


Records the protocol version in which this RPC was added.


The receiving counterpart to FinalityFlow.


The ReceiveStateAndRefFlow should be called in response to the SendStateAndRefFlow.


The ReceiveTransactionFlow should be called in response to the SendTransactionFlow.


Wrapper over StateRef to be used when filtering reference states.


A wrapper for a StateAndRef indicating that it should be added to a transaction as a reference input state.


Defines a simple domain specific language for the specification of financial contracts. Currently covers:

First version of a cash contract ORM schema that maps all fields of the Cash contract state as it stood at the time of writing.

Second version of a cash contract ORM schema that extends the CommonSchemaV1.FungibleState abstract schema.

First version of a cash contract ORM schema that maps all fields of the Cash contract state as it stood at the time of writing.


Any FlowLogic which is schedulable and is designed to be invoked by a net.corda.core.contracts.SchedulableState must have this annotation. If it's missing FlowLogicRefFactory.create will throw an exception when it comes time to schedule the next activity in net.corda.core.contracts.SchedulableState.nextScheduledActivity.


Something which is scheduled to happen at a point in time.


This class represents the lifecycle activity that a contract state of type LinearState would like to perform at a given point in time. e.g. run a fixing flow.


Represents a contract state (unconsumed output) of type LinearState and a point in time that a lifecycle event is expected to take place for that contract state.


Container for a cryptographically secure hash value. Provides utilities for generating a cryptographic hash using different algorithms (currently only SHA-256 supported).


The SendStateAndRefFlow should be used to send a list of input StateAndRef to another peer that wishes to verify the input's integrity by resolving and checking the dependencies as well. The other side should invoke ReceiveStateAndRefFlow at the right point in the conversation to receive the input state and ref and perform the resolution back-and-forth required to check the dependencies.


The SendTransactionFlow should be used to send a transaction to another peer that wishes to verify that transaction's integrity by resolving and checking the dependencies as well. The other side should invoke ReceiveTransactionFlow at the right point in the conversation to receive the sent transaction and perform the resolution back-and-forth required to check the dependencies and download any missing attachments.


Used to annotate methods which expose calculated values that we want to be serialized for use by the class carpenter.


Parameters to serialization and deserialization.


Allows CorDapps to provide custom serializers for third party libraries where those libraries cannot be recompiled with the -parameters flag rendering their classes natively serializable by Corda. In this case a proxy serializer can be written that extends this type whose purpose is to move between those an unserializable types and an intermediate representation.


Global singletons to be used as defaults that are injected elsewhere (generally, in the node or in RPC client).


A test serialization rule implementation for use in tests


An abstraction for serializing and deserializing objects, with support for versioning of the wire format via a header / prefix in the bytes.


This represents a token in the serialized stream for an instance of a type that implements SerializeAsToken.


Provide a subclass of this via the java.util.ServiceLoader mechanism to be able to whitelist types for serialisation that you cannot otherwise annotate. The name of the class must appear in a text file on the classpath under the path META-INF/services/net.corda.core.serialization.SerializationWhitelist


This interface should be implemented by classes that want to substitute a token representation of themselves if they are serialized because they have a lot of internal state that does not serialize (well).


A context for mapping SerializationTokens to/from SerializeAsTokens.


A type safe wrapper around a byte array that contains a serialised object. You can call SerializedBytes.deserialize to get the original object back.


A service hub is the starting point for most operations you can do inside the node. You are provided with one when a class annotated with CordaService is constructed, and you have access to one inside flows. Most RPCs simply forward to the services found here after some access checking.


Subset of node services that are used for loading transactions from the wire into fully resolved, looked up forms ready for verification.


The SignTransactionFlow should be called in response to the CollectSignaturesFlow. It automates the signing of a transaction providing the transaction:


A SignableData object is the packet actually signed. It works as a wrapper over transaction id and signature metadata. Note that when multi-transaction signing (signing a block of transactions) is used, the root of the Merkle tree (having transaction IDs as leaves) is actually signed and thus txId refers to this root and not a specific transaction.


An AttachmentConstraint that verifies that the attachment has signers that fulfil the provided PublicKey. See: Signature Constraints


SignatureMeta is required to add extra meta-data to a transaction's signature. It currently supports platformVersion only, but it can be extended to support a universal digital signature model enabling partial signatures and attaching extra information, such as a user's timestamp or other application-specific fields.


This class is used to define a digital signature scheme.


A serialized piece of data and its signature. Enforces signature validity in order to deserialize the data contained within.


SignedTransaction wraps a serialized WireTransaction. It contains one or more signatures, each one for a public key (including composite keys) that is mentioned inside a transaction command. SignedTransaction is the top level transaction type and the type most frequently passed around the network and stored. The identity of a transaction is the hash of Merkle root of a WireTransaction, therefore if you are storing data keyed by WT hash be aware that multiple different STs may map to the same key (and they could be different in important ways, like validity!). The signatures on a SignedTransaction might be invalid or missing: the type does not imply validity. A transaction ID should be the hash of the WireTransaction Merkle tree root. Thus adding or removing a signature does not change it.


A base class for the case of point-to-point messages


A class representing a SerializationToken for some object that is not serializable but can be looked up (when deserialized) via just the class name.


A base class for implementing large objects / components / services that need to serialize themselves to a string token to indicate which instance the token is a serialized form of.

Sort allows specification of a set of entity attribute names and their associated directionality and null handling, to be applied upon processing a query specification.

Simple data class to associate the origin, owner, or holder of a particular Amount object.


Token class, used to indicate stack presence of the corda internal data. Since this data is of no use for a CordApp developer, it is skipped from serialisation and its presence is only marked by this token.


Any FlowLogic which is to be started by the RPC interface (net.corda.core.messaging.CordaRPCOps.startFlowDynamic and net.corda.core.messaging.CordaRPCOps.startTrackedFlowDynamic) must have this annotation. If it's missing the flow will not be allowed to start and an exception will be thrown.


Any FlowLogic which is to be started by the AppServiceHub interface from within a CordaService must have this annotation. If it's missing the flow will not be allowed to start and an exception will be thrown.


A class that represents a started mock node for testing.


A convenience class for passing around a state and it's contract


A StateAndRef is simply a (state, ref) pair. For instance, a vault (which holds available assets) contains these.


Contains information about the consuming transaction for a particular state.


Represents information about a flow (the name "state machine" is legacy, Kotlin users can use the FlowInfo type alias). You can access progress tracking, information about why the flow was started and so on.


A unique identifier for a single state machine run, valid across node restarts. Note that a single run always has at least one flow, but that flow may also invoke sub-flows: they all share the same run id.


Marker interface to denote a persistable Corda state entity that will always have a transaction id and index


A StatePointer contains a pointer to a ContractState. The StatePointer can be included in a ContractState or included in an off-ledger data structure. StatePointers can be resolved to a StateAndRef by performing a vault query. There are two types of pointers; linear and static. LinearPointers are for use with LinearStates. StaticPointers are for use with any type of ContractState.


A stateref is a pointer (reference) to a state, this is an equivalent of an "outpoint" in Bitcoin. It records which transaction defined the state and where in that transaction it was.


Controls whether the transaction is sent to the vault at all, and if so whether states have to be relevant or not in order to be recorded. Used in ServiceHub.recordTransactions


A StaticPointer contains a pointer to a specific StateRef and can be resolved by looking up the StateRef via ServiceHub. There are a number of things to keep in mind when using StaticPointers:

kotlin.String (extensions in package net.corda.core.utilities)

This class parses strings in a format designed for human usability into ParsedMethodCall objects representing a ready-to-invoke call on the given target object. The strings accepted by this class are a minor variant of Yaml and can be easily typed at a command line. Intended use cases include things like the Corda shell, text-based RPC dispatch, simple scripting and so on.


We expect that almost every non-deterministic element can have its bytecode deleted entirely from the deterministic version of Corda. This annotation is for those (hopefully!) few occasions where the non-deterministic function cannot be deleted. In these cases, the function will be stubbed out instead.


A Clock that can have the time advanced for use in testing.


Encapsulates a CorDapp that exists on the current classpath, which can be pulled in for testing. Use TestCordapp.findCordapp to locate an existing CorDapp.


A class that encapsulates a test identity containing a CordaX500Name and a KeyPair, alongside a range of utility methods for use during testing.


This interpreter builds a transaction, and TransactionDSL.verifies that the resolved transaction is correct. Note that transactions corresponding to input states are not verified. Use LedgerDSL.verifies for that.


An interval on the time-line; not a single instantaneous point.

Checks if the current instant provided by the input clock falls within the provided time-window.


This interface is used by Amount to determine the conversion ratio from indicative/displayed asset amounts in BigDecimal to fungible tokens represented by Amount objects.


Contextual tracing information, including invocation and session id.


A TransactionBuilder is a transaction class that's mutable (unlike the others which are all immutable). It is intended to be passed around contracts that may edit it by adding new states/commands. Then once the states and commands are right, this class can be used as a holding bucket to gather signatures from multiple parties.


Underlying class for the transaction DSL. Do not instantiate directly, instead use the transaction function.


This interface defines the bare bone functionality that a Transaction DSL interpreter should implement.


The node asked a remote peer for the transaction identified by hash because it is a dependency of a transaction being resolved, but the remote peer would not provide it.


A wrapper over the signature output accompanied by signer's public key and signature metadata. This is similar to DigitalSignature.WithKey, but targeted to DLT transaction (or block of transactions) signatures.


A wrapper for ContractState containing additional platform-level state information and contract information. This is the definitive state that is stored on the ledger and used in transaction outputs.

Thread-safe storage of transactions.


Indicates that some aspect of the transaction named by txId violates the platform rules. The exact type of failure is expressed using a subclass. TransactionVerificationException is a FlowException and thus when thrown inside a flow, the details of the failure will be serialised, propagated to the peer and rethrown.


An interface for transactions containing signatures, with logic for signature verification.


Implemented by WireTransaction and FilteredTransaction. A TraversableTransaction allows you to iterate over the flattened components of the underlying transaction structure, taking into account that some may be missing in the case of this representing a "torn" transaction. Please see the user guide section "Transaction tear-offs" to learn more about this feature.


Representation of an operation that has either succeeded with a result (represented by Success) or failed with an exception (represented by Failure).

Classes for manipulating a two party deal or agreement.

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:


Commands that inherit from this are intended to have no data items: it's only their presence that matters.


Thrown when a flow session ends unexpectedly due to a type mismatch (the other side sent an object of a type that we were not expecting), or the other side had an internal error, or the other side terminated when we were waiting for a response.


This class provides a truly unique identifier of a trade, state, or other business object, bound to any existing external ID. Equality and comparison are based on the unique ID only; if two states somehow have the same UUID but different external IDs, it would indicate a problem with handling of IDs.

A class that represents an unstarted mock node for testing.


A small utility to approximate taint tracking: if a method gives you back one of these, it means the data came from a remote source that may be incentivised to pass us junk that violates basic assumptions and thus must be checked first. The wrapper helps you to avoid forgetting this vital step. Things you might want to check are:


Interface which can upgrade state objects issued by a contract to a new state object issued by a different contract. The upgraded contract should specify the legacy contract class name, and provide an upgrade function that will convert legacy contract states into states defined by this contract.


This interface allows specifying a custom legacy contract constraint for upgraded contracts. The default for UpgradedContract is WhitelistedByZoneAttachmentConstraint.


Object encapsulating a node rpc user and their associated permissions for use when testing using the driver


Simple interface encapsulating the implicit Kotlin contract for mutable property delegates.

A vault (name may be temporary) wraps a set of states that are useful for us to keep track of, for instance, because we own them. This class represents an immutable, stable state of a vault: it is guaranteed not to change out from underneath you, even though the canonical currently-best-known vault may change as we learn about new transactions from our peers and generate new transactions that consume states ourselves.

A VaultService is responsible for securely and safely persisting the current state of a vault to storage. The vault service vends immutable snapshots of the current vault for working with: if you build a transaction based on a vault that isn't current, be aware that it may end up being invalid if the states that were used have been consumed by someone else first!


This interface asserts that the DSL at hand is capable of verifying its underlying construct(ledger/transaction).


Sent by the notary when the notary detects it will unlikely respond before the client retries.


Class which represents a handle to a webserver process and its NetworkHostAndPort for testing purposes.


An AttachmentConstraint that verifies that the hash of the attachment is in the network parameters whitelist. See: net.corda.core.node.NetworkParameters.whitelistedContractImplementations It allows for centralized control over the cordapps that can be used.


A transaction ready for serialisation, without any signatures attached. A WireTransaction is usually wrapped by a SignedTransaction that carries the signatures over this payload. The identity of the transaction is the Merkle tree root of its components (see MerkleTree).


Given a flow which uses reference states, the WithReferencedStatesFlow will execute the flow as a subFlow. If the flow fails due to a NotaryError.Conflict for a reference state, then WithReferencedStatesFlow will be suspended until the state refs for the reference states are consumed. In this case, a consumption means that:


When a Corda feature cannot be used due to the node's compatibility zone not enforcing a high enough minimum platform version.