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/net.corda.finance.workflows.asset.selection.AbstractCashSelection.
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.
Simple enum for returning accurals adjusted or unadjusted.
We don't actually do anything with this yet though, so it's ignored for now.
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.
(extensions in package net.corda.core.utilities)
A net.corda.core.node.services.CordaService annotated class requires a constructor taking a
single parameter of type AppServiceHub.
With the AppServiceHub parameter a net.corda.core.node.services.CordaService is able to access to privileged operations.
In particular such a net.corda.core.node.services.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.
Subset of state, containing the elements which must match for two obligation transactions to be nettable.
If two obligation state objects produce equal bilateral net states, they are considered safe to net directly.
Bilateral states are used in close-out netting.
Interface for state objects that support being netted with other state objects.
(extensions in package net.corda.core.serialization)
A non-specific exception for the attachment identified by attachmentId. The context
for this error is provided via the message and cause.
A business calendar performs date calculations that take into account national holidays and weekends. This is a
typical feature of financial contracts, in which a business may not want a payment event to fall on a day when
no staff are around to handle problems.
(extensions in package net.corda.core.crypto)
(extensions in package net.corda.core.serialization)
(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.
A cash transaction may split and merge money 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 couldn't merge outputs of two colours together, but you COULD put them in
the same transaction.
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).
An object used to fully qualify the CashSchema family name (i.e. independent of version).
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.
Allows CorDapps to provide custom serializers for classes that do not serialize successfully during a checkpoint.
In this case, a proxy serializer can be written that implements this interface whose purpose is to move between
unserializable types and an intermediate representation.
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.
(extensions in package net.corda.core.contracts)
(extensions in package net.corda.core.utilities)
Get and check the required signature.
The CollectSignaturesFlow is used to automate the collection of counterparty signatures for a given transaction.
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.
An object used to fully qualify the CommercialPaperSchema family name (i.e. independent of version).
First version of a commercial paper contract ORM schema that maps all fields of the CommercialPaper contract state
as it stood at the time of writing.
Class representing a commodity, as an equivalent to the Currency class. This exists purely to enable the
CommodityContract contract, and is likely to change in future.
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.
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.
A CordappInfo describes a single CorDapp currently installed on the node
Provides access to what the node knows about loaded applications.
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 docs.corda.net 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<CordaRPCOps> 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.
Please see ServiceLifecycleEvent.STATE_MACHINE_STARTED for the purpose of this exception.
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
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.
Thrown when a flow start command died before receiving a net.corda.core.messaging.FlowHandle.
On catching this exception, the typical behaviour is to run a "logical retry", meaning only retry the flow if the expected outcome did not occur.
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:
(extensions in package net.corda.finance)
The Data feed contains a snapshot of the requested data and an Observable of future updates.
This reflects what happens if a date on which a business event is supposed to happen actually falls upon a non-working day.
Depending on the accounting requirement, we can move forward until we get to a business day, or backwards.
There are some additional rules which are explained in the individual cases below.
This is utilised in the DateRollConvention class to determine which way we should initially step when
finding a business day.
This forms the day part of the "Day Count Basis" used for interest calculation.
Note that the first character cannot be a number (enum naming constraints), so we drop that
in the toString lest some people get confused.
This forms the year part of the "Day Count Basis" used for interest calculation.
Interface representing an agreement that exposes various attributes that are common. Implementing it simplifies
implementation of general flows that manipulate many agreement types.
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.
An abstraction for flow session destinations. A flow can send to and receive from objects which implement this interface. The specifics
of how the messages are routed depend on the implementation.
A DiagnosticsService provides APIs that allow CorDapps to query information about the node that CorDapp is currently running on.
Interface for injecting custom digest implementation bypassing JCA.
The DigestService class is a service that offers the main crypto methods for calculating transaction hashes and
building Merkle trees. The default instance is passed by default to instances of classes like TransactionBuilder
and as a parameter to MerkleTree.getMerkleTree(...) method. In future the default instance can be parametrized
to initialize with the network default hash algorithm or just a more secure algorithm (e.g. SHA3_256). While the
SHA2_256 is vulnerable to pre-image attacks, the computeNonce and componentHash methods behaviour is defined by
the hashTwiceNonce and hashTwiceComponent; with SHA2_256 they both must be set to true to ensure pre-image attack
won't work (and for backward compatibility), but for other algorithms like SHA3_256 that are not affected, they
can and should be set to false as hashing twice would not improve security but affect performance.
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.
(extensions in package net.corda.finance)
Underlying interface for the driver DSL. Do not instantiate directly, instead use the driver function.
Builder for configuring a driver.
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.
Represents a textual expression of e.g. a formula
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.
A Fix represents a named interest rate, on a given day, for a given duration. It can be embedded in a tx.
Interface adding fixing specific methods.
A FixOf identifies the question side of a fix: what day, tenor and type of fix ("LIBOR", "EURIBOR" etc)
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).
FlowExternalAsyncOperation represents an external future that blocks a flow from continuing until the future returned by
FlowExternalAsyncOperation.execute has completed. Examples of external processes where FlowExternalAsyncOperation would be useful
include, triggering a long running process on an external system or retrieving information from a service that might be down.
FlowExternalOperation represents an external process that blocks a flow from continuing until the result of execute
has been retrieved. Examples of external processes where FlowExternalOperation would be useful include, triggering a long running
process on an external system or retrieving information from a service that might be down.
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.
RPC operations to perform operations related to flows including management of associated persistent states like checkpoints.
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.
Frequency at which an event occurs - the enumerator also casts to an integer specifying the number of times per year
that would divide into (eg annually = 1, semiannual = 2, monthly = 12 etc).
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.
(extensions in package net.corda.core.concurrent)
(extensions in package net.corda.core.utilities)
GracefulReconnect provides the opportunity to perform certain logic when the RPC encounters a connection disconnect
during communication with the node.
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.
This exception allows a flow to pass itself to the flow hospital. Once the flow reaches
the hospital it will determine how to progress depending on what causes the exception wraps.
Assuming there are no important wrapped exceptions, throwing a HospitalizeFlowException
will place the flow in overnight observation, where it will be replayed at a later time.
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.
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.
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.
Thrown if a request is made to spend an amount of a FungibleAsset but there aren't enough tokens in the vault.
(extensions in package net.corda.core.utilities)
(extensions in package net.corda.finance)
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.
(extensions in package net.corda.core.contracts)
(extensions in package net.corda.core.crypto)
(extensions in package net.corda.finance.contracts.utils)
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.
(extensions in package net.corda.testing.flows)
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)
An exception that is thrown when a flow has been killed.
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".
(extensions in package net.corda.core.utilities)
(extensions in package net.corda.core.utilities)
(extensions in package net.corda.finance)
(extensions in package net.corda.testing.flows)
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.
Thrown to indicate an RPC operation has been retried for the maxNumberOfRetries unsuccessfully.
In the words of Matt working code is more important then pretty code. This class that contains code that may
be serialized. If it were always serialized then the local disk fetch would need to serialize then de-serialize
which wastes time. However over the wire we get batch fetch items serialized. This is because we need to get the exact
length of the objects to pack them into the 10MB max message size buffer. We do not want to serialize them multiple times
so it's a lot more efficient to send the byte stream.
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.
Subset of state, containing the elements which must match for two or more obligation transactions to be candidates
for netting (this does not include the checks to enforce that everyone's amounts received are the same at the end,
which is handled under the verify() function).
In comparison to BilateralNetState, this doesn't include the parties' keys, as ensuring balances match on
input and output is handled elsewhere.
Used in cases where all parties (or their proxies) are signing, such as central clearing.
Interface for state objects that support being netted with other state objects.
An RPC client connects to the specified server and allows to make calls using specified remote interface to the server that perform various
useful tasks. Please see the Client RPC section of Corda Documentation to learn more about how this API works.
Only a brief description is provided here.
Implemented by anything that can be named by a secure hash value (e.g. transactions, attachments).
A common netting command for contracts whose states can be netted.
Common interface for the state subsets used when determining nettability of two or more states. Exposes the
underlying issued thing.
Enum for the types of netting that can be applied to state objects. Exact behaviour
for each type of netting is left to the contract to determine.
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 NodeDiagnosticInfo holds information about the current node version.
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 net.corda.core.node.services.NetworkMapCache. They are also available via RPC
using the net.corda.core.messaging.CordaRPCOps.networkMapSnapshot method.
Parameters for creating a node for DriverDSL.startNode.
Version info about the node. Note that this data should be used for diagnostics purposes only - it is unsafe to rely on this for
functional decisions.
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.
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.
(extensions in package net.corda.client.rpc)
(extensions in package net.corda.core)
(extensions in package net.corda.core.observable)
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 couldn't merge outputs of two colours together, but you COULD put them in the same
transaction.
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 simple holder for a (possibly anonymous) AbstractParty and a quantity of tokens
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.
Whether the payment should be made before the due date, or after it.
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.
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)
A contract state that may be mapped to database schemas configured for this node to support querying for,
or filtering of, states.
Indexing assumptions:
QueryCriteria assumes underlying schema tables are correctly indexed for performance.
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.
A wrapper for a StateAndRef indicating that it should be added to a transaction as a reference input state.
Wrapper over StateRef to be used when filtering reference states.
Defines a simple domain specific language for the specification of financial contracts. Currently covers:
Thrown whenever a flow result cannot be serialized when attempting to save it in the database
Holds a proxy object implementing I that forwards requests to the RPC server. The server version can be queried
via this interface.
A listener that can be attached to MultiRPCClient to be notified about important RPC connectivity events.
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.
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).
An abstraction for serializing and deserializing objects, with support for versioning of the wire format via
a header / prefix in the bytes.
This is used to pass information into CustomSerializationScheme about how the object should be (de)serialized.
This context can change depending on the specific circumstances in the node when (de)serialization occurs.
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.
Specifies that given CordaService is interested to know about important milestones of Corda Node lifecycle and potentially react to them.
Subscription can be performed using net.corda.core.node.AppServiceHub.register method from a constructor of CordaService.
Subset of node services that are used for loading transactions from the wire into fully resolved, looked up
forms ready for verification.
Represents scope for the operation when JPA Session been created, i.e. transaction started.
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.
The SignTransactionFlow should be called in response to the CollectSignaturesFlow. It automates the signing of
a transaction providing the transaction:
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:
(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.
Placeholder class for the Tenor datatype - which is a standardised duration of time until maturity
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.
(extensions in package net.corda.testing.flows)
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.
(extensions in package net.corda.core.utilities)
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.
Thrown to indicate a fatal error in the RPC system which cannot be recovered from and so needs some manual support.
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.