Bike NFT - dapp32

What the app does

The app models a bicycle component registry. A trusted registrar creates a verified record for a physical component serial number and mints a normal ERC-721 token to the owner. The manager contract stores the serial lookup, status, registrar, timestamps, token contract, and token id. The NFT contract remains a regular token contract, so wallets and indexers can treat component ownership normally.

The visible app is defined by CAM resources. A host contract publishes the manifest URI/hash and contract address bindings; the generic viewer loads those resources, calls the read routes, renders the declared UI nodes, and prepares wallet writes from the manifest routes.

User workflow

1. Look up

Enter the serial number stamped on a component and read the current registry projection.

2. Register

A registrar mints the component NFT and creates the verified serial record.

3. Maintain

The owner or a scoped delegate updates metadata, opens a missing report, or resolves it.

4. Finalize

The owner can retire the component; retirement remains registry-final even if the NFT later transfers.

Onchain pieces

`CamRoot`

Publishes the CAM URI/hash and resolves manifest contract names to deployed addresses for this chain.

`BicycleComponents`

A non-upgradeable ERC-721 collection. It owns token behavior, transferability, token URI storage, and collection metadata.

`BicycleComponentManager`

The registry and policy contract. It owns serial lookup, status, component delegations, account info, missing report state, lifecycle events, and write permissions.

`BicycleComponentManagerUI`

A read-only route projection contract. It never writes manager state; it returns semantic view data and action names for CAM.

CAM manifest

Declares contract namespaces, read routes, write routes, ABI resources, and the UI resource consumed by generic viewers.

Generic viewer

Renders the workflow from manifest data and prepares contract calls; business authority remains in the manager and token contracts.

Authority model

Registrar authority

Registrars create verified component records and mint component tokens to owners. Removing the registrar role immediately changes both write authority and the registration view.

Owner authority

Current ERC-721 owners can update component metadata, open missing reports, resolve missing reports, and retire components. The manager contract also supports scoped delegation. V1 CAM uses active delegations to expose delegate-authorized actions, but does not expose a grant/revoke workflow.

Scoped delegates

Delegates receive explicit capabilities with an expiry. Delegations only work while the grantor remains the token owner, so an ordinary ERC-721 sale invalidates old repair-shop permissions. Grant and revoke calls remain contract-level operations because capability and expiry inputs need a lower-error UI than V1 provides.

Account metadata

Account info is self-managed by the account address and is used by the read projection. Report and resolution documents remain external URI references, not registry authority.

CAM routes

The manifest exposes a small route graph. Read routes return semantic app views; write routes prepare wallet calls to the manager and then continue to the declared follow-up read route.

Route	Kind	Contract function	User-facing purpose
`entry`	read	`viewEntry(account)`	Initial lookup screen and registration availability.
`component`	read	`viewComponent(serialNumber, account)`	Component lookup, owner view, current status, token URI, and available actions.
`register`	read	`viewRegister(serialNumber, account)`	Registration readiness for a serial number.
`registerComponent`	write	`registerComponent(owner, serialNumber, tokenURI_)`	Registrar supplies an explicit owner, mints the component NFT, and creates the verified record.
`setAccountInfo`	write	`setAccountInfo(infoURI)`	The connected account publishes or clears its own account metadata URI.
`updateComponentMetadata`	write	`setComponentMetadata(serialNumber, tokenURI_)`	Owner or delegate updates the component token URI.
`markComponentMissing`	write	`markComponentMissing(serialNumber, reportURI)`	Owner or delegate reports the component missing with an external report URI.
`clearComponentMissing`	write	`clearComponentMissing(serialNumber, resolutionURI)`	Owner or delegate restores the component to active status with an external resolution URI.
`retireComponent`	write	`retireComponent(serialNumber)`	Owner or delegate moves the registry record to final retired state.

Important boundaries

The UI contract is read-only

BicycleComponentManagerUI has no roles, no owner, and no write functions. It selects views and actions from manager state, including hiding manager writes while the registry is paused and registration or component metadata writes while the component token is paused.

The token remains standard

Transfers and approvals are ordinary ERC-721 operations on BicycleComponents. Registry status is manager truth, not a transfer hook in V1.

The manifest is not authority

CAM describes reads, UI nodes, and prepared writes. The manager and token contracts still enforce all business rules onchain.