Minting

Minting logic lives in a separate minter contract, not in the token. The token exposes one mint primitive; a minter calls it and emits sale events. The minter spine is the vocabulary those sale contracts speak, so a frontend can follow a mint across many projects without the protocol taking a position on price. Like effects, it is a sibling convention, scoped to the minter contract.

What the token provides

The token core has two concerns: which address may mint, through the External Minter extension read with minter(), and where proceeds go, through the Primary Payee extension read with primaryPayee(). A minter calls the sequential mint primitive:

interface IAbxSequentialMint {
    function mint(address to) external returns (uint256 tokenId);
}

A mint appears on the token as an ERC-721 Transfer from 0x0. A minter targets the interface, verified through ERC-165, and reads owner(), primaryPayee(), minter(), maxInvocations(), totalSupply(), and paused() as needed. The one-shot 1/1 OneOfOneImage does not advertise the interface and is not a minter target.

The reference minter

The reference minter is fixed-price. It is deployed once per chain, and is ownerless and multi-tenant: each project's sale is keyed by the token address, and all authority defers to that token's owner. A sale is configured before any purchase:

struct Sale {
    bool    configured;
    address paymentToken;   // address(0) is ETH, otherwise an ERC-20
    uint256 price;          // raw units per token
    uint256 allocation;     // max tokens this minter may sell for the project
    uint256 sold;
}

Running a sale takes two grants, both from the project owner: mint rights, with setMinter(minter) on the token, and sale terms, with configure(token, paymentToken, price, allocation) on the minter. A purchase is public, through purchase(token) or purchaseTo(token, to). Each purchase mints exactly one token: it checks that the sale is configured and within allocation, collects exactly price, mints, and forwards payment to the primary payee. It is non-reentrant, and payment must be exact; there is no refund path.

Because the minter defers to the token, the token's pause is the sale's on-off switch, the payee is read fresh on each purchase, and the allocation is a budget separate from the supply cap.

Sale events

SaleConfigured(address indexed token, address paymentToken, uint256 price, uint256 allocation)
Purchase(address indexed token, address indexed buyer, address indexed to, uint256 tokenId, address paymentToken, uint256 price)

SaleConfigured fires when an owner sets or updates terms. Purchase fires when a purchase settles. Both are indexed on token. The token still emits its protocol events alongside them: the Transfer from 0x0, and the one-time MinterSet when the minter is assigned.

The edition minter lane

An edition (the ERC-1155 twin of a 1/1, Series, or code project — copies of an artwork, not unique tokens) targets a different mint primitive, not a generalization of the sequential one:

interface IAbxEditionMint {
    function mint(address to, uint256 id, uint256 amount) external;
}

Same token-side auth as the sequential primitive (owner always; the assigned minter when not paused). There is no mintMany — every ABX token is Multicallable, so batching several ids or amounts is multicall's job, not the primitive's. OneOfOneEdition keeps the same uniform signature but reverts unless id == 0, since its id space is fixed to the one artwork.

The edition sibling of the reference minter is AbxFixedPriceMinter1155 — the same ownerless, multi-tenant, non-reentrant shape, keyed one step finer: (token, id) instead of just token, so an edition project prices each artwork on its own terms.

function configure(address token, uint256 id, address paymentToken, uint256 price, uint256 allocation) external;
function purchase(address token, uint256 id, uint256 qty)               external payable;
function purchaseTo(address token, uint256 id, uint256 qty, address to) external payable;

Same require → collect → mint → forward shape as the reference minter, generalized to a quantity: it checks the sale is configured and within allocation, collects exactly price * qty, mints that many copies, and forwards payment to the primary payee. The token's pause is still the sale's on-off switch, and the payee is still read fresh on each purchase.

A OneOfOneEdition is a first-class target here — unlike a plain 1/1. OneOfOneImage sits out the reference minter by design (one-shot, owner-only, no sequential primitive); OneOfOneEdition doesn't: a priced open or limited edition of a single artwork is the dominant 1155 product, so it exposes IAbxEditionMint (id space fixed to 0) and needs no Series wrapper to get a native sale.

Sale events mirror the reference minter's, indexed on (token, id):

SaleConfigured(address indexed token, uint256 indexed id, address paymentToken, uint256 price, uint256 allocation)
Purchase(address indexed token, address indexed buyer, address indexed to, uint256 id, uint256 amount, address paymentToken, uint256 price)

Additive, same as the reference minter: strip these and an ABX-aware indexer still reconstructs holdings and per-id supply from TransferSingle/TransferBatch and MaxSupplyUpdated alone.

Other sale mechanics

Only the fixed-price minter ships now. Other price mechanics, such as Dutch or English auctions, free mints, or allowlist-gated sales, are separate minter contracts that target the same IAbxSequentialMint and extend the spine with their own events. To run more than one at once, a router is assigned as the single minter() and dispatches to them.