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.

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.