Deploy a digital asset

A digital asset takes one of three shapes: a single piece, a collection, or a generative program. The deploy flow is the same for each; they differ in the command and its options. For each, you choose how much of the asset is stored on-chain.

Any of the three shapes can also be a copies-based edition instead of unique tokens — that's a separate, orthogonal choice from which shape you pick.

Before a real launch, decide two things (an agent will ask you these): how much of the asset is stored on-chain (see the on-chain spectrum), and where the source bytes are stored (see Storage).

Single asset

abx deploy --image ./art.png --name "..." --symbol ABX --sign

Deploys one 1/1 token and indexes it. No server is required. Notable options:

• --onchain-image: store the image bytes on-chain through the chunk store. This implies --onchain-uri. Add --compress fastlz or --compress gzip to compress them.
• --onchain-uri: resolve tokenURI and contractURI fully on-chain.
• --description, --external-url, --traits "k=v; k2=v2", and --royalty-bps <0-10000> (default 500).
• --no-mint to deploy without minting, and --salt 0x... to deploy to a predicted address.

A plain 1/1 has no built-in primary sale. To sell a single piece through the fixed-price minter, deploy a one-token collection instead (abx deploy-series --count 1), or — if copies of that piece are fine — an edition (abx deploy --copies <n|open>), which ships its own sale stack.

Collection

abx deploy-series --dir ./art --name "..." --symbol ABX --sign

Deploys one contract and mints many tokens from a folder of media. Files sort into token ids 0, 1, 2, .... Notable options:

• Mint timing: --mint-all, --mint-count N, or --no-mint.
• Image custody: --onchain-image [--compress fastlz]; or --onchain-uri --backend arweave|ipfs|cloud, which puts the image off-chain and the JSON on-chain with no server; or --public-base-url <url> for a hosted resolver.
• --minter 0x..., --primary-payee 0x..., and --unpaused (the default is paused).

Generative or code

abx inspect ./sketch.js
abx deploy-code --script ./sketch.js --public-base-url <url> --sign

Run inspect first: it analyzes a script for traits, on-chain reproducibility, and dependencies, and recommends a lane. deploy-code then deploys the project. It needs a resolver you run (--public-base-url) or the fully on-chain lane (--onchain-uri). Notable options:

• Source: --script <file> (the program on-chain in chunks), --code-dir <dir> (an off-chain build with an index.html), or --image-renderer 0x... (a Solidity SVG renderer).
• --dep <ref> (repeatable and ordered; index 0 is the runtime; name@version or an address), and --dep-registry 0x....
• --schema key:Type:Auth,... for governed parameters, for example palette:HexColor:TokenOwner.
• --image-base <url> for off-chain thumbnails, or --attributes-renderer 0x... for on-chain traits.

You can have both: a live program and an on-chain thumbnail

--script and --image-renderer are not an either-or, which is the most common misreading of the two lanes. Passing both gives every surface an on-chain home in one deploy:

abx deploy-code --script ./sketch.js \
  --image-renderer 0x...      # thumbnail: an in-chain Solidity SVG \
  --attributes-renderer 0x... # traits: computed on-chain \
  --onchain-uri --name "…" --symbol …

animation_url still assembles on-chain from your script chunks (the interactive piece), while image and attributes are computed by your Solidity renderers. Nothing to render, no bucket, no runner, no refresh — and the dry run's Surfaces block confirms each one before you spend gas. Scaffold the two renderers with abx scaffold-renderer.

The alternative zero-infrastructure shape is a Solidity renderer with no --script at all: fully on-chain, but with no program there is no animation_url — abx verify will say so.

Editions: copies of an artwork

Add --copies <n|open> to any of the three commands above to deploy it as an ERC-1155 edition — copies of the artwork(s) — instead of unique ERC-721 tokens:

abx deploy --image ./art.png --copies open --name "..." --symbol ABX --sign
# an open (uncapped) edition of one artwork

abx deploy-series --dir ./art --copies 50 --name "..." --symbol ABX --sign
# N artworks from the folder, 50 copies of each

abx deploy-code --script ./sketch.js --copies 25 --public-base-url <url> --sign
# a generative drop, minted as copies of each id

open is an uncapped open edition — the flagship edition product; a number caps every id at that many copies (--copies 1 is legal but rarely what you want — drop --copies for a unique token instead). Every custody, storage, and hosting answer above still applies per artwork; only the token standard changes. An edition ships its own sale stack — see Sales.

Custody is the same on an edition as on its ERC-721 twin: bytes fully on-chain (--onchain-image), image off-chain with the JSON on-chain and nothing to run (--onchain-uri --backend arweave|ipfs), inline SVG (--onchain-uri), or a resolver you host (--public-base-url). Two details are worth knowing:

• A folder of media with a uniform file extension uploads as ONE directory under --onchain-uri --backend arweave|ipfs, and the collection gets a single {id}-substituting image field — so an N-artwork edition costs one on-chain field, not N.
• --onchain-image can't be signed offline on any lane, 721 or edition: staging is a sequence where each chunk transaction's receipt feeds the next, so --unsigned is refused. Use the hot lane or --sign, where one wallet session covers the chunk writes and the deploy together.

Two flags aren't wired for an edition deploy yet, and are refused by name rather than silently ignored: deploy-code --copies refuses --code-dir and the on-chain field renderers (--image-renderer/--attributes-renderer/--image-base) — on-chain dependencies (--dep) do work — and deploy-code --resume doesn't cover editions yet. Run the command with --copies ... --help for the exact, current list.

After deploying

1. Attach data (optional). abx attach <address> <key> <uri> adds a named, typed file to the token's data plane, such as stems, a 3D model, or a dataset. Use --file <path> to store small bytes on-chain instead of a URI.
2. Serve. abx serve runs the resolver, which re-indexes from the chain and serves metadata and images.
3. Verify. abx verify <address> re-hashes the served bytes against the on-chain commitment.

Read next

• Storage, Sales, and Operate a project.
• The Protocol: the on-chain spectrum.