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. Size decides who can read it — not whether you can write it. The write is chunked across transactions (~200 gas/byte), so no block limit binds it at any size. The read is one eth_call: tokenURI reassembles the whole document per call at roughly 360,000–405,000 gas per KB (climbing with size). Under ~117 KB (~50M gas) every endpoint measured serves it; above that the CLI probes your own RPC and reports its real allowance next to the estimate, so you can see who else will render the token. No size is refused. Details and the measured gas: on-chain storage.
• --onchain-uri: resolve tokenURI and contractURI fully on-chain.
• --ipfs-gateway <prefix> / --arweave-gateway <prefix>: the HTTPS prefix this collection's content-addressed fields are served through. Optional — leave them unset for the public defaults, and repoint any time with abx set-gateway, since the CID itself never moves (preferred gateways).
• --description, --external-url, --traits "k=v; k2=v2", and --royalty-bps <0-10000> (default 500). The ceiling is --royalty-cap (default 10%), owner-set at deploy and reduce-only after — a royalty above the cap reverts RoyaltyTooHigh(). Add --burnable to let holders burn their own tokens (default off).
• --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] (the same per-token read-size envelope as the 1/1 — judged per file, so a big collection of small pieces is fine); 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.
• --no-seed to opt out of a mint-time seed entirely, or --seed-source 0x... to draw it from your own IAbxSeedSource instead of the canonical one (see the callout below).

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 a work

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

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

abx deploy-series --dir ./art --copies 50 --name "..." --symbol ABX --sign
# N works 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 work; 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-work edition costs one on-chain field, not N. That field stores the bare CID; the serving gateway is a separate, repointable collection setting (preferred gateways).

• --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.

• A true on-chain-rendered edition needs no server at all. deploy-code --copies open --image-renderer 0x… --attributes-renderer 0x… --onchain-uri is an open ERC-1155 whose image and traits are computed by your Solidity renderers and whose uri(id) assembles on-chain — copies minted over time, permissionlessly, with nothing to render, host, or keep running. --script is optional on this shape: a renderer-only edition stores no program and has no animation_url, and passing both composes (an on-chain live view and an on-chain still). Same field renderer contract and same invariants as the ERC-721 lane — abx scaffold-renderer writes a buildable starting point for either.

A few flags still aren't wired for an edition deploy, and are refused by name rather than silently ignored: deploy-code --copies refuses --code-dir (use --script) and --image-base (it needs the effect runner to write a still per id), and deploy-code --resume doesn't cover editions yet. On-chain dependencies (--dep) do work. 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.