Dark Matter platform architecture

The problem

The missing infrastructure

Private market ownership — venture capital, private equity, private credit, real estate, infrastructure, energy — runs on analog rails. There is no equivalent of DTCC for settlement, SWIFT for messaging, or FIX for trading. Every private market transaction is bespoke.

In practice

Consider a single secondary transfer — an investor selling their LP interest in a Series C SPV to a buyer:

Total: 6–8 weeks. $30,000–$50,000 in legal and administrative costs.

Every one of these steps is manual. Every one of these steps rebuilds ownership state from documents rather than querying a system of record. And every one of these steps is repeated — from scratch — for every subsequent transaction involving the same position.

The structural cause

The root cause is not complexity. The root cause is that private market ownership has no canonical digital representation.

Public securities have ticker symbols, CUSIPs, ISINs, and LEIs. A share of Apple stock is the same object whether it is held at Fidelity, traded on Nasdaq, or lent as collateral at JPMorgan. The object has a universal identifier, a standardized set of attributes, and a shared understanding of what rights and restrictions it carries.

Private market positions have none of this. An LP interest in Fund III is a PDF in a drawer. The rights, restrictions, and obligations governing that interest are scattered across an LPA, one or more side letters, an operating agreement, and possibly an amendment stack. No two positions are encoded the same way. There is no common schema.

Without a common schema, there is no common API. Without a common API, there is no programmatic access. Without programmatic access, there are no automated workflows, no real-time surveillance, no lending markets, and no agent-driven coordination.

The insight

Ownership as a typed, executable object

Dark Matter's foundational insight is that every private market position — regardless of vehicle class, asset type, or jurisdiction — can be represented as a single canonical object: the DMTR Position Object.

The Position Object is not a document. It is not a database row. It is a typed, versioned, event-sourced state object that encodes everything a system needs to know about a position in order to answer three questions:

1. What is it? — Asset identity, vehicle class, issuer, vintage, terms hash
2. What can happen to it? — Transfer restrictions, consent requirements, lockups, encumbrances, eligible jurisdictions
3. Who has claims on it? — Owner, lender, GP, custodian, regulatory authority

{
  "entity_id": "meg-2026-047",
  "version": 3,
  "status": "active",
  "owner": "part-allocator-001",
  "asset": {
    "issuer": { "name": "AV Acme Corp, LLC", "ref": "av-acme-corp", "lei": "5493001KJTIIGC8Y1R12", "jurisdiction": "US-DE" },
    "vehicle_class": "doiv_membership_interest",
    "underlying": { "company": "Acme Corp", "sector": "defense", "security_type": "preferred_equity" },
    "vintage": "2024-06-15",
    "terms_hash": "sha256:a1b2c3d4...",
    "governing_document_id": "doc-oa-acme-001"
  },
  "economic_rights": {
    "preference": "pari_passu",
    "cost_basis": "3500000",
    "sharing_percentage": 0.10,
    "carry": { "rate": 0.20, "gp_rate": 0.05, "deal_originator_rate": 0.15, "schedule": "deal_by_deal", "adjudication": "deal_by_deal" }
  },
  "transfer": {
    "transferable": true,
    "restrictions": [
      { "type": "lockup", "expires": "2025-06-15" },
      { "type": "rofr", "parties": ["general-partner-001"] },
      { "type": "consent_required", "parties": ["general-partner-001"] },
      { "type": "itar_restriction" },
      { "type": "reg_d_506b", "no_general_solicitation": true }
    ],
    "consent_chain": [
      { "party": "general-partner-001", "role": "general_partner", "required": true, "timeout_days": 30 }
    ]
  },
  "compliance": {
    "kyc_status": "cleared",
    "aml_status": "cleared",
    "accreditation_required": true,
    "itar_sensitive": true,
    "eligible_jurisdictions": ["US", "GB", "SG"]
  },
  "valuation": {
    "current_mark": { "value": "5000000", "currency": "USD", "as_of": "2026-03-01", "provenance": "gp_mark" },
    "cost_basis": "3500000"
  },
  "encumbrances": [],
  "tokenization": { "status": "not_tokenized" },
  "provenance": { "acquired_via": "primary" }
}

This is the key shift: ownership stops being a document bundle and becomes an executable state object. Once it is an object, it can be queried, transferred, pledged, decomposed, and surveilled programmatically.

The schema is the platform

The Position Object is not one feature among many. It is the platform. Every capability Dark Matter offers — registry lookups, transfer feasibility evaluation, consent chain orchestration, collateral pledge, lifecycle events — is an operation on Position Objects.

This means the Position Object schema is the interface contract that connects producers (who create and list assets) to consumers (who discover, transact, and lend against them). Any service that can write a valid Position Object can list into Dark Matter. Any client that can read a Position Object can consume from it.

The architecture

The producer-schema-consumer model

Dark Matter is structured as a three-tier architecture:

1. Upstream producers — domain-specific businesses that originate assets, generate intelligence, or create financial products. They list into Dark Matter by encoding their assets as Position Objects via MCP or API.

2. Dark Matter (the schema layer) — the canonical registry, rights engine, identity graph, and settlement bus. It stores, validates, and enforces the rules encoded in Position Objects. It is the single source of truth for ownership state.

3. Downstream consumers — applications, terminals, command-line tools, and autonomous agents that read from Dark Matter to discover assets, evaluate transactions, execute transfers, and monitor portfolios.

graph TB
    subgraph "Upstream Producers"
        direction LR
        G["Research Platform<br/><i>Thesis Intelligence</i>"]
        J["Energy Platform<br/><i>Stranded Energy<br/>→ Compute</i>"]
        M["Venture Fund<br/><i>Venture Assets</i>"]
        FP["Lending Platform<br/><i>Lending & Collateral</i>"]
        N["[Future Producers]<br/><i>Real estate, credit,<br/>carbon, IP, NIL, ...</i>"]
    end

    subgraph "Dark Matter — Canonical Schema Layer"
        direction TB
        API["MCP / API Gateway<br/><i>Unified ingress and egress</i>"]
        REG["DMTR Registry<br/><i>Authoritative ownership record</i>"]
        RE["Rights Engine<br/><i>Transfer, consent, eligibility,<br/>waterfall logic</i>"]
        IG["Identity Graph<br/><i>KYC, AML, accreditation,<br/>jurisdictional constraints</i>"]
        CE["Collateral Engine<br/><i>Pools, coverage ratios,<br/>cure mechanics, settlement</i>"]
        PO["Position Object<br/><i>The atomic unit</i>"]
    end

    subgraph "Downstream Consumers"
        direction LR
        WEB["Web Clients<br/><i>Dashboards, portals</i>"]
        CLI["CLI<br/><i>Developer tools</i>"]
        TERM["Bloomberg, PitchBook,<br/>AlphaSense<br/><i>Research terminals</i>"]
        AGENT["Autonomous Agents<br/><i>Portfolio management,<br/>lending, rebalancing</i>"]
    end

    G -->|"lists thesis objects<br/>+ entity intelligence"| API
    J -->|"lists energy positions<br/>(capacity, cost, SLA)"| API
    M -->|"lists venture<br/>positions"| API
    FP -->|"lists lending<br/>facilities"| API
    N -->|"lists new<br/>asset classes"| API

    API --> REG
    API --> RE
    API --> IG
    API --> CE
    REG --- PO
    RE --- PO
    IG --- PO
    CE --- PO

    API -->|"reads positions,<br/>evaluates transfers,<br/>pledges collateral"| WEB
    API --> CLI
    API --> TERM
    API -->|"agent-to-agent<br/>coordination"| AGENT

What each layer does

Upstream producers

Producers are domain-specific businesses. Each one generates assets, intelligence, or financial products within its area of expertise. Producers do not need to understand each other's domains. They only need to encode their outputs as Position Objects (or related schema objects) and list them into Dark Matter via the MCP/API surface.

The critical design property: each new producer makes DMTR more valuable to every consumer, and each new consumer makes DMTR more valuable to every producer. This is a network effect, and the Position Object schema is the interface that enables it.

Dark Matter — the schema layer

The schema layer is composed of five subsystems. Each subsystem operates on Position Objects and exposes its capabilities through the unified MCP/API surface.

DMTR Registry. The authoritative record of who owns what. Every position has exactly one registry entry. The registry is event-sourced: current state is derived from an append-only log of immutable events (position.registered, position.updated, position.transferred, position.encumbered, position.exited, position.voided). This means the full ownership history of every position is reconstructible at any point in time.

Rights Engine. The deterministic rules engine that answers "can this happen?" for any proposed state transition. When a buyer wants to acquire a position, the Rights Engine evaluates:

• Lockup restrictions — is the lockup period expired?
• Right of first refusal (ROFR) — have existing holders been offered first?
• Consent requirements — which parties must approve, in what order, with what timeouts?
• Blackout periods — is the transfer window open?
• Regulatory constraints — is the buyer accredited? Is the jurisdiction eligible?
• Encumbrance state — is the position pledged as collateral? Can it be released?

The Rights Engine returns a deterministic verdict: allowed, blocked (with reasons), or conditional (with required actions). There is no discretion. The rules are encoded in the Position Object itself.

Identity Graph. The participant registry that tracks KYC, AML, accreditation, and jurisdictional eligibility for every entity that interacts with DMTR. Before any transfer or collateral pledge can execute, the Identity Graph confirms that both counterparties are cleared. Pre-clearance is available so participants can establish eligibility before initiating transactions.

Collateral Engine. The subsystem that enables any DMTR-encoded position to serve as collateral for institutional lending. The Collateral Engine manages:

• Collateral pools — groups of pledged positions organized by liquidity tier (liquid, semi-liquid, illiquid)
• Coverage ratios — real-time computation of the Hybrid Coverage Ratio (HCR) across multi-pool structures
• Haircut policies — dynamic haircuts by asset class, liquidity tier, and intelligence-driven risk adjustments
• Cure mechanics — a programmatic cure ladder (draw freeze, distribution sweep, menu rotation, mandatory top-up) that executes in declared order during stress
• Fortress periods — configurable windows (typically 0–5 years) during which no forced liquidation is permitted, only structural cures
• Atomic pledge settlement — all-or-nothing collateral pledges that only complete when custody, control agreements, and facility capacity are verified

MCP/API Gateway. The unified ingress and egress surface. Every operation — whether initiated by a human on a web client, a Bloomberg terminal, a CLI tool, or an autonomous agent — enters and exits through the same gateway. The gateway enforces authentication (bearer token JWT), authorization (scoped permissions), rate limiting, idempotency, and audit logging. It exposes two parallel interfaces:

• REST API (api.dmtr.ai/v1) — for programmatic integration by applications and services
• MCP (Model Context Protocol) server — for LLM-native integration by AI assistants and autonomous agents

Both interfaces operate on the same Position Objects, the same registry, and the same rules. There is no data or capability asymmetry between them.

Downstream consumers

Consumers read from Dark Matter to discover assets, evaluate transactions, execute transfers, monitor portfolios, and manage collateral. They do not need to know which producer originated a given position. They interact with Position Objects through the unified MCP/API surface.

How data flows through the system

The following diagram traces a single asset from origination through transfer to collateral pledge — touching every subsystem:

flowchart LR
    subgraph "1. Origination"
        DOC["Documents<br/>(LPA, cap table,<br/>side letters)"]
        ORIG["Producer<br/>(e.g., venture fund)"]
    end

    subgraph "2. Registration"
        ING["Ingest Pipeline"]
        PO["Position Object<br/>created"]
        REG["Registry<br/>records ownership"]
    end

    subgraph "3. Enrichment"
        INT["Research Platform<br/>(thesis objects +<br/>entity intelligence layer)"]
        VAL["Structured conviction,<br/>metrics, risk factors,<br/>evidentiary links"]
    end

    subgraph "4. Transaction"
        DISC["Discover<br/>position"]
        EVAL["Evaluate<br/>feasibility"]
        IOI["Express<br/>intent (IOI)"]
        CONSENT["Consent<br/>chain"]
        SETTLE["Transfer<br/>settles"]
    end

    subgraph "5. Collateral"
        ELIG["Eligibility<br/>check"]
        PLEDGE["Atomic<br/>pledge"]
        POOL["Collateral<br/>pool"]
        HCR["Coverage<br/>surveillance"]
        CURE["Cure<br/>mechanics"]
    end

    DOC --> ING
    ORIG --> ING
    ING --> PO
    PO --> REG

    INT --> VAL
    VAL -->|"enriches"| PO

    REG --> DISC
    DISC --> EVAL
    EVAL --> IOI
    IOI --> CONSENT
    CONSENT --> SETTLE
    SETTLE -->|"registry<br/>updated"| REG

    SETTLE --> ELIG
    ELIG --> PLEDGE
    PLEDGE --> POOL
    POOL --> HCR
    HCR -->|"threshold<br/>breached"| CURE
    CURE -->|"coverage<br/>restored"| HCR

Step-by-step narrative:

1. Origination. A producer (e.g., a venture fund) creates a venture position. The underlying documents — LPA, cap table, side letters — are ingested into Dark Matter's ingest pipeline, which extracts ownership state and creates a Position Object.

2. Registration. The Position Object is registered in the DMTR Registry. It now has a canonical entity_id, a status of active, and an immutable event log recording its creation. The registry is the authoritative source of truth for this position from this point forward.

3. Enrichment. The research platform provides structured thesis context: versioned thesis objects encoding conviction strength, valuation metrics, competitive positioning, risk factors, and evidentiary links — all backed by the entity intelligence layer (SCD Type 2 normalized metrics, funding histories, document snapshots). This intelligence is linked to the Position Object via entity crosswalk and becomes available to any consumer querying the position. A lender evaluating collateral quality, a buyer pricing a secondary transfer, or an agent computing haircuts all draw from the same enrichment layer.

4. Transaction. A downstream consumer (human or agent) discovers the position, evaluates transfer feasibility through the Rights Engine, expresses intent by creating an IOI (Indication of Interest), and triggers the consent chain. Once consent is obtained and compliance is verified, the transfer settles and the registry is updated with new ownership.

5. Collateral. The new owner pledges the position into a collateral pool for a lending facility. The Collateral Engine checks eligibility, computes the appropriate haircut based on asset class, liquidity tier, and intelligence-derived risk factors, and executes an atomic pledge. The position is now encumbered. Coverage is surveilled in real time. If the HCR drops below a threshold, the cure ladder activates — draw freeze, distribution sweep, menu rotation — without forced liquidation during the fortress period.

The agent-to-agent horizon

The architecture described above works identically whether the participants are humans or autonomous agents. This is by design. The MCP interface exposes the same tools to an LLM assistant as the REST API exposes to a web application. The difference is in orchestration.

Today, the typical workflow is human-initiated: a portfolio manager asks an AI assistant to evaluate a transfer, reviews the result, and decides whether to proceed. The human is in the loop at every step.

The architecture supports a progressive shift toward agent autonomy:

The Position Object schema is what makes agent-to-agent coordination tractable. Agents need unambiguous, typed, machine-readable representations of assets and rights. They need deterministic evaluation of what is and is not permitted. They need atomic settlement that either fully succeeds or fully fails. These are exactly the properties the Position Object provides.

An LP's portfolio agent seeking liquidity and a lender's credit agent seeking yield can discover each other through the marketplace, evaluate collateral eligibility through the Collateral Engine, negotiate terms through structured IOI exchange, and settle through atomic pledge — all without a human in the critical path, but with full auditability and human override at every stage.

Concrete outcomes

For asset originators (producers)

Concrete metric: Time from position origination to secondary-market availability drops from weeks to minutes. Time from origination to collateral eligibility drops from months to days.

For allocators and portfolio managers (consumers)

Concrete metric: Discovery-to-IOI time drops from weeks to under 5 minutes (agent-assisted). Collateral pledge-to-first-draw drops from months to 48 hours.

For lenders

Concrete metric: Coverage ratio recomputation latency is under 1 second after a mark update. Cure resolution rate target is 90%+ without escalation to the next cure step.

For the market

Liquidity creation. Most private market positions cannot be sold, lent against, or even queried programmatically. Dark Matter makes these assets liquid — not by creating a trading venue, but by making ownership state legible and actionable. When a position can be queried, transferred, and pledged through a standard API, liquidity is a natural consequence.

Cost compression. The $30–50K cost of a single secondary transfer is almost entirely attributable to manual reconstruction of ownership state. When ownership state is already encoded in a Position Object, the marginal cost of a transfer approaches zero. This is the same dynamic that drove payment costs from dollars to fractions of a cent once payments became digital.

Market formation. When enough assets are encoded in a common schema and enough participants are registered in a common identity graph, new markets form spontaneously. The lending marketplace (where lenders bid for yield against collateral pools) is one example. Agent-mediated secondary markets (where buy-side and sell-side agents negotiate programmatically) are another. Neither is possible without the canonical schema layer.

Trajectory

DMTR evolves in four phases. Each phase builds on the prior phase's infrastructure and adds a new category of capability.

Phase 1: Schema adoption. The Position Object becomes the standard encoding for private market ownership. Producers list into the schema because it makes their assets discoverable, transferable, and collateral-eligible. Consumers adopt because it gives them a unified view across all producers. The critical mass threshold is reached when the cost of not encoding positions as Position Objects exceeds the cost of doing so — when being outside the schema means being invisible to the largest pool of buyers, lenders, and agents.

Phase 2: Network effects. As more producers list and more consumers connect, DMTR becomes a multi-sided marketplace. Thesis objects from the research platform make venture positions more valuable — a buy-side agent evaluating a secondary purchase gets structured conviction context (not just a data dump) directly linked to the Position Object. The lending platform's DCIL infrastructure makes energy positions more liquid — a 10 MW stranded gas position encoded with capacity, cost-per-kWh, uptime SLA, and carbon intensity becomes collateral-eligible the moment it is registered. Each new participant makes DMTR more valuable to every existing participant. The Position Object schema is the interface that enables this composability — it is the reason a thesis object produced by one research workflow can directly inform a haircut computation in a DCIL facility managed by a separate lending platform, even though the two services have no direct relationship.

Phase 3: Institutional credit infrastructure. The collateral engine matures into a full lending marketplace. Lenders deploy capital against DMTR-encoded collateral pools with real-time coverage surveillance, programmatic cure mechanics, and fortress periods that eliminate reflexive liquidation risk. Warehouse lines accumulate performing facilities and convert to rated term structures (ABS/CLO). The desk tape — the auditable record of every collateral transaction — becomes the data product that rating agencies and trustees consume. DMTR becomes the settlement bus for private market credit, the same way DTCC is the settlement bus for public securities.

Phase 4: Agent-native capital markets. The MCP surface enables autonomous agents to participate in markets as first-class counterparties. An LP's portfolio agent monitors coverage, detects a position that could be pledged for better capital efficiency, evaluates collateral eligibility, negotiates terms with a lender's credit agent, and executes the pledge — all programmatically, with human oversight at policy-defined approval gates. The Position Object's deterministic, typed, machine-readable structure is what makes this possible. Agents cannot operate on PDFs and phone calls. They can operate on Position Objects.

The endgame

Dark Matter is not an application. It is the operating system for private capital.

The application layer is above it — thesis intelligence, venture inventory, DCIL lending infrastructure, compute-ready energy positions, and producers that do not exist yet. The client layer is below it — web dashboards, Bloomberg terminals, CLIs, and agents that do not exist yet. Dark Matter sits in the middle: the schema, the registry, the rights engine, the collateral engine, the settlement bus.

Every private asset in the world gets an encoding. Every participant gets an identity. Every transaction gets a canonical record. Producers compete on origination and domain expertise. Consumers compete on user experience and intelligence. Dark Matter makes all of it composable.

The [...] in the architecture diagram is the point. The system is designed so that a producer no one has imagined yet — tokenized real estate, carbon credits, intellectual property royalties, athlete earnings — can list into the same schema tomorrow and immediately gain access to the entire consumer base, the lending fabric, the identity graph, and the agent orchestration layer.

That is the platform.