# Technical domain-bridge investigation

Case SP–GTS–001 · Prepared 5 November 2026, approximately 12:27 UTC.

**This branch found new dated infrastructure records, but did not establish the requested bridge** between `treasurysolutions.com`, `globaltreasury.solutions`, and GLOBAL TREASURY SOLUTIONS LTD (15907803). The positive findings are historical Global Treasury DNS and recent mail-domain certificates. Neither identifies the UK company or the named individuals as operator. The machine-readable companion is [domain-bridge-technical-findings.json](domain-bridge-technical-findings.json).

## Findings

### DBT-F01 · Global Treasury infrastructure independently observed in January 2026

The public [WhoisFreaks Global Treasury history page](https://whoisfreaks.com/tools/dns/history/lookup/globaltreasury.solutions), captured **2026-11-05 12:24:36.567286 UTC**, displays a historical configuration first seen **24 January 2026**, last seen **9 August 2026**:

- A: `83.228.211.130`
- AAAA: `2001:1600:18:102:0:0:0:388`
- Nameservers: `ns43.domaincontrol.com.` and `ns44.domaincontrol.com.`
- SOA primary: `ns43.domaincontrol.com.`, administrative name `dns.jomax.net.`, serial `2026012207`

This adds a provider-observation date alongside the previously preserved certificate whose validity starts 23 January 2026. It **does not establish a launch date, trading, ownership or the UK-company connection**. First/last-seen fields belong to the provider’s dataset. The SOA serial is a version value and is not independently a dated business event. The page warns that anonymous data may be stale.

Raw source and exact request metadata: `sources/domain-bridge-technical/whoisfreaks-global-history.{body,json}`; extracted response: `whoisfreaks-global-visible.txt`.

### DBT-F02 · Fresh certificate validity dates for treasurysolutions.com

The public [Cert Spotter query](https://api.certspotter.com/v1/issuances?domain=treasurysolutions.com&include_subdomains=true&expand=dns_names&expand=issuer), captured **12:23:58.320450 UTC**, returned five unexpired certificate issuance objects. Three have validity starts on **3–4 November 2026**. The latest returned object begins **2026-11-04 02:57:11 UTC** and expires **2027-02-01 20:46:33 UTC**. The returned SAN names are only `treasurysolutions.com` and `*.treasurysolutions.com`.

This is recent certificate infrastructure, **not evidence that people took fresh action, that the website is reachable, or that business continued after dissolution**. Managed platforms can renew certificates automatically. The issuer strings include Google Trust Services WE1 and a Cloudflare TLS Issuing ECC CA operated by SSL.com. Those commercial providers do not identify the domain’s business operator.

The documented next page after issuance `18161073065` returned an empty array at **12:26:15.916587 UTC**. The five objects therefore exhaust this particular unexpired query at retrieval. The [primary API documentation](https://sslmate.com/help/reference/ct_search_api_v1), captured **12:24:54.677113 UTC**, expressly limits this endpoint to unexpired issuances and warns that `not_before` can be predated or postdated. It is **not a full historical certificate search**, and a validity-start timestamp should not be relabelled as an exact issuance timestamp.

Raw sources: `certspotter-mail.{body,json}`, `certspotter-mail-next.{body,json}`, `certspotter-primary-docs.{body,json}` in the source folder.

### DBT-F03 · No certificate bridge in the compared records

None of the five mail-domain certificates names Global Treasury in its SANs. The API query for Global Treasury returned an empty array; because the API covers unexpired certificates, that does not contradict the previously presented expired Global Treasury certificate.

A local cryptographic comparison was also completed against that preserved Global Treasury certificate. Its DER SubjectPublicKeyInfo SHA-256 is `c7014fa627454275c0091280b25bda099853f78a612c37000d1943e6c8589323`. It matches **none** of the five returned mail-domain public-key hashes. The exact compared IDs, fingerprints and keys are preserved in `certificate-comparison.json`.

This is a **bounded negative comparison**: one previously presented Global certificate versus five current mail-domain certificates. It cannot exclude an older joint certificate, common ownership, different servers or an unrelated past configuration. No certificate-transparency log was scanned in bulk and no new certificate was requested.

### DBT-F04 · Independent Portuguese archive queries returned no captures for these inputs

[Arquivo.pt’s Global Treasury version-history query](https://arquivo.pt/textsearch?versionHistory=globaltreasury.solutions&maxItems=50) returned HTTP 200, zero estimated results and an empty response-item list at **12:24:36.887342 UTC**. The [mail-domain equivalent](https://arquivo.pt/textsearch?versionHistory=treasurysolutions.com&maxItems=50) did the same at **12:24:53.135010 UTC**.

This materially different archive route supplies a valid archive-specific result despite the earlier Internet Archive CDX rate limit. It does not establish that either site never existed, and it does not inspect every possible path or independently establish Arquivo’s completeness. The empty pages contain no capture identifier to follow. The advertised `next_page` is a generic pagination URL even when the result count is zero; it was not mistaken for evidence of another page of captures.

Raw sources: `arquivo-global-history.{body,json}`, `arquivo-mail-history.{body,json}`.

### DBT-F05 · Existing public urlscan search remains limited

The mail-domain existing-scan [search API](https://urlscan.io/api/v1/search/?q=domain%3Atreasurysolutions.com&size=100) returned zero results at **12:23:56.182662 UTC**, with an explicit `search_date_limit_days: 30`. No scan was submitted. This cannot support a historical absence claim. The earlier Global Treasury query had the same limitation, recorded in [the original domain trail](global-impact-trail.md). No public result UUID or archived response was recovered to inspect further.

Raw source: `urlscan-mail-existing.{body,json}`.

### DBT-F06 · Exact-root Common Crawl queries still failed upstream

The earlier branch tried domain-wide queries in September/October indexes. This branch tried the narrower **exact root URL** in the January 2026 index for each domain. Global Treasury returned HTTP 504 at **12:23:44.489779 UTC**; the mail domain returned HTTP 504 at **12:23:55.329111 UTC**. Raw metadata records the precise request URLs and client times.

These are upstream failures, not zero-capture results. No capture offset, WARC filename or payload was obtained. The same failed query was not repeatedly retried, and no WARC content was invented. The other public-footprint branch owns further mail-website archive work to avoid duplication.

Raw sources: `cc-exact-global-2026-04.{body,json}`, `cc-exact-mail-2026-04.{body,json}`.

### DBT-F07 · Hosting addresses lead to Infomaniak, not a named case subject

The recovered IPv4 address was followed to [RIPE RDAP](https://rdap.db.ripe.net/ip/83.228.211.130), captured **12:25:48.039086 UTC**. It falls in `83.228.211.0–83.228.211.255`, network name `INFOMANIAK-CLOUD`, country CH. [The IPv6 RDAP record](https://rdap.db.ripe.net/ip/2001:1600:18:102::388), captured **12:25:48.062455 UTC**, names the allocation `CH-INFOMANIAK-20070726`. Both identify Infomaniak Network SA in public administrative/technical records.

This identifies network administration, **not the hosting customer or website operator**. Sharing a Swiss provider or being located in the same country as the Impact operator would not establish control or succession. The raw RDAP records contain no identified case-subject/customer assignment. This hosting-provider branch reaches that attribution boundary; the provider was not contacted.

Raw sources: `ripe-global-ipv4.{body,json}`, `ripe-global-ipv6.{body,json}`.

### DBT-F08 · Public Global Treasury MX history supplies no email-domain link

The [ordinary public MX-history filter](https://whoisfreaks.com/tools/dns/history/lookup/globaltreasury.solutions?type=MX&page=1) returned HTTP 200 at **12:25:46.705428 UTC**, but the rendered page says `404` and `No Record Found` for Global Treasury. This is a provider application result, not an HTTP 404, and it does not prove there was never an MX record. No hidden or gated record was inspected. No mail-routing reference to `treasurysolutions.com` was recovered.

Raw source: `whoisfreaks-global-mx.{body,json}`; visible text saved separately as `whoisfreaks-global-mx-visible.txt`.

### DBT-F09 · Required entity bridge remains unresolved

The new sources above contain no retrieved legal notice, company-number identifier, shared cross-domain certificate, common subscriber identity or dated redirect tying the three requested nodes together. The named-company attribution therefore remains **unverified in this technical branch**. Similar names, mainstream GoDaddy infrastructure, hosting geography and certificate renewals must not be converted into a documented company relationship.

The earlier public mail-domain history snapshot names different GoDaddy nameservers (`ns39`/`ns40`) and A addresses (`3.33.130.190`, `15.197.148.33`) from this Global Treasury snapshot. These observations concern different dates and cannot prove separateness either. They provide no distinctive matching technical identifier. See [historical email-date follow-up](historical-email-date.md).

## Collection limits and preservation

The branch used public GET requests and existing records. It made no subject contact, account access, login, new urlscan submission, active service scan or invalid-TLS exception. Search-index exact pair/company-number queries yielded no relevant result in this bounded check, but search indexes are incomplete. The root investigation separately owns the fresh current-domain and registrar checks and the Internet Archive availability-API route.

Every newly collected response has a client request/completion timestamp, URL, status/error, raw body and SHA-256 digest. The initial guessed Cert Spotter documentation route returned 404; it is preserved as an error and was replaced by the provider’s actual documented API reference. The collector script remains for reproducibility. Generated Python caches have been removed and are excluded from the evidence manifest.

The machine findings file carries stable DBT-Fxx finding IDs and DBT-Sxx source IDs for integration without changing the application or master reports. Hashes document snapshot integrity after collection; they do not independently authenticate a publisher or prove historical ownership.