Database tables

A Corda node database contains tables corresponding to the various services that the node provides. It also contains custom tables defined by the CorDapps that are installed on the node. Currently all these tables share the same database schema, but in a future release they will be isolated from each other.

Some tables, especially the ones where the Ledger is maintained are append-only and the data will never change.

Network map

Node info

These are tables that store the node info of other network participants. They are just a local cache that is kept in sync with the network map server. By calling rpc.clearNetworkMapCache() all these tables will be cleared and recreated from the network map server.

Read more in Network map.

node info tables
NODE_INFOSStores NodeInfo objects. The principal table.
NODE_INFO_IDPrimary key
NODE_INFO_HASHHash of the binary nodeInfo file
PLATFORM_VERSIONDeclared version of the participant node.
SERIALVersion of the NodeInfo
NODE_INFO_HOSTSMany-to-one addresses to node
HOSTS_IDPrimary key
HOST_NAMEHost name of the participant’s node
NODE_INFO_PARTY_CERTLegal identity for a network participant
PARTY_NAMEThe X500 name
OWNING_KEY_HASHThe public key
ISMAINIf this is a main identity
PARTY_CERT_BINARYThe certificate chain
NODE_LINK_NODEINFO_PARTYMany-to-Many link between the hosts and the legal identities
NODE_INFO_IDFK to Node_info

Node identities

The following four tables are used by the IdentityService and are created from the NodeInfos. They are append only tables used for persistent caching. They will also be cleared on rpc.clearNetworkMapCache(). Read more in api-identity and node-services

NODE_IDENTITIESMaps a public key hash to an identity.
PK_HASHThe public key hash.
IDENTITY_VALUEThe certificate chain.
NODE_NAMED_IDENTITIESMaps the X500 name of a participant to a public key hash.
NAMEThe x500 name.
PK_HASHThe public key hash.
NODE_IDENTITIES_NO_CERTMaps a public key hash to the X500 name of a participant.
PK_HASHThe public key hash.
NAMEThe x500 name.
NODE_HASH_TO_KEYMaps a public key hash to a public key.
PK_HASHThe public key hash.
PUBLIC_KEYThe public key.

Network parameters

Read more in Network map. Each downloaded network parameters file will create an entry in this table. The historical network parameters are used when validating transactions, which makes this table logically part of the Ledger. It is an append only table and the size will be fairly small.

NODE_NETWORK_PARAMETERSStores the downloaded network parameters.
HASHThe hash of the downloaded file. Used as a primary key.
EPOCHThe version of the parameters
PARAMETERS_BYTESThe serialized bytes
CERTFirst signer certificate in the certificate chain.
PARENT_CERT_PATHParent certificate path of signer.


The ledger data is formed of transactions and attachments. In future versions this data will be encrypted using SGX. Read more in Ledger.


Read more in Working with attachments and Node services.

attachments tables
NODE_ATTACHMENTSStores attachments
ATT_IDThe hash of the content of the file.
CONTENTThe binary content
FILENAMENot used at the moment.
UPLOADEROne of: p2p, app, rpc, unknown. Currently used for for determining if this attachment is safe to execute during transaction verification.
VERSIONThe version of the JAR file.
NODE_ATTACHMENTS_CONTRACTSMany-to-one contracts per attachment. Empty for non-contract attachments.
ATT_IDForeign key
CONTRACT_CLASS_NAMEThe fully qualified contract class name. E.g.:
NODE_ATTACHMENTS_SIGNERSMany-to-one JAR signers of an attachment. Empty if not signed.
ATT_IDForeign key
SIGNERHex encoded public key of the JAR signer.


These are all the transactions that the node has created or has ever downloaded as part of transaction resolution. This table can grow very large. It is an append-only table, and the data will never change. Read more in Node services - DBTransactionStorage. This is the key ledger table used as a source of truth. In the future the content will be encrypted to preserve confidentiality.

NODE_TRANSACTIONSCorda transactions in a binary format
TX_IDThe hash of the transaction. Primary key.
TRANSACTION_VALUEThe binary representation of the transaction.
STATE_MACHINE_RUN_IDThe flow id associated with this transaction.
TIMESTAMPThe insert or status update time of this transaction, as measured by the local node, in UTC.

Contract upgrades

Read more in Upgrading contracts.

NODE_CONTRACT_UPGRADESRepresents an authorisation to upgrade a state_ref to a contract.
STATE_REFThe authorised state.

This table should be empty when no states are authorised for upgrade or after authorised states have been upgraded.


Read more in Scheduling time-based events.

NODE_SCHEDULED_STATESContains scheduled states
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
SCHEDULED_ATTimestamp when this state will execute.

This table should be empty when no events are scheduled.

Storage of private keys

NODE_OUR_KEY_PAIRSStores the anonymous identities
PUBLIC_KEYBinary public key
PRIVATE_KEYBinary private key
PRIVATE_KEY_MATERIAL_WRAPPEDBinary (encrypted) private key
SCHEME_CODE_NAMEString code representing the key algorithm

The columns PRIVATE_KEY_MATERIAL_WRAPPED and SCHEME_CODE_NAME are populated, instead of the column PRIVATE_KEY, if an HSM is configured for anonymous identities. For more details about this feature, read Using an HSM with confidential identities.

PK_HASH_TO_EXT_ID_MAPMaps public keys to external ids. Mainly used by CorDapps that need to simulate accounts.
EXTERNAL_IDExternal id
PUBLIC_KEY_HASHPublic key hash

These tables should be append only.

Node state machine

Read more in Node services.

NODE_CHECKPOINTSStores high-level information about checkpoints
FLOW_IDPrimary key
STATUSThe status of the flow
COMPATIBLEWhether the checkpoint is compatible with the current CorDapps/Corda version
PROGRESS_STEPThe progress step that the flow reached
FLOW_IO_REQUESTThe request type the flow suspended on
TIMESTAMPThe timestamp
NODE_CHECKPOINT_BLOBSStores serialized flow checkpoint blobs
FLOW_IDPrimary key
CHECKPOINT_VALUESerialized information about the flow
FLOW_STATESerialized application stack
TIMESTAMPThe timestamp
NODE_FLOW_RESULTSStores results of flows
FLOW_IDPrimary key
RESULT_VALUESerialized result of the flow
TIMESTAMPThe timestamp
NODE_FLOW_EXCEPTIONSStores exceptions thrown by flows
FLOW_IDPrimary key
TYPEThe class name of the exception
EXCEPTION_MESSAGEThe message of the exception
STACK_TRACEThe stack trace of the exception
EXCEPTION_VALUESerialized exception thrown by the flow
TIMESTAMPThe timestamp
NODE_FLOW_METADATAStores exceptions thrown by flows
FLOW_IDPrimary key
INVOCATION_IDThe invocation id of the flow
FLOW_NAMEThe class name of the flow
FLOW_IDENTIFIERThe identifier of the flow
STARTED_TYPEHow the flow was started
FLOW_PARAMETERSThe parameters the flow was started with
CORDAPP_NAMEThe name of the CorDapp that contains the flow
PLATFORM_VERSIONThe platform version at the start time of the flow
STARTED_BYThe RPC user that started the flow
INVOCATION_TIMEThe time the flow was originally invoked by RPC
START_TIMEThe time the flow started inside the state machine
FINISH_TIMEThe finish time of the flow

These tables will see the most intense read-write activity, especially NODE_CHECKPOINTS and NODE_CHECKPOINT_BLOBS. Depending on the installed flows and the traffic on the node, the I/O operations on this table will be the main bottleneck of the node performance. There will be an entry for every running flow. Draining the node means waiting for this table to become empty. Read more in Upgrading deployed CorDapps.

NODE_MESSAGE_IDSUsed for de-duplication of messages received by peers.
MESSAGE_IDMessage id
INSERTION_TIMEInsertion time
SENDERP2p sender
SEQUENCE_NUMBERSequence number

The NodeJanitor is a background process that will clean up old entries from this table. The size should be fairly constant.

Key value store

NODE_PROPERTIESGeneral key value store. Currently only used for the flow draining mode.

Vault tables

Read more about the vault in Vault.

Note that the vault tables are guaranteed to remain backwards compatible and are safe to be used directly by third party applications.

VAULT_STATESPrincipal vault table.
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
CONSUMED_TIMESTAMPWhen the state was consumed.
LOCK_IDThe soft lock id
LOCK_TIMESTAMPThe soft lock timestamp
RECORDED_TIMESTAMPRecorded timestamp
CONSTRAINT_TYPEThe contract constraint.
CONSTRAINT_DATAThe hash or the composite key depending on the CONSTRAINT_TYPE

The VAULT_STATES table contains an entry for every relevant state. This table records the status of states and allows CorDapps to soft lock states it intends to consume. Depending on the installed CorDapps this table can grow. For example when fungible states are used.

In case this table grows too large, the DBA can choose to archive old consumed states. The actual content of the states can be retrieved from the NODE_TRANSACTIONS table by deserializing the binary representation.

VAULT_TRANSACTION_NOTESAllows additional notes per transaction
SEQ_NOPrimary key
TRANSACTION_IDThe transaction
NOTEThe note
STATE_PARTYMaps participants to states
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
PUBLIC_KEY_HASHThe pk of the participant
X500_NAMEThe name of the participant or null if unknown.
V_PKEY_HASH_EX_ID_MAPThis is a database view used to map states to external ids.
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
PUBLIC_KEY_HASHThe public key of the participant.
EXTERNAL_IDThe external id.

Fungible states

vault fungible states
VAULT_FUNGIBLE_STATESProperties specific to fungible states
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
ISSUER_REFReference number used by the issuer
OWNER_NAMEX500 name of the owner, or null if unknown
QUANTITYThe amount.
VAULT_FUNGIBLE_STATES_PARTSMany-to-one participants to a fungible state
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
PARTICIPANTSX500 name of participant.

Linear states

vault linear states
VAULT_LINEAR_STATESProperties specific to linear states
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
EXTERNAL_IDThe external id of this linear state.
UUIDThe internal id of this linear state.
VAULT_LINEAR_STATES_PARTSMany-to-one participants to a linear state
OUTPUT_INDEXReference to a state - index in transaction
TRANSACTION_IDReference to a state - transaction id
PARTICIPANTSX500 name of participant.

Hot cold setup

NODE_MUTUAL_EXCLUSIONLock for hot-cold deployments. Only 1 entry with the active machine.
MACHINE_NAMEThe machine holding the lock
PIDThe process id
MUTUAL_EXCLUSION_TIMESTAMPWhen the lock was taken.
VERSIONThe version


NODE_METERING_DATAMetering data recorded for signing events on this node
TIMESTAMPThe time in UTC, to the nearest hour, that the metering count was recorded
SIGNING_IDAn external identifier that signed a transaction, or UNMAPPED_IDENTITY
TRANSACTION_TYPEWhether this was a normal transaction, a contract upgrade, a notary change, or an indication that signing events were discarded due to heavy memory use or restarting a node
CORDAPP_STACK_IDAn identifier linking to the NODE_METERING_CORDAPPS table
COMMAND_IDAn identifier linking to the NODE_METERING_COMMANDS table
COUNTThe total number of events in this window with the above characteristics
IS_COLLECTEDWhether these counts have been gathered by collection tooling
VERSIONThe platform version at which this data was recorded
NODE_METERING_CORDAPPSA record of what CorDapps were involved in signing events
STACK_HASHAn identifier for the set of CorDapps involved in a signing event
CORDAPP_HASHThe JAR hash of one CorDapp involved in the signing event
POSITIONThe position in the stack this CorDapp was present at
IDA unique identifier for this row
NODE_METERING_COMMANDSA record of what commands were on a transaction that has been metered
COMMAND_HASHAn identifier for the set of commands on a transaction
COMMAND_CLASSThe class name of a command in the set
IDA unique identifier for this row
NODE_CORDAPP_METADATAMetadata about CorDapps that have been installed on the node
CORDAPP_HASHThe JAR hash of the installed CorDapp
NAMEThe name of the CorDapp
VENDORThe vendor of the CorDapp
VERSIONThe version of the CorDapp
NODE_CORDAPP_SIGNERSSigning keys for a particular CorDapp
CORDAPP_HASHThe JAR hash of the CorDapp
SIGNING_KEY_HASHHash of the public key used to sign this CorDapp

Node RPC audit data

RPC actions play a vital part in the process of triggering commands and flows on a node. In a variety of cases you will need to track the usage of RPC actions - for example, when there are security and regulatory concerns. To do so, you can use the Corda Enterprise node’s capability to record audit information about RPC actions as they are received, prior to executing each action.

Read more in Recording of RPC audit data

NODE_RPC_AUDIT_DATARecording audit information about RPC actions as they are received, prior to executing each action
USERNAMEThe specific user who executed the action (limited to 130 characters)
INTERFACEthe specific type of RPC on which the action was called (limited to 130 characters)
ACTIONThe action that the user intended to invoke (limited to 130 characters)
PARAMETERSFor non-flow actions, the parameter list which was passed with the action (limited to 255 characters)
INVOCATIONTIMEThe time when the action was recorded by the node and invoked
INVOCATIONIDThe unique invocation id of the action
ALLOWEDA boolean field indicating if the user was allowed to call the action

Liquibase database migration

These are Liquibase proprietary tables used by Corda internally and by CorDapps to manage schema change and evolution.