Attestation routing
As DPO2U grows, the hard problem is not only generating attestations. It is deciding which attestation path should be used for a given relying party, jurisdiction, and trust threshold.
The routing problem
A future DPO2U deployment may have multiple possible validation paths:
- purely off-chain schema validation
- local-node proof-backed validation
- chain-recorded public attestations
- jurisdiction-specific validators
- higher-assurance or lower-latency modes
Routing is the policy that selects the right path for the request.
Dimensions that affect routing
At minimum, routing depends on:
- jurisdiction — which legal interpretation is relevant
- assurance level — how much evidence or proof is required
- latency budget — how quickly the relying party needs a result
- privacy budget — how much disclosure is acceptable
- infrastructure availability — which execution paths are actually healthy
The last point matters today: public MCP availability is confirmed, and the gateway routes chain=midnight attestations on the Midnight preview network through its own driver (an asynchronous queue to a self-funding agent, gated by MIDNIGHT_CHAIN_ENABLED). A public Midnight RPC path is not a dependable route at this time. See Midnight.
Current practical routing rule
Given the confirmed VPS state, the pragmatic routing rule is simple:
- if the task is read-heavy or schema-centric, use the public MCP path
- if the task requires end-to-end proof generation and settlement, route to the local Midnight node path
- do not assume
rpc.dpo2u.comas an available public dependency
Why routing is a research topic
Routing becomes nontrivial when multiple attestors, chains, or regulatory mappings coexist. At that point the protocol needs formal criteria for selecting:
- cheapest acceptable path
- highest-assurance path
- most private acceptable path
- jurisdictionally valid path
This is where DPO2U can become more than a single attestation service: it can become a broker of verifiable compliance paths.