Ordex Rescue Mission - findings and ways to recover Ethscriptions

0_ordex-rescue-prompt.md

Here is the Ordex Ethscriptions escrow-based marketplace - https://etherscan.io/address/0xC33F8610941bE56fB0d84E25894C0d928CC97ddE

The worst part of Ethscriptions trading - it requires escrow-based markets, to this day.

I am Wiggle/WGW (@wgw_eth on x/twitter). I'm builder and part of ethscriptions since day one. Well-known in the community and one of the few most familiar with anything Ethscriptions - after the founders Tom & Hirsch, and Chopper Daddy.

Ordex rugpulled, and had a backend-based signer behind API, i believe.

The problem is that there are thousands of ethscriptions locked there (as seen in the screenshot with escrow-0xC33F8. Can we figure out a way to rescue them? The escrow is a proxy, and unverified contract. Can we decompile the bytecode, recover into a proper solidity for better inspection of what does, and figure out a backdoor? Going through the previous proxy impl upgrades would probably be beneficial too.

The idea is to find a way to rescue (transfer out) the stuck ethscriptions to their respective depositor, or at the worst case to a single new owner that will distribute them.

The ittybits founder (@posvar on twitter/x) even put a bounty awhile ago, if somebody can help save the stuck ittybits. The bounty is off, i think, we are not doing it for the bounty. Just that i got a bit of time to spend some time figuring it out.

Back when Ordex crashed, while the API was still working, I helped with scripts for rescuing. But after the API went down too.. I don't know.

That's why we should start from the contract. If it can help us if it decisively requires the API-backed signer or not.

1_research-response.md

Done — I pulled the escrow apart on-chain and decompiled/analyzed the implementation. Here's the decisive picture.

See more detailed addresses and info at 2_FINDINGS.md file below.

The bottom line

Rescue does NOT require the Ordex API/backend to be running — but there is no permissionless backdoor either. Every way an ethscription can leave that escrow is gated by a cryptographic signature or a role, and all the meaningful power collapses onto a single, still-live EOA: 0x92545Caf654109b354ff5BcC7b5a4343f77BF269. So this is a key-custody / cooperation problem, not a contract-bypass problem. Decompiling further won't produce a magic exit — I checked the actual signature-verification path and it's sound.

What the contract actually is

It's a stock OpenZeppelin TransparentUpgradeableProxy → ProxyAdmin (0xddac7e8b…) → implementation 0x11BA2230…ACadB4 (unverified, but I recovered its full ABI + logic). The impl is an "ORDEX" EthscriptionMarket built on OZ AccessControlEnumerable + Ownable + ReentrancyGuard + EIP-712.

The complete external ABI has no deposit, no emergency-withdraw, no owner-withdraw, and no depositor-only withdraw. The only three ways items move out:

Function	Gate
bulkTransferItems((from,to,ids),(deadline,v,r,s))	EIP-712 sig from an INDEXER_ROLE key
bulkWithdrawItems((from,to,ids),(deadline,v,r,s))	INDEXER sig + "EM: are you owner?" (depositor must match)
checkout(from,to,itemId,price)	EXCHANGE_ROLE (a contract)

From the bytecode: exactly one ecrecover, EIP-712 domain name="ORDEX", version="1", deadline/expiry enforced ("EM: expired"), global nonce (lastUsedNonce=1440), and the recovered signer must hold INDEXER_ROLE or it reverts "EM: wrong sig". This is textbook — you cannot forge an indexer signature without an indexer private key, and those two indexer addresses (0x5dEa8369…, 0x818D4B7e…) have never sent a transaction, so there's no nonce-reuse key leak to exploit.

Who holds the keys (this is the whole game)

• 0x92545Caf…BF269 — the god key. It is simultaneously the ProxyAdmin owner (can upgrade), the DEFAULT_ADMIN_ROLE holder (can grant INDEXER_ROLE to anyone), and Ownable owner(). It's a live EOA — nonce 390, last active ~2025-10-08 (a USDC transfer), and it called the Ordex exchange contract directly in 2025. This key is not lost; it's the operator's.
• INDEXER_ROLE = the API's off-chain signer keys.
• EXCHANGE_ROLE = 0xC89C2E60… (a contract, not a signer).

Realistic rescue paths, ranked

1. Reach whoever controls 0x92545Caf… and have them grantRole(INDEXER_ROLE, <a key you control>). Then you sign EIP-712 bulkTransferItems messages sending each depositor's items back to them (or to a distributor). This reuses existing, audited code — cleanest and no upgrade risk. This is the whole rescue if the operator cooperates, and the key being live/funded suggests they're reachable.
2. Same key upgrades the implementation (via ProxyAdmin) to one with an unconditional rescue(). More powerful but riskier, and it needs an on-chain enumerable item list, which this contract may not have — so path 1 is actually better since bulkTransferItems takes explicit id arrays.
3. Harvest old, still-valid indexer signatures you may have cached from your 2023-era rescue scripts, or from failed/pending txs — the only path that needs neither the key nor the operator. But there's a deadline check, so anything the API signed back then is almost certainly expired. Worth grepping your old scripts to confirm, but I'd treat it as a long shot.

There is no fourth path. Absent that key or a valid indexer sig, the items cannot move — the access control is clean.

What I'd do next (I can drive these)

• Rebuild the rightful-owner list now, independent of any rescue path: escrows(uint256) is a public getter returning the depositor per item (keyed by the ethscription id as uint256). Cross-referenced with the ethscriptions.com transfer history into the escrow, that reconstructs the full depositor→items map for all 2244 ittybits / 2148 darwins / 486 nakamingos / 352 phunks / 348 mfpurrs / 210 moonbirds. Having this ready makes path 1 executable the moment a key is available.
• Confirm whether 0x92545Caf maps to a known Ordex identity you can contact (I can trace its funding/counterparties).
• If you find any cached indexer signatures, I can decode them against the exact EIP-712 struct and test-simulate bulkTransferItems to see if any are still live.

Full writeup with every address, slot, and string I decoded is saved at /home/arcka/brainstorming/ordex/FINDINGS.md.

Want me to start reconstructing the depositor→items map from the escrows mapping + transfer history?

2_FINDINGS.md

Ordex escrow (0xC33F8610941bE56fB0d84E25894C0d928CC97ddE) — recovery analysis

Architecture

• Standard OpenZeppelin TransparentUpgradeableProxy (proxy bytecode selectors: upgradeTo/upgradeToAndCall/changeAdmin/admin).
• EIP-1967 implementation: 0x11BA2230F2275e9DedF3a3147249E9bcB6ACadB4 (unverified, 6860 bytes).
• EIP-1967 admin: 0xddac7e8b536e6c1f4acfe7d64488fcb47a6560b0 = an OZ ProxyAdmin contract.
• ProxyAdmin.owner() = 0x92545Caf654109b354ff5BcC7b5a4343f77BF269.

Implementation = "ORDEX" EthscriptionMarket (OZ AccessControlEnumerable + Ownable + ReentrancyGuard + EIP-712)

Full external ABI (decoded from selectors):

• release/movement: bulkTransferItems((address,address,uint256[]),(uint256,uint8,bytes32,bytes32)), bulkWithdrawItems((address,address,uint256[]),(uint256,uint8,bytes32,bytes32)), checkout(address,address,uint256,uint256)
• data: escrows(uint256)->address, itemToCollection(uint256)->address, tokenBalances(address,address), collectionTypes(address), lastUsedNonce()=1440, cooldownPeriod()=0
• roles: isIndexer(address), EXCHANGE_ROLE(), INDEXER_ROLE(), DEFAULT_ADMIN_ROLE(), grant/revoke/renounce/get role*, owner()/transferOwnership/renounceOwnership, __EthscriptionMarket_init()
• No deposit, no emergency-withdraw, no owner-withdraw, no depositor-only withdraw.

Control map (all read from chain)

• 0x92545Caf654109b354ff5BcC7b5a4343f77BF269 = god key — simultaneously ProxyAdmin owner (upgrade), DEFAULT_ADMIN_ROLE (can grant any role), and Ownable owner(). EOA. nonce 390. Last tx ~2025-10-08 (USDC transfer); also called the exchange contract directly in 2025 → live, operator-controlled, not lost.
• EXCHANGE_ROLE holder: 0xC89C2E6FE008592D6a787eFd02DB7fDB8eA64020 — a CONTRACT (proxy → impl 0x9630a602...).
• INDEXER_ROLE holders (the API signers): 0x5dEa8369776d279bB812C93C3b095Cf593724069, 0x818D4B7eFDf9fE70E2eD69084B4a0dDeDb8818A2 — both nonce 0 / 0 ETH (pure off-chain signing keys).

Release mechanics (from disassembly)

• Exactly one ecrecover (STATICCALL @ 0x9f3). Signatures are EIP-712: domain name "ORDEX", version "1", standard EIP712Domain typehash (0x8be0079c..., includes chainId).
• Recovered signer must hold INDEXER_ROLE else revert "EM: wrong sig".
• Also enforced: expiry ("EM: expired"/"EW: expired"), depositor check ("EM: are you owner?"), "EM: not to contract", exchange gate on checkout ("EM: exchange?"), reentrancy guard, global nonce (lastUsedNonce).
• No CHAINID opcode found in runtime (domain separator likely cached/hardcoded to mainnet) — irrelevant to forgery.

Verdict

• Does rescue require the Ordex API/backend running? NO.
• Is there a permissionless/cryptographic backdoor? NO — signature verification is textbook EIP-712 + ecrecover + AccessControl. You cannot forge an INDEXER signature without an INDEXER private key, and those addresses never transacted on-chain (no key leakage via nonce reuse).
• The ONLY levers are held by the god key 0x92545Caf: (a) grantRole(INDEXER_ROLE, fresh key) then sign EIP-712 bulkTransferItems to send items to depositors; or (b) upgrade the implementation to add an unconditional rescue. Both need cooperation of / access to that one live EOA. Rescue is a key-custody problem, not a contract-bypass problem.

Rightful-owner reconstruction

• escrows(uint256 ethscriptionIdAsUint) returns the depositor per item (public getter) — keyed by the ethscription id (bytes32→uint256), not a sequential index. Cross-reference with ethscription transfer history INTO the escrow (ethscriptions.com indexer) to rebuild the full depositor→items map.

Frontend key-leak hunt (ordex.io Wayback) + API liveness — CONCLUSION

• Scanned ~90 unique decoded JS chunks (incl. every pages/_app bundle variant across 4 build IDs) + page-data JSON.
• NO leaked secret: the 166 privateKey hits are ethers.js library code (SigningKey/HDNode, BIP32 0x0488ADE4/0x0488B21E); no new Wallet('0x..') / no 64-hex key literal; no mnemonic; no JWT. Indexer signer addresses (5dea8369/818d4b7e) never appear client-side.
• Only client config present: NEXT_PUBLIC_API_ORD, NEXT_PUBLIC_DRPC_ID (runtime ${eR} template, not hardcoded), NEXT_PUBLIC_DEPLOYMENT_URL, NEXT_PUBLIC_HIGHLIGHT_CHAIN; public contract addr c89c2e6f (exchange).
• Backend hosts discovered: api.ordex.io (+/v0.1, Rarible/Union protocol), eths-api.ordex.io (ethscriptions signer), go.ordex.io, ord-mirror.ordex.io (NXDOMAIN), union-api.ordex.ai, litecoin-api.ordex.io, openordex.org.
• Signer endpoints: eths-api.ordex.io exposes /checkout and /signer/s/{bc,dc,tc,wc} (the sig-producing routes).
• LIVENESS: eths-api.ordex.io + api.ordex.io resolve to Cloudflare, TLS handshakes succeed, but ORIGIN never responds (request hangs → no HTTP status). The signer backend is DOWN. API rescue path is dead.

FINAL VERDICT

Both API-independent rescue routes are closed: (1) no indexer key leaked to the frontend; (2) the signer API origin is offline. The ONLY lever that can move items out of 0xc33f is the admin/owner EOA 0x92545Caf654109b354ff5BcC7b5a4343f77BF269 (ProxyAdmin owner + DEFAULT_ADMIN_ROLE + Ownable owner; live, last active 2025-10). Rescue = obtain cooperation/custody of that key, then either grantRole(INDEXER_ROLE, freshKey) and sign EIP-712 bulkTransferItems to depositors, or upgrade the impl to add an unconditional rescue.

3_chat.md

Where it landed

The frontend key-leak hunt came back negative, and I also confirmed the signer API is dead — which together close out the two "no-admin-key" rescue routes. Here's the full picture.

Frontend scan (ordex.io Wayback, ~90 unique decoded chunks incl. every _app bundle across all 4 build IDs + page JSON): no leaked key. The 166 privateKey matches are all ethers.js library internals (SigningKey/HDNode, BIP32 version bytes 0x0488ADE4/0x0488B21E) — there's no new Wallet('0x…'), no 64-hex key literal, no mnemonic, no JWT. The two indexer signer addresses never appear client-side at all. The only config in the bundle is NEXT_PUBLIC_* (client-safe by design) and public contract addresses. Signing was server-side, as you remembered — nothing bled into the client.

The signer API is offline. The scan did surface the backend map, including the money endpoints: eths-api.ordex.io exposed /checkout and /signer/s/{bc,dc,tc,wc} — those are the routes that minted the EIP-712 withdrawal signatures. But eths-api.ordex.io (and api.ordex.io) now resolve to Cloudflare, TLS handshakes succeed, and then the origin never answers — the backend behind Cloudflare is gone. That's exactly the "API went down" state you described; the original rescue path you used is no longer reachable.

Bottom line for the rescue

Every avenue that doesn't need the admin key is now ruled out:

• ❌ Permissionless/backdoor withdraw — doesn't exist (clean EIP-712 + ecrecover + AccessControl).
• ❌ Forge an indexer signature — need a private key you don't have; those addresses never touched chain, so no leakage.
• ❌ Leaked key in the frontend — confirmed not present.
• ❌ Replay an old/cached signature — expiry is enforced; and the API that made them is down.
• ❌ Revive the live API — origin is dead.

The only lever that moves anything out of 0xc33f is the admin EOA 0x92545Caf654109b354ff5BcC7b5a4343f77BF269 — it's simultaneously ProxyAdmin owner, DEFAULT_ADMIN_ROLE, and owner(), and it's a live wallet (last active Oct 2025). Whoever holds it can rescue everything cleanly two ways: grantRole(INDEXER_ROLE, <a fresh key>) and then sign EIP-712 bulkTransferItems sending each depositor's items back to them, or upgrade the implementation to add an unconditional rescue. So this is now a key-custody / find-the-operator problem, not a technical one.

What I'd do next (happy to drive any of these)

1. Trace 0x92545Caf — map its funding sources and counterparties (CEX deposits, ENS, links to Ordex socials) to identify/contact the operator. This is the single highest-value lead now.
2. Pre-build the depositor→items map from the escrows mapping + ethscription transfer history, so a rescue is executable the instant a key is available. This is worth doing regardless of how key custody shakes out.
3. Profile the sibling escrow 0x57b8… ("possibly Etch", 110k ethscriptions) the same way, in case it has a different (maybe softer) control model.

---

tunnckoCore / wgw

can you find the actual worker (cf worker - workers.dev domain, or vercel deployment - vercel.app domain) that was sitting behind the eths-api.ordex.io? There's gotta be some hints, headers, other stuff?

Meanwhile i found my unescrow script - from jan 2025 - it uses the api-next.ordex.io. Everything behind that domain is dead, that's clear, point is.. we should be able to find where the actual server was, you know.. vercel or cloudflare, i vaguely remember it was vercel, but i'm not sure. If we can find it somehow, we will use it since it could still be hosted and served and sit as project in his account.

Maybe i can scan my system for these api responses, shapes, headers?

---

also, Etch was totally another thing, but i believe it worth it to investigate it full blown too, from the bottom - the contract up. But i'm not that familiar with it, tho i do remember i had some ethscriptions there too. I think it's domain was etch.market but it's also dead anyway (maybe again through web archive). Do not start the investigation on etch yet. lets clear the points about ordex from above.

---

just talk, no work.

---

agent

Yeah, this is findable, and your instinct to check your own machine first is the right one — that's almost certainly the fastest path. Let me lay out how I'm thinking about it.

First, a distinction that matters. There are really two different backends in what we found, and only one of them is the target:

• api.ordex.io/v0.1/... — those /v0.1/nft-order/... and /v0.1/order/... paths are literally the Rarible Protocol "Union" API surface. That's a heavy JVM/Kotlin service (Rarible's open protocol). It would not have been a Cloudflare Worker or a Vercel function — that lives on a VPS/k8s/managed container somewhere. Not what we care about.
• eths-api.ordex.io / api-next.ordex.io with /checkout and /signer/s/{bc,dc,tc,wc} — this is the custom ethscriptions signer, the thing that produced the EIP-712 withdrawal signatures. This is the one plausibly on Vercel or a Worker, and the one you want.

So we're hunting the origin of eths-api / api-next specifically.

What's actually in front of it right now: those hostnames resolve to Cloudflare (104.26.x / 172.67.x), TLS still terminates, but the origin behind Cloudflare is dead. Note the contrast — ordex.io itself resolves to 76.76.21.21, which is Vercel's anycast IP. So the frontend was on Vercel, but the API subdomains were put behind Cloudflare (CNAME-flattened, so the real origin is hidden). Cloudflare-in-front tells us nothing about what's behind it — could be a Worker (compute on CF's own edge, no separate origin) or CF proxying through to a Vercel/Render/Fly/Railway origin.

The one signal that settles it: response headers from when it was alive. This is why your Jan 2025 script is gold. What to grep your system for:

• HAR exports, curl -v/-i logs, any saved .http output, axios/fetch error dumps (they often print the whole response), browser devtools "Copy as cURL" snippets, or the script's own logged responses.
• The headers that fingerprint the platform:
  • x-vercel-id, x-vercel-cache, server: Vercel → Vercel origin (and x-vercel-id even encodes the region, e.g. iad1).
  • cf-ray + server: cloudflare with no x-vercel-* and a Worker-style shape → likely a CF Worker / Pages Function.
  • x-powered-by: Express/Next.js, via:, fly-request-id, x-railway-*, x-render-*, x-served-by (Fastly) → tells us the host directly.
• Even the body of a 404/500 fingerprints it — Vercel's error page, a CF Worker's default, and an Express Cannot GET / all look distinct.

If you have a single real response with headers from api-next.ordex.io, we'll know Vercel vs Worker in about ten seconds. And if it's Vercel, the request ID region narrows the account/project.

Why you might be right that it's still live: when a custom domain dies, the underlying deployment often doesn't. A Vercel production deployment keeps serving at <project>.vercel.app (and its immutable <project>-<hash>-<team>.vercel.app URLs) even after the custom domain is detached, as long as the project isn't deleted. Same for a Worker at <name>.<account>.workers.dev unless workers.dev was disabled. So the plan, once we know the platform, is to find that native URL and hit it directly.

How we'd find the native URL when we resume work (no promises, ranked by likelihood):

1. Your script's headers/responses — as above. Decisive.
2. NEXT_PUBLIC_DEPLOYMENT_URL — I saw that env var name in the bundle but didn't pull its value yet. If it's a *.vercel.app, it confirms Vercel and likely reveals the team/project naming convention.
3. crt.sh (Certificate Transparency) — every TLS cert Vercel/CF ever issued for an *.ordex.io subdomain or an attached custom domain shows up. This often leaks staging hosts, api-old, or the raw *.vercel.app/*.workers.dev the domain was mapped to.
4. DNS history (SecurityTrails / DNSDumpster) — historical CNAME for eths-api/api-next. Before Cloudflare fronted it, it may have CNAME'd straight to cname.vercel-dns.com or a workers.dev — that's the smoking gun for the platform.
5. Wayback X-Archive-Orig-* headers — the archive preserves the original response headers as X-Archive-Orig-server, X-Archive-Orig-x-vercel-id, etc. Only one /api/ URL got archived, but any snapshot at all could carry the fingerprint.
6. Educated guesses at ordex-eths-api.vercel.app / eths-api-ordex.vercel.app / a worker subdomain, and probe.

One reality check so we go in clear-eyed: even if we find a still-live signer endpoint, whether it'll actually sign a rescue is a separate question. Two likely blockers — it probably requires an auth session (/auth/signin), and /checkout almost certainly reads order/ownership state from a database that's also dead. If the signing is gated on DB state, a live compute node still won't produce a signature. The scenario where it does help is if the signer route is thin enough to sign based on on-chain ownership alone, or if finding the live Vercel project effectively means it's your contact's account and they can just read the INDEXER private key out of the env vars (which then also just... gets used directly). Worth chasing, but the admin-key path stays the primary.

So my ask: dig up that Jan 2025 unescrow script and anything with captured api-next.ordex.io responses/headers. Share it (or point me at it) and I can read the exact auth flow, the request/response shapes, the endpoint that returned the signature, and — if headers are in there — the platform, in one pass. That single file probably collapses half of the list above.

Etch is parked — noted, contract-up investigation later, not touching it until we've closed out Ordex.

tunnckoCore / wgw

my script is tiny and doesn't have the response headers. it is on my gist. locally on my machine i probably could find the dir and the script too, but i don't believe i have response headers or error outputs. but i will scan at some point.

---

and ye, the frontend was definitely on vercel - the marketplace frontend site was down cuz of payment, but we were hitting the API with rescue scripts, thus it's most likely cloudflare.

fun fact: the ordex.io still resolves but the page is vercel's "payment required" This deployment is temporarily paused. maybe if we can find the frontend's vercel .app domain we could debug it totally.

---

check the public deployment url, the crt.sh for the subdomains, the full ordex.io deep dive too, and the dns history, and the wayback headers, and the educated guesses (on vercel - i tried the listed it's 404, but again i think it was on cloudflare because his account was blocke due to failing payment).

agent

That settles it. Pointed at Vercel's IPs, the API hostnames return 000 (Vercel drops the TLS SNI for domains not in the account) — whereas the real frontend hosts like staging-beta return 402 DEPLOYMENT_DISABLED. So the API was never on Vercel. Combined with the 522 (rules out a CF Worker) and the 404 from the live OVH box, the conclusion is firm.

Here's the full platform picture.

Where everything actually lived

Frontend → Vercel, account disabled for non-payment (recoverable). Apex ordex.io (76.76.21.21), plus www, staging-beta, beta-release (all on Vercel IPs 66.33.60.x) every one returns 402 DEPLOYMENT_DISABLED, server: Vercel, region fra1 (Frankfurt). The whole Vercel account/team is paused, not deleted. Guessing the .vercel.app won't help debug it — it'll just return the same 402 until the operator settles the bill. (Good news: we don't need it live — I already have the frontend bundles from Wayback and can reconstruct the client logic fully.)

API → behind Cloudflare, origin server is powered off (the bad news). prod-api / api-next / eths-api / api.ordex.io all sit on the same Cloudflare IPs and return 522 — Cloudflare is up, but the origin it proxies to doesn't answer at the TCP level. That rules out:

• a CF Worker (would return a 1101 worker error, never 522),
• a Vercel origin (a disabled Vercel deployment answers 402, which CF would pass through — and Vercel disowns these SNIs anyway),
• the live OVH box (15.204.196.123, which hosts ipfs-gateway and answers 404 for the API hosts).

So the API was a self-hosted origin server — almost certainly OVH, since they demonstrably run OVH infra and the stack is the heavy NFTmall/Rarible-Union JVM service (that's what the /v0.1/... Union paths are). That box has been shut down. This is the important distinction from the frontend: the API isn't dormant-and-un-pausable in someone's account — the compute is gone. Bringing it back would require the operator's server image and its database, not just a payment.

Two incidental finds worth noting: the real API base default is prod-api.ordex.io (from NEXT_PUBLIC_API_ORD), and Ordex is a white-label fork of "NFTmall" (Cloudinary nftmall assets, ThunderCore strings baked in) — which pins the exact codebase if we ever want to read the signer logic from the NFTmall/Rarible source.

The one thing I couldn't get (and how to)

The historical origin IP behind Cloudflare — the actual server the dead API pointed at. That's the classic "find origin behind CF" problem, and the free CT/DNS tools don't expose it: crt.sh only yields hostnames (and was flaky), certspotter gave the subdomain list but no IPs, and pre-Cloudflare A-record history needs a paid source. If you have (or want to grab) a Censys, SecurityTrails, or Shodan API key, I can pin the origin IP and its provider in a single query — a Censys cert search for ordex.io on non-Cloudflare IPs is the highest-yield move, and given the OVH lead it'd likely either locate the box or confirm it's decommissioned.

Net for the rescue

This actually reinforces the earlier verdict rather than opening a new door: the frontend is revivable but useless for signing; the signer API's server is gone, not merely un-paid; and there's no dormant serverless deployment to resurrect. So the rescue still routes through the admin key 0x92545Caf — nothing here changes that, but we've now conclusively closed the "maybe the signer is still hosted somewhere" thread.

Where your machine scan still genuinely helps: even without response headers, your Jan-2025 script + any cached JSON gives the exact request/response shapes and auth flow for /checkout and /signer/s/*. That's what we'd need to replicate the signer ourselves if INDEXER_ROLE ever gets granted to a fresh key — so it's worth digging up regardless.

Want me to (a) reconstruct the frontend/signer client flow from the Wayback bundles I already have, or (b) stand ready to run the Censys/SecurityTrails origin lookup if you can get a key?