AttachmentStorage

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

ContractUpgradeService

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.

IdentityService

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.

KeyManagementService

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.

NetworkMapCache

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.

NetworkMapCacheBase

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

NotaryService

PartyInfo

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

TimeWindowChecker

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

TransactionStorage

Thread-safe storage of transactions.

TrustedAuthorityNotaryService

A base notary service implementation that provides functionality for cases where a signature by a single member of the cluster is sufficient for transaction notarisation. For example, a single-node or a Raft notary.

UniquenessProvider

A service that records input states of the given transaction and provides conflict information if any of the inputs have already been used in another transaction.

Vault

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.

VaultService

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!

CordaService

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.

StatesNotAvailableException

UniquenessException

UnknownAnonymousPartyException

VaultQueryException

AttachmentId

queryBy

trackBy