Ashlar Blue Institutional & Developer Documentation

# Platform Overview

Ashlar Blue addresses the fundamental constraint of institutional cross-rail clearing: transaction graph surveillance and counterparty settlement risk. When institutions transact across public and permissioned ledgers without enclave isolation, their bilateral books, margin positions, and execution strategies are exposed to external observation.

Ashlar Blue unifies three core technologies into a single non-custodial clearing layer:

• Hardware Enclaves (AMD SEV-SNP & Intel TDX): Continuous 24/7/365 post-match multilateral netting, SPAN 2 / ISDA SIMM cross-margining, and signature validation execute within hardware-isolated memory perimeters inaccessible to hosts, cloud providers, or operators.
• Dual-Stack x402 Clearinghouse Authority: Gasless two-phase DvP/PvP settlement routing using canonical EIP-3009 authorizations, ISDA CDM bindings, and IETF DNS discovery.
• IETF SCITT Transparency Receipts (RFC 9162): Every settlement emits a 384-byte merkleized Digital Regulatory Reporting (DRR) receipt verifiable offline in sub-millisecond latency without calling live APIs.

# 5-Minute Quickstart

To interact with an x402 clearing endpoint on Ashlar Blue, follow the two-step handshake:

Step 1: Probe the Resource for the 402 Challenge

Send an unauthenticated request to the clearing endpoint. The server responds with HTTP 402 Payment Required containing the accepted settlement rails and terms in the canonical payment-required header:

curl -i -X POST https://api.ashlar.blue/settle/isda

Step 2: Interactive Live Endpoint Probe

Test the live D-FMI settlement endpoint directly from this documentation portal:

# The x402 Protocol Wire Specification

Ashlar Blue operates a dual-stack x402 v1 / v2 non-custodial clearing authority. In x402 v2, settlement requirements are delivered in the payment-required Base64 response header:

HTTP/2 402 Payment Required
Content-Type: application/json; charset=utf-8
Access-Control-Expose-Headers: payment-required
payment-required: eyJ4NDAyVmVyc2lvbiI6MiwiZXJyb3IiOiJwYXltZW50IHJlcXVpcmVkIiwicmVzb3VyY2UiOnsidXJsIjoiaHR0cHM6Ly9hcGkuYXNobGFyLmJsdWUvc2V0dGxlL2lzZGEiLCJkZXNjcmlwdGlvbiI6Ikluc3RpdHV0aW9uYWwgSVNEQSBDRE0gRHZQIGNsZWFyaW5nIGFuZCBTQ0lUVCBhdHRlc3RhdGlvbiByZWNlaXB0LiJ9LCJhY2NlcHRzIjpbeyJzY2hlbWUiOiJleGFjdCIsIm5ldHdvcmsiOiJlaXAxNTU6ODQ1MyIsImFtb3VudCI6IjEwMDAwMCIsImFzc2V0IjoiMHhBblVTREM4MzM1ODlmQ0Q2ZURiNkUwOGY0YzdDMzJENGY3MWI1NGJkQTAyOTEzIiwicGF5VG8iOiIweDNjMzY0NTBiODRiN2I5NzEyQTM5NmFiNGUxYjU1MTg4OGFiMzY1OTkiLCJtYXhUaW1lb3V0U2Vjb25kcyI6MzAwfV19

Decoded, the challenge contains an array of acceptable offers identified by CAIP-2 network identifiers:

# DNS Discovery Specification (_x402)

Institutional OMS/EMS systems and settlement engines discover clearing endpoints without centralized registries by querying standard DNS TXT records defined under the IETF x402 DNS Discovery draft.

To announce an x402 settlement authority for a domain, configure the _x402 apex record:

_x402.ashlar.blue. IN TXT "v=x402-1; wk=https://api.ashlar.blue/.well-known/x402; k=facilitator; net=multi-rail; scheme=exact"

# Hardware Enclave Silicon & Remote Attestation

All clearing decisions and cryptographic verifications on Ashlar Blue execute inside attested hardware execution environments: AMD SEV-SNP and Intel TDX.

Verifying Remote Attestation

Integrators can independently verify the enclave's code integrity using the verify_tdx_quote or get_enclave_attestation tool over the Model Context Protocol (MCP) or via our public API endpoint.

# Model Context Protocol (MCP) Server

Ashlar Blue provides a full-featured MCP server (@ashlar-blue/x402-trust v0.5.95) enabling institutional engineering teams and automated compliance agents to discover clearing endpoints, verify enclave attestation, and validate SCITT receipts.

{
  "mcpServers": {
    "ashlar-trust": {
      "command": "npx",
      "args": ["-y", "@ashlar-blue/x402-trust", "mcp"]
    }
  }
}

Core Tool Reference

# REST API Reference

The non-custodial clearinghouse exposes clean HTTP endpoints for pre-settlement verification, atomic DvP/PvP settlement, and capability discovery.

POST /verify

Pre-verifies an EIP-3009 authorization before broadcast to confirm signature validity, nonce status, and sufficient balance.

curl -X POST https://api.ashlar.blue/verify \
  -H "Content-Type: application/json" \
  -d '{
    "x402Version": 2,
    "paymentPayload": {
      "from": "0x118970D2b9c36fB65Eb00F0203Ad5DF...",
      "to": "0x3c36450b84b7b9712A396ab4e1b551888ab36599",
      "value": "100000",
      "validAfter": 0,
      "validBefore": 1788700000,
      "nonce": "0x8f2d...",
      "v": 27,
      "r": "0x...",
      "s": "0x..."
    }
  }'

GET /supported

Returns the live array of supported multi-rail settlement adapters, tokens, and hardware enclave environments.

{
  "networks": [
    { "name": "multi-rail-direct", "caip2": "eip155:8453", "type": "evm" },
    { "name": "multi-rail-ledger", "caip2": "xrpl:0", "type": "settlement" },
    { "name": "multi-rail-attested", "caip2": "eip155:14", "type": "evm" },
    { "name": "multi-rail-enterprise", "caip2": "eip155:50", "type": "evm" }
  ],
  "enclaves": ["GCP_AMD_SEV_SNP", "INTEL_TDX_V4"],
  "standards": ["x402-v2", "EIP-3009", "RFC-8785", "IETF-SCITT-RFC-9162"]
}