Smart Contracts

DPO2U uses smart-contract and attestation patterns to make compliance outputs more verifiable.

The correct documentation stance is conservative:

• smart contracts are part of the verification and settlement design space
• they are not the only way to understand the product
• public docs should distinguish between reference architecture, environment-dependent backends, and current public runtime truth

What this page covers

This page describes how smart contracts fit into DPO2U conceptually:

1. what should be public vs private
2. what an attestation-oriented registry might store
3. how verification and settlement layers complement the MCP/runtime surface

It does not treat every contract example below as proof of a universally live public deployment.

Privacy-by-design principle

The rule is simple:

sensitive compliance material should not be published as raw on-chain state.

What belongs in a public verification layer is typically limited to compact, reviewable references such as:

1. hashed identifiers
2. evidence references or CIDs
3. compliance state or score summaries
4. timestamps
5. validating identity or service reference

Reference attestation model

A contract-oriented attestation flow can be modeled like this:

The important property is selective disclosure: the public layer stores only what is needed for verification, indexing, or dispute handling.

Reference example

The example below is conceptual and exists to illustrate the storage boundary, not to claim that this exact contract shape is the default public runtime path.

// Conceptual reference example
contract ComplianceRegistry {
  state attestations: Map<Hash, Attestation>;

  transition registerAttestation(
    subject_hash: Hash,
    validator_ref: Bytes,
    evidence_ref: Bytes,
    score: Uint8
  ) {
    attestations[subject_hash] = Attestation {
      validator_ref,
      evidence_ref,
      score,
      timestamp: now()
    };
  }
}

Contract catalog

The reference Midnight system (preview network) contains 14 Compact contracts. Each is described in Self-funding compliance agents.

Contract	What it does
AgentRegistry	Registers agent DIDs with a role and tracks active status.
AgentWalletFactory	Maps an agent DID to its wallet address.
ComplianceRegistry	Stores score-private attestations and generic PASS, FAIL, REVIEW verdicts keyed by evidence hash.
ComplianceEscrow	Conditional payment gated on a score-private proof (bookkeeping amounts).
ComplianceEscrowV2	Same escrow logic with real custody of native NIGHT.
PaymentGateway	Treasury and staking counters, plus non-custodial DUST delegation records.
FeeDistributor	Enforces a 40 / 60 expert and auditor fee split and LP revenue-share accounting.
SolvencyRegistry	Proof-of-Reserve seal: reserves >= liabilities without disclosing either amount.
TrustStackRegistry	Anchors the hash of the audited compliance stack.
LegalSourceManifest	Anchors statute citations to canonical source hashes.
ConsentRegistry	LGPD and GDPR consent grant, revoke, and purpose updates per hashed subject.
DataAuditLog	Data-processing event trail (LGPD Art. 37) without storing the data.
DataSubjectRights	Tracks data-subject requests and their Art. 19 response deadline.
LgpdKitRegistry	Registers hashes of a generated DPIA and privacy policy with a score and auditor DID.

Three further contracts from the lab environment are covered in Midnight chain notes.

Public vs private boundary

Public verification layer	Private / off-chain layer
Subject hash or derived identifier	Source documents
Evidence reference / CID	Raw policy or DPIA content
Compliance state / score summary	Internal notes and sensitive metadata
Timestamp	Detailed operational context
Validator reference	Full identity or secret material

How to think about contract status

Rather than overclaiming deployment status, DPO2U should describe contract-related components using a maturity model.

Maturity label	Meaning
Reference architecture	part of the intended design, documented conceptually
Local / environment-dependent path	usable only in a constrained backend or local environment
Publicly exposed runtime	reachable and verifiable from the public surface
Roadmap	planned, researched, or partially hardened

Prefer maturity labels over heroic claims

If a contract or settlement path is not publicly and repeatedly verifiable, describe it by maturity rather than calling it fully deployed or production-ready.

Relationship to the public runtime

The smart-contract layer does not replace the public runtime surface.

The current documentation model is:

• MCP runtime = capability discovery and public integration truth
• smart contracts / settlement = verification-oriented backend layer
• frontend = human-readable workflow and outcome presentation

That keeps the public story honest while preserving the protocol thesis.

What to avoid in the docs

The docs should avoid presenting all of the following as automatically true at once unless explicitly verified:

• a public chain endpoint is stable
• settlement is available in the current environment
• a contract example is live exactly as shown
• a tutorial snippet reflects the active public runtime

Why this matters

The value of DPO2U is not “there are contracts somewhere.”

The value is that compliance outputs can become:

• structured
• reviewable
• referentially stable
• progressively more verifiable

Smart contracts are one part of that path.

What's next

• Architecture — trust boundaries and runtime surfaces
• MCP Server — the current public capability layer
• Frontend Visualization — how results should be presented to humans
• Tutorial: Zero-knowledge compliance verification — conceptual walkthrough with operational caveats