System Architecture
DPO2U should be understood through trust boundaries and runtime surfaces, not through a single monolithic chain story.
The key distinction is:
- what is publicly verifiable today
- what is a documented backend path
- what remains research or roadmap
Current architecture model
1. Public runtime surfaces
These are the surfaces external users, developers, and agents can actually interact with.
- MCP Server — the most reliable public capability surface during this documentation refresh
- Frontend — human-facing visualization and workflow presentation
- Documentation — interpretive layer that explains what is live, degraded, demo, or roadmap
Confirmed public posture
During VPS validation for this refresh:
https://mcp.dpo2u.comresponded publicly- runtime discovery was available through:
https://mcp.dpo2u.com/toolshttps://mcp.dpo2u.com/openapi.json
That makes the MCP runtime the least ambiguous public source of capability truth.
2. Attestation services
This layer covers the actual compliance work:
- intake and workflow orchestration
- evidence collection or retrieval
- validation and scoring
- attestation-oriented result production
The important architectural rule is that this layer can still be useful without requiring every downstream verification backend to be live all the time.
3. Evidence layer
DPO2U keeps verbose or sensitive material off-chain wherever possible.
Typical artifacts in this layer include:
- schemas
- evidence bundles
- document references
- hashes, IDs, and content-addressed pointers
This is what lets the system remain verifiable without turning private compliance material into public application state.
4. Settlement and verification backends
DPO2U should document this layer conservatively.
This layer may include:
- verification services
- attestation backends
- chain-connected flows
- environment-dependent proof and settlement paths
The public-facing docs should not assume that every verification or chain backend is equally live, equally public, or equally reliable.
The canonical public capability surface is the MCP runtime. Backend settlement paths should be described as current validated paths, environment-dependent paths, or roadmap paths.
5. Research and roadmap
Some parts of the DPO2U thesis belong to research and advanced roadmap, not to current shipped capability.
Examples include:
- FHE-backed analytics
- more advanced cryptographic proof workflows
- richer operator and institutional analytics layers
These are legitimate parts of the architecture direction, but they should remain clearly labeled as not current public runtime truth.
Recommended reading model
Use the docs with this hierarchy:
| Question | Best source |
|---|---|
| What is publicly reachable right now? | MCP runtime |
| What should humans understand visually? | Frontend + docs |
| Where does evidence live? | Evidence layer docs |
| How do verification backends fit in? | Architecture + smart contracts docs |
| What is future-looking rather than current? | Research / roadmap docs |
Practical flow today
- a request enters through a public integration surface
- orchestration and validation services process the request
- evidence and references are stored off-chain where appropriate
- a result becomes available through a publicly consumable surface
- optional verification or settlement backends can be layered on top depending on environment and maturity
What this architecture page is intentionally not doing
This page does not treat a single blockchain environment as the entire product.
That is intentional. DPO2U is better understood as:
- a compliance and attestation system
- with multiple public and backend surfaces
- where the MCP runtime is the clearest public truth layer today
What's next
- Integration Surfaces — when to use MCP vs SDK vs frontend
- Frontend Visualization — live vs demo presentation model
- MCP Server — runtime capability surface
- Smart Contracts — verification and settlement patterns described conservatively