Deploy Bike NFT

This page defines the app-specific inputs and checks. Use the shared guide for source snapshots, protected configuration, approval, records and cleanup. Example addresses and paths below are placeholders; your saved configuration selects the actual instance.

The shared component workflow provides bike-nft/release/contracts/deploy, bike-nft/release/ui/deploy and keyless bike-nft/release/cam/bundle. Business deployment, UI contract deployment and CAM root configuration have separate records and may use different actors and source commits. A UI replacement can reuse the verified business artifact without redeploying its contracts.

Release policy

A complete Bike release needs four distinct kinds of input. Select them for the operations that own them:

publication: exact CAM URI and bytes;
collection identity: name, symbol, base token URI, and collection metadata URI;
governance: final CamRoot, component-token, and manager authorities plus nonzero default-admin delays;
operations: explicit pauser, configurer, and one or more unique registrar addresses.

The release creates an empty NFT collection on testnets and mainnets; the normal release rehearsal also starts empty. Only the separate local demo script registers the sample frame, battery and motor NFTs. Metadata JSON and images hosted on GitHub are files, not on-chain NFTs: publishing or referencing them does not mint a token. An authorized registrar must register a component through the manager to create its NFT.

We recommend a separate funded deployment account. The deployer may retain any explicitly selected owner, admin or operational role, and the same account may hold several declared roles. The release gives the manager the token mint and URI-setter roles and removes the deployer's operational roles unless explicitly selected. For each intended owner or admin that differs from the deployer, it starts an independent handoff:

CamRoot.acceptOwnership() by the final root owner;
BicycleComponents.acceptDefaultAdminTransfer() by the final component admin after its delay;
BicycleComponentManager.acceptDefaultAdminTransfer() by the final manager admin after its delay.

The deployment script submits only the nominations for these handoffs; it does not sign or submit acceptance for any nominee. In the Bike viewer, open Deployment handovers from the registry's opening screen and connect the nominated wallet. Each section shows its target contract, current authority, nominee and acceptance status. Admin sections also show the acceptance time. Unavailable acceptance buttons remain visible but disabled. Choose Refresh handovers after chain time has passed the deadline, then choose the applicable acceptance action, review the transaction and send it with the wallet. Each successful receipt refreshes the screen. CAM ownership has no acceptance delay.

Each nominee can also call the method above directly. Business addresses are in contracts/artifact/contract-deployment.json under contracts.components.address and contracts.manager.address; the CAM address is root.contract.address in the final CAM publication. Each admin's delay runs from its contract's nomination. Until acceptance, the current owner or admin retains that authority. Historical release/verify accepts recorded pending nominations; check the live handover screen or contract state for current acceptance. When the deployer is also the intended owner or admin, no handoff is needed. Older deployments need the updated read-only UI projection, CAM resources and ICamRootOwnership binding to expose this screen; updating the browser alone does not add it.

Choose the authority addresses and delays before creating a release plan. A production-like Sepolia rehearsal should normally use a disposable funded deployer, a testnet Safe or separate owner for final administration, a separate registrar, and explicitly controlled pauser/configurer accounts.

Public setup suggests 3 days (259200 seconds) for each administrator-transfer delay. Press Enter to accept the displayed value or enter another positive number of seconds. Revisiting settings preserves your earlier choice. These delays apply to administrator transfers, including the initial handover; they do not delay ordinary role grants, configuration changes or pausing.

To change either default admin later, that contract's current default admin calls beginDefaultAdminTransfer(newAdmin). After the contract's current transfer delay, the nominee calls acceptDefaultAdminTransfer() on that same contract. The current admin retains authority until acceptance. The setup fields COMPONENTS_ADMIN_DELAY and MANAGER_ADMIN_DELAY set the initial delays. These transfers are separate from CAM ownership and do not change operational role holders.

Each contract's current default admin manages its operational roles with grantRole(role, account) and revokeRole(role, account): pausers and configurers on Components; pausers, configurers and registrars on Manager. Roles can have several holders. Granting a role to a new account does not remove an old holder; the admin must revoke the old holder, or that holder can call renounceRole(role, ownAddress). These role changes have no admin-transfer wait.

Token and collection metadata

Use an empty base token URI for independent metadata on each component. This supports the viewer's complete HTTP(S) metadata URLs and embedded JSON data URIs. Setup proposes none for the base; accepting it stores an empty string. Enter none to clear a previously entered prefix.

Collection metadata describes the whole collection through contractURI(); it is separate from each token's metadata and from the CAM manifest. Setup proposes inline: it generates a JSON document containing the chosen collection name and stores that document in a data URI, so no hosted collection file is needed. You can instead enter your own collection metadata URI.

A nonempty base is an advanced option for clients that supply relative metadata suffixes. The contract concatenates that prefix with every stored token URI, including full URLs and data URIs; it does not recognize them as exceptions. Use the empty base for the generic viewer's full-URI and embedded-JSON workflow. Changing the base changes the resolved metadata URIs of existing tokens.

CAM publication

Prepare a bundle from the selected business and UI artifacts with the ordinary component workflow. The bundle exports their original ABIs and refreshes resource hashes. Host only the prepared bundle/ contents, including every declared protocol, ABI and UI resource, preserving relative paths and browser CORS.

settings.CAM_HASH=auto commits the prepared manifest's SHA-256. An explicit nonzero digest must match those exact bytes; zero selects an unverified root commitment. Publication validates the retained local bundle for the selected URI. Check its served bytes and browser access separately.

Release deployment

make bike-nft/release/setup INSTANCE=/absolute/private/002-avalanche-fuji
make bike-nft/release/deploy INSTANCE=/absolute/private/002-avalanche-fuji

Setup collects the collection metadata, intended authorities, transfer delays and operational roles described above. The full command uses the ordinary business, UI, bundle and CAM operations. Purpose-specific setup can save independent UI and CAM signer configurations referenced by instance.json. Follow the hosting pause to host the exact prepared files before configuring the CAM root.

Keep the entire instance. Paths below are relative to an allocated full operation; a UI update reuses the selected business artifact rather than creating a new business phase:

contracts/artifact/contract-deployment.json
ui/artifact/ui-deployment.json
cam-bundle/bundle/
cam/artifact/cam-publication.json

Each signed phase retains its own plan, broadcast and approval evidence. A partial CAM operation retains its original attempt; approved continuation records have their own directories and final publication. Use the latest final publication to open or update that root.

Verify saved evidence

make bike-nft/release/verify INSTANCE=/absolute/private/002-avalanche-fuji

Choose the saved operation using its recorded configuration references; see the keyless verification requirements. Each saved plan selects its original program source. Verification checks or completes historical phase evidence without signing; it preserves existing records and accepts recorded pending nominations. It does not assert today's admins, operational roles, metadata, pause state or readiness. Inspect the live handover and app state separately.

UI update deploys a compatible read-only UI contract or selects a saved one, prepares matching files locally and updates the existing CAM root’s references without redeploying Components or Manager. Business contracts may come from an older source; choose interfaces supported by the selected UI and authored CAM workflows.

Public rehearsal

Configure the generic CAM web viewer with the public chain ID, a public read RPC, the deployed CamRoot address, the published CAM resource origin, and wallet/network switching. Hosting and wallet injection are deployment-provider concerns; this repository does not yet own a public hosting target.

The viewer URL supplies chainId (for example eip155:11155111), host, account, and rpcUrl. The hosting configuration supplies VITE_CAM_WEB_RESOURCE_ORIGIN; links cannot override that resource origin. Use a credential-free public read RPC because its URL is included in shareable read links. Such links reopen a route against current state and do not carry wallet authority, unsent form edits, or prepared transactions.

Exercise registrar creation, token receipt, metadata update, missing/report resolution, delegation grant/revoke, transfer with permission changes, pause/unpause, and unauthorized failures. Check current explorer metadata and role state after activity; release/verify continues to verify the retained historical operations. Explorer source publication is advisable but remains separate from the repository's bytecode verifier.

Explicit uncertainties and limits

AccessControlDefaultAdminRules is not enumerable. The recorded business operation proves the selected initialization transactions; it does not enumerate every current role holder. Current-state checks cannot enumerate undisclosed third-party holders through this interface alone. The clean pinned script and preserved broadcast remain part of the audit evidence.
The repository does not choose the actual Safe/EOA addresses, the final nonzero delay, RPC provider, CAM host, browser host, block explorer, or operator finality threshold.
The release artifact records operator intent and immutable deployment provenance, not a mutable snapshot of every later handoff state. Current contract reads and the handover screen establish whether ownership and administration have since been accepted.

No upgrade, recovery, hidden registrar, generic CAM machine resource, or production monitoring authority is introduced by this lane.