End-to-End: $5M Secondary Transfer

Overview

This walkthrough follows a $5M fund LP secondary transfer from the seller's initial intent through settlement and position closure. It touches every major DMTR subsystem: the Registry, Rights Engine, Identity Graph, and lifecycle event trail.

The scenario

Step 1: Express transfer intent

The seller signals interest in transferring their position. This creates an Intent of Interest (IOI) record without initiating the formal transfer.

curl -X POST https://api.dmtr.ai/v1/intents \
  -H "Authorization: Bearer $DMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "position_id": "meg-2026-089",
    "direction": "sell",
    "units": 200,
    "indicative_price": 25000,
    "currency": "USD",
    "notes": "Full LP interest, seeking secondary buyer"
  }'

{
  "id": "ioi-2026-0456",
  "position_id": "meg-2026-089",
  "direction": "sell",
  "units": 200,
  "indicative_price": 25000,
  "currency": "USD",
  "status": "open",
  "created_at": "2026-07-01T10:00:00Z"
}

Step 2: Evaluate transfer feasibility

Before matching with a buyer, check whether the position can be transferred at all.

curl -X POST https://api.dmtr.ai/v1/transfers/evaluate \
  -H "Authorization: Bearer $DMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "position_id": "meg-2026-089",
    "counterparty_id": "part-allocator-456",
    "proposed_units": 200
  }'

Carry economics

When the position has carry terms, the evaluate response includes a carry_analysis block. This tells the buyer exactly what they're inheriting.

{
  "carry_analysis": {
    "carry_on_transfer_mode": "passthrough",
    "inherited_basis": 1000000,
    "purchase_price": 5000000,
    "current_nav_slice": 5000000,
    "carry_rate": 0.20,
    "accrued_carry_burden": 800000,
    "carry_adjusted_nav": 4200000,
    "carry_recipients": [
      { "recipient": "deal_originator", "rate": 0.15, "amount": "600000" },
      { "recipient": "fund_gp", "rate": 0.05, "amount": "200000" }
    ]
  }
}

Under passthrough mode (the default for deal-by-deal DOIV structures), the buyer inherits the seller's position in the distribution waterfall. The inherited_basis ($1M) is the cost basis the waterfall sees — carry is computed against this at exit. The purchase_price ($5M) is what the buyer actually paid. The carry_adjusted_nav ($4.2M) is the effective value net of carry — this is the number a lender would use for collateral coverage.

After settlement, the buyer's Position Object will include both numbers: economic_rights.original_cost_basis (the waterfall basis) and economic_rights.nav_at_transfer (the purchase price). The carry_on_transfer mode is configurable in the Operating Agreement — alternatives are crystallize_and_defer (carry computed and recorded as a receivable, settled at exit) and crystallize_and_settle (carry paid from transfer proceeds at settlement).

Step 3: ROFR notification

The Rights Engine automatically notifies the ROFR holder. They have 30 days to match or waive.

# Check ROFR status
curl https://api.dmtr.ai/v1/transfers/xfr-2026-0789/rofr \
  -H "Authorization: Bearer $DMTR_API_KEY"

{
  "transfer_id": "xfr-2026-0789",
  "rofr_holder": "fund-sponsor-llc",
  "status": "waived",
  "waived_at": "2026-07-10T14:30:00Z",
  "response_deadline": "2026-07-31T23:59:59Z"
}

The ROFR holder waived their right on day 10. The transfer can proceed to consent.

Step 4: GP consent

The GP is the final approval gate. The Rights Engine sends a consent request with a 15-day timeout.

# Check consent chain status
curl https://api.dmtr.ai/v1/transfers/xfr-2026-0789/consent \
  -H "Authorization: Bearer $DMTR_API_KEY"

{
  "transfer_id": "xfr-2026-0789",
  "consent_chain": [
    {
      "party": "GP Holdings LLC",
      "role": "general_partner",
      "status": "approved",
      "approved_at": "2026-07-12T09:00:00Z",
      "timeout_days": 15,
      "deadline": "2026-07-16T10:00:00Z"
    }
  ],
  "all_consents_obtained": true
}

Step 5: Execute the transfer

All restrictions are cleared. Execute the transfer.

curl -X POST https://api.dmtr.ai/v1/transfers/execute \
  -H "Authorization: Bearer $DMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: xfr-exec-2026-0789-001" \
  -d '{
    "transfer_id": "xfr-2026-0789",
    "settlement_date": "2026-07-15",
    "settlement_currency": "USD",
    "settlement_amount": 5000000
  }'

{
  "transfer_id": "xfr-2026-0789",
  "status": "settled",
  "legs": [
    {
      "from": "part-seller-001",
      "to": "part-allocator-456",
      "position_id": "meg-2026-089",
      "fraction": 1,
      "consideration_usd": 5000000,
      "new_position_id": "meg-2026-102",
      "escrow_reference": "esc-nc-2026-0789",
      "payment_method": "wire",
      "payment_status": "released",
      "payment_confirmed_at": "2026-07-15T11:00:00Z"
    }
  ],
  "escrow_id": "esc-nc-2026-0789",
  "escrow_provider": "north_capital",
  "escrow_status": "released_to_seller",
  "settled_at": "2026-07-15T11:00:00Z"
}

Step 6: Lifecycle events

The transfer produces a cascade of lifecycle events on both the seller's and buyer's positions.

What happened

1. Seller expressed intent (IOI) → matched with buyer
2. Rights Engine evaluated feasibility → lockup expired, ROFR and consent pending
3. ROFR holder waived within 10 days (transfer.consent_granted)
4. GP approved within 2 days (transfer.consent_granted)
5. Buyer funded escrow via DVP settlement (transfer.payment_funded)
6. Transfer settled atomically — registry updated, escrow released (transfer.settled)
7. Seller position (meg-2026-089) → status: transferred (closed)
8. Buyer position (meg-2026-102) → status: active (new record)
9. Payment released to seller from escrow (transfer.payment_released)
10. Lifecycle events recorded as hash-chained PositionEvent records for WORM-compliant audit trail

This entire flow — from intent to settlement — is API-driven, auditable, and programmatic. The same transfer that takes 6-8 weeks with manual processes completes in days when the consent chain cooperates.