dAppWhat the dApp Is
OverviewD1

What the dApp is

An evidence and Registry layer for mining projects: it records where a claim came from, who reviewed it under what authority, what the review did not cover, and which published version a chain commitment belongs to.

Status
Design & build stage
Whitepaper basis
§4.2 Structure · §5.3 Data and Registry Architecture · §15.2 MPC Token and Asset Token
Verified on-chain today
None — nothing here is deployed yet
Still at design stage
RegistryAnchor contract · Public Explorer · Evidence Adapter framework · Compliance Policy Engine

In one sentence: the MPC dApp connects official registries, government records, professional bodies and project material — inside the limits of confirmed access rights, licence terms and source authority — reproduces who reviewed which evidence version under what method and what limitation, and lets anyone check the integrity of a disclosure-approved Registry version on BNB Chain.

It assumes no institutional integration that has not been confirmed. Every source carries its own state — planned, feasibility confirmed, access confirmed, in test, in use, unavailable, manual — and the product refuses to present one as another.

Three registries, three responsibilities

A project can complete a useful Registry workflow without ever becoming an issued asset. Each promotion needs its own evidence and its own separately accountable decision.

01registered

Project Registry

What the project is, who the parties are, and what evidence exists. Unconfirmed items stay pending rather than being rounded up to confirmed.

02published

Verification Registry

Who reviewed which evidence version, within what scope, under which schema, and with what stated limitation.

03locked

Asset Registry

Conditional. Opens only after legal, organisational, regulated-service and security gates are each evidenced separately.

Nine structures, one lifecycle

The value is not the number of integrations. It is the ability to reproduce where a claim came from, who reviewed it, what changed since, and what was disclosed.

01

Authority & Trust Registry

Which institution or issuer holds authority, in which jurisdiction and scope — and what a given source does not prove.

02

Verification Party Registry

Reviewer credential, scope, assignment, expiry, revocation and conflict of interest.

03

Attestation Schema Registry

Per review type: the evidence, method, limitation, freshness and disclosure rules, managed as versions.

04

Verification Attestation

A signed review of one frozen evidence snapshot, never of a moving target.

05

Compliance Policy Engine

A versioned readiness assessment against jurisdiction and gate requirements. Not an approval engine.

06

Evidence Snapshot + Anchor

Fixes the integrity and the point in time of a disclosure-approved Registry version.

07

Public Explorer

Publishes source, review, limitation, freshness, change history and the integrity proof.

08

Evidence Adapter Framework

API, signed electronic documents, bulk export and manual confirmation all produce the same receipt contract.

09

Mongolia Jurisdiction Profile

Mongolia's real authorities, sources, legal meaning and disclosure rules — kept outside the country-neutral core.

Mockup · 1440px capture
Mockup landing screen with the headline 'Evidence that can be traced. Decisions that remain accountable.' and a design-and-build-stage note.
Mockup entry screen. The build-stage note and the synthetic-demo bar are part of the product, not an overlay added for this page.Full size ↗

The trust boundary

One canonical record produces different projections. Raw material never becomes public by accident, and the chain carries a commitment rather than a document.

Private

Encrypted evidence store

  • Raw source responses and receipt detail
  • Contracts, PII and KYC material
  • Detailed geological coordinates and trade secrets
  • Reviewer working material and access logs

Public Explorer

Approved projection

  • Status, version and as-of date
  • Authority type and the scope it covers
  • Review scope and stated limitation
  • Correction, revocation and proof references

BNB Chain

Integrity commitment

  • Projection root and batch reference
  • Schema and rule version references
  • Publish, revoke and supersede events
  • No raw documents, no personal data

What this does not do

  • It is not a purchase, subscription, transfer or custody surface, and no such function is pre-built and hidden.
  • It does not hold client funds and does not act as an intermediary for them.
  • It does not certify that a reviewed document is true — it records who reviewed what, and what they excluded.
  • It does not replace a legal issuance decision, a government approval, or an investment recommendation.

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