dapp32

One workflow for people and agents

dapp32 lets an app author describe screens, inputs, contract calls and their next steps in JSON, using the Contract Application Manifest (CAM) format. A deployed contract publishes where to find that description and its hash. Given the chain and that contract’s address, the dapp32 viewer can load the workflow and render its screens; a TypeScript library lets apps and agents inspect the same workflow and prepare contract calls without a browser. You write the app-specific workflow; dapp32 supplies the reusable viewer and library.

Example apps Run locally

Framework, examples, deployments

This GitHub Pages site hosts documentation. A running viewer and a deployment of an example app are separate.

Example apps

Bike NFT, Escrow and Pay-to-Play supply their own contracts and workflows. Their guides explain app behavior and local demos.

Deployments

Open listed instances and inspect their deployed contract addresses.

Deploy an instance

An operator selects the chain, exact CAM publication and authorities, then deploys and verifies contract addresses. This is separate from hosting the viewer.

Example apps

These apps supply contracts and CAM bundles that exercise the generic dapp32 viewer. Each guide explains its workflow and local demo; use Deployment to create your own instance.

Bike NFT

Register bicycle components and manage ownership, metadata, reports and delegation.

Escrow

Fund a contractor milestone, review work, resolve disputes and withdraw settlement credit.

Pay-to-Play

Deposit native coins, register a permanent voucher key and authorize cumulative payments. Recover funds through delayed withdrawals or full refunds, and retire shared channels.

Why not just build a website?

An ABI describes callable functions. A CAM workflow also declares which inputs a screen collects, how an action uses those inputs in a contract call, and what follows the call. Another compatible viewer or agent can discover that description from the contract, without opening the app’s website.

A custom website can provide all of this. dapp32 lets you reuse its form rendering, contract-call preparation and workflow navigation instead of implementing them for each app. You still design the workflow; dapp32 does not infer an application from an ABI. Use the generic viewer when its controls fit, or build a custom interface for a different experience or service integration. A custom interface can also use the TypeScript library.

Approach

Contract-anchored manifests

A host contract publishes the manifest's location and hash. The manifest also records hashes for its ABI and UI resources, so the viewer can check that it loaded the expected bytes. The app's screens, reads, and actions live in reviewable manifest data instead of a custom frontend codebase.

Routes before rendering

A route names a contract call and its follow-up view. Read routes supply values to the UI. Write routes prepare transaction arguments for simulation and wallet review; preparation does not send a transaction.

Small UI model

The UI resource describes portable nodes such as text, fields, addresses, status rows, NFT references, includes, and actions. The viewer renders these nodes as controls. Apps and agents can inspect the resolved screens and action descriptions through the TypeScript library.

Current evidence

Local demo

Use a demo to explore an app’s workflow or manually test changes to its contracts, CAM bundle and viewer together. Each launcher starts its own disposable blockchain and fresh app contracts, serves the CAM resources, and prints a local viewer URL. See what the demo launchers do, or follow the Bike NFT, Escrow or Pay-to-Play instructions. Docker, Compose and Make are required; install the locked dependencies before launching a demo.

Each demo attempts cleanup when its foreground command exits. Closing the browser tab does not stop the GUI. Successful cleanup removes the fixture state. If interruption or cleanup failure leaves a demo running, use make bike-nft/local/demo/gui/down or make escrow/local/demo/gui/down or make pay-to-play/local/demo/gui/down for the matching demo, then check that it has stopped. 

git clone https://github.com/numpde/dapp32.git
cd dapp32
make dapps/deps/install
make js/deps/install
make cam/conformance/check
make bike-nft/local/demo/gui/up
# 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.

Build on the current model

Each example manifest declares its format version; use the matching CAM reference. Read the authoring guide to connect a host, manifest, ABI resources, routes, and a declarative UI.

Start with the existing examples and validation lanes. A manifest describes the workflow; the onchain contracts enforce permissions, amounts, and deadlines.

Historical PoC

The archive/poc-2026-05-20 tag preserves the historical proof of concept. Use main and the local workflows documented here for the current implementation.