Atinamos Verification
Core Principle You can pay to be tested. You cannot pay to be trusted.
Explore verification

Study 4 — Ashlar Blue Independent Assurance

Result

Classification: independent_assurance_partial

On 3 September 2026 Atinamos independently tested public Ashlar Blue discovery and assurance surfaces after Ashlar Blue invited Atinamos to test its facilitator infrastructure and inspect its hardware-attested evidence model.

The invitation did not affect the test standard or conclusion.

Atinamos confirmed that Ashlar publishes a conforming-looking _x402 DNS discovery record, a machine-readable /.well-known/x402 manifest, and a published npm trust SDK containing substantive discovery, evidence-reference and Merkle-verification code.

However, Atinamos could not independently reproduce several stronger live claims from the public evidence path presented at the time of testing:

x402 DNS discovery                  = observed
/.well-known/x402 manifest          = observed
live facilitator /supported         = not confirmed
published MCP endpoint              = not operational as advertised
current attestation independently
  checkable by published resolver   = false
raw Intel TDX quote verification    = not established
x402ev/1 implementation             = observed in published SDK
live x402ev/1 evidence artefact      = not located in tested public path

Atinamos reports what could be independently observed and reproduced. A published claim, registry entry or user-interface status is not treated as proof of the underlying condition unless the evidence chain can be independently checked.

Scope of the invitation

Ashlar Blue publicly invited Atinamos to test its public facilitator infrastructure and inspect hardware-attested evidence, including Intel TDX-related material and deterministic evidence/receipt digests.

Atinamos therefore tested the public evidence path available to an unrelated external verifier. No payment was made. A paid service purchase was not required to answer the invitation as presented, so Atinamos did not extend the exercise into a paid-service QA audit.

What Atinamos confirmed

x402 DNS discovery

Atinamos queried:

_x402.ashlar.blue

and observed:

v=x402-1
wk=https://ashlar.blue/.well-known/x402
k=facilitator
net=eip155:14,eip155:114,xrpl:mainnet
scheme=exact

The DNS record and public manifest were consistent about the three advertised exact network kinds.

Public x402 manifest

https://ashlar.blue/.well-known/x402 returned HTTP 200 JSON and advertised:

baseUrl: https://ashlar.blue/api
supported: /supported
verify: /verify
settle: /settle

It also published an attested-identity extension with supported enclave types and an allowed measurement root.

Published trust SDK

Atinamos preserved the npm package:

@ashlar-blue/x402-trust 0.5.2

with local archive SHA-256:

81129897dc41171c01ab8766317761a3e4bdcb951c7b09f71f9432b497188f1a

Static inspection confirmed real implementations for DNS discovery, evidence references, registry badge reads, Merkle inclusion verification and evidence canonicalisation.

The package implements the evidence-reference format:

x402ev/1; digest=<alg>:<hex>[; anchor=<caip2>:<contract>:<record>][; ref=<uri>]

and treats the digest, rather than the fetch URL, as the stable identity of an evidence artefact.

Live facilitator result

The manifest-derived capability URL was:

https://ashlar.blue/api/supported

Atinamos received HTTP 200 with text/html containing the Ashlar website rather than a machine-readable facilitator kinds[] response.

Atinamos then executed Ashlar's own published resolveX402() implementation against ashlar.blue. The SDK returned:

{
  "via": "dns-txt",
  "attestationUsable": false,
  "liveCheck": "unreachable"
}

This is an important result: the live capability failure is not merely an Atinamos interpretation. Ashlar's own published resolver classified its current facilitator live check as unreachable at the observation time.

Advertised API and MCP surfaces

Ashlar's invitation referenced:

https://api.ashlar.blue

From the Atinamos test environment, A and CNAME DNS lookups for api.ashlar.blue returned NXDOMAIN.

Ashlar's public MCP manifest advertised:

https://ashlar.blue/api/mcp

A GET returned the public website HTML. A JSON-RPC POST using an initialize request returned:

HTTP 405 Method Not Allowed

Atinamos therefore did not observe an operational JSON-RPC MCP server at the advertised URL during this test.

Hardware attestation

Ashlar's public Ops page claimed an active Intel TDX node, including:

Node: tdx-us-east-01
Status: TDX MKTME ACTIVE
Silicon: Intel Xeon Scalable 4th Gen (TDX v4)
MRTD Hash: 0x7f83...9069
Quote Authority: Intel Root CA (Verified)
Ledger DA Anchor: Flare DA Block #18492810

These are observed Ashlar claims. Atinamos did not locate publicly dereferenceable raw Intel TDX quote bytes, Intel collateral, a full quote-verification chain, or a public verifier that allowed the claim to be reproduced independently.

Ashlar's own resolver returned:

attestationUsable: false

because the live manifest did not contain the top-level independently checkable attestation structure expected by that resolver.

Accordingly, Atinamos records:

Hardware attestation claimed. Independent raw Intel TDX attestation verification not established from the public evidence surfaces inspected.

Historical registry evidence

The published SDK documents a Coston2 registry lookup for the badge kind:

x402-facilitator-attested

and publishes the registry address:

0xb02f83e994830C4954c89C10482665A3963229c5

The SDK correctly distinguishes:

verified        = historical/durable registry fact
liveAttestation = current manifest state
attestedNow     = both conditions true

However, the README instructs callers to obtain the subject from:

r.manifest.badges.subject

while the live manifest contained no badges block and the inspected package did not expose the missing Ashlar subject address elsewhere. Atinamos therefore could not reproduce the historical badge lookup from the published discovery path alone.

Public verification controls

Two public UI controls were inspected because they appeared to provide direct attestation verification.

Ops — “Re-Verify All Quotes”

The implementation did not retrieve or verify quotes. Its JavaScript used a timer and then unconditionally displayed:

✓ All 4 Clusters Verified Valid

Atinamos therefore records this control as a presentation-layer animation, not an observable cryptographic re-verification operation.

Developer Lab — “Execute Cryptographic Audit”

The page source explicitly labels its implementation:

Sandbox Audit Simulator Logic

The function selects one of three predefined scenarios and prints predetermined Intel CA, MRTD, freshness and verdict messages. No quote retrieval, certificate-chain validation, hashing, nonce calculation, signature verification or Flare lookup was observed in that function.

Atinamos therefore records the Developer Lab as a simulation of attestation-verification outcomes, not as evidence that a real Intel TDX verification occurred.

MCP attestation-entry verification

The published MCP implementation contains a tool named:

x402_verify_attestation_entry

Its implementation accepts an already-formed directory entry plus Merkle proof, index, size and output root, then calls verifyEntry(...).

This can verify Merkle inclusion of the supplied record. It does not itself parse or cryptographically validate raw Intel TDX quote bytes, Intel collateral, MRTD derivation or quote freshness.

Atinamos therefore distinguishes:

Evidence that an attestation record belongs to a committed tree is not the same thing as verification of the underlying hardware attestation.

A package-wide search of the published runtime distribution did not identify a separate raw Intel TDX quote-validation implementation.

Deterministic evidence model

The strongest independently inspectable part of the Ashlar assurance implementation was the deterministic evidence-reference model.

Atinamos confirmed that the published SDK contains x402ev/1 encoding/parsing and a canonical JSON function intended for RFC 8785/JCS-style evidence hashing.

The package documentation instructs verifiers to fetch an evidence artefact, canonicalise it, hash it and compare the resulting digest with the evidence reference.

Atinamos confirmed the implementation exists. A current live x402ev/1 evidence artefact suitable for independent digest recomputation was not located through the public evidence path exercised in this test, so no live digest match is claimed here.

Overall conclusion

Atinamos's independent result is mixed rather than binary.

Confirmed:

  • x402 DNS discovery publication;
  • public machine-readable x402 manifest;
  • substantive published trust SDK;
  • deterministic x402ev/1 evidence-reference implementation;
  • explicit separation in the SDK between durable historical verification and current live attestation state.

Not independently reproduced at the observation time:

  • a live machine-readable facilitator /supported response;
  • the advertised MCP server;
  • a current independently checkable Intel TDX attestation;
  • a reproducible historical badge lookup from the discovery chain;
  • a live x402ev/1 evidence artefact whose digest Atinamos could independently recompute.

The narrow Atinamos conclusion is therefore:

Ashlar Blue publishes meaningful discovery and evidence-verification architecture, but the public deployment observed on 3 September 2026 did not provide Atinamos with a complete reproducible path to several of its strongest live facilitator and Intel TDX assurance claims.

What this does not prove

This observation does not prove that:

  • Ashlar Blue has no working facilitator infrastructure elsewhere;
  • its TDX infrastructure is fabricated or invalid;
  • a private or unpublished TDX verifier does not exist;
  • historical attestation evidence is false;
  • the observed routing or deployment state is permanent;
  • Ashlar Blue as an organisation is trustworthy or untrustworthy.

It records what an unrelated verifier could independently reach and reproduce through the public paths inspected at the stated time.

Buyer-facing evidence statement

A buyer or verifier considering Ashlar-related infrastructure should see:

Atinamos independently tested Ashlar Blue's public discovery and assurance path on 3 September 2026. DNS discovery and the public x402 manifest were observed, and the published trust SDK contains substantive evidence/discovery implementations. The SDK's own live check classified the facilitator as unreachable and attestationUsable as false at the observation time. Public TDX status claims were observed, but raw independently verifiable Intel TDX evidence was not reached through the tested public path. No payment was made. Apply your own policy to these timestamped observations.

Atinamos publishes evidence, not a universal trust verdict.