github.com/onflow/cadence

The Cadence v1.7.0 release marks a major step forward for Cadence. This upgrade delivers powerful new features that make Cadence more precise, more consistent, and more approachable for both developers and AI agents. With improvements ranging from higher-precision numeric types to more descriptive, AI-friendly error messages, Cadence v1.7.0 strengthens its position as the most developer-friendly smart contract language in Web3.

The upgrade advances the Cadence roadmap across three key dimensions: developer experience, consistency and precision in financial workloads, and AI-powered autonomy. Together, these improvements ensure that building on Flow with Cadence is faster, safer, and more aligned with the future of agent-assisted development.

Introducing Fix128 and UFix128 for high-precision math

Cadence extends its fixed-point number system with Fix128 and UFix128, 128-bit fixed-point types that support precision up to 24 decimal places. Until now, developers relied on Fix64/UFix64, which are limited to eight decimal places. For many financial workloads such as interest accrual, risk modeling, and per-second rate calculations, this level of precision could fall short and force developers to manually convert values into scaled integers, which could introduce errors. The new 128-bit types expand numeric range while dramatically increasing fractional precision (24 decimal places vs eight), enabling accurate, high-resolution financial computations without custom math scaffolding. All values from Fix64/UFix64 convert losslessly to their 128-bit counterparts. Converting in the other direction can result in a range error, which will abort the transaction, and/or lost precision, which developers must handle explicitly, hence errors cannot go unnoticed.

This is the implementation of FLIP 341: Add 128-bit fixed-point types to Cadence.

On Ethereum, tokens and DeFi protocols typically represent fractional values by storing large integers alongside a decimals field (e.g. 18), leaving rounding and precision management to application code. Cadence eliminates this burden by providing fixed-point types natively at both 64-bit and 128-bit precision, significantly reducing rounding-related errors in application code.

Example:

Solidity (integer math with decimals)

// ERC-20 token with 18 decimals
uint8 public constant decimals = 18;  

// Balance stored as integer with scaling
uint256 public balance = 1500 * (10 ** decimals);  
// balance represents "1500.000000000000000000"

// Annual interest rate, represented as integer with scaling
// 5% = 0.05, so store 0.05 * 1e18
uint256 public yearlyRate = 5 * (10 ** 16);  

// Seconds in a year
uint256 public constant SECONDS_PER_YEAR = 31_536_000;  

// Per-second interest rate, using integer division
uint256 public perSecondRate = yearlyRate / SECONDS_PER_YEAR;  

// Updated balance after one second (simplified)
uint256 public updated = balance * (10**18 + perSecondRate) / 10**18;

Cadence (native fixed-point types)

let preciseBalance: UFix128 = 1500.0

let yearlyRate: UFix128 = 0.05   // 5% interest
let perSecondRate = yearlyRate / 31536000.0  // seconds in a year

let updated = preciseBalance * (1.0 + perSecondRate)

Fix numeric type rounding inconsistency

In the same vein as introducing higher-precision fixed-point numbers, Cadence has also unified the rounding behavior of its numeric types to remove inconsistencies. Previously, Fix64 and large integer types like Int128 and Int256 used Euclidean division semantics, which produced different results for negative values compared to smaller integer types. With this change, all numeric types, including Fix64, now consistently use truncation when handling division of negative numbers. This ensures predictable and uniform arithmetic across the language, reducing surprises for developers.

This is the implementation of FLIP 342: Fix numeric type rounding inconsistency

Example

Before:

Fix64(-0.00000005) / Fix64(2.0) == Fix64(-0.00000003)

Now:

Fix64(-0.00000005) / Fix64(2.0) == Fix64(-0.00000002)

Descriptive, AI- and human-friendly Cadence errors

Cadence already lends itself well to AI assistance, and this release strengthens that foundation by making compiler and linter errors far more descriptive and actionable. In the past, many errors such as those triggered by deprecated pre-1.0 keywords like pub only stated what was invalid, without suggesting how to fix it or linking to migration notes. This left both developers and AI agents without enough context to resolve issues automatically.

Error messages have now been rewritten to explain the cause, suggest concrete fixes, and link directly to reference documentation. For example:

Before:

pub fun foo() {}
// error: 'pub' is no longer a valid access keyword

Now:

pub fun foo() {}
// error: 'pub' is no longer a valid access keyword
// note: replace with 'access(all)' for the same effect
// see: https://developers.flow.com/cadence/migration-guide

These enriched messages are also exposed through the Cadence language server, so IDEs and agent-based tools like Cursor can automatically apply the recommended fix, follow the link, and validate the change. The result is faster feedback, fewer trips to documentation, and a smoother path for both humans and AI agents working with Cadence.

Import Aliasing

Previously, developers could not import two contracts with the same name in the same scope, which led to conflicts and forced duplication of code when working with multiple contracts such as different token implementations. To address this, Cadence now supports import aliasing, allowing developers to assign custom names to imported contracts. For example,

import FUSD as FUSD1 from 0x02
import FUSD as FUSD2 from 0x03

This reduces code duplication, prevents naming conflicts, and improves readability. It is the implementation of FLIP 314: Import Aliasing.

Cadence Runtime Transition: Interpreter → Compiler & VM

Cadence is progressing from its current interpreter to a new compiler and virtual machine. Historically, programs were executed by an interpreter that traverses the Abstract Syntax Tree (AST), which enabled rapid language evolution but limited runtime performance. With the compiler, Cadence programs are translated into a lower-level bytecode executed by a dedicated VM. This reduces AST overhead for improved performance and establishes a unified runtime that simplifies backward compatibility, since contracts from different Cadence versions compile to a common instruction set. Existing smart contracts continue to function without modification as the language evolves. See here for more information.

Once complete, the new compiler/VM backend will be deployed in an upcoming release, opening the door to performance gains and a more flexible path to long-term language evolution. Developers do not need to change how they write or deploy contracts. Compilation occurs automatically within the Cadence execution runtime.

Key updates in this release:

Full compiler and VM implementation

Implementation of all Cadence language features in the compiler and VM is now complete.

Compatibility verification

Key book-keeping functions have been validated, including fee deduction, account storage limit checks, and minimum account balance checks. Executing these paths with the compiler and VM yields results identical to the interpreter. Significant progress has also been made on the correctness of user transaction execution, which remains the primary focus going forward.

Performance improvements

Early benchmarks already show meaningful performance gains, establishing a solid foundation for further optimization.

---