Cross-Chain OTC Trading Desk

What you will build.

Two fictional counterparties accept DEMO-OTC-01 for delivery on two named test networks. One party reports delivery; the other has no confirmed receipt. Reconcile the agreement and both deliveries without assuming that an address, balance or negotiated deal enables cross-chain settlement.

Your working record

Create a private worksheet with columns for the source reference, observed state, responsible system, observation time, expected result and unresolved issue. Use the same fictional case throughout the steps; do not paste live personal or financial records into this exercise.

1. 01Freeze the terms you intend to reconcile
2. 02Check each network's readiness
3. 03Expose unmatched delivery
4. 04Close the review without inventing guarantees

Run the example before changing it.

Inspect the baseline record below. Download and read the complete JavaScript file before running it. It uses only Node’s built-in test and assertion modules; there is no package installation, account connection or secret to configure.

{
  "agreementValid": true,
  "networksReady": true,
  "bothDeliveriesConfirmed": true
}

Save it as cross-chain-otc-trading-desk.mjs. Open a terminal in that folder and run:

node --version
node --test cross-chain-otc-trading-desk.mjs

Expected result: four passing tests and zero failures. These tests verify the teaching classifier only. They do not verify a production integration, security boundary or financial outcome.

// Hybrid-Chain offline teaching model: cross-chain-otc-trading-desk
// Fictional fields/states; NOT an API client, authorization system or production implementation.
// No network calls, credentials, payments or file writes. Review before running.
// Requires Node.js 22+. Run: node --test cross-chain-otc-trading-desk.mjs
import test from 'node:test';
import assert from 'node:assert/strict';

export function inspect(record) {
  if (!record.agreementValid) return 'TERMS_REVIEW_REQUIRED';
  if (!record.networksReady) return 'READINESS_REQUIRED';
  if (!record.bothDeliveriesConfirmed) return 'DELIVERY_UNMATCHED';
  return 'MATCHED_FOR_REVIEW';
}

const baseline = {
  "agreementValid": true,
  "networksReady": true,
  "bothDeliveriesConfirmed": true
};
const cases = [
  {
    "name": "matched fixture",
    "patch": {},
    "expected": "MATCHED_FOR_REVIEW"
  },
  {
    "name": "stale terms",
    "patch": {
      "agreementValid": false
    },
    "expected": "TERMS_REVIEW_REQUIRED"
  },
  {
    "name": "network not ready",
    "patch": {
      "networksReady": false
    },
    "expected": "READINESS_REQUIRED"
  },
  {
    "name": "unmatched delivery",
    "patch": {
      "bothDeliveriesConfirmed": false
    },
    "expected": "DELIVERY_UNMATCHED"
  }
];

for (const example of cases) {
  test(example.name, () => {
    assert.equal(inspect({...baseline, ...example.patch}), example.expected);
  });
}

Know what the tests demonstrate

matched fixture

MATCHED_FOR_REVIEW

stale terms

TERMS_REVIEW_REQUIRED

network not ready

READINESS_REQUIRED

unmatched delivery

DELIVERY_UNMATCHED

Now change one fixture at a time. If you change a case’s input without changing its expected result, the test should fail. Read the actual-versus-expected difference and use the walkthrough to decide whether your rule or your expectation needs correcting. Keep an unchanged copy for comparison.

Work through the case, step by step.

1. 01

   Freeze the terms you intend to reconcile

   Do this

   1. Write DEMO-OTC-01 and record each asset, amount, network and counterparty alias separately.
   2. Attach the accepted-terms reference and expiry; changing either asset creates a new review question.
   3. Name the desk operator responsible for mismatched or disputed delivery.

   Expected result

   The review concerns a specific agreement, not an informal promise that any later deposit can satisfy.

   If your result is different

   If the evidence only contains a chat message or matching amount, obtain an explicit agreement reference before joining delivery records.

2. 02

   Check each network's readiness

   Do this

   1. Run the local exercise with networksReady=true; this is a fixture, not a discovery result.
   2. Set networksReady=false and confirm READINESS_REQUIRED.
   3. Use the MPC wallet guide to list the real network, signing, customer-authority and release checks needed on both sides.

   Expected result

   A proposed trade and an operational settlement route remain separate decisions in your design.

   If your result is different

   Do not infer withdrawal availability from token-import networks, a displayed address or a wallet balance.

3. 03

   Expose unmatched delivery

   Do this

   1. Set bothDeliveriesConfirmed=false and confirm DELIVERY_UNMATCHED.
   2. In the worksheet replace that combined teaching flag with two separate provider records and observation times.
   3. Assign the missing leg to its settlement owner while retaining the completed leg's evidence.

   Expected result

   Support can explain which party's delivery remains unresolved without disclosing private counterparty files.

   If your result is different

   When a response is lost, look up the authoritative record before proposing a retry; silence is not proof that no transfer occurred.

4. 04

   Close the review without inventing guarantees

   Do this

   1. Set agreementValid=false and verify that stale terms cannot qualify the fixture for review.
   2. Restore the baseline and retain MATCHED_FOR_REVIEW as the local outcome.
   3. Document the actual escrow, delivery-versus-payment or other settlement arrangement separately with its owners and failure procedure.

   Expected result

   The completed packet explains terms and observed deliveries while leaving custody and execution guarantees to the actual arrangement.

   If your result is different

   This classifier is not an escrow or atomic-swap implementation. Do not connect its output directly to a signing service.

Review what you produced.

Save the worksheet, unmodified test output, one deliberately failing case and the explanation of its fix. A useful result includes an unresolved item with an owner; it is not just a screenshot of four green tests.

Map the model to actual systems.

Your desk supplies negotiation, trade agreements, price acceptance, liquidity, dispute resolution, and the approved settlement arrangement. Confirm custody and counterparty responsibilities independently.

For each worksheet field, name the owning system, exact current operation, permission and error behavior. Put “not available” next to any missing operation and assign a dependency owner. Do not substitute the teaching classifier for that missing integration.

Open the current API reference and inspect each operation’s request, response, scope and implementation status. Code examples on this page are local models only; they do not call those operations.

Before a real deployment, the responsible organization must obtain appropriate legal, compliance and security review. The tutorial does not determine licensing, eligibility, entitlement enforceability or financial suitability.

Take the next technical step.

Use your worksheet and failing-case notes in the next walkthrough. Keep the same reference trail so you can see which assumptions become actual observations—and which remain dependencies.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.