Skip to main content

Manifest Reference

Move.toml is the manifest file for a Sui Move package. It declares the package name, dependencies, network environments, and environment-specific dependency overrides. Every Move project has a Move.toml at its root (Move package management).

This reference covers the syntax and available fields for each section of Move.toml.

Move.toml structure​

A Move.toml manifest can contain the following top-level sections:

[package]
name = "<package-name>"
# Optional: edition = "2024"
# Optional: implicit-dependencies = false

[dependencies]
# Package dependencies (mvr, git, local, or system)

[environments]
# Custom environment definitions mapping names to chain IDs

[dep-replacements.<env>]
# Environment-specific dependency overrides

[package]​

FieldRequiredDescription
nameYesThe package name.
editionNoMove edition (for example, "2024").
implicit-dependenciesNoSet to false to exclude the default std and sui dependencies.

[dependencies]​

Lists the packages your project depends on. Each dependency has a name (the key) and a source specifier (the value). The following dependency formats are available:

FormatSyntaxWhen to use
MVR (Move Registry)name = { r.mvr = "@SCOPE/PACKAGE" }Published packages registered in the Move Registry
Gitname = { git = "URL", subdir = "PATH", rev = "BRANCH_OR_TAG" }Packages hosted in a Git repository. subdir is required when the package is not at the repo root. rev specifies a branch, tag, or commit hash.
Localname = { local = "../path/to/package" }Packages on your local filesystem (useful during development)

The sui and std framework dependencies are resolved automatically. You do not need to add them to [dependencies] unless you set implicit-dependencies = false in [package].

[environments]​

Maps custom environment names to chain identifiers. The mainnet and testnet environments are implicitly available and do not need to be listed.

Chain IDs accept either format interchangeably:

  • Hex (short form): the first 4 bytes of the genesis checkpoint digest, hex-encoded (for example, "aba3e445").
  • Base58 (full form): the complete genesis checkpoint digest, Base58-encoded (for example, "69WiPg3DAQhKenaFN9I6pYc7MYk...").

The package system compares chain IDs by their underlying bytes, so a Hex value in the manifest matches a Base58 value from the CLI and vice versa.

Use sui client chain-identifier to look up both formats for the network you are connected to.

[dep-replacements.<ENV>]​

Overrides dependencies for a specific environment. Replace ENV with the environment name (mainnet, testnet, or a custom name defined in [environments]). Each entry in the section replaces the corresponding dependency from [dependencies] when you build or publish for that environment.

Dependency replacements support the same formats as [dependencies] (MVR, Git, local). You can also use the use-environment key to instruct the resolver to use the address published on a different environment:

[dep-replacements.mainnet]
my-dep = { use-environment = "testnet" }

This tells the resolver to use the testnet published address for my-dep when building for mainnet. This is useful when a dependency has not yet been published on Mainnet but has a Testnet deployment you can reference.

See environment-specific dependencies for details and additional examples.

Example manifests​

Minimal manifest​

A basic project that only depends on sui and std (resolved automatically):

[package]
name = "my_project"
edition = "2024"

MVR and Git dependencies​

A package with an MVR dependency and a Git dependency that uses a different branch for Mainnet:

[package]
name = "my_project"
edition = "2024"

[dependencies]
ascii = { r.mvr = "@potatoes/ascii" }
my_lib = { git = "https://github.com/ORGANIZATION/REPO.git", subdir = "packages/my_lib", rev = "testnet" }

[dep-replacements.mainnet]
my_lib = { git = "https://github.com/ORGANIZATION/REPO.git", subdir = "packages/my_lib", rev = "mainnet" }

The [dep-replacements.mainnet] section overrides my_lib when you build with --build-env mainnet. The ascii MVR dependency does not need an override because MVR resolves network-specific addresses automatically.

Custom environment with dep-replacements​

A package that defines a custom staging environment and uses use-environment to reference addresses from a different network:

[package]
name = "my_project"
edition = "2024"

[environments]
staging = "4c78adac"

[dependencies]
ascii = { r.mvr = "@potatoes/ascii" }
my_lib = { git = "https://github.com/ORGANIZATION/REPO.git", subdir = "packages/my_lib", rev = "testnet" }

[dep-replacements.staging]
ascii = { use-environment = "testnet" }
my_lib = { use-environment = "testnet" }

The use-environment key tells the resolver to use the published address from the specified environment. In this example, building for staging uses the Testnet addresses for both dependencies.

FAQ​

When should you use Git dependencies versus MVR?​

Use MVR for packages registered in the Move Registry (these resolve network-specific addresses automatically). Use Git dependencies for packages not registered in MVR, or when you need to pin to a specific branch, tag, or commit.

How do environments affect publishing?​

The environment determines which dependency addresses the compiler uses during the build. When you publish with sui client publish, the active environment (set with --build-env or inferred from the connected network) determines which [dep-replacements] section applies.

What is a lockfile?​

The Move.lock file records the exact resolved versions and addresses of your dependencies. It is generated automatically when you build. Commit Move.lock to version control to ensure reproducible builds.