Cadence updates for the Nov 2022 Mainnet Spork

Since the last spork in August, which deployed Cadence v0.25.0, the Cadence team has been busy and released three major versions of Cadence. These changes have been deployed on Testnet as part of the Testnet spork on October 19th by deploying Cadence v0.28.0 and will be deployed to Mainnet on November 2nd.

We wanted to highlight several of the new features and improvements of Cadence v0.26.0 to v0.28.0.



Paths can now be compared and the () literal has been introduced to construct the Void value.

Interface Default Functions

Cadence now supports default implementations in interfaces: If a type that implements an interface does not provide an implementation for a function required by the interface, then the interface’s default function, if any, is used in the implementation.

This feature reduces the amount of code, developers have to write to adopt an interface and is also useful for updating interfaces in a backwards-compatible way.

Standard library

Storage Iteration

Cadence now supports iterating over account storage with a suite of new fields and functions on account objects:

let publicPaths: [PublicPath]
let privatePaths: [PrivatePath]
let storagePaths: [StoragePath]

fun forEachPublic(_ function: ((PublicPath, Type): Bool))
fun forEachPrivate(_ function: ((PrivatePath, Type): Bool))
fun forEachStored(_ function: ((StoragePath, Type): Bool))

This new API is available on the AuthAcccount object, and the PublicPath-specific features are also available on PublicAccount objects.

The three Paths fields are arrays containing all the paths in use in each of the /public, /private, and /storage domains, while the three new methods iterate over these storage domains, applying the provided callback function to each path in the domain. The first parameter of this callback function is the actual Path value in question, while the Type parameter is the runtime type of the value stored at that Path. So if a user had previously stored a value of type MyNFT at /storage/myNFTpath, these arguments to this function when considering that path would be /storage/myNFTPath and Type<@MyNFT>.

These functions by default do not load the actual value stored at each path, as this is a potentially expensive operation, and also has the potential to mutate storage. If users wish to inspect the actual stored values during iteration (as opposed to just the Paths and Types), we recommend doing so with copy or borrow (in the case of storage paths) or getCapability (in the case of public and private paths) in the body of the callback function.

The Bool return of the callback function indicates whether should continue after the callback finishes executing for a path; true causing iteration to continue and false causing it to terminate. So, for example, when using these functions to search storage for a value satisfying a specific predicate, one might return false after such a value is found in order to prevent needlessly checking all the other stored values.

More details about this new API can be found here, including some important caveats about the order of iteration and how mutation is handled.

With this new API, scripts like this one to get all the NFTs in an account will be significantly easier to write and will not need to rely on libraries like the NFTCatalog, which require manual approval of each new NFT type. In general, user agents like wallets will now be able to introspect accounts and display their content without needing to explicitly handle and support specific data types and paths.

Conversion Functions

Cadence now provides the function String.fromUTF8 which can be used to convert a byte array of UTF-8 data ([UInt8]) into a string.

In addition, the number types, like Int and UInt64, have gained a fromString function, which can be used to convert a String to the number.

Iteration Functions

It is now possible to iterate over dictionaries’ keys using the forEachKey function.


The new Cadence testing framework provides a convenient way to write tests for Cadence programs in Cadence. To learn more about writing tests in Cadence, have a look at the documentation here.

The testing framework will be available through the flow-CLI. See here on how to run tests using the CLI.


Type Checking

The type checking for resources has been fixed and significantly improved, especially for cases where control flow statements (e.g. break , continue, etc.) are involved.

In addition, some of the error messages have been improved. For example, for type mismatch errors, the error message now includes both the actual and the expected type.


All components of Cadence, i.e. the parser, type checker, and interpreter, have been optimized in multiple ways. As a result, Cadence has gotten significantly faster and its memory consumption has been reduced.


The REPL has been improved and is now able to gracefully handle static errors, such as parsing or type-checking errors, as well as execution errors.

Cadence releases

1 Like