MPCMPC
dAppMockup Walkthrough
The ProductD9

Walk the mockup

A deterministic, fully synthetic walkthrough of one project — registration, evidence, review, readiness, decision, publication, change, and a normal exit without an offering.

Status
Mockup · synthetic data
Whitepaper basis
§5.4.2 Application Layer · §15.4 Mining RWA and Verification Risk — status wording is inherited from here
Verified on-chain today
None — nothing here is deployed yet
Still at design stage
Every screen shown below · All source connections · The chain anchor and its proof

The fixture project is SYNTH-PROJECT-001, labelled synthetic_test_project inside the product itself. It was built to demonstrate one thing: that the workflow holds together when the evidence is imperfect, which is the only condition it will ever run in.

Eight steps

  1. 01Project Registryregister
  2. 02Sources & receiptsconnect
  3. 03Professional verificationreview
  4. 04Readinessassess
  5. 05Human decisiondecide
  6. 06Publication & proofpublish
  7. 07Change impactmonitor
  8. 08Conditional Asset gatelocked

Steps 06 to 08 are locked until the authorised decision at step 05 is recorded. The lock is the point of the demo, not a loading state.

Evidence in, with its limits attached

Mockup · 1440px capture
Mockup source receipts screen showing three receipts with results confirmed_from_source, source_unavailable and conflicting, each with a scope limitation.
Source receipts. Three illustrative sources return three different results; each one carries the limitation of what it does not establish.Full size ↗

Readiness, then a separate decision

Mockup · 1440px capture
Mockup readiness matrix with requirement rows graded ok, not_evaluable, gap and watch, each with a reason.
The readiness matrix. Each requirement carries its evidence, grade, freshness, status and the reason for that status. There is no operator override control.Full size ↗
Mockup · 1440px capture
Mockup decision step showing a HOLD notice and a disabled 'Go is blocked' button next to an enabled 'Simulate replacement evidence' button.
The decision. While a blocking readiness result stands, go is not an available action; the only route forward is better evidence.Full size ↗

Pressing Simulate replacement evidence resolves the blockers to watch. The go button still does not appear on its own — a demo approver has to record the decision, with a monitoring condition and the input snapshot reference. Only then do publication and proof unlock.

Mockup · 1440px capture
Mockup publication step showing the rail private evidence, disclosure allowlist, registry version, Merkle root and public explorer.
Publication. Only a disclosure-approved projection reaches the public version and the simulated anchor batch.Full size ↗

The exit that is not a failure

Mockup · 1440px capture
Mockup asset gate step listing issuer, SPV, legal bridge, required ERSPs and security audit, all pending or not evaluable, with the registry locked.
The conditional Asset gate. Five gates, five named responsible actors, and a locked Asset Registry until each is evidenced.Full size ↗

It is built to be read on a phone

The same screens at 390px: the step rail becomes a horizontal scroller, and every table row restacks into labelled fields rather than scrolling sideways. No value is dropped between breakpoints — a status that is visible on a desktop is visible on a phone.

390 × 844
The same readiness step at 390 pixels wide, with the step list collapsed into a horizontal scroller.
390px — the step rail collapses into a scroller; the panel keeps its full copy.Full size ↗
390 × 844
Readiness requirements at 390 pixels wide, each table row restacked as a labelled card.
390px — each requirement row restacks into labelled fields, so status and reason stay together instead of scrolling sideways.Full size ↗
390 × 844
The Public Explorer at 390 pixels wide, with the registry status fields stacked in a single column.
390px — the Explorer's field grid becomes a single column; no value is dropped.Full size ↗

What this does not do

  • The mockup connects to nothing and broadcasts nothing.
  • Its numbers, entity names and hashes are fixtures and must never be quoted as project facts.
  • It does not demonstrate a purchase, subscription, transfer, custody or offering control, because none exists.

This chapter is a public adaptation of the internal product specification. Where the two differ, the specification and the whitepaper govern.

MPC dApp Guide · design & build stage · synthetic demo data