Contract-anchored manifests
A host contract points to a pinned CAM bundle. The app's screens, reads, and actions live in reviewable manifest data instead of a custom frontend codebase.
Why this matters
Smart contracts enforce dapp rules, but the workflow a human or agent follows is usually encoded in a custom website: what to display, what to collect from the user, what a button does, and what should happen after a transaction. Every team rebuilds that UI layer even when the contract already knows the relevant state and permissions.
dapp32 moves that workflow description into declarative manifest data published by the contract. A generic viewer validates the manifest, then renders a human UI or exposes the same flow as a barebones agent API before preparing wallet actions.
Approach
Routes before rendering
Reads are explicit route calls into contract views. Their outputs flow into a declarative UI catalog. Writes become prepared ABI calls for simulation and wallet review.
Small UI model
The UI resource describes portable nodes such as text, fields, addresses, status rows, NFT references, includes, and actions. Those nodes can become graphical controls or a minimal machine interface, not an app-specific runtime every project must rebuild.
Current evidence
- The local bike NFT scenario deploys a real contract fixture, serves CAM resources, and runs in a graphical viewer.
- Runtime packages load CAM hosts, verify resources, resolve contract namespaces, read routes, and prepare writes.
@cam/viewerprovides a headless state machine that a terminal, web app, wallet, or agent can drive.@cam/conformancecatches authoring errors across manifests, ABI usage, resources, routes, UI, and typeflow.- The React viewer is deliberately thin: DOM and wallet interaction stay outside the protocol packages.
- A generic integration-fuzz runner walks deployed CAM hosts to catch workflow failures that static checks miss.
Local demo
The current path is Docker-backed through the Makefile. Dependency installation is explicit and may take time. The GUI target starts a local Anvil chain, deploys the bike NFT fixture, serves CAM resources, and launches the React viewer through a local gateway. The target prints the URL to open in your browser.
git clone https://github.com/numpde/dapp32.git
cd dapp32
make deps
make package-deps
make cam-conformance-check
make bike-nft-viewer-gui
# open the printed http://127.0.0.1:5173/... URL
What is in the repo
Protocol packages
@cam/protocol, @cam/core,
@cam/screen, @cam/evm-viem,
@cam/viewer, and @cam/conformance parse,
validate, resolve, and test CAM bundles.
Reference app
cam-web is a thin renderer around the headless viewer.
The browser owns DOM and wallet interaction; protocol logic stays in
reusable packages.
Demo dapp
dapps/bike-nft exercises
registration, lookup, metadata updates, a missing report lifecycle,
retirement, local deployment, and CAM UI projection.
Next milestones
Stabilize CAM v0.1
Freeze a small manifest/UI surface, document the authoring model, and keep the trust boundary narrow enough for independent review.
Make validation useful to builders
Turn conformance and integration fuzzing into a clear publication workflow with precise diagnostics before a contract points users at a CAM bundle.
Prove the model outside one demo
Add a second serious dapp so CAM is tested against another contract shape, permission model, and user workflow.
Harden wallet and agent handoff
Refine prepared writes, simulation diagnostics, and the interface a generic client uses before handing work to a wallet or agent.
Historical PoC
The original 2023 proof of concept ran on Polygon Mumbai. Mumbai was
sunset in April 2024, so the old live URL is no longer a working
deployment. The archived branch
remains available as historical context, while active development
happens on main.