Corda 5 Developer Preview 2 is now available.

Corda Open Source 4.7 release notes

Corda Open Source 4.7 Apache Log4j update release notes (December 16 2021)

Corda Open Source 4.7 was updated on December 16th 2021 to fix the urgent security issue - CVE-2021-44228 - caused by the Apache Log4j 2 dependency.

To build the latest version of Corda 4.7:

  1. Open a terminal window in the directory where you want to download the Corda repository.
  2. Clone the Corda repository by running this command: git clone
  3. Checkout the release branch for Corda 4.7 by running this command: git checkout origin/release/os/4.7
  4. Run the command: ./gradlew assemble
  5. Find node/capsule/build/libs/corda-4.7-SNAPSHOT.jar, this replaces your node’s current corda.jar. To replace the superseded .jar file, follow the instructions on upgrading your node to Corda 4.7.

Corda Open Source 4.7 release notes

Welcome to the Corda 4.7 release notes. This release introduces several new features and enhancements, and fixes a number of known issues from previous releases.

Just as prior releases have brought with them commitments to wire and API stability, Corda 4.7 comes with those same guarantees.

States and apps valid in Corda 3.0 and above are usable in Corda 4.7.

New features and enhancements

Ability to break transaction backchains by reissuing a state with a guaranteed state replacement

Reissuing a state is usually considered for privacy reasons or to optimise performance. This has already been possible in Corda, using an approach where a CorDapp developer could write custom logic to allow a state to periodically be exited and then reissued onto the ledger in separate transactions. However, this approach relies on the developer’s foresight in anticipating performance issues when chains would grow to a certain size, and its implementation varies in consistency and success.

Corda 4.7 introduces a new mechanism to reissue states, bringing platform support for creating breaks in transaction chains where state owners can request a transaction break through a flow and rest assured that a state is not removed without being replaced. Nodes can now request the reissuance of a state by returning it to the issuer or to another trusted party. This reissuance mechanism is atomic and risk-free and provides better support for a developer pattern known as “chain snipping" - once a state is reissued, its pre-reissuance transaction history is no longer shared as part of transaction resolution. This improves performance for applications that build up very long transaction chains, and can help avoid leakage of information regarding the state’s history.

For more information about this feature, see Reissuing a state.

Business Network Membership version 1.1

Corda 4.7 introduces enhancements to the Business Network Membership extension to allow for access control group reporting, batch onboarding, membership group querying, and a way to log and report actions to membership attestations.

Ability to interact with a Corda node via the new Multi RPC Client

A new RPC Client, called the Multi RPC Client, has been added in Corda 4.7. Node operators can use the Multi RPC client to interact with a Corda node via the net.corda.core.messaging.CordaRPCOps remote RPC interface.

For more information, see the Interacting with a node documentation section.

Corda Payments Alpha

Corda Payments Alpha is a first glimpse at a new set of Apps that allows you to create your own payment solution in Corda.

In this early release version, you can:

  • Experiment with making payments across a Corda network, and to parties outside of the network.
  • Trial a live payments solution using Modulr as the Payment Service Provider.

Reference app: Bank in a Box

Bank in a Box is a new sample CorDapp that includes accounts, transactions, and other features typical of a retail banking application.

The app is designed to showcase key Corda features:

Using a set of flows and APIs, Bank in a Box provides the ability to create intrabank payments, recurring payments, issue loans, set account limits, and more. It offers a complete solution with a straightforward UI and authenticated roles, all delivered in a Kubernetes container for easy deployment.

The application highlights best practices and examples for developers who wish to build banking applications using Corda.

Platform version change

The platform version of Corda 4.7 has been bumped up from 8 to 9.

For more information about platform versions, see Versioning.

Fixed issues

  • We have fixed an issue where vault queries using the OR combinator and filter condition would incorrectly throw pagination errors even when the result of the queries was below the defined pagination limit (so the page limit was not exceeded). This fix has also been propagated back to Corda Enterprise Edition 4.5 and 4.6.

Known issues

  • Flows responders do not perform sufficient validation checks of Business Network permissions. This could be an issue due to the potential for incorrect handling of BNO permissions by Business Network nodes, where potentially any node in the Business Network is able to modify a flow and turn the validations off.

Corda 4.6 release notes

Welcome to the Corda 4.6 release notes.

This release introduces a number of new features and some major functional and operational improvements, and fixes a range of issues in the following major areas:

Business Network Membership improvements

Corda 4.6 adds support for Business Network membership representation. In the short video overview below we are introducing a new core concept in Corda and tooling to model membership lists in Corda and represent natively business networks:

Database harmonisation

We have rationalised the way in which database schema management is performed across Corda open source and Corda Enterprise.

  • We have moved all schema management options from node configuration files to start-up sub-commands (in order to reduce misconfigurations and make changing options a less onerous process).
  • We have removed the ability to create/upgrade the database schema as part of running a node, by introducing a schema creation/migration sub-command that needs to be run as part of a node installation/upgrade.
  • We have harmonised the configuration, set-up, and behaviour of databases between Corda and Corda Enterprise.
  • We have removed automatic schema migration for updating from Corda versions prior to 4.0.
  • We have added support in Corda open source for packaging custom CorDapp schemas into Liquibase migrations through introducing Liquibase schema migration/description scripts for CorDapps.

Flow management features and improvements

Corda 4.6 provides the ability to use a unique ID to prevent duplicate flow starts. This can be done using an RPC client and is an additional way to start flows by passing in a unique identifier when starting a flow. This allows you to:

  • Check that a flow started correctly (for example, if there was a disconnect event).
  • Prevent duplicate flow starts - if you try and start a flow twice with the same unique identifier, it will only fire once.
  • Recover the progress tracker for in-flight flows.
  • Recover the result of finished flows.

Watch the short video overview of this feature:

Developer experience features and improvements

We are focused on improving the overall developer experience to ensure Corda maintains its status as an easy-to-use platform for developers. In this release we have a number of improvements that will help developers build more resilient applications.

  • Automatic detection of unrestorable checkpoints. During development, flows are now automatically serialized then deserialized whenever they reach a checkpoint. This enables automatic detection of flow code that creates checkpoints that cannot be deserialized.
  • Register custom pluggable serializers for CorDapp checkpoints. Custom serializers can now be used when serializing types as part of a flow framework checkpoint. Most classes will not need a custom serializer. This exists for classes that throw exceptions during checkpoint serialization. Implement the new CheckpointCustomSerializer interface to create a custom checkpoint serializer.

Operational improvements

  • Corda 4.6 introduces a set of improvements to make the flow state machine more resilient.
  • New flow session close API adds support for eager termination of flow sessions and release of their resources.

Plus a lot more - please read these release notes carefully to understand what’s new in this release and how the new features and enhancements can help you.

New features and enhancements

Business Network membership extension

The Business Network Membership extension for creating and managing business networks allows you (a node operator) to define and create a logical network based on a set of common CorDapps as well as a shared business context. Corda nodes outside of your Business Network are not aware of its members.

With this extension, you can use a set of workflows to add members to the network, remove members, and manage their permissions.

Database schema harmonisation

As part of this release, we have rationalised the way in which database schema management is performed across Corda open source and Corda Enterprise.

  • We have moved all schema management options from node configuration files to start-up sub-commands (in order to reduce misconfigurations and make changing options a less onerous process).
  • We have removed the ability to create/upgrade the database schema as part of running a node, by introducing a schema creation/migration sub-command that needs to be run as part of a node installation/upgrade.
  • We have harmonised the configuration, set-up, and behaviour of databases between Corda and Corda Enterprise.
  • We have removed automatic schema migration for updating from Corda versions prior to 4.0.
  • We have added support in Corda open source for packaging custom CorDapp schemas into Liquibase migrations through introducing Liquibase schema migration/description scripts for CorDapps.

Some of the more significant changes are listed below.

Schema management for CorDapps

Corda 4.6 now supports CorDapp schema migration via Liquibase in the same way as Corda Enterprise, where:

  • Each CorDapp needs to provide a migration resource with Liquibase scripts to create/migrate any required schemas.
  • Old Corda open source CorDapps that do not have migration scripts need to be migrated in the same way as described in the Corda Enterprise Enterprise migration documentation.
  • A node can manage app schemas automatically using Hibernate with H2 in dev mode. This must be enabled with the --allow-hibernate-to-manage-app-schema command-line flag.

Schema creation

In Corda 4.6, a Corda node can no longer modify/create schema on the fly in normal run mode. Instead, you should apply schema setup or changes deliberately using a new sub-command called run-migration-scripts. This subcommand will create/modify the schema and then exit.

A split into core and app schema

Corda nodes have a set of core schema that is required for the node itself to work. In addition, CorDapps can define additional mapped schemas to store their custom states in the vault.

Up to Corda 4.6, the node/schema migration would use the combination of both and run all the required schema creation/migration using hardcoded lists and heuristics to figure out which is which (as, for example, core and app schema have different requirements whether they can be run while checkpoints are present in the database).

This has now changed - the run-migration-scripts sub-command takes two new parameters: --core-schemas and --app-schemas. At least one of these parameters must be present and will run the migration scripts for the respective requested schema set.


Automated tests (as in MockNetwork, NodeBasedTest and Node Driver tests) are able to set up the required schema automatically.

  • Mock Network. The MockNode overrides a field in AbstractNode that allows the node to run schema migration on the fly (which is not available via the command-line). It takes extra constructor parameters to control whether Liquibase will be run and whether Hibernate can be used to create the app schema. Both default to true for compatibility with existing tests.
  • Node Driver. In-process nodes use a similar mechanism to Mock Nodes. Out-of-process nodes using a persistent database need the database to be set up before they start (as does a real node). Therefore, DriverDSL will run a schema migration step before running the node in this case. Out-of-process nodes using an in-memory database are a particularly tricky case, as there is no persistent database that could be set up before the node starts. Therefore, the node itself can check for H2 in-memory JDBC URLs and will run any required migration if that is detected.
  • Node-based Tests use the same in-process node as does NodeDriver.


The Network Bootstrapper runs core schema migrations as part of the bootstrapping process.

Cordformation has an extra parameter that can be added to the node section in the build.gradle, as follows:

runSchemaMigration = true

This will run the full schema migration as the last step of the cordformation setup, leaving the nodes ready to run.

Configuration changes

The following fields have been removed from the database section in the node configuration file. These need to be removed from the node configuration as the node will throw an exception on startup if it finds any of them:

  • transactionIsolationLevel: this is now hard-coded in the node.
  • initialiseSchema: as above - schema initialisation cannot be run as part of node startup.
  • initialiseAppSchema: as above.

Please check the schema management documentation to see what adjustments are needed to your CorDapp packaging process.

Schema migration from Corda versions prior to V4.0

Corda 4.6 drops the support for retro-fitting the database changelog when migrating from Corda versions older than 4.0. Thus it is required to migrate to a previous 4.x version before migrating to Corda 4.6 - for example, 3.3 to 4.5, and then 4.5 to 4.6.

Ability to prevent duplicate flow starts and retrieve the status of started flows

Corda’s RPC client now allows each flow to be started with a unique client-provided ID. Flows started in this manner have the following benefits:

  • If a flow is invoked multiple times with the same client ID, they will be considered duplicates. All subsequent invocations after the first will simply return the result of the first invocation.
  • A running flow can be reattached using the client ID. This allows its flow handle to be recovered.
  • The result of a completed flow can still be viewed after the flow has completed, using the client ID.

This enables you to:

  • Reconnect reliably to previously started flows.
  • Reclaim a flow’s result or exception at any time in the future.

For more information, see Starting a flow with a client-provided unique ID.

New flow session close API

Corda 4.6 introduces a new flow session close API, which provides support for eager termination of flow sessions and release of their resources.

For more information, see API: Flows.

Hotloading of notaries list

The notaries list can now be hotloaded. Updates to the notaries network parameter do not require the node to be shut down and restarted.

For more information, see Hotloading in The network map.

Host to Container SSH port mapping for Dockerform

When creating a Docker container, you can now map the SSH port on the host to the same port on the container. For more information, see Optional configuration in Creating nodes locally.

Ability to register custom pluggable serializers for CorDapp checkpoints

CorDapp developers now have the ability to create a custom serializer for a given type, which is then used when serializing the type in question as part of a flow framework checkpoint.

Note that this is an advanced feature, designed specifically for certain types that throw exceptions during checkpoint serialization. The vast majority of classes will not need a custom serializer.

Custom checkpoint serializers are created by implementing the new CheckpointCustomSerializer interface.

For more information, see Pluggable serializers for CorDapp checkpoints.

Automatic detection of unrestorable checkpoints

Flows are now automatically serialized then deserialized whenever they reach a checkpoint. This allows better detection of flow code that creates checkpoints that cannot be deserialized, and enables developers and network operators to detect unrestorable checkpoints when developing CorDapps and thus reduces the risk of writing flows that cannot be retried gracefully.

This feature addresses the following common problems faced by developers:

  • Creating objects or leveraging data structures that cannot be serialized/deserialized correctly by Kryo (the checkpoint serialization library Corda uses).
  • Writing flows that are not idempotent or do not deduplicate behaviour (such as calls to an external system).

The feature provides a way for flows to reload from checkpoints, even if no errors occur. As a result, developers can be more confident that their flows would work correctly, without needing a way to inject recoverable errors throughout the flows.

For more information, see Automatic detection of unrestorable checkpoints.

Other changes and improvements

  • In Corda 4.6 we have introduced a set of improvements to make the flow state machine more resilient.
  • As of Corda 4.6, support for DemoBench is deprecated.
  • We have released a new minor version of Accounts SDK - version 1.0.2. This version includes database improvements that make it compatible with Corda 4.6. If you are planning to use the Accounts SDK with Corda 4.6, you must use Accounts SDK V 1.0.2.
  • We have released a new minor version of Tokens SDK - version 1.2.1. This version includes database improvements that make it compatible with Corda 4.6. If you are planning to use the Tokens SDK with Corda 4.6, you must use Tokens SDK V 1.2.1.
  • When starting a new driver using the driver DSL, the notary node will start by default as a thread in the same JVM process that runs the driver regardless to the startNodesInProcess driver properties (and not as a new process if the startNodesInProcess is false). This setting can be overridden. Please note that if the test interacts with the notary and expects the notary to run as a new process, you must set startInProcess to false.
  • In Corda 4.6, if a CorDapp’s minimumPlatformVersion is higher than the platform version of the node, the CorDapp is not loaded and the node fails to start. This is a change in behaviour compared to Corda 4.5 where under these conditions the node would start up and log that the CorDapp could not be loaded. See Versioning for more information.

Platform version change

The platform version of Corda 4.6 has been bumped up from 7 to 8.

For more information about platform versions, see Versioning.

Important upgrade notes

Fixed issues

  • We have fixed an issue where the RPC startFlow could not reattach to existing client id flows when flow draining mode was enabled.
  • We have fixed an issue where the Classloader failed to find the class when a CorDapp class was used.
  • We have fixed an issue where the FlowSessionCloseTest.flow could not access a closed session unless it was a duplicate close that was handled gracefully.
  • We have fixed an issue where the RetryFlowMockTest failed due to restart not setting senderUUID and the early end session message not hanging the receiving flow.
  • We have fixed an issue where the ExceptionsErrorCodeFunctionsTest failed due to timeout.
  • We have fixed an issue where the expected error_code="5" error was missing in logs run with custom CorDapps without the Liquibase schema.
  • We have fixed an issue with inconsistent behaviour between killed client ID flows and flows with other statuses.
  • The path for network parameters is now configurable and the network parameters file is stored in the location specified by the node configuration.
  • We have fixed an issue where logging was detecting but not printing an issue with certificates.
  • We have fixed an issue where the end session message did not hang when a flow flakey test was received.
  • We have fixed an issue where the MembershipAuthorisationException message contained StateAndRef<MembershipState> instead of the flow name.
  • We have fixed an issue in the Demo CorDapp where the mandatory notary parameter was missing in the ModifyGroupFlow description.
  • We have fixed an issue in the Demo CorDapp where the nodes failed to start due to an incompatible database schema error.
  • We have fixed an issue where the optional file:prefix was stripped from the classpath element passed to the ClassGraph() filter function, resulting in the filter function not recognising the element.
  • We have fixed an issue where flows would start executing when the StateMachineManager.start database transaction had not started yet.
  • We have reverted to Jackson 2.9.7 to resolve an issue where R3 Tools could not work properly with the upgraded version.
  • We have fixed an issue where Paths.get("") returns null instead of the current working directory.

Known issues

  • Using the local network bootstrapper takes longer than in previous versions of Corda.
  • The new operation on the FlowRPCOps RPC interface takes a StateMachineID as an argument parameter, leading to repetitive invocations of the form.
  • An SSL connection cannot be established between two nodes when one of the nodes does not have access to the Identity Manager Service and, as a result, to CRL distribution points.
  • A node cannot be run with the --dev-mode option unless devModeOptions.allowCompatibilityZone=true is added to the node configuration.
  • When a valid command is run in the wrong location, an exception occurs rather than a clear error message.
  • In the Attachment Demo, the runSender task uses myLegalName instead of serviceLegalName for notarisation.
  • Some samples cannot be run on Windows due to an issue with long file names.
  • Business Network roles are not displayed when membership state is queried via CLI.
  • The SSH Client returns inconsistent exit codes after gracefulShutdown is run, indicating that an error has occurred.
  • The node rejects the incoming P2P connection from a node with a revoked certificate, with warnings and errors, but does not block any attempts to re-establish it. This leads to a quick accumulation of warnings and errors in the node log.
  • The error text is repeated in the console when trying to register a node with the forbidden characters in the Organisation (O) name.
  • The <install-shell-extensions> sub-command of Corda node creates log files in the home folder, while all other sub-commands create log files the logs subfolder.

Corda 4.5 release notes

Welcome to the Corda 4.5 release notes.

Please read these carefully to understand what’s new in this release and how the new features and enhancements can help you.

Just as prior releases have brought with them commitments to wire and API stability, Corda 4.5 comes with those same guarantees.

States and apps valid in Corda 3.0 and above are usable in Corda 4.5.

New features and enhancements

Improved killFlow operations

We have improved the existing killFlow RPC operation, which allows node operators to terminate flows manually - in several ways:

  • When a flow is terminated, any counterparty that has an open flow session with the flow in question is notified that the flow has ended unexpectedly

  • Any vault soft-locks held by a flow are released when the flow is terminated

  • A flow can now check programmatically whether its termination has been requested. This allows a looping flow to use this API to ensure it doesn’t loop indefinitely when a termination has been requested. Previously, the flow would wait until it reached the next checkpoint to decide whether to terminate, allowing deadlocks to occur (e.g. if the flow was caught in an infinite loop)

New flow APIs

We have introduced new flow framework APIs sendAll and sendAllMap, which can be used to send messages to multiple counterparties with improved performance. Previously, a flow was able to send messages to multiple counterparties by using the send API once for each counterparty. These new APIs can now be used to achieve the same with better performance, which comes from a smaller number of suspensions and checkpoints.

For more information about the new APIs, see the API flows documentation section.

Improved Tokens SDK along with new documentation and training

The Tokens SDK has been extended to provide a consistent API for use in both Java and Kotlin.

The documentation has been relocated to the main Corda and Corda Enterprise documentation site, and a comprehensive training module for developers added to the Corda training site. Read the documentation. Explore the training module.

Error code knowledge base

Error reports generated in Corda stack traces will include (starting from Corda 4.5 onwards) a unique code linked to a knowledge base in our documentation.

When a documented error is encountered, users can access the knowledge base page to get more information about the error. This replaces the error codes based on stack trace hashes that had been introduced in earlier versions of Corda.

Excluding .jar files from Quasar instrumentation

Corda uses Quasar to instrument flows, which makes it possible to resume a flow from a checkpoint. However, the Quasar instrumentation causes OutOfMemoryError exceptions to occur when certain .jar files are loaded as dependencies.

To resolve this issue, we have added the new node configuration option quasarExcludePackages, which allows you to list packages that are to be excluded from the Quasar instrumentation. See Node configuration for more information.

RestrictedEntityManager and RestrictedConnection

To improve reliability and prevent user errors, we have modified the database access provided via JDBC and EntityManager to block access to functions that may corrupt flow checkpointing. As a result, it is now impossible to mistakenly call rollback inside the raw vault observer transaction, or to close the database connection prematurely.

The full list of blocked functions can be found below:

Updated Dockerform task

We have updated our Dockerform local development task plug-in to use PostgreSQL as the chosen external database.

Platform version change

The platform version of Corda 4.5 has been bumped up from 6 to 7 due to the addition of the new flow framework APIs sendAll and sendAllMap, which can be used to send messages to multiple counterparties with improved performance.

For more information about platform versions, see Versioning.

Fixed issues

  • We have fixed an issue where the deserialization of throwables did not support evolution, which made it difficult to add constructor parameters in new versions or to rename a property.
  • We have fixed an issue where the implementation of FieldInfo.notEqual in QueryCriteriaUtils was the same as FieldInfo.Equal.
  • We have optimised Corda’s DJVM deserializer so that loadForSandbox() now returns a Class instead of a LoadedClass.
  • We have modified CordaFuture so that any throwable can complete it, even if exceptions that do not subclass java.lang.Exception are re-thrown immediately.
  • We have fixed an issue where CorDapp custom serializers were not supported in MockNetwork, causing unit tests of flows to fail without using Driver.
  • We have fixed an issue where serializing a FlowExternalOperation, which had maintained a reference to a FlowLogic, could throw an IndexOutOfBoundsException error when constructing a FlowAsyncOperation from a FlowExternalOperation.
  • We have fixed an issue where ServiceHub.signInitialTransaction() threw undeclared checked exceptions (TransactionDeserialisationException and MissingAttachmentsException.
  • We have standardised all node database timestamps to use the UTC time zone.
  • We have fixed issues with the existing checkpoint iterator serializers related to null handling and the use of equals when restoring the iterator position.
  • We have fixed an issue where Corda failed to deserialize Enums with custom toString() methods into the DJVM sandbox.
  • We have fixed an issue where Corda’s internal providerMap field in core, which is supposed to be private, was both public and mutable.
  • We have fixed an issue with failing session init messages when the state machine replayed them from the Artemis queue in order to retry flows that had not yet persisted their first checkpoint, due to problems with database connectivity.
  • We have fixed an issue where the com.r3.corda.enterprise.settlementperftestcordapp.flows.SwapStockForCashFlowTest failed for Oracle 11 due to failed migration.
  • We have fixed an issue where Level.WARN and Level.FATAL logs did not include the original log message after updating them to extract more information from the stack traces.
  • We have fixed an issue where a race condition would occur when a flow hung while waiting for the ledger to commit a transaction with hash even when that transaction was present in the database.
  • We have fixed an issue where no CRL check was done when using embedded Artemis, which could cause nodes to continue to be involved in transactions after they had been blacklisted.
  • We have fixed an issue with inconsistent error messages on starting components if HSM was not available.
  • We have fixed an issue where a Vault Query using LinearStateQueryCriteria(linearId = emptyList()) would translate into an illegal SQL statement on PostgreSQL and would throw an exception.
  • We have added a custom serializer (IteratorSerializer) that can fix broken iterators in order to resolve an issue with a ConcurrentModificationException in FetchDataFlow.
  • We have fixed an issue with failing VaultObserverExceptionTest tests on Oracle.

Corda 4.4 release notes

Corda 4.4 lays the foundation of a new open core approach for the Corda codebase. This involved a refactoring of the main functional components of Corda. Please consult the CorDapp overview to get an overview of the practical impact on CorDapp development.

Furthermore, Corda 4.4 introduces improvements to the flow framework API and a new diagnostic ServiceHub call, and includes a number of security enhancements.

Changes for developers in Corda 4.4

Flows API improvements

Corda 4.4 introduces a FlowLogic.await API, allowing a CorDapp developer to suspend a flow when executing user-defined long-running operations, such as call-outs to external services. The FlowLogic.await API prevents these long-running operations from blocking the flow thread, allowing other flows to progress. Previously, these operations had to be executed synchronously, blocking the flow thread.

The CorDapp developer can decide whether to run these asynchronous flow operations in a dedicated thread pool, or to handle the threading themselves directly.

Note that as before, the flow framework suspends automatically for certain operations (for example, when waiting to receive a message from a counterparty). These suspensions do not have to be triggered explicitly.

The node operator can configure the number of threads in the threadpool to dedicate to external operations.

Corda 4.4 also introduces a new HospitalizeFlowException exception type that, when thrown, causes a flow to halt execution and send itself to the flow hospital for observation. The flow will automatically be retried on the next node start.

This exception gives user code a way to retry a flow from its last checkpoint if a known intermittent failure occurred.

New utility APIs

Corda 4.4 introduces a new call (ServiceHub.DiagnosticsService) available to CorDapp developers that allows them to access:

  • The edition of Corda being run (e.g. Open Source, Enterprise)
  • The version of Corda being run including the patch number (eg. 3.2.20190215)

Corda 4.4 also provides a callback (AppServiceHub.register) to allow Corda services to register custom actions to be performed once the node is fully started-up. This pattern prevents issues caused by the service trying to immediately access a part of the node that hadn’t yet been initialised .

Security enhancements

  • The SSH server in the Node shell has been updated to remove outdated weak ciphers and algorithms.
  • The ability to SSH into the standalone shell has been removed
  • A new read-only RPC user role template has been documented in Node shell

Changes to integration testing

Driver DSL (see Integration testing) tests now default to on-disk H2 databases instead of in-memory. This is done to enable use of a snapshot database schema, to reduce time spent creating the database schema on each node startup. User tests are not expected to be impacted, but in case of issues you can set inMemoryDB = true on the driver parameters to revert.

The “out-of-process” nodes spawned through Driver DSL will no longer accidentally contain your CorDapps on their application classpath. The following items will be filtered out:

  • Directories (only files are allowed)
  • .jar files with Maven classifiers tests or test
  • .jar files with any CorDapp attributes in their manifests (any of those listed in Building and installing a CorDapp or Target-Platform-Version and Min-Platform-Version if both are present)
  • .jar files with the Corda-Testing attribute in their manifests. The manifest of the following artifacts has been updated to include the Corda-Testing attribute:
    • corda-node-driver
    • corda-test-utils
    • corda-test-common
    • corda-test-db
    • corda-mock
  • Any files with names beginning with corda-mock, junit, testng or mockito

Some of your existing integration tests might implicitly be relying on the presence of the above files, so please keep this in mind when upgrading your version of Corda.

Platform version change

Given the addition of new APIs, the platform version of Corda 4.4 has been bumped up from 5 to 6. This is to prevent CorDapps that use it being deployed onto nodes unable to host them. Note that the minimum platform version has not been changed - this means that older Corda nodes can still interoperate with Corda 4.4 nodes. Since the APIs added do not affect the wire protocol or have other zone-level implications, applications can take advantage of these new platform version 6 features even if the Corda 4.4 node is running on a network whose minimum platform version is 4.

For more information on platform version, please see Versioning. For more details on upgrading a CorDapp to use platform version 5, please see Upgrading CorDapps to newer Platform Versions.

Known Issues

Changes introduced in Corda 4.4 to increase ledger integrity have highlighted limitations regarding database transactions. To prevent flows from continuing to process after a database transaction has failed to commit or suffered from a pre-commit persistence exception, extra database flushes have been added. These extra flushes can cause exceptions to be thrown where they were not before (or cause different exception types to be raised compared to Corda 4.3 or previous versions). In general, CorDapp developers should not expect to be able to catch exceptions thrown during a database transaction and then continue with further DB operations as part of the same flow. A safer pattern involves allowing the flow to fail and be retried

Fixed Issues

  • A failure response from Doorman during initial registration causes a class cast exception.
  • Add an exception for Unrecoverable RPC errors.
  • Fix the misleading Flow has been waiting message.
  • Update Quasar agent so that we can exclude entire ClassLoaders from being instrumented.
  • Don’t fail on Liquibase errors when using H2.
  • Exceptions thrown in raw vault observers can cause critical issues.
  • Migration from Corda 3.x to 4.x for PostgreSQL require a manual workaround.
  • Prepare DJVM library for 1.0 release.
  • Improve node configuration override documentation.
  • Allow EvolutionSerializer to handle primitive types becoming nullable.
  • Fix caching of local AMQPSerializer.
  • Fixed NPE in BlobInspector.
  • Update DemoBench so that using the DJVM is configurable.
  • Scanning for Custom Serializers in the context of transaction verification is broken.
  • Allow EvolutionSerializer to handle boxed types becoming primitive.
  • Create interface to perform transactional operations from custom CordaServices.
  • Fix typo in node database table documentation.
  • Fix node database page.
  • Add timestamp column to NODE_TRANSACTIONS table.
  • Support adding new mandatory field and removal of optional.
  • Fix link to network builder.
  • Provide option for user to specify custom serializers without classpath scanning.
  • The CordaRPCClientConfiguration is not respected when GracefulReconnect is used.
  • Fix for Could not start flow as connection failed error on starting flow via ShellCli if user is not authorized to use this flow.
  • Support whitelists and custom serializers inside the DJVM.
  • Load DJVM serialization types more precisely to avoid runtime warnings.
  • Use the config values for reconnecting retry interval and max reconnect attempts.
  • SSH memory leak and security.
  • Remove support for outdated ciphers and algorithms from SSH.
  • Deserialization using the DJVM creates too many SerializerFactory objects.
  • Allow initial registration errors to propagate up so the node exits with a failure code.
  • Remove reference to man run.
  • Always add TestCorDapps to the classpath when building _driverSerializationEnv.
  • Use the connectionMaxRetryInterval configuration when reconnection the RPC client.
  • Update docs for X500 name and SSH hostkey.
  • hashLookup command help misspelling.
  • Exit the InteractiveShell on shutdown command.

Corda 4.3 release notes

Corda 4.1 was released with a great suite of new features to build on top of the success of Corda 4. Now, Corda 4.3 extends upon that with some powerful new capabilities. Corda 4.3 contains over 400 fixes and documentation updates to bring additional stability and quality of life improvements to those developing on the Corda platform.

We recommend you upgrade from Corda 4.1 to Corda 4.3 as soon as possible.

Changes for developers in Corda 4.3

Introduction of Accounts

With Corda 4.3 we are introducing the concept of “Accounts”. Vaults can be logically partitioned into subsets, each subset representing an account.

This is advantageous for several reasons:

  • Node operators can reduce costs by hosting multiple entities, as accounts, on one node
  • Node operators can partition the vault on a per entity basis
  • In many cases, node owners or operators will be maintaining balances of cash, assets, or agreements on behalf of others
  • Accounts allow network access to those who cannot (or do not want to) be first-class citizens on the network

This new functionality allows hosts to take a custodial role over their nodes, supporting a broader range of use-cases.

Please find more information on Accounts functionality in the documentation.

Confidential Identities

Confidential Identities have been revisited, and nodes no longer use or store X.500 certificates. Keys used for signing confidential transactions have been decoupled from the node’s identity, and a nonce challenge is used to confirm a Confidential Identity belongs to the legal identity claiming it.

This removes the requirement to serialize and store the certificate chain for each new key that is registered.

In addition, confidential identities can now be shared without needing a transaction.

Improved RPC client connectivity

The CordaRPCClient library has been improved in Corda 4.3 to address issues where the library does not automatically reconnect to the node if the RPC connection is broken.

The improved library provides the following enhancements:

  • Reconnects to the node via RPC if the RPC connection to the node is broken
  • Reconnects any observables that have been created
  • Retries all operations on failure, except for flow start operations that die before receiving a valid FlowHandle, in which case a CouldNotStartFlowException is thrown

We’re confident in the improvements made to RPC client connectivity but would remind you that applications should be developed with contingencies in the event of an RPC connection failure. See Interacting with a node for details.

Additional flexibility in recording transactions

In Corda 4.3, nodes can choose to record a transaction with three different levels of visibility:

  • Store only the relevant states in the transaction (the default)
  • Store every state in the transaction (used when observing a transaction, for example)
  • Store none of the states in the transaction (used during transaction resolution, for example)

Previously, there was a limitation in that if a node initially records a transaction with a specific level of visibility, they cannot later record it with a different level of visibility.

In Corda 4.3, an enhancement has been made to observer node functionality to allow observers to re-record transactions that have already been recorded at a lower visibility. See Posting transactions to observer nodes for details of how to work with observer nodes.

Changes for operators in Corda 4.3

Additional flexibility for RPC permissioning

RPC permissions can now contain wildcards; for example: com.example.* matches both and

Security Upgrades

There have been several security upgrades, including changes to the Corda webserver, dependency changes, changes to X509 extended key usage, and whitelisting attachments.

  • Extended key usage: Corda certificates previously defined the X509 ‘Extended Key Usage’ as ‘anyExtendedKeyUsage’ which was too broad. Only the necessary key uses are included now. For example, for Corda TLS certificates, the only required extended key usages are ‘Client Authentication’ and ‘Server Authentication’.
  • Corda webserver moved to testing module: The Corda webserver is deprecated and not suitable for production use. In Corda 4.3 it has been renamed test-server and moved to the testing module.
  • Enhancements to attachment whitelisting: Transactions referencing contracts that are not installed on a node can still be accepted if the contract is signed by a trusted party.
  • Updated vulnerable dependency: Jolokia 1.2 to 1.6.0 are vulnerable to system-wide cross-site-request-forgery attacks. Updated to Jolokia 1.6.1

Platform version change

Given the addition of a new API to support the Accounts feature, the platform version of Corda 4.3 has been bumped up from 4 to 5. This is to prevent CorDapps that use it being deployed onto nodes unable to host them. Note that the minimum platform version has not been changed - this means that older Corda nodes can still interoperate with Corda 4.3 nodes. Since the APIs added do not affect the wire protocol or have other zone-level implications, applications can take advantage of these new platform version 5 features even if the Corda 4.3 node is running on a network whose minimum platform version is 4.

For more information on platform version, please see Versioning. For more details on upgrading a CorDapp to use platform version 5, please see Upgrading CorDapps to newer Platform Versions.


The Corda Finance library is now deprecated and has been superseded by the Corda Tokens SDK. While the finance library is not yet being removed, we are no longer improving or updating it. We strongly encourage users to transition from the Corda Finance library to the Corda Tokens SDK. Find more information and begin using the tokens SDK in the GitHub repository here

Any confidential identities registered using the old API will not be reflected in the new tables after migration to Corda 4.3. However, the standard APIs work with both old and new confidential identities tables. For this reason, we do not recommend the use of both old and new confidential identities APIs in the same deployment. The old confidential identities API will be deprecated in a future release.

Issues Fixed

  • Register custom serializers for jackson as well as amqp.
  • Cleanup non-finalised, errored flows.
  • Introduce max number of retries per invocation for reconnecting RPC.
  • Fix for CORDA-3315.
  • Add a check for shutdown to avoid some of the errors ()” , (#5578) (revert CORDA-3281).
  • RPC Invocation fails when calling classes with defaulted constructors O/S.
  • Avoid flushing when inside a cascade.
  • fix observables not being tagged with notUsed().
  • deployNodes doesn’t use right version of Java.
  • Remove quasarRPC client.
  • Fix infinite loop.
  • Add a check for shutdown to avoid some of the errors.
  • Make Tx verification exceptions serializable.
  • Node configuration doc change.
  • Improve error handling for registering peer node.
  • JDK11, built and published artifacts to include classifier.
  • Missing logs on shutdown.
  • Improve CorDapp loading logic for duplicates.
  • Publish checkpoint agent jar and allow for inclusion of version id in jar upon run-time execution
  • O/S version of fix for slow running in 4.3.
  • Enhance backwards compatibility logic to include Inter….
  • Prevent node startup failure upon cross-platform execution.
  • Remove Gradle’s evaluation dependency on node:capsule.
  • New detekt rules based on feedback.
  • Remove Gradle’s evaluation dependency on node:capsule.
  • Fix dba migration for PostgreSQL following changes in CORDA-3009.
  • Vault Query API enhancement, strict participants matching.
  • Move executor thread management into CordaRPCConnection.
  • Replace deprecated use of Class.newInstance() for sake of DJVM.
  • Support of multiple interfaces for RPC calls.
  • Rename the webserver.
  • optional node.conf property not recognized when overridden.
  • Add missing quasar classifier to web server capsule manifest.
  • Revert back to quasar 0.7.10 (Java 8).
  • Ensure that ArraySerializer.elementType is resolved for GenericArray.
  • backporting detekt config changes to OS 4.1 and rebaselining.
  • Fix vault query for participants specified in common criteria.
  • Do not add java.lang.Class fields and properties to local type cache.
  • Fix Classgraph scanning lock type.
  • Added exception handling for missing files that displays appropriate messages rather than defaulting to file names.
  • new baseline for 4.3 since new debt has been added with the last few commits.
  • Upgrade Corda to Java 11 (compatibility mode).
  • Add GracefulReconnect callbacks which allow logic to be performed when RPC disconnects unexpectedly.
  • Checkpoints which cannot be deserialised no longer prevent the nodestarting up.
  • Make set of serializer types considered suitable for object reference to be configurable.
  • Notary logging improvements.
  • Improve Notary loggingan operator/admins point of view.
  • Make set of serializer types considered suitable for object reference to be configurable.
  • Fix postgres oid/ bytea column issue.
  • Load drivers directory automatically.
  • Fixed bug where observable leaks on ctrl+c interrupt while waiting in stateMachinesFeed.
  • Fail build on compiler warnings.
  • (Version 2 - CORDA-3133).
  • Prevent node running SwapIdentitiesFlowinitiating session with itself.
  • Split migrations as per….
  • Remove RPC exception obfuscation.
  • Whitelisting attachments by public key, phase two tooling.
  • Use PersistentIdentityMigrationBuilder instead of schema a….
  • Add -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError to default JVM args for node.
  • Ignore synthetic and static fields when searching for state pointers.
  • Additional Back Chain Resolution performance enhancements.
  • Close security manager after broker is shut down.
  • Added additional property on VaultQueryCriteria for querying by account.
  • Added ability to lookup the associated UUID for a public key to KeyManagementService.
  • Remove dependency on 3rd party javax.xml.bind library for simple hex parsing/printing.
  • FilterMyKeys now uses the key store as opposed to the cert store.
  • Refine documentation around rpc reconnection.
  • Rebase identity service changes onto 4.3.
  • Close previous connection after reconnection.
  • Add wildcard RPC permissions
  • Migrate identity service to use to string short.
  • Modify Corda’s custom serialiser support for the DJVM.
  • JacksonSupport, for CordaSerializable classes, improved to only uses those properties that are part of Corda serialisation.
  • Update cache to check node identity keys in identity table.
  • Removed InMemoryTransactionsResolver as it’s not needed and other resolution cleanup.
  • Update app upgrade notes to document source incompatibility.
  • improvements to checkpoint dumper.
  • Add a cache for looking up external UUIDspublic keys.
  • Cater for port already bound scenario during port allocation.
  • Update owasp scanner.
  • Whitelisting attachments by public key, relax signer restrictions.
  • Add failover listeners to terminate node process.
  • Parallel node info download.
  • Checkpoint agent tool.
  • More information in log warning for CorDapps missing advised JAR manifest file entries.
  • Restore CompositeKey support to core-deterministic.
  • Restrict extended key usage of certificate types.
  • Hash to Signature Constraint automatic propagation.
  • Prevent connection threads leaking on reconnect.
  • Exception is logged if flow session message can’t be deserialised.
  • Do not throw exception for missing fiber and log instead.
  • Make the RPC client reconnect with gracefulReconnect param.
  • Pass base directory when resolving relative paths.
  • Add Node Diagnostics Info RPC Call, Update changelog.
  • Add Node Diagnostics Info RPC Call, Backport a diff from CORDA-3028.
  • fix network builder.
  • Add Node Diagnostics Info RPC Call.
  • Allow transactions to be re-recorded using StatesToRecord.ALL_VISIBLE.
  • shorten poll intervals for node info file propagation.
  • Allow certificate directory to be a symlink.
  • fix network builder.
  • min after normal operation (CORDA-3034. Reconnecting Rpc will now not wait only for 60).
  • Refactor NodeConfiguration out of NodeRegistrationHelper.
  • NotaryLoader, improve exception handling.
  • Introduce SignOnlyCryptoService and use it whenever possible.
  • Introducing Destination interface for initiating flows with CORDA-3033.
  • Fine-tune compile vs runtime scopes of published deterministic jars.
  • Upgrade notes for C4 need to include required minimum previous Corda version () , (#5124).
  • Align timeouts for CRL retrieval and TLS handshake.
  • disable hibernate validator integration with hibernate () , (#5144).
  • Fix release tooling when product name != jira project.
  • Constrain max heap size for Spring boot processes.
  • Updated the majority of the dependencies that were out of date.
  • Allow AbstractParty to initiate flow.
  • Reverting jersey and mockito as it currently causes issues with ENT.
  • Fixing x500Prinicipal matching.
  • Fix for Liquibase changelog warnings.s
  • Add documentation on the options for deploying nodes.
  • Disable slow consumers for RPC since it doesn’t work.
  • Revert usage of Gradle JUnit 5 Platform Runner.
  • Fix for CORDA-2972.
  • Catch IllegalArgumentException to avoid shutdown of NodeExplorer.
  • Remove version uniqueness check.
  • Support for custom Jackson serializers ()” , (#5167) (revert “CORDA-2773).
  • disable hibernate validator integration with hibernate.
  • improve error messages for non composable types.
  • Align timeouts for CRL retrieval and TLS handshake .
  • Remove AMQP system property.
  • Simple prose checking.
  • Minor Typos & Commands info in “Other transaction components” intro.
  • Minor Typographic Changes.
  • Whitelist attachments signed by keys that already sign existing trusted attachments.
  • Prevent node startup if legal identity key is lost but node key isn’t.
  • Change default dataSource.url to match the docker container structure.
  • Change documentation.
  • Allow bring-your-own-config to docker image.
  • Remove the CanonicalizerPluginbuildSrc.
  • Improve Signature Constraints documentation.
  • Automatic propagation of whitelisted to Signature Constraints.
  • Docker build tasks will pull the corda jarartifactory.
  • Support for custom Jackson serializers.
  • Added ability to specify signature scheme when signing.
  • Drop the acknowledge window for RPC responses to 16KB1MB because the memory footprint is multipled by the number of RPC clients.
  • Handle exceptions when file does not exist.
  • Allow users to whitelist attachments by public key config.
  • Remove CORDA_VERSION_THAT_INTRODUCED_FLATTENED_COMMANDS as commands are not flattened anymore.
  • Fix issue with Quasar errors redirecting to useless page.
  • Support custom serialisers when attaching missing attachments to txs.
  • Use compileOnly instead of cordaCompile in irs-demo to depend on node module.
  • Improvements to docker image , compatible with v3.3.
  • Add peer information to stacktrace of received FlowException.
  • Fix to allow softlinks of logs directory.
  • Add dynamic port allocation.
  • relax property type checking.
  • give the message executor its own artemis session and producer.
  • Do not remove exception information in dev mode.
  • Update getting setup guide java details.
  • Documentation around explicit upgrades.
  • Follow up changes to error reporting around failed flows.
  • change parameter syntax to conform to Corda CLI guidelines.
  • relax fingerprinter strictness.
  • Check if resources are in classpath.
  • Improve error reporting around failed flows.
  • Fix the way serialization whitelist is calculated for CorDappImpl.
  • Changed crash version to our latest.
  • Clarify error message when base directory doesn’t exist.
  • Change message when rpc/p2p login fails.
  • Nodeinfo signing tool.
  • Restructure evolution serialization errors to print reason first.
  • Add Java samples to upgrading to Corda 4 documentation.
  • Update contract testing documentation.
  • Do not start the P2P consumer until we have at least one registered handler (the state machine). This prevents message being delivered too early.
  • Fix Progress Tracker bug.

Corda 4.1 release notes

It’s been a little under 3 1/2 months since the release of Corda 4.0 and all of the brand new features that added to the powerful suite of tools Corda offers. Now, following the release of Corda Enterprise Edition 4.0, we are proud to release Corda 4.1, bringing over 150 fixes and documentation updates to bring additional stability and quality of life improvements to those developing on the Corda platform.

Information on Corda Enterprise Edition 4.0 can be found here and here. (It’s worth noting that normally this document would have started with a comment about whether or not you’d been recently domiciled under some solidified mineral material regarding the release of Corda Enterprise Edition 4.0. Alas, we made that joke when we shipped the first release of Corda after Enterprise 3.0 shipped, so the thunder has been stolen and repeating ourselves would be terribly gauche.)

Corda 4.1 brings the lessons and bug fixes discovered during the process of building and shipping Enterprise 4.0 back to the open source community. As mentioned above there are over 150 fixes and tweaks here. With this release the core feature sets of both entities are far closer aligned than past major releases of the Corda that should make testing your CorDapps in mixed type environments much easier.

As such, we recommend you upgrade from Corda 4.0 to Corda 4.1 as soon possible.

Issues Fixed

  • Docker images do not support passing a prepared config with initial registration.
  • Different hashes for container Corda and normal Corda jars.
  • Auto attachment of dependencies fails to find class.
  • Artemis session can’t be used in more than one thread.
  • Property type checking is overly strict.
  • Serialisation bug (or not) when trying to run SWIFT Corda Settler tests.
  • Custom serialisers not found when running mock network tests.
  • Base directory error message where directory does not exist is slightly misleading.
  • Progress tracker not reloadable in checkpoints written in Java.
  • Missing quasar error points to non-existent page.
  • TransactionBuilder can build unverifiable transactions in V5 if more than one CorDapp loaded.
  • The node hangs when there is a dis-connection of Oracle database.
  • Docs: fix the latex warnings in the build.
  • Docs: build the docs page needs updating.
  • Don’t retry database transaction in abstract node start.
  • Upgrade Corda Core to use Java Persistence API 2.2.
  • Improve test reliability by eliminating fixed-duration Thread.sleeps.
  • Not handled exception when certificates directory is missing.
  • Unable to run FinalityFlow if the initiating app has targetPlatformVersion=4 and the recipient is using the old version.
  • Performing a registration with an incorrect Config gives error without appropriate info.
  • Regression: java.lang.Comparable is not on the default whitelist but never has been.
  • Docs: replace version string with things that get substituted.
  • Inconsistent docs between internal and external website.
  • Change the doc substitution so that it works in code blocks as well as in other places.
  • net.corda.core.internal.LazyStickyPool#toIndex can create a negative index.
  • NetworkMapUpdater#fileWatcherSubscription is never assigned and hence the subscription is never cleaned up.
  • Infinite recursive call in NetworkParameters.copy.
  • Unexpected exception de-serializing throwable for OverlappingAttachmentsException.
  • Always log config to log file.
  • ReceiveTransactionFlow states to record flag gets quietly ignored if checkSufficientSignatures = false.
  • Fix Driver’s PortAllocation class, and then use it for Node’s integration tests.
  • State machine logs an error prior to deciding to escalate to an error.
  • Migrate DJVM into a separate module.
  • Error in HikariPool in the performance cluster.
  • Package DJVM CLI for standalone distribution.
  • Unable to insert state into vault if notary not on network map.
  • Create sample code and integration tests to showcase rpc operations that support reconnection.
  • RPC v4 client unable to subscribe to progress tracker events from Corda 3.3 node.
  • Doc Fix: Rpc client connection management section not fully working in Corda 4.
  • AnsiProgressRenderer may start reporting incorrect progress if tree contains identical steps.
  • The FlowProgressHandle does not always return expected results.
  • Doc fix: integration testing tutorial could do with some gradle instructions.
  • Release upgrade to Corda 4 notes: include upgrading quasar.jar explicitly in the Corda Kotlin template.
  • DJVM CLI log file is always empty.
  • DJVM documentation incorrect around djvm check.
  • Doc fix: reflect the CorDapp template doc changes re quasar/test running the official docs.
  • Upgrade to Corda 4 test docs only have Kotlin examples.
  • Log message “Cannot find flow corresponding to session” should not be a warning.
  • Flow failing due to “Flow sessions were not provided” for its own identity.
  • RPC user security using Shiro docs have errant commas in example config.
  • The crlCheckSoftFail option is not respected, allowing transactions even if strict checking is enabled.
  • Vault paging fails if setting max page size to Int.MAX_VALUE.
  • Upgrade to Corda Gradle Plugins 4.0.41.
  • Corda complaining of duplicate classes upon start-up when it doesn’t need to.
  • Launching node explorer for node creates error and explorer closes.
  • Transactions created in V3 cannot be verified in V4 if any of the state types were included in “depended upon” CorDapps which were not attached to the transaction.
  • Reduce CorDapp scanning logging.
  • Clean up verbose warning: ProgressTracker has not been started.
  • Add a no-carpenter context.
  • Improve CorDapp upgrade guidelines for migrating existing states on ledger (pre-V4).
  • SessionRejectException.UnknownClass trapped by flow hospital but no way to call dropSessionInit().
  • Repeated CordFormations can fail with ClassLoader exception.
  • Backwards compatibility break in serialisation engine when deserialising nullable fields.
  • Simplify sample CorDapp projects.
  • Remove ExplorerSimulator from Node Explorer.
  • Reintroduce pendingFlowsCount to the public API.
  • Trader demo integration tests fails with jar not found exception.
  • Fix Source ClassLoader for DJVM.
  • Issue with simple transfer of ownable asset.
  • Fix references to Docker images in docs.
  • Add something to docsite the need for a common contracts Jar between OS/ENT and how it should be compiled against OS.
  • Create document outlining CorDapp Upgrade guarantees.
  • Fix DJVM CLI tool.
  • Corda Service needs Thread Context ClassLoader.
  • Useless migration error when finance workflow jar is not installed.
  • Database connection pools leaking memory on every checkpoint.
  • Exception swallowed when querying vault via RPC with bad page spec.
  • Applying CordFormation and CorDapp Gradle plugins together includes Jolokia into the CorDapp.
  • Provide a better error message on an incompatible implicit contract upgrade.
  • uploadAttachment via shell can fail with unhelpful message if the result of the command is unsuccessful.
  • Provide a better error msg when the notary type is misconfigured on the net params.
  • Maybe tone down the level of panic when somebody types their SSH password in incorrectly.
  • Cannot complete transaction that has unknown states in the transaction history.
  • Switch off the codepaths that disable the FinalityHandler.
  • Updates to API documentation (is our API documentation (what is stable and what isn’t) correct?).
  • Getting set up guide needs to be updated to reflect Java 8 fun and games.
  • Not handle exception when Explorer tries to connect to inaccessible server.
  • Errors received from peers can’t be distinguished from local errors.
  • Add flow kill command, deprecate run killFlow.
  • Hash to signature constraints migration: add a config option that makes hash constraints breakable.
  • Deadlock between database and AppendOnlyPersistentMap.
  • Docfix: Document custom CorDapp configuration.
  • Bootstrapper - option to include contracts to whitelist from signed jars.
  • Explicit contract upgrade sample fails upon initiation (ClassNotFoundException).
  • IRS demo app missing demodate endpoint.
  • Doc fix: Contract testing tutorial errors.
  • Unclear error message when receiving state from node on higher version of signed CorDapp.
  • Terminating ssh connection to node results in stack trace being thrown to the console.
  • Error propagating hash to signature constraints.
  • Unable to import trusted attachment.
  • Invalid node command line options not always gracefully handled.
  • node.conf with rogue line results non-comprehensive error.
  • Fix v4’s inability to migrate V3 vault data.
  • Vault Query fails to process states upon CorDapp Contract upgrade.
  • Signature Constraints end-user documentation is limited.
  • Docs update: document transition from the whitelist constraint to the sig constraint.
  • The ContractUpgradeWireTransaction does not support the Signature Constraint.
  • Intermittent relation “hibernate_sequence” does not exist error when using Postgres.
  • Implement package namespace ownership.
  • Show explicit error message when new version of OS CorDapp contains schema changes.
  • Dockerfile improvements and image size reduction.
  • Update QPID Proton-J library to latest.
  • Not handled excpetion when certificates directory is missing.
  • The DJVM cannot sandbox instances of Contract.verify(LedgerTransaction) when testing CorDapps.
  • State machine logs an error prior to deciding to escalate to an error.
  • Should Jolokia be included in the built jar files?
  • Transactions created in V3 cannot be verified in V4 if any of the state types were included in “depended upon” CorDapps which were not attached to the transaction.
  • Prevent a node re-registering with the doorman if it did already and the node “state” has not been erased.
  • The cert hierarchy diagram for C4 is the same as C3.0 but I thought we changed it between C3.1 and 3.2?
  • Windows build fails with FileSystemException in TwoPartyTradeFlowTests.
  • Cash.generateSpend cannot be used twice to generate two cash moves in the same tx.
  • FlowException thrown by session.receive is not propagated back to a counterparty
  • invalid command line args for corda result in 0 exit code
  • Windows build fails on TwoPartyTradeFlowTests
  • C4 performance below C3, bring it back into parity
  • Deserialisation of ContractVerificationException blows up trying to put null into non-null field
  • Reference state test (R3T-1918) failing probably due to unconsumed linear state that was referenced.
  • Signature constraint: Jarsigner verification allows removal of files from the archive.
  • Node explorer bug revealed from within Demobench: serialisation failed error is shown
  • Security: Fix vulnerability where an attacker can use CustomSerializers to alter the meaning of serialized data
  • Node/RPC is broken after CorDapp upgrade
  • RPC client disconnects shouldn’t be a warning
  • Hibernate logs warning and errors for some conditions we handle

Corda 4 release notes

Welcome to the Corda 4 release notes. Please read these carefully to understand what’s new in this release and how the changes can help you. Just as prior releases have brought with them commitments to wire and API stability, Corda 4 comes with those same guarantees. States and apps valid in Corda 3 are usable in Corda 4.

For app developers, we strongly recommend reading “Upgrading CorDapps to newer Platform Versions”. This covers the upgrade procedure, along with how you can adjust your app to opt-in to new features making your app more secure and easier to upgrade in future.

For node operators, we recommend reading “Upgrading your node to Corda 4”. The upgrade procedure is simple but it can’t hurt to read the instructions anyway.

Additionally, be aware that the data model improvements are changes to the Corda consensus rules. To use apps that benefit from them, all nodes in a compatibility zone must be upgraded and the zone must be enforcing that upgrade. This may take time in large zones. Please take this into account for your own schedule planning.

Changes for developers in Corda 4

Reference states

With Corda 4 we are introducing the concept of “reference input states”. These allow smart contracts to reference data from the ledger in a transaction without simultaneously updating it. They’re useful not only for any kind of reference data such as rates, healthcare codes, geographical information etc, but for anywhere you might have used a SELECT JOIN in a SQL based app.

A reference input state is a ContractState which can be referred to in a transaction by the contracts of input and output states but, significantly, whose contract is not executed as part of the transaction verification process and is not consumed when the transaction is committed to the ledger. Rather, it is checked for “current-ness”. In other words, the contract logic isn’t run for the referencing transaction only. Since they’re normal states, if they do occur in the input or output positions, they can evolve on the ledger, modeling reference data in the real world.

Signature constraints

CorDapps built by the corda-gradle-plugins are now signed and sealed JAR files by default. This signing can be configured or disabled with the default certificate being the Corda development certificate.

When an app is signed, that automatically activates the use of signature constraints, which are an important part of the Corda security and upgrade plan. They allow states to express what contract logic governs them socially, as in “any contract JAR signed by a threshold of these N keys is suitable”, rather than just by hash or via zone whitelist rules, as in previous releases.

We strongly recommend all apps be signed and use signature constraints going forward.

Learn more about this new feature by reading the Upgrading CorDapps to newer Platform Versions.

State pointers

State Pointers formalize a recommended design pattern, in which states may refer to other states on the ledger by StateRef (a pair of transaction hash and output index that is sufficient to locate any information on the global ledger). State pointers work together with the reference states feature to make it easy for data to point to the latest version of any other piece of data, with the right version being automatically incorporated into transactions for you.

New network builder tool

A new graphical tool for building test Corda networks has been added. It can build Docker images for local deployment and can also remotely control Microsoft Azure, to create a test network in the cloud.

Learn more on the Corda Network Builder page.

network builder v4

JPA access in flows and services

Corda 3 provides the jdbcConnection API on FlowLogic to give access to an active connection to your underlying database. It is fully intended that apps can store their own data in their own tables in the node database, so app-specific tables can be updated atomically with the ledger data itself. But JDBC is not always convenient, so in Corda 4 we are additionally exposing the Java Persistence Architecture, for object-relational mapping. The new ServiceHub.withEntityManager API lets you load and persist entity beans inside your flows and services.

Please do write apps that read and write directly to tables running alongside the node’s own tables. Using SQL is a convenient and robust design pattern for accessing data on or off the ledger.

Security upgrades

Sealing. Sealed JARs are a security upgrade that ensures JARs cannot define classes in each other’s packages, thus ensuring Java’s package-private visibility feature works. The Gradle plugins now seal your JARs by default.

BelongsToContract annotation. CorDapps are currently expected to verify that the right contract is named in each state object. This manual step is easy to miss, which would make the app less secure in a network where you trade with potentially malicious counterparties. The platform now handles this for you by allowing you to annotate states with which contract governs them. If states are inner classes of a contract class, this association is automatic. See API: Contract Constraints for more information.

Two-sided FinalityFlow and SwapIdentitiesFlow. The previous FinalityFlow API was insecure because nodes would accept any finalised transaction, outside of the context of a containing flow. This would allow transactions to be sent to a node bypassing things like business network membership checks. The same applies for the SwapIdentitiesFlow in the confidential-identities module. A new API has been introduced to allow secure use of this flow.

Package namespace ownership. Corda 4 allows app developers to register their keys and Java package namespaces with the zone operator. Any JAR that defines classes in these namespaces will have to be signed by those keys. This is an opt-in feature designed to eliminate potential confusion that could arise if a malicious developer created classes in other people’s package namespaces (e.g. an attacker creating a state class called com.megacorp.exampleapp.ExampleState). Whilst Corda’s attachments feature would stop the core ledger getting confused by this, tools and formats that connect to the node may not be designed to consider attachment hashes or signing keys, and rely more heavily on type names instead. Package namespace ownership allows tool developers to assume that if a class name appears to be owned by an organisation, then the semantics of that class actually were defined by that organisation, thus eliminating edge cases that might otherwise cause confusion.

Network parameters in transactions

Transactions created under a Corda 4+ node will have the currently valid signed NetworkParameters file attached to each transaction. This will allow future introspection of states to ascertain what was the accepted global state of the network at the time they were notarised. Additionally, new signatures must be working with the current globally accepted parameters. The notary signing a transaction will check that it does indeed reference the current in-force network parameters, meaning that old (and superseded) network parameters can not be used to create new transactions.

RPC upgrades

AMQP/1.0 is now default serialization framework across all of Corda (checkpointing aside), swapping the RPC framework from using the older Kryo implementation. This means Corda open source and Enterprise editions are now RPC wire compatible and either client library can be used. We previously started using AMQP/1.0 for the peer to peer protocol in Corda 3.

Class synthesis. The RPC framework supports the “class carpenter” feature. Clients can now freely download and deserialise objects, such as contract states, for which the defining class files are absent from their classpath. Definitions for these classes will be synthesised on the fly from the binary schemas embedded in the messages. The resulting dynamically created objects can then be fed into any framework that uses reflection, such as XML formatters, JSON libraries, GUI construction toolkits, scripting engines and so on. This approach is how the Blob Inspector tool works - it simply deserialises a message and then feeds the resulting synthetic class graph into a JSON or YAML serialisation framework.

Class synthesis will use interfaces that are implemented by the original objects if they are found on the classpath. This is designed to enable generic programming. For example, if your industry has standardised a thin Java API with interfaces that expose JavaBean style properties (get/is methods), then you can have that JAR on the classpath of your tool and cast the deserialised objects to those interfaces. In this way you can work with objects from apps you aren’t aware of.

SSL. The Corda RPC infrastructure can now be configured to utilise SSL for additional security. The operator of a node wishing to enable this must of course generate and distribute a certificate in order for client applications to successfully connect. This is documented here Working with the CordaRPCClient API

Preview of the deterministic DJVM

It is important that all nodes that process a transaction always agree on whether it is valid or not. Because transaction types are defined using JVM byte code, this means that the execution of that byte code must be fully deterministic. Out of the box a standard JVM is not fully deterministic, thus we must make some modifications in order to satisfy our requirements.

This version of Corda introduces a standalone Deterministic JVM. It isn’t yet integrated with the rest of the platform. It will eventually become a part of the node and enforce deterministic and secure execution of smart contract code, which is mobile and may propagate around the network without human intervention.

Currently, it is released as an evaluation version. We want to give developers the ability to start trying it out and get used to developing deterministic code under the set of constraints that we envision will be placed on contract code in the future. There are some instructions on how to get started with the DJVM command-line tool, which allows you to run code in a deterministic sandbox and inspect the byte code transformations that the DJVM applies to your code. Read more in “Deterministic JVM”.

Configurable flow responders

In Corda 4 it is possible for flows in one app to subclass and take over flows from another. This allows you to create generic, shared flow logic that individual users can customise at pre-agreed points (protected methods). For example, a site-specific app could be developed that causes transaction details to be converted to a PDF and sent to a particular printer. This would be an inappropriate feature to put into shared business logic, but it makes perfect sense to put into a user-specific app they developed themselves.

If your flows could benefit from being extended in this way, read “Configuring Responder Flows” to learn more.

Target/minimum versions

Applications can now specify a target version in their JAR manifest. The target version declares which version of the platform the app was tested against. By incrementing the target version, app developers can opt in to desirable changes that might otherwise not be entirely backwards compatible. For example in a future release when the deterministic JVM is integrated and enabled, apps will need to opt in to determinism by setting the target version to a high enough value.

Target versioning has a proven track record in both iOS and Android of enabling platforms to preserve strong backwards compatibility, whilst also moving forward with new features and bug fixes. We recommend that maintained applications always try and target the latest version of the platform. Setting a target version does not imply your app requires a node of that version, merely that it’s been tested against that version and can handle any opt-in changes.

Applications may also specify a minimum platform version. If you try to install an app in a node that is too old to satisfy this requirement, the app won’t be loaded. App developers can set their min platform version requirement if they start using new features and APIs.

Dependency upgrades

We’ve raised the minimum JDK to 8u171, needed to get fixes for certain ZIP compression bugs.

We’ve upgraded to Kotlin 1.2.71 so your apps can now benefit from the new features in this language release.

We’ve upgraded to Gradle 5.4.1.

Changes for administrators in Corda 4

Official Docker images

Corda 4 adds an Official Corda Docker Image for starting the node. It’s based on Ubuntu and uses the Azul Zulu spin of Java 8. Other tools will have Docker images in future as well.

Auto-acceptance for network parameters updates

Changes to the parameters of a compatibility zone require all nodes to opt in before a flag day.

Some changes are trivial and very unlikely to trigger any disagreement. We have added auto-acceptance for a subset of network parameters, negating the need for a node operator to manually run an accept command on every parameter update. This behaviour can be turned off via the node configuration. See The network map.

Automatic error codes

Errors generated in Corda are now hashed to produce a unique error code that can be used to perform a lookup into a knowledge base. The lookup URL will be printed to the logs when an error occur. Here’s an example:

[ERROR] 2018-12-19T17:18:39,199Z [main] internal.NodeStartupLogging.invoke - Exception during node startup: The name 'O=Wawrzek Test C4, L=London, C=GB' for identity doesn't match what's in the key store: O=Wawrzek Test C4, L=Ely, C=GB [errorCode=wuxa6f, moreInformationAt=]

The hope is that common error conditions can quickly be resolved and opaque errors explained in a more user friendly format to facilitate faster debugging and trouble shooting.

At the moment, Stack Overflow is that knowledge base, with the error codes being converted to a URL that redirects either directly to the answer or to an appropriate search on Stack Overflow.

Standardisation of command line argument handling

In Corda 4 we have ported the node and all our tools to use a new command line handling framework. Advantages for you:

  • Improved, coloured help output.
  • Common options have been standardised to use the same name and behaviour everywhere.
  • All programs can now generate bash/zsh auto completion files.

You can learn more by reading our CLI user experience guidelines document.

Liquibase for database schema upgrades

We have open sourced the Liquibase schema upgrade feature from Corda Enterprise. The node now uses Liquibase to bootstrap and update itself automatically. This is a transparent change with pre Corda 4 nodes seamlessly upgrading to operate as if they’d been bootstrapped in this way. This also applies to the finance CorDapp module.

Ability to pre-validate configuration files

A new command has been added that lets you verify a config file is valid without starting up the rest of the node:

java -jar corda-4.0.jar validate-configuration

Flow control for notaries

Notary clusters can now exert backpressure on clients, to stop them from being overloaded. Nodes will be ordered to back off if a notary is getting too busy, and app flows will pause to give time for the load spike to pass. This change is transparent to both developers and administrators.

Retirement of non-elliptic Diffie-Hellman for TLS

The TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 family of ciphers is retired from the list of allowed ciphers for TLS as it is a legacy cipher family not supported by all native SSL/TLS implementations. We anticipate that this will have no impact on any deployed configurations.

Miscellaneous changes

To learn more about smaller changes, please read the Changelog.

Finally, we have added some new jokes. Thank you and good night!

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.