# Deployment and upgrade workflow

This release includes the exact public configuration needed to reconstruct and verify the Bazarr ERC-1155 factory implementation and its UUPS proxy on Quai mainnet. No private key, seed phrase or secret configuration is included or required for verification.

## Mainnet deployment

The authoritative public deployment record is `deployment/mainnet.json`. It identifies:

- Quai Cyprus-1 mainnet, chain ID 9;
- factory implementation and proxy addresses;
- deployment transaction hashes, block numbers and block hashes;
- all four factory constructor arguments;
- the proxy initializer owner and calldata;
- compiler immutable values and EIP-1967 implementation slot;
- the four-byte Quai address-grinding salts present in the original transaction inputs.

Run the following after `npm ci --ignore-scripts`:

```sh
npm run prepare:deployment
npm run verify:onchain
```

`prepare:deployment` reconstructs both original creation inputs and writes them to `build/deployment-inputs.json`. It does not sign or broadcast. `verify:onchain` performs read-only RPC calls and checks the active EIP-1967 implementation, runtime bytecode, immutable values, proxy bytecode, deployment transaction inputs and receipts, owner, dependency getters, contract name and version. Set `QUAI_RPC_URL` to use another compatible public RPC endpoint.

The original deployment used `quais` 1.0.0-alpha.36. Its `ContractFactory` appended a four-byte salt while grinding the contract address into the deployer's Quai shard. The recorded salts are included so that transaction input comparison is byte exact. They are not constructor arguments.

## Reproducing a deployment

The generated `factory.transactionInput` and `proxy.transactionInput` values are the exact historical mainnet inputs. A standard Quai signer can submit equivalent creation input for a new deployment, but a different sender, nonce or grind salt produces a different address. Reusing the historical input does not recreate the historical address unless all address-derivation inputs also match.

Review every address before any new deployment. The factory constructor order is:

1. Zora ERC-1155 collection implementation;
2. Merkle minter;
3. fixed-price minter;
4. redeem minter factory.

The proxy constructor receives the factory implementation followed by `initialize(factoryOwner)` calldata. The public scripts deliberately stop before signing or broadcasting so verification cannot move funds or change contracts.

## UUPS upgrade preparation

Generate calldata for a reviewed replacement implementation:

```sh
npm run prepare:upgrade -- 0xNewImplementation
```

The command prints the proxy target, required owner and `upgradeTo(address)` calldata. It never signs or broadcasts. Before an upgrade, independently verify the candidate source, runtime bytecode, constructor immutables, contract name, storage compatibility and authorization. An upgrade is an owner-controlled production action and is outside this source-verification procedure.

## Scope

The factory implementation is the combined work containing the AGPL-covered Solmate CREATE3 code. The proxy source and artifact are included because they are required to initialize and operate the deployed UUPS factory. Other Zora ERC-1155 implementation and minter contracts are separately deployed contracts and are identified by their public addresses; they are not linked into the factory runtime bytecode.