# 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](effects.md), 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:

```solidity
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:

```solidity
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.