# Dojo 1.7 / Starknet 0.14 migration guide

## Starknet 0.14.0

Starknet's [upcoming 0.14.0 upgrade](https://community.starknet.io/t/sn-0-14-0-pre-release-notes/115618) represents a big step forward for the network, migrating to a multi-sequencer architecture.

**The upgrade is scheduled to go live on mainnet September 1, 2025.**

Some of the key changes include:

- The move to a multi-sequencer architectures (3 sequencers!)
- Introduction of RPC 0.9 and the "Preconfirmed" status
- Ending support for v1, v2, and RPC-0.7 v3 transactions
- Advanced fee markets (following EIP-1559)

[See the Starknet governance proposal](https://governance.starknet.io/voting-proposals/9)

[See the Starknet 0.14 release notes](https://docs.starknet.io/resources/version-notes/#starknet_v0_14_0_aug_18_25)

[See more information about Starknet transactions](https://docs.starknet.io/architecture/transactions/)

[See the Starknetjs v8 migration guide](https://starknetjs.com/docs/next/guides/migrate/)

[See the RPC 0.9 spec](https://github.com/starkware-libs/starknet-specs/releases/tag/v0.9.0)

### Multi-Sequencer Architecture

Starknet 0.14.0 introduces of multiple sequencers, who will produce blocks round-robin, running Tendermint consensus on each block. Each sequencer will keep its *own transaction mempool* which is not gossiped to other sequencers. However, once a sequencer accepts a transaction (`pre_confirmed`), it *will* gossip the transaction to other sequencers, ensuring transactions are processed regardless of which sequencer receives the request.

Note that currently, p2p communication is not enabled for full nodes. **This means that full nodes *are not aware* of transactions submitted by other nodes, until they are confirmed.** Users are advised to maintain sticky HTTP connections to a single full node in order to get accurate information about transaction status.

### Pending vs Preconfirmed Transaction Status

Previously, a sequencer would execute transactions while preparing a block and tag those transactions as "pending". These transactions would often be displayed as "finalized on L2" even though there was still a chance that the block would fail to finalize (e.g. in the case of a sequencer crash or L1 re-org). This created confusing edge-cases where "confirmed" transactions might be rolled back, impeding UI development.

The introduction of the "preconfirmed" state clarifies the distinction between a transaction which a sequencer has successfully executed (i.e. "preconfirmed") but has not yet been "accepted on L2" (i.e. achieved finality). This allows for a more reliable UX, **with "preconfirmed" status available within 0.5 seconds of tx submission.**

### New Mempool behaviors

Various change to how transactions are treated in the mempool.

- Increasing the fee by 10%+ will replace a pending same-nonce tx
- Transactions have a 5 min TTL, after which they will be booted from the mempool
- A nonce increase of +50-100 from the previous accepted nonce will be rejected

## Dojo 1.7.0

As part of the Starknet 0.14.0 upgrade, Dojo will be releasing version 1.7.0 of the framework and its toolchain, with several important changes.

**Dojo v1.7 is targeting internal prerelease August 12, and public release on August 15.**

### Dojo

Dojo v1.7.0 will introduce the new `DojoStore` trait as a solution to limitations regarding enum serialization. See [this guide](https://hackmd.io/@remyb/HyKHqDqull) for more context.

### Installation

There is now asdf plugins for each tool of the stack :
`asdf plugin add katana https://github.com/dojoengine/asdf-katana.git`
`asdf plugin add torii https://github.com/dojoengine/asdf-torii.git`
`asdf plugin add sozo https://github.com/dojoengine/asdf-sozo.git`

sozo v1.7.0-alpha.1 still relies on a nightly scarb version :
`asdf install scarb nightly-2025-05-08`

### Katana

Katana v1.7.0 introduces support for RPC 0.9, and removes support for RPC 0.8 or below.

### Torii

Torii v1.7.0 introduces support for RPC 0.9, and removes support for RPC 0.8 or below.

### Dojo.js

Dojo.js v1.7.0 bumps the underlying starknet.js to the 0.14.0-compatible v8.

### Dojo.c

Dojo.c v1.7.0 bumps the underlying Dojo, Torii, and starknet-rs dependencies.

## Migration Guide

Note: Dojo 1.7 includes breaking changes for both contracts and infrastructure. However, they do not need to be migrated synchronously. Existing deployed contracts will continue to work while migrating infrastructure to Starknet 0.14; contract changes are necessary only as part of ongoing contract development.

### Contract Updates

The introduction of the new `DojoStore` trait affects serialization for all Dojo models containing enums. If this applies to your project, you will need to do a simple migration to avoid data loss. Note that this is a **breaking change**.

More information and instructions can be found [in this document](https://hackmd.io/@remyb/HyKHqDqull).

### Slot Users

For Slot users, all Katana and Torii instances will be upgraded automatically. No action is necessary on your part.

Please ensure that any other infrastructure / RPC nodes are upgraded to RPC 0.9.

### Manual Deployments

For teams managing Katana or Torii instances manually, please upgrade your instances to their respective 1.7 versions.

If using your own deployers / executors, please ensure your accounts have support for v3 transactions.

### Client SDK Updates

For teams using Dojo.js or Dojo.c for their clients, please upgrade to version 1.7 to ensure compatibility with Katana and Torii.

#### Dojo.js

The main differences you'll need to migrate are documented here in [starknet.js](https://starknetjs.com/docs/next/guides/migrate/).

#### Dojo.c

You should be able to use the wasm build with no changes. However if you're using the RPC client directly, upgrade the `starknet` crate to `v0.17.0`.