Resources in Cadence are automatically assigned a unique identifier. The identifier is unique and is accessible through the
uuid field, and has the type
UInt64, a 64-bit unsigned integer.
Like warned about in the documentation, the details of how the identifiers are generated is an implementation detail, and developers should not assume any particular behavior.
Still, the behavior of the resource ID generation is changing, and this may impact programs that had previously made assumptions about the behavior of the IDs are generated.
Previously, resource IDs were generated in a sequential scheme: Newer resources got higher IDs, older resources have lower IDs.
After the change, resource IDs are no longer generated sequentially.
This means that resource IDs are more likely to be distributed in the full range of the integer space, e.g. higher than the maximum of
Applications working with resource IDs may have previously used data types which do not support the representation of the full range of 64-bit unsigned integers. Before, this did not cause problems, as the number of generated resource IDs was still small.
For example, databases like PostgreSQL and Firebase do not natively support 64-bit unsigned integers, so developers might have used types with smaller ranges. In PostgreSQL, use
NUMERIC(20,0), not a type like
bigint (only a signed 64-bit integer).
number type can only safely store integers up to 2^53 − 1 (see (
This change was made to remove a bottleneck for concurrent execution. Previously, the ID generator was a global state, and all transactions generating IDs would be bottlenecked by the generator and couldn’t be parallelized. Concurrent execution is required to unlock higher TPS on the network, and updates are being rolled out piecemeal since it’s a fairly large change. Concurrent execution will be turned on once its feature complete.
This change has been deployed on Flow testnet and will be deployed to Flow mainnet after the Flow mainnet upgrade on Nov 8th, 2023.
The change has been rolled back from Testnet as of today, Oct 27th.
The decision on whether or not the change will be rolled out to mainnet as part of the network upgrade (spork) on Nov 8th is still pending.
The change has been on the emulator since July this year.
Resource id generation has always been an implementation detail, and dApps or client code should not rely on any particular behaviour (see warning here: Resources | Cadence)
If you are using a signed integer type (see Integers) to store the UUID, those values may overflow causing IDs to no longer be unique.
If you are using an signed integer to store the resource.uuid please switch to using an unsigned integer.
More about the change: See pull request: Partition UUID to reduce transaction conflicts by pattyshack · Pull Request #4497 · onflow/flow-go · GitHub