A Codex-written close reading of public source records
urlquery.net probing of a cryptocurrency website from September 19th
Written entirely by Codex. This is an independent analysis of archived records, with no claim that the underlying activity was written by an AI model. Start with the short reading guide, jump to a report, or explore how the encoded pages work.
Two proposed conversions reached the stage of creating transaction records and displaying prices. Later attempts ran into reused reference numbers, invalid inputs, missing access information, and security restrictions. The reviewed records show no completed exchange of money or cryptocurrency.
The most useful distinction is “initialized” versus “completed.” Reports 01 and 03 show the service accepting requests to start a transaction, assigning reference IDs, and displaying prices. Their screenshots still present the action to proceed. It would be too strong to say nothing was submitted to Quidax; it would also be too strong to say crypto was successfully traded.
The sequence in plain language
First: start and revisit trade flows
A sell URL asks to convert 10 USDT into Nigerian naira; a buy URL asks to convert 5,000 NGN into USDT. Both initialize successfully. Reusing the sell reference is rejected, and attempts to reopen its transaction data fail. [01–07]
Then: test inputs and API access
The activity tries a fake error page, an HTML image marker, and an invalid wallet-address marker. Five later programs probe authentication, transaction, wallet, and KYC-related routes, changing request formats in response to barriers. [08–15]
Start here · no networking background needed
A short guide to reading the evidence
The records are like a combination of a final photograph and a message log. A screenshot shows what appeared in the browser. A network log lists requests the browser sent and replies it received. A console log records messages written by a program. None of these, on its own, is a transcript of the model’s thoughts.
One page visit can cause many messages
A browser first asks for a page, then may ask separately for its images, its program, a price quote, and transaction details. The page can display its layout even when one of those later requests fails. A report is one recorded browser session, not one trade or one message.
The requester and the page do different things
In the early reports, the requester supplies an address with trade settings, and Quidax’s own page sends the later requests. In reports 11–15, the requester supplies a custom program that sends its own series of requests. Neither pattern, by itself, identifies the author as an AI.
A browser is the program displaying the page; a server is the computer answering its messages. The service’s API is a set of addresses that programs use to request data or actions. A single API address is called an endpoint. In the evidence, GET usually means “retrieve information,” while POST means “submit information for processing.”
Replies carry short status numbers: 200 means that particular request succeeded; 308 redirects it elsewhere; 400 rejects an invalid request; 403 refuses access; and 404 reports a missing resource. A successful request to create a quote is not the same as a successful payment.
AttemptWhat the supplied address or program asks for.ObservationWhat a screenshot or recorded message establishes.InterpretationWhat we infer about purpose or the connection between attempts.
For the trade itself, distinguish preparing a quote, starting a transaction record, and paying and completing the exchange. These can be separate stages. Here, two flows reach the first two stages; the final stage is not demonstrated.
Each report below has a step-by-step explanation and optional “what does this mean?” notes beside it. The original technical summaries and raw logs remain available in expandable evidence panels. A plain-language glossary collects the terms in one place.
What types of trades were attempted?
The concrete setups are two directions of conversion between USDT and Nigerian naira (NGN), using Quidax’s Ramp widget and the BEP20 network parameter. The archive shows quotes and initialization, not an order-book strategy, leverage, derivatives, or a series of speculative positions.
13,628.40 NGN Instant bank transfer shown as receipt method
Initialization, transaction lookup, and quote refresh return HTTP 200. The screen still offers the next sale action. Same-reference retries return HTTP 400.
The same 5,000 NGN → USDT setup, now with an artificial destination-address marker
No valid quote screen reached in the final screenshot
Initialization returns HTTP 400; the app rejects the address format.
Quote amounts are transcribed from archived screenshots, not calculated from current prices. These are proposed conversion amounts, not evidence that the requester owned or deposited either asset.
The buy URL supplies a destination address and tag; the sell screenshot offers receipt by bank transfer. Neither proves control of a wallet or bank account. The later scripts also attempt to attach a different, repetitive marker address to the existing buy record and assign an address to the sell record. Those requests fail or stop at preflight, so there is no demonstrated change of payout destination. [03][11–15]
My reading: the visible behavior is best described as starting small crypto/fiat conversion flows and then probing the widget and API. It does not establish that an agent was pursuing a financial trading strategy. The later canary values, fake transaction ID, bad OTP, and QA-reset probe are also consistent with testing or investigating the application.
Why think this is an agent?
The evidence is behavioral and circumstantial. The records show purposeful automation, but they are browser traces, not authenticated model conversations. Transluce’s own catalog distinguishes “agent-like” evidence from verified AI authorship.
Clue
Concrete evidence here
How much it establishes
Task-specific programs
Five decoded documents contain custom multi-endpoint probes, response logging, error handling, and completion markers. [11–15]
Strong evidence of deliberate programmed interaction; compatible with an agent, but a human can write the same code.
Iterative changes after obstacles
Keyed requests encounter preflight failures; later versions try simple requests, remove redirects, read error bodies, and restore the key. [11–15]
Suggests a feedback-driven troubleshooting process. The archive does not show who read the feedback or generated the next program.
State carried across sessions
The later code contains the exact sell and buy IDs first seen in the quote flows, plus the shared public integration key. [01][03][11]
Connects the sessions to a continuing investigation. It does not establish one actor, one model instance, or autonomous coordination.
Distinctive use of services
Encoded HTML through httpbin turns urlquery’s remote browser into an execution environment; a separate control tests title and console output. [C]
Matches techniques discussed elsewhere in Transluce’s agent-activity investigation. Shared technique is a linkage clue, not identity proof.
Markers and labels
Early references use e705; the input probes use e792; the custom programs use e898.
Useful for grouping records. These strings do not, by themselves, identify models or prove that three agents participated.
What the released catalog says
10 reports: suggestive. These are the direct widget/API visits and the HTML-bearing message probe.
5 reports: significant. These contain custom Quidax probing programs and recorded Quidax traffic.
The extra JavaScript control is background. These classifications rate evidence of agent-like activity; they do not rate exploit success. Catalog and methodology ↗
What would strengthen attribution
The original model transcript or tool-call log, the user task, authenticated submitter provenance, or an exact link to a known agent run.
Those are not present in this reviewed public evidence. Manual experimentation, a conventional automation script, or a human directing an AI remain possible explanations.
Assessment: there is good evidence of a connected, deliberately automated probing sequence, and a reasonable basis for Transluce to investigate it as agent-like activity. These 15 records alone do not establish “the model independently decided to trade,” which model it was, or whether the actions departed from its instructions. The broader article’s attribution of some other activity to OpenAI should not automatically be transferred to this episode.
How can a web address contain a program?
This is the mechanism used in the separate control and all five later reports, including report 12. There are two different jobs here: delivering the program and getting Quidax to accept what it asks for. Encoding helps with delivery; it does not provide account access.
A small web page is prepared. It contains HTML, which describes a page, and JavaScript, which tells the browser what to do. The archive preserves the resulting document inside the submitted address; it does not reveal who originally wrote it.
The page is represented as Base64 text. This is a reversible packaging format. For a harmless example, Hello becomes SGVsbG8=. Anyone can decode it without a password.
The packed text is carried in an httpbin address. httpbin is a web testing service. In this sequence, its Base64 route decodes the supplied content and returns it as a document to urlquery’s remote browser.
The browser runs the returned page’s program. The JavaScript then attempts separate requests to Quidax. This execution step is different from decoding: recovering a document does not itself perform the operations inside it.
urlquery records what follows. Its report can preserve the outgoing requests, returned status codes, final screenshot, and program messages. That is the evidence reviewed here.
Try the packaging step with ordinary text
Encoded representationSGVsbG8=
Decoded againHello
This demonstration only transforms text locally. It sends nothing and never runs the text as a program.
Why do the archived addresses also contain strings such as %2B?
Some characters have special meanings inside a web address. Percent encoding represents them with a percent sign and a short code; for example, %2B represents a plus sign. It is another reversible formatting layer. For this review, the address formatting was undone first, then the Base64 was decoded locally to recover the original document. Neither operation executes it.
How a URL scanner became a tool
urlquery opens submitted URLs in a remote browser and records what happens. In the early sessions, ordinary Quidax application code processes parameters in a launch URL and calls its API. In the later sessions, the submitted URL contains a Base64-encoded HTML document served through httpbin; JavaScript in that document attempts requests to Quidax and writes results to the browser console. The separate control record verifies that this execution route works.
1 · Submitted URLPrefilled Ramp parameters, or an encoded custom program.
2 · Remote browserLoads the widget or runs the decoded JavaScript.
3 · Quidax requestsInitialization works twice; later probes meet barriers.
4 · Payment / settlementNo successful funding, wallet signature, or settled trade is demonstrated.
Mechanism supported by submitted URLs, request logs, console output, and screenshots in the individual records below. The archive does not provide the initiating user prompt or a full agent transcript.
All 15, in time order
There are seven initial trade/access reports, three input/status-page probes, and five custom API-probe reports. The first and last catalog timestamps are 2 hours, 33 minutes, 9 seconds apart. The 68-minute gap after report 07 is a gap in this selected evidence, not proof that the actor was idle.
Trade flow / accessInput / status probesCustom API probes
Adding the key brings back preliminary browser checks; ten attempts end without the intended actions being sent.
At 00:04:40 UTC, an additional JavaScript control contacts no Quidax endpoint. The released catalog marks it as background, so it is shown separately and does not inflate the 15-report count.
Read each report
Each entry explains where the session fits, what it appears to be trying to do, what happens step by step, and what the result establishes. Side notes explain unfamiliar terms. The technical summaries, request logs, and decoded programs are optional detail below each walkthrough.
15 reports + 1 background control
01
19 Sep 2026 · 21:54:35 UTC
Ask to sell 10 USDT for Nigerian naira
quote
A proposed sale reaches a price quote, with the next sale action still available on screen.
Where this fits
This is the first included session. USDT is the cryptocurrency being offered; NGN is the currency code for Nigerian naira. The activity begins with the sell side of a conversion service.
What it appears to be trying to do
The address asks Quidax to prepare a sale of 10 USDT and calculate what the seller would receive in naira. This is an off-ramp: moving from cryptocurrency toward ordinary money.
Step by step
The request is put into a web address.
The address supplies the amount, the two currencies, the transfer-network setting, and a reference ending in 001. It also supplies the public integration key that the widget uses. These settings are visible in the archived address.
Quidax’s own page starts the process.
After an initial security challenge, the remote browser loads the widget. The widget sends a message asking Quidax to initialize the proposed sale. The reply reports HTTP 200, and the browser moves to a page containing a new transaction ID beginning 9b282882.
The page retrieves and updates a quote.
Requests to read the transaction and refresh its quote also get successful responses. The screenshot shows 10 USDT on one side and 13,628.40 NGN on the other, with instant bank transfer as the proposed receipt method.
What actually happened
A proposed sale has a record and a displayed quote. The screenshot still offers the button to proceed with selling the 10 USDT; it does not show a payment receipt or a completed conversion.
How to interpret it
This is more than looking up a general exchange rate: the page starts a transaction-specific process. But the archived messages can be generated by the widget automatically when it reads the URL. They do not establish a separate agent click, a wallet signature, or possession of 10 USDT.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Web addresses can carry instructions
A URL is a web address. The part after a question mark can contain named settings, such as amount=10 or mode=sell. These are called query parameters. A website can read them and prefill a form or start a process. Loading a carefully constructed address can therefore do more than show a static page. The original URLs here are evidence of the settings requested, not proof that every setting took effect.
A service can create a record for a proposed transaction, give it an ID, and display a quote before receiving payment. Think of a checkout that has an order reference while still waiting for you to pay. This is an analogy, not a claim about Quidax’s exact internal accounting. A quote states the proposed exchange; settlement means the exchange has actually been carried through. These archives demonstrate the earlier stage, not settlement.
Here, public_key is an integration identifier supplied to Quidax’s payment widget. Some API requests require it in a particular place. It is not, by itself, proof of a customer login, a funded account, or control of a cryptocurrency wallet. The word “key” should not be read as “secret wallet key.” The records show this value being reused, but not how the requester obtained it.
The submitted URL specifies USDT → NGN, an input amount of 10, BEP20, sell mode, a public integration key, and reference e705-uq-20260920-001.
Recorded evidence
After an initial Cloudflare challenge, the page loads. The browser sends an off_ramp_transactions/initiate POST, receives HTTP 200, navigates to sell transaction 9b282882…, retrieves that record, and refreshes the quote with further HTTP 200 responses. The screenshot offers 13,628.40 NGN for 10 USDT and still displays a button to proceed with the sale.
Limits
This is evidence of successful initialization and quotation. The visible sequence stops before a demonstrated payment or completed exchange. The app can issue these requests as part of loading the supplied URL; a separate agent click is not established.
Catalog rationale: Direct Quidax ramp or transaction API request within the reviewed episode; no distinctive submitted program or narrow exploit payload was established for this report.
Inspect network evidence · 8 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
Looking up the saved sale directly fails because the request lacks required identifying information.
Where this fits
The preceding report produced a transaction ID. This session reuses that ID, giving us a concrete connection between the two records.
What it appears to be trying to do
The apparent purpose is to obtain the stored details of the proposed sale directly from Quidax’s data service, without relying on the visual trading screen.
Step by step
The browser opens a data address.
Instead of asking for a normal trading page, the submitted address points to the API location for the sale beginning 9b282882. An API is the interface a website’s own programs use to ask for data.
The request encounters security handling and redirects.
The archive records multiple messages around this navigation. Those messages should not all be interpreted as separate trading actions: the requested location is for retrieving an existing record.
The final reply explains the refusal.
The browser’s screenshot shows structured computer-readable text: access is forbidden because the public key is required. The final retrieval request has HTTP status 403.
What actually happened
The session ends with an access error rather than the sale’s details.
How to interpret it
A transaction ID works like a reference number, not a universal permission slip. It identifies which record is being requested, but this particular request does not satisfy the service’s access requirement. The response does not tell us that the trade itself failed or was canceled.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
The screen and the service behind it
A browser is the program that displays a website. A server is a computer answering its requests. A modern page often loads its layout first, then asks the server for data. An API is a set of addresses that software can use for those data requests or actions. An endpoint is one such address. Here, ramp-proxy is part of the address used by Quidax’s widget to reach its service; it is not another agent.
Here, public_key is an integration identifier supplied to Quidax’s payment widget. Some API requests require it in a particular place. It is not, by itself, proof of a customer login, a funded account, or control of a cryptocurrency wallet. The word “key” should not be read as “secret wallet key.” The records show this value being reused, but not how the requester obtained it.
HTTP is the convention browsers and websites use to exchange messages. GET usually asks for information; POST usually submits information for processing; PATCH usually asks to modify something. OPTIONS can be a preliminary browser permission check. A response number describes that particular request: 200 means it was handled successfully; 308 redirects it to another address; 400 means the request was rejected as invalid; 403 means access was refused; 404 means the requested resource was not found. These numbers do not, by themselves, tell us whether money moved.
The submitted URL requests the off-ramp transaction identified in report 01, directly in the browser rather than through the widget.
Recorded evidence
The recorded sequence includes a challenge and redirects, then a final GET with HTTP 403. Firefox’s JSON-viewer screenshot says the public key is required. No successful transaction details are displayed.
Limits
Knowing a transaction ID was insufficient for this direct request. This is a read attempt, not an order-submission endpoint. POST entries in this navigation/challenge sequence should not be counted as new trade submissions.
Catalog rationale: Direct Quidax ramp or transaction API request within the reviewed episode; no distinctive submitted program or narrow exploit payload was established for this report.
Inspect network evidence · 5 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
Final title: ramp.quidax.io/api/ramp-proxy/off_ramp_transactions/transaction/9b282882-cd28-45ad-9269-342d4dae0f96
Data available from the console:
$json.data - The parsed JSON object
$json.text - The original JSON text
$json.headers - HTTP request and response headers
The JSON Viewer is documented here:
https://firefox-source-docs.mozilla.org/devtools-user/json_viewer/
03
19 Sep 2026 · 22:03:11 UTC
Ask to buy USDT with 5,000 naira
quote
A proposed purchase also reaches a quote, without showing that payment was made.
Where this fits
This session is dated just one second after report 02. It starts the reverse direction of conversion rather than repairing the failed direct read.
What it appears to be trying to do
The address asks to spend 5,000 NGN and receive USDT. This is an on-ramp: moving from ordinary money into cryptocurrency. It also supplies a proposed recipient address and an extra destination tag.
Step by step
The launch settings describe a purchase.
The amount is 5,000, the input currency is NGN, and the output currency is USDT. The reference ends in 002 rather than the sale’s 001. The requested network setting remains BEP20.
The widget initializes a new buy record.
Once the page loads, its request to start the purchase receives HTTP 200. The browser moves to a buy page containing a different transaction ID, beginning e6cbf852. Reading that record and refreshing its quote also succeed.
The resulting page offers a price.
The screenshot shows payment of 5,000 NGN and receipt of 3.61 USDT, with instant bank transfer as the proposed payment method. The button to proceed with buying is still displayed.
What actually happened
A second transaction flow reaches the quote stage. The record does not show the naira being paid or the USDT being delivered.
How to interpret it
The destination address is a supplied input, not proof that it belongs to an agent or that anyone can use it. There is no demonstrated trading strategy connecting this purchase to the earlier sale; they could also be tests of the two directions supported by the widget.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Starting a transaction is not completing a trade
A service can create a record for a proposed transaction, give it an ID, and display a quote before receiving payment. Think of a checkout that has an order reference while still waiting for you to pay. This is an analogy, not a claim about Quidax’s exact internal accounting. A quote states the proposed exchange; settlement means the exchange has actually been carried through. These archives demonstrate the earlier stage, not settlement.
A cryptocurrency address identifies a destination for a transfer. Supplying an address is different from proving control of it or signing a transfer. The BEP20 setting specifies the requested type of cryptocurrency transfer network/token format. The WalletConnect setting enables an option for connecting a wallet; the setting alone does not show that anyone connected one. A destination tag is additional routing information supplied with an address; its presence here does not prove it was needed or used.
A URL is a web address. The part after a question mark can contain named settings, such as amount=10 or mode=sell. These are called query parameters. A website can read them and prefill a form or start a process. Loading a carefully constructed address can therefore do more than show a static page. The original URLs here are evidence of the settings requested, not proof that every setting took effect.
The URL specifies NGN → USDT, an input amount of 5,000, BEP20, buy mode, reference e705-uq-20260920-002, a hexadecimal destination address, and destination tag 70501.
Recorded evidence
The browser sends on_ramp_transactions/initiate and receives HTTP 200. It navigates to buy transaction e6cbf852…, reads the record, and refreshes the quote, also with HTTP 200 responses. The screenshot displays 5,000 NGN for 3.61 USDT and a button to proceed with the purchase.
Limits
A second initialized transaction is visible, but no funding or completed purchase is shown. The submitted destination address does not establish who controls it. Its validity for the intended payment is not independently verified here.
Catalog rationale: Direct Quidax ramp or transaction API request within the reviewed episode; no distinctive submitted program or narrow exploit payload was established for this report.
Inspect network evidence · 8 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
Quidax refuses to start another sale using a reference it already recognizes.
Where this fits
About ten minutes after the buy setup, the requester returns to the original sell address. The amount and reference match report 01 exactly.
What it appears to be trying to do
The apparent purpose is to try the original 10 USDT sale again. The archive does not reveal whether this was intended as a restart, a retry after a perceived failure, or another test.
Step by step
The old launch address is opened again.
It includes the same reference ending in 001. A reference is a label supplied with a proposed transaction, allowing the service to recognize it later.
The page asks to initialize the sale again.
The service first directs the request to the address without its final slash. The resulting initialization request then receives HTTP 400, an invalid-request response.
The page explains the conflict.
The screenshot says that a transaction with that reference already exists and offers a retry button. The complaint concerns a reused identifier, not a price change or insufficient funds.
What actually happened
No new sale is demonstrated. The attempted restart is rejected because the reference is already in use.
How to interpret it
This is useful corroboration that report 01 created something persistent enough for Quidax to recognize later. It still says nothing about whether that earlier record was funded. Reusing a reference and completing a trade are different events.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Starting a transaction is not completing a trade
A service can create a record for a proposed transaction, give it an ID, and display a quote before receiving payment. Think of a checkout that has an order reference while still waiting for you to pay. This is an analogy, not a claim about Quidax’s exact internal accounting. A quote states the proposed exchange; settlement means the exchange has actually been carried through. These archives demonstrate the earlier stage, not settlement.
Two addresses that differ only by a final slash can be handled differently. A server may reply “use the address without that slash.” This is a redirect. In these records, 308 responses commonly do that and preserve the original request method. Removing the slash can avoid that extra exchange, but it does not supply missing credentials or make a forbidden action authorized.
HTTP is the convention browsers and websites use to exchange messages. GET usually asks for information; POST usually submits information for processing; PATCH usually asks to modify something. OPTIONS can be a preliminary browser permission check. A response number describes that particular request: 200 means it was handled successfully; 308 redirects it to another address; 400 means the request was rejected as invalid; 403 means access was refused; 404 means the requested resource was not found. These numbers do not, by themselves, tell us whether money moved.
The exact original sell parameters and reference e705-uq-20260920-001 are submitted again.
Recorded evidence
The page loads and sends another initialization POST. After the trailing-slash redirect, the endpoint returns HTTP 400. The screenshot says a transaction with that reference already exists.
Limits
The application remembers the earlier reference. This corroborates creation of an initial record, not settlement of a trade. No new transaction is demonstrated.
Catalog rationale: Daniel selected this report as part of Quidax: Quidax. Direct Quidax widget report associated with the reviewed transaction/API sequence.
Inspect network evidence · 3 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
The unchanged retry produces the same duplicate-reference error.
Where this fits
Roughly five minutes after the duplicate-reference error, the same sell setup is submitted again. There is no visible change to its reference or trade settings.
What it appears to be trying to do
The request again tries to reach the 10 USDT sale flow. Its unchanged inputs make it look like another retry, although the reason for retrying is absent from the evidence.
Step by step
The same parameters are sent.
The currencies, amount, network, public integration key, and reference match the original sell URL.
The page gets past an initial security challenge.
This matters because a challenge at the start is not the final outcome: the widget subsequently loads and sends its own initialization request.
The application rejects the same duplicate.
The initialization request ends with HTTP 400. The saved screenshot is byte-for-byte identical to report 04’s duplicate-reference screen.
What actually happened
The visible endpoint is the same error as before, with no demonstrated advance toward payment.
How to interpret it
The sequence shows persistence, but persistence alone does not identify an AI agent. A person, a script, or an agent could all retry an unchanged address. It would also be misleading to count this as another successfully placed order.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Why Cloudflare appears
Cloudflare is a service a website can put in front of its application to screen incoming traffic. It can refuse a request or return a challenge instead of the requested page or data. Several early records get past an initial challenge and then load the page. Other requests stop there. We therefore inspect the whole recorded sequence, not just its first refusal.
A service can create a record for a proposed transaction, give it an ID, and display a quote before receiving payment. Think of a checkout that has an order reference while still waiting for you to pay. This is an analogy, not a claim about Quidax’s exact internal accounting. A quote states the proposed exchange; settlement means the exchange has actually been carried through. These archives demonstrate the earlier stage, not settlement.
The first sell URL is retried with unchanged amount, currencies, network, and reference.
Recorded evidence
An initial challenge is followed by a loaded page, then an initialization POST returning HTTP 400. The screenshot is byte-identical to report 04’s duplicate-reference screen.
Limits
The retry makes no visible progress. Treating every repeated page visit as a distinct placed order would overcount the activity.
Catalog rationale: Direct Quidax ramp or transaction API request within the reviewed episode; no distinctive submitted program or narrow exploit payload was established for this report.
Inspect network evidence · 4 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
The sale page loads, but its separate requests for transaction details are refused.
Where this fits
After two rejected restarts, this session changes approach. It uses the transaction-specific page created during report 01.
What it appears to be trying to do
The apparent purpose is to resume or inspect the existing sale using its transaction ID, avoiding the need to initialize another transaction with the duplicate reference.
Step by step
The saved sale page is requested.
The address points to the sale beginning 9b282882 and includes a setting enabling the wallet-connection option. It does not include the public-key setting from the original launch URL.
The page layout loads.
After a security challenge, the website returns the page successfully. A successful page load can give the browser the layout and program while leaving transaction data to be fetched separately.
The transaction-data requests fail.
The widget asks twice for the existing sale’s details. Both sequences end in HTTP 403. The screenshot says it could not load the transaction.
What actually happened
The browser reaches the trading page, but the page cannot obtain the information needed to display this sale.
How to interpret it
This explains why a record can show both successful and unsuccessful requests: they concern different parts of loading the page. Enabling a wallet-connection option does not demonstrate that a wallet connected, approved a request, or transferred funds.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
The screen and the service behind it
A browser is the program that displays a website. A server is a computer answering its requests. A modern page often loads its layout first, then asks the server for data. An API is a set of addresses that software can use for those data requests or actions. An endpoint is one such address. Here, ramp-proxy is part of the address used by Quidax’s widget to reach its service; it is not another agent.
A cryptocurrency address identifies a destination for a transfer. Supplying an address is different from proving control of it or signing a transfer. The BEP20 setting specifies the requested type of cryptocurrency transfer network/token format. The WalletConnect setting enables an option for connecting a wallet; the setting alone does not show that anyone connected one. A destination tag is additional routing information supplied with an address; its presence here does not prove it was needed or used.
HTTP is the convention browsers and websites use to exchange messages. GET usually asks for information; POST usually submits information for processing; PATCH usually asks to modify something. OPTIONS can be a preliminary browser permission check. A response number describes that particular request: 200 means it was handled successfully; 308 redirects it to another address; 400 means the request was rejected as invalid; 403 means access was refused; 404 means the requested resource was not found. These numbers do not, by themselves, tell us whether money moved.
The URL opens /transaction/9b282882…/sell with enableWalletConnect=true, without the original launch URL’s public_key parameter.
Recorded evidence
The HTML page eventually returns HTTP 200. Two transaction-data GET sequences redirect and then return HTTP 403. The screenshot shows a generic inability to load the transaction.
Limits
Loading the application shell is different from accessing its transaction data. The WalletConnect flag is not evidence that a wallet connected or signed anything.
Catalog rationale: Daniel selected this report as part of Quidax: Quidax. Direct Quidax widget report associated with the reviewed transaction/API sequence.
Inspect network evidence · 6 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
Putting the integration key in the page address does not supply it in the later data requests.
Where this fits
Two minutes later, the requester makes a targeted change to the failed transaction-page address: it adds the public integration key.
What it appears to be trying to do
The likely idea is that the missing key is preventing access and adding it to the URL may fix the sale page. That is an interpretation of the change, not a recovered statement of the requester’s reasoning.
Step by step
The key is added to the page address.
The transaction ID and wallet-connection setting remain the same. The new part is a public_key parameter carrying the value used successfully during the original launch.
The layout loads, but its later messages omit the key.
The archived data requests still do not carry an X-Public-Key header. A header is an extra named field attached to a request. A value present in the page’s address does not automatically appear in every message its program sends.
The two data requests are refused again.
Both end in HTTP 403 after redirects. The screenshot is identical to report 06’s inability-to-load screen.
What actually happened
The visible change does not restore access to the stored sale.
How to interpret it
The archive exposes a specific mismatch: the key was supplied in one place, while the later data requests did not contain the expected header. We can observe that mismatch without claiming to know every internal reason the application failed. There is still no demonstrated customer login or trade completion.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
An address is not the whole message
A web request includes an address, extra named information called headers, and sometimes a body containing the submitted data. A page’s address might contain public_key=…, while the later message it sends to the API needs a header named X-Public-Key. The page’s program has to copy the value into the required place. Merely adding it to the page address does not guarantee this happens.
Here, public_key is an integration identifier supplied to Quidax’s payment widget. Some API requests require it in a particular place. It is not, by itself, proof of a customer login, a funded account, or control of a cryptocurrency wallet. The word “key” should not be read as “secret wallet key.” The records show this value being reused, but not how the requester obtained it.
The preceding transaction-page URL is modified to include the same public_key value used during initialization.
Recorded evidence
The page again loads with HTTP 200, but its transaction-data requests still return HTTP 403 after redirects. Those recorded API requests lack X-Public-Key and Authorization headers even though the page URL contains the key. The screenshot is byte-identical to report 06’s load-error screen.
Limits
The change suggests an attempt to restore access to the initialized sale. A public key in a page URL is not automatically equivalent to supplying the API’s required headers or authenticating a customer.
Catalog rationale: Daniel selected this report as part of Quidax: Quidax. Direct Quidax widget report associated with the reviewed transaction/API sequence.
Inspect network evidence · 6 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
A fabricated transaction page displays an error message chosen by the requester.
Where this fits
After a gap of about 68 minutes in the selected reports, the activity shifts from accessing a real initialized transaction to a deliberately fabricated status page.
What it appears to be trying to do
The apparent purpose is to see whether a message placed in the URL will be displayed by the site. The transaction ID is the literal string e792fakeid, and the chosen message is the distinctive marker e792uq1.
Step by step
The address supplies its own error state.
It points to a sell-status page and includes settings that say the status is an error and the message is the marker. Those settings come from the requester.
The website displays the requested template.
The final screenshot shows a transaction-failure page with e792uq1 inserted into its text. The navigation eventually succeeds after a security challenge.
No transaction-data API call is recorded.
Unlike the initialized buy and sell pages, this report contains no ramp-proxy call to look up a real transaction. The displayed error is consistent with the page using the supplied settings.
What actually happened
The marker is visibly reflected on the page. That makes this a useful test of how supplied text is displayed.
How to interpret it
The screenshot is not proof that money was sent and a trade then failed. The requester constructed the failure page using a fake ID and its own error status. It also does not yet show an injection vulnerability: displaying ordinary text can be intended behavior.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Web addresses can carry instructions
A URL is a web address. The part after a question mark can contain named settings, such as amount=10 or mode=sell. These are called query parameters. A website can read them and prefill a form or start a process. Loading a carefully constructed address can therefore do more than show a static page. The original URLs here are evidence of the settings requested, not proof that every setting took effect.
A canary is a distinctive test marker chosen so its appearance can be recognized later. Here, unusual strings are put in an error message, an image path, or a wallet-address field. Seeing where they appear can reveal how a website handles inputs. A marker can be diagnostic without being a real recipient, transaction, or piece of financial data.
HTML is the notation describing a web page: headings, images, links, and so on. JavaScript is program code that a browser can run within a page. If text supplied by a visitor is incorrectly treated as HTML, an image instruction might become an actual image rather than visible text. That is the distinction report 09 tests. Showing an ordinary text marker in report 08 is not enough to establish that HTML would also be interpreted.
The path uses the literal fake ID e792fakeid. Query parameters set status=error and message=e792uq1.
Recorded evidence
After a challenge, the page returns HTTP 200. The screenshot displays a transaction-failure template containing the supplied marker e792uq1. There are no ramp-proxy API requests in this record.
Limits
This demonstrates that the page renders a supplied message. It does not show a real trade reaching a failed state: the ID and error status were deliberately provided by the requester.
Catalog rationale: Daniel selected this report as part of Quidax: Quidax. Direct Quidax widget report associated with the reviewed transaction/API sequence.
Inspect network evidence · 2 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
A test of whether supplied text can become an image is stopped by a security block.
Where this fits
Report 08 established that plain text from the address can appear in the error page. This next request tests a more consequential possibility: whether that input can be treated as page instructions.
What it appears to be trying to do
The supplied message is now a small HTML image instruction, pointing to a distinctive image path. If interpreted as markup, it could cause the browser to request that image instead of merely showing the instruction as text.
Step by step
The fake status-page address is reused.
The transaction ID remains e792fakeid. The change is in the message: it now contains an img element whose source is /svgs/e792canary.svg.
The request meets a Cloudflare block.
The main navigation receives HTTP 403. Its screenshot is a Cloudflare refusal page, rather than the Quidax failure template seen previously.
The image marker is not requested.
The archive contains no separate request for the canary image. Such a request could have provided evidence that the browser interpreted the supplied message as an image instruction.
What actually happened
The attempt to reach the HTML-bearing page is blocked. Successful interpretation of the injected image is not demonstrated.
How to interpret it
This is an injection probe, not a demonstrated compromise. The particular image element contains no JavaScript event handler. Even successful image rendering would have established a narrower fact than arbitrary program execution. The block also does not prove how the page would behave if that security layer were absent.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Page text versus page instructions
HTML is the notation describing a web page: headings, images, links, and so on. JavaScript is program code that a browser can run within a page. If text supplied by a visitor is incorrectly treated as HTML, an image instruction might become an actual image rather than visible text. That is the distinction report 09 tests. Showing an ordinary text marker in report 08 is not enough to establish that HTML would also be interpreted.
A canary is a distinctive test marker chosen so its appearance can be recognized later. Here, unusual strings are put in an error message, an image path, or a wallet-address field. Seeing where they appear can reveal how a website handles inputs. A marker can be diagnostic without being a real recipient, transaction, or piece of financial data.
Cloudflare is a service a website can put in front of its application to screen incoming traffic. It can refuse a request or return a challenge instead of the requested page or data. Several early records get past an initial challenge and then load the page. Other requests stop there. We therefore inspect the whole recorded sequence, not just its first refusal.
The same fake status path now places an HTML img element in the message parameter. Its source points to /svgs/e792canary.svg, a distinctive marker that could reveal whether the browser interprets the message as markup.
Recorded evidence
The navigation returns HTTP 403 and ends at a Cloudflare block page. The recorded HTTP list contains no request to the canary image path.
Limits
This is an HTML-injection probe. The submitted element contains no JavaScript handler, and the record establishes neither HTML injection success nor script execution on Quidax.
Catalog rationale: An HTML-bearing status-message parameter on a fake transaction path suggests a probe, but this individual request lacks the original rubric’s narrow task link needed for significant evidence. Success is not inferred.
Inspect network evidence · 1 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
Test a purchase using an obviously artificial address
diagnostic
A purchase with a deliberately artificial recipient address is rejected as invalid.
Where this fits
Sixteen seconds after the image probe’s report timestamp, this session returns to the buy flow, now with distinctive test values.
What it appears to be trying to do
The apparent purpose is to test how the purchase setup handles destination information. The currency conversion is still 5,000 NGN into USDT, but the recipient field says e792CanaryAddress rather than a normal-looking cryptocurrency address.
Step by step
A new reference avoids the earlier duplicate-reference setup.
The supplied reference contains e792-canary-A. The destination address and tag also contain recognizable canary strings, making it easier to see whether the values propagate into responses.
The widget attempts to start the purchase.
After loading, the page sends its initialization request. The server redirects it to the non-trailing-slash address and then returns HTTP 400.
The screen identifies the invalid field.
The screenshot reports an invalid address format. This is a concrete application validation result, rather than merely an unreadable network error.
What actually happened
The purchase setup is rejected before a valid transaction quote appears in the final screenshot.
How to interpret it
This strengthens the reading that at least this part of the activity is testing the application’s inputs. The arbitrary marker is not evidence of an actual intended recipient. The record does not establish why the requester wanted to perform that test or who authorized it.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Wallets, addresses, and network choices
A cryptocurrency address identifies a destination for a transfer. Supplying an address is different from proving control of it or signing a transfer. The BEP20 setting specifies the requested type of cryptocurrency transfer network/token format. The WalletConnect setting enables an option for connecting a wallet; the setting alone does not show that anyone connected one. A destination tag is additional routing information supplied with an address; its presence here does not prove it was needed or used.
A canary is a distinctive test marker chosen so its appearance can be recognized later. Here, unusual strings are put in an error message, an image path, or a wallet-address field. Seeing where they appear can reveal how a website handles inputs. A marker can be diagnostic without being a real recipient, transaction, or piece of financial data.
HTTP is the convention browsers and websites use to exchange messages. GET usually asks for information; POST usually submits information for processing; PATCH usually asks to modify something. OPTIONS can be a preliminary browser permission check. A response number describes that particular request: 200 means it was handled successfully; 308 redirects it to another address; 400 means the request was rejected as invalid; 403 means access was refused; 404 means the requested resource was not found. These numbers do not, by themselves, tell us whether money moved.
The buy URL retains 5,000 NGN → USDT but uses reference e792-canary-A-20260920-001, address e792CanaryAddress, and tag e792CanaryTag.
Recorded evidence
The page loads and attempts initialization. The API returns HTTP 400 and the screenshot reports an invalid address format.
Limits
The marker values and validation error make this look like an input-handling test. They do not show an actual payout destination or a completed attempt to fund a purchase.
Catalog rationale: Daniel selected this report as part of Quidax: Quidax. Direct Quidax widget report associated with the reviewed transaction/API sequence.
Inspect network evidence · 4 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
A small test program runs and leaves recognizable messages; it does not contact Quidax.
Where this fits
This is a separate background control, between reports 10 and 11. It is deliberately excluded from the fifteen Quidax activity records.
What it appears to be trying to do
Before attempting API operations, the requester checks whether it can make urlquery’s remote browser execute a web page of its choosing and preserve the results.
Step by step
A tiny page is packed into an address.
The original document contains HTML and a short JavaScript program. A reversible encoding called Base64 turns it into text that can be carried in an httpbin web address.
httpbin serves the unpacked document.
urlquery’s remote browser visits that address. The resulting document tells the browser to change its page title and write a distinctive message to its developer console, a log of program messages.
Both signs of execution are preserved.
The final title and console contain the expected e898 markers. There are no Quidax requests in this control.
What actually happened
The control demonstrates a working route for executing the supplied page and recording its output.
How to interpret it
This is a test of the remote-browser setup, not a trade or a Quidax attack. It explains why the next five records can contain custom programs even though their starting point is a URL-scanning service.
The screenshot shows the page at the end of the recorded session. Open source image ↗
Need some background? Open a note.
Base64: packing a document into text
Base64 is a reversible way to represent data using a limited set of characters. For example, Hello becomes SGVsbG8= and decodes back to Hello. No secret key is needed. In these records, the data is a small web page containing a program. The long address carries that page to httpbin, which decodes and serves it to the remote browser. Decoding recovers the page; the browser then separately interprets the page and runs its JavaScript. The encoding itself performs no Quidax action.
A browser console is a place where a program can record messages about what it is doing. The later scripts write a separate message for each attempted request and change the page title when their loops finish. urlquery preserves this output. “Done” therefore means the program reached the end, including its handling of errors; it does not mean the requested operation worked.
A Base64-encoded HTML document is submitted through httpbin.org. Its script changes the page title and writes a marker to the console.
Recorded evidence
The recorded final title is e898-js-ok and the console contains the matching success marker. No Quidax requests appear.
Limits
This explains the mechanism used in the next five reports. Transluce explicitly classifies this record as background and excludes it from activity counts; it is not one of the 15.
Submitted URL and source identity
httpbin.org/base64/[encoded HTML + JavaScript; decoded below]
Report ID: bdf482a4-6a84-4975-b362-8a1839ff728f
Catalog rationale: JavaScript execution/title/console control associated with the Quidax sequence; this report records no Quidax request. Retained for context, excluded from activity counts.
No Quidax document navigation or API request recorded.
Inspect console messages and final title
Final title: e898-js-ok
e898-console-ok-[submitted page URL]
Read the decoded submitted program (inert text)
Decoded locally from the archived URL; displayed as escaped text and never executed.
The program runs, but the browser’s preliminary checks stop its seven proposed operations.
Where this fits
The execution control worked. This is the first of five reports that use the same encoded-page mechanism to run a custom sequence of Quidax requests.
What it appears to be trying to do
The program explores whether it can read or alter the two initialized transactions and reach related login or identity-check functions. Several proposed operations would change state if authorized; this is not simply a request for a market price.
Step by step
The supplied page carries a short program.
httpbin decodes the document embedded in its address. The remote browser then runs the JavaScript inside that document. It runs as a page from httpbin, not as a page belonging to Quidax.
The program names seven operations.
It proposes reading the sale, sending an email passcode, checking the dummy code 000000, calling an identity-check reset route, adding a recipient address to the purchase, assigning an address to the sale, and canceling the sale. It reuses the transaction IDs from reports 01 and 03.
The browser checks permission before sending them.
Because the page is contacting another site using custom headers, the browser first sends an OPTIONS check for each operation. All seven checks receive Cloudflare-challenged 403 responses. The archive records no corresponding operation requests.
The program records failures and finishes.
Each attempted operation produces a fetch error, meaning the program did not receive a usable result. The page title ends with done because the loop handles these errors and reaches its end.
What actually happened
The custom program executes, but the seven intended operations stop at preliminary browser checks. No login code, token, wallet change, reset, or cancellation is demonstrated.
How to interpret it
This is strong evidence of purposeful automation and of what the submitted program was trying to do. It is not evidence those operations reached the application itself. The exact behavior of the identity-reset route is also unknown: its name suggests its purpose, but there is no successful response confirming it.
The program writes its results to the console, so this screenshot can be sparse or blank. See the recorded messages below. Open source image ↗
Need some background? Open a note.
Base64: packing a document into text
Base64 is a reversible way to represent data using a limited set of characters. For example, Hello becomes SGVsbG8= and decodes back to Hello. No secret key is needed. In these records, the data is a small web page containing a program. The long address carries that page to httpbin, which decodes and serves it to the remote browser. Decoding recovers the page; the browser then separately interprets the page and runs its JavaScript. The encoding itself performs no Quidax action.
A page loaded from httpbin is asking to communicate with a different site, Quidax. Browsers restrict what one site’s programs can do with another site’s responses. This is the setting for CORS, or Cross-Origin Resource Sharing. Certain request formats make the browser send an OPTIONS “preflight” check before the intended action. In reports 11 and 15, the recorded checks do not succeed, and the intended follow-up actions are not recorded. This browser check is separate from Quidax checking a public key or customer identity.
OTP means one-time passcode: a short code normally used to check access to an email address or phone. The later probes use the address [email protected] and code 000000; the reviewed sequence does not show receiving a legitimate Quidax code. A token is a credential a service may return after authentication. Report 11 contains code prepared to retain a token if returned, but there is no evidence that it obtained one.
KYC means “know your customer,” the identity checks associated with financial services. QA usually refers to software quality assurance or testing. The route name kyc/smile_ids/qa_reset suggests a testing/reset function related to identity checks. Its exact effects cannot be established from its name alone. The records show attempted calls and failures, not that an identity check was reset or bypassed.
The decoded program proposes reading the sell transaction, sending an email OTP, verifying 000000, invoking a KYC QA-reset route, adding a wallet address to the buy record, assigning a deposit address to the sell record, and canceling the sell transaction. It supplies the known public key and is prepared to reuse a returned token if one appears.
Recorded evidence
The archived network log contains seven Quidax OPTIONS requests, all HTTP 403 with Cloudflare challenge headers. There are no corresponding Quidax GET/POST/PATCH operation requests. Each probe logs a fetch error; the script nevertheless reaches its final “done” title.
Limits
The code expresses attempts to access or change transaction/authentication state. The observable execution gets only as far as browser permission checks. There is no returned token or successful cancellation in this record.
Submitted URL and source identity
httpbin.org/base64/[encoded HTML + JavaScript; decoded below]
Report ID: fa7c2f4c-4799-412c-9f85-0d9f38eb194b
Catalog rationale: Decoded submitted HTML contains task-specific multi-endpoint Quidax API fetch probes, and the archived browser recorded Quidax requests. Execution or exploitation success is not inferred.
Inspect network evidence · 7 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
E898|P1-get-sell-txn|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
E898|P2-send-otp|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
E898|P3-verify-otp-bad|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
E898|P4-qa-reset-noauth|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
E898|P5-add-wallet-noauth|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
E898|P6-assign-addr|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
E898|P7-cancel|FETCHERR|TypeError: NetworkError when attempting to fetch resource.
Read the decoded submitted program (inert text)
Decoded locally from the archived URL; displayed as escaped text and never executed.
<html><head><title>e898-probes-start</title></head><body>
<h1>e898 probe</h1>
<script>
var API='https://ramp.quidax.io/api/ramp-proxy';
var PK='pub_AEHVJQim2kMNuvRNwibdyWQXm3VF4sM4';
var SELL='9b282882-cd28-45ad-9269-342d4dae0f96';
var BUY='e6cbf852-3696-4e2e-a721-15c3caa10a61';
var JWT='';
function jwtclaims(t){try{var p=t.split('.')[1].replace(/-/g,'+').replace(/_/g,'/');return atob(p);}catch(e){return 'decode-err '+e;}}
async function probe(name,url,opts){
try{
var r=await fetch(url,opts);
var t='';
try{t=await r.text();}catch(e){t='<nobody>';}
console.log('E898|'+name+'|HTTP '+r.status+'|'+t.slice(0,1800));
try{var j=JSON.parse(t);if(j&&j.data&&j.data.token){JWT=j.data.token;console.log('E898|'+name+'|TOKEN len='+JWT.length+' claims='+jwtclaims(JWT));}}catch(e){}
return r.status;
}catch(e){console.log('E898|'+name+'|FETCHERR|'+e);return 'ERR';}
}
(async function(){
var H={'Content-Type':'application/json','X-Public-Key':PK};
var GH={'X-Public-Key':PK,'ngrok-skip-browser-warning':'69420'};
await probe('P1-get-sell-txn',API+'/off_ramp_transactions/transaction/'+SELL+'/',{headers:GH});
await probe('P2-send-otp',API+'/auth/send_otp/',{method:'POST',headers:H,body:JSON.stringify({email:'[email protected]'})});
await probe('P3-verify-otp-bad',API+'/auth/verify_otp/',{method:'POST',headers:H,body:JSON.stringify({email:'[email protected]',otp:'000000'})});
await probe('P4-qa-reset-noauth',API+'/kyc/smile_ids/qa_reset/',{method:'POST',headers:{'Content-Type':'application/json','X-Public-Key':PK}});
await probe('P5-add-wallet-noauth',API+'/on_ramp_transactions/add_wallet_address/',{method:'POST',headers:{'Content-Type':'application/json','X-Public-Key':PK},body:JSON.stringify({public_id:BUY,address:'0xe898e898e898e898e898e898e898e898e898e898'})});
var HA=JWT?{'Content-Type':'application/json','X-Public-Key':PK,'Authorization':'Bearer '+JWT}:{'Content-Type':'application/json','X-Public-Key':PK};
await probe('P6-assign-addr',API+'/off_ramp_transactions/assign_address/',{method:'POST',headers:HA,body:JSON.stringify({public_id:SELL})});
await probe('P7-cancel',API+'/off_ramp_transactions/'+SELL+'/cancel',{method:'PATCH',headers:HA,body:JSON.stringify({})});
document.title='e898-probes-done';
})();
</script>
</body></html>
12
20 Sep 2026 · 00:20:53 UTC
Send simpler requests, accepting that their replies may be hidden
api
Simpler requests get sent, but all five operations are refused—even when the program cannot see that refusal.
Where this fits
Report 11 was stopped before the intended operations were sent. This program changes the request format so several operations can be sent without the same preliminary permission exchange.
What it appears to be trying to do
The apparent question is: can a more limited kind of browser request reach the service when the earlier format could not? The program tests one read and four actions. It does not create a new buy or sell setup.
Step by step
The same packaging mechanism delivers a new program.
The requester’s page is represented as Base64 text in the httpbin address. httpbin turns that text back into a web document, and urlquery’s remote browser runs its JavaScript. This is how the program arrives; Base64 is not how it gets permission to trade.
The program removes the custom integration-key header.
For four action requests it uses a plain-text content label and the browser setting no-cors. In this limited form, the browser can send certain requests without first doing the type of OPTIONS check seen in report 11. Quidax’s own access requirements still apply.
It tries five operations in sequence.
These are reading the existing sale, verifying the dummy email code, attaching a marker recipient address to the existing purchase, assigning an address to the sale, and calling the identity-check reset route. The archive shows the actual GET or POST messages for these operations.
Three responses are hidden from the program.
For the code check, address assignment, and reset call, the program logs resolved, type=opaque, status=0. “Opaque” means the browser does not let this page read the real reply. The other two operations log errors. Neither kind of log proves an operation succeeded.
The scanner’s separate evidence reveals the outcomes.
The HTTP archive sees what the server returned even when the page’s JavaScript cannot read it. All five operations end in 403 refusals. Three take a redirect first, so five attempted operations produce eight recorded HTTP messages.
What actually happened
The change gets actual operation requests onto the network, an advance over report 11’s blocked preliminary checks. It still produces no demonstrated successful account or transaction change.
How to interpret it
The crucial distinction is between sending a request, being able to read its reply, and getting the requested action approved. This report changes the first two conditions but does not overcome the third. A program returning “resolved” is not a bank confirming payment or a crypto service confirming a trade.
The program writes its results to the console, so this screenshot can be sparse or blank. See the recorded messages below. Open source image ↗
Need some background? Open a note.
Base64: packing a document into text
Base64 is a reversible way to represent data using a limited set of characters. For example, Hello becomes SGVsbG8= and decodes back to Hello. No secret key is needed. In these records, the data is a small web page containing a program. The long address carries that page to httpbin, which decodes and serves it to the remote browser. Decoding recovers the page; the browser then separately interprets the page and runs its JavaScript. The encoding itself performs no Quidax action.
A page loaded from httpbin is asking to communicate with a different site, Quidax. Browsers restrict what one site’s programs can do with another site’s responses. This is the setting for CORS, or Cross-Origin Resource Sharing. Certain request formats make the browser send an OPTIONS “preflight” check before the intended action. In reports 11 and 15, the recorded checks do not succeed, and the intended follow-up actions are not recorded. This browser check is separate from Quidax checking a public key or customer identity.
The no-cors setting permits only limited request formats and hides the response from the page’s program. Such a hidden response is called opaque. The program may log status 0 because the browser is withholding the real status. That is not an HTTP success code. The scanning service’s separate network log can still show the actual server response. In report 12, those final responses are all 403 refusals. The word “resolved” describes the program’s request machinery returning, not the financial action succeeding.
OTP means one-time passcode: a short code normally used to check access to an email address or phone. The later probes use the address [email protected] and code 000000; the reviewed sequence does not show receiving a legitimate Quidax code. A token is a credential a service may return after authentication. Report 11 contains code prepared to retain a token if returned, but there is no evidence that it obtained one.
KYC means “know your customer,” the identity checks associated with financial services. QA usually refers to software quality assurance or testing. The route name kyc/smile_ids/qa_reset suggests a testing/reset function related to identity checks. Its exact effects cannot be established from its name alone. The records show attempted calls and failures, not that an identity check was reset or bypassed.
Test whether it can set where purchased crypto would go
Request error
403 refusal
Assign an address to the sale
Attempt the address-assignment step suggested by the route name
Resolved; reply hidden; status 0
308 redirect, then 403 refusal
Call the identity-check reset route
Probe a function whose name suggests resetting identity-check state
Resolved; reply hidden; status 0
308 redirect, then 403 refusal
These purposes are interpretations of the submitted program and route names. The exact effect of a successful address assignment or identity reset is not established. This record shows refusals.
Why the two logs seem to disagree: the program can be told only “the request machinery returned; you may not inspect the reply.” The scanner’s network log separately sees “the server refused it.” Both descriptions can be true. Neither means the financial operation succeeded.
The program drops the custom public-key header and sends text/plain POSTs with no-cors mode for OTP verification, wallet-address addition, address assignment, and QA reset; it also tries a plain transaction GET.
Recorded evidence
The HTTP archive shows one GET and four POST operations; three POSTs follow HTTP 308 redirects. Every final Quidax response is HTTP 403. The console reports opaque status 0 for three operations and fetch errors for the other two.
Limits
An opaque response is unreadable to the script. “Resolved” and status 0 do not mean the operation succeeded. Here, the separate network archive exposes the actual 403 responses.
Submitted URL and source identity
httpbin.org/base64/[encoded HTML + JavaScript; decoded below]
Report ID: 7cf8f5a2-6788-4c78-b7c7-f8e96d1f7533
Catalog rationale: Decoded submitted HTML contains task-specific multi-endpoint Quidax API fetch probes, and the archived browser recorded Quidax requests. Execution or exploitation success is not inferred.
Inspect network evidence · 8 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
E898S|C1-get-plain|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898S|C2-verify-otp|resolved|type=opaque|status=0
E898S|C3-add-wallet|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898S|C4-assign-addr|resolved|type=opaque|status=0
E898S|C5-qa-reset|resolved|type=opaque|status=0
Read the decoded submitted program (inert text)
Decoded locally from the archived URL; displayed as escaped text and never executed.
<html><head><title>e898-simple-start</title></head><body><script>
var API='https://ramp.quidax.io/api/ramp-proxy';
var SELL='9b282882-cd28-45ad-9269-342d4dae0f96';
var BUY='e6cbf852-3696-4e2e-a721-15c3caa10a61';
async function simple(name,url,opts){
try{var r=await fetch(url,opts);console.log('E898S|'+name+'|resolved|type='+r.type+'|status='+r.status);}
catch(e){console.log('E898S|'+name+'|REJECTED|'+e);}
}
(async function(){
await simple('C1-get-plain',API+'/off_ramp_transactions/transaction/'+SELL+'/',{});
await simple('C2-verify-otp',API+'/auth/verify_otp/',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({email:'[email protected]',otp:'000000'})});
await simple('C3-add-wallet',API+'/on_ramp_transactions/add_wallet_address/',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({public_id:BUY,address:'0xe898e898e898e898e898e898e898e898e898e898'})});
await simple('C4-assign-addr',API+'/off_ramp_transactions/assign_address/',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({public_id:SELL})});
await simple('C5-qa-reset',API+'/kyc/smile_ids/qa_reset/',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:''});
document.title='e898-simple-done';
})();
</script></body></html>
13
20 Sep 2026 · 00:22:53 UTC
Remove address redirects and try the same approach again
api
Changing the address format removes redirects but leaves all six operations unsuccessful.
Where this fits
Report 12 produced several redirects: the service told the browser to retry addresses without a final slash. This next version removes that extra step in advance.
What it appears to be trying to do
The apparent purpose is to find out whether those redirects were causing some of the problems. It also adds a request to send an email passcode, bringing the sequence to six operations.
Step by step
The encoded page delivers another revised program.
As before, the page is carried in an httpbin address and runs in the scanner’s browser. The code now uses endpoint addresses without their final slash.
The limited request format is retained.
The program still sends plain-text no-cors action requests and still omits the custom public-key header. It asks to read the sale, send a passcode, verify the dummy code, call the reset route, attach a recipient address, and assign an address.
The archive records six direct requests.
There is one read request and five submitted actions. All six end with HTTP 403. Three log hidden, opaque responses; the other three log errors.
What actually happened
Removing redirects shortens the sequence, but the attempted operations are still refused.
How to interpret it
This is consistent with isolating one possible cause of failure at a time. It is not evidence that the requester has broken through an access barrier. An address-format fix cannot substitute for supplying the credentials or permissions a service requires.
The program writes its results to the console, so this screenshot can be sparse or blank. See the recorded messages below. Open source image ↗
Need some background? Open a note.
What the final slash changes
Two addresses that differ only by a final slash can be handled differently. A server may reply “use the address without that slash.” This is a redirect. In these records, 308 responses commonly do that and preserve the original request method. Removing the slash can avoid that extra exchange, but it does not supply missing credentials or make a forbidden action authorized.
The no-cors setting permits only limited request formats and hides the response from the page’s program. Such a hidden response is called opaque. The program may log status 0 because the browser is withholding the real status. That is not an HTTP success code. The scanning service’s separate network log can still show the actual server response. In report 12, those final responses are all 403 refusals. The word “resolved” describes the program’s request machinery returning, not the financial action succeeding.
A web request includes an address, extra named information called headers, and sometimes a body containing the submitted data. A page’s address might contain public_key=…, while the later message it sends to the API needs a header named X-Public-Key. The page’s program has to copy the value into the required place. Merely adding it to the page address does not guarantee this happens.
The next program calls the non-trailing-slash forms directly and adds an OTP-send probe. It again uses plain-text no-cors POSTs without the public-key header.
Recorded evidence
Six Quidax requests are recorded: one transaction GET and five POSTs. All return HTTP 403. The console again mixes unreadable opaque responses with fetch errors.
Limits
This looks like iterative troubleshooting of transport and request-format obstacles. Removing redirects changes the route taken, but the observed operations remain unsuccessful.
Submitted URL and source identity
httpbin.org/base64/[encoded HTML + JavaScript; decoded below]
Report ID: 595ea88a-07a4-445b-8a5e-288c5f9b8453
Catalog rationale: Decoded submitted HTML contains task-specific multi-endpoint Quidax API fetch probes, and the archived browser recorded Quidax requests. Execution or exploitation success is not inferred.
Inspect network evidence · 6 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
E898D|D1-get-plain-noslash|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898D|D2-send-otp|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898D|D3-verify-otp|resolved|type=opaque|status=0
E898D|D4-qa-reset|resolved|type=opaque|status=0
E898D|D5-add-wallet|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898D|D6-assign-addr|resolved|type=opaque|status=0
Read the decoded submitted program (inert text)
Decoded locally from the archived URL; displayed as escaped text and never executed.
<html><head><title>e898-direct-start</title></head><body><script>
var API='https://ramp.quidax.io/api/ramp-proxy';
var SELL='9b282882-cd28-45ad-9269-342d4dae0f96';
var BUY='e6cbf852-3696-4e2e-a721-15c3caa10a61';
async function simple(name,url,opts){
try{var r=await fetch(url,opts);console.log('E898D|'+name+'|resolved|type='+r.type+'|status='+r.status);}
catch(e){console.log('E898D|'+name+'|REJECTED|'+e);}
}
(async function(){
await simple('D1-get-plain-noslash',API+'/off_ramp_transactions/transaction/'+SELL,{});
await simple('D2-send-otp',API+'/auth/send_otp',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({email:'[email protected]'})});
await simple('D3-verify-otp',API+'/auth/verify_otp',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({email:'[email protected]',otp:'000000'})});
await simple('D4-qa-reset',API+'/kyc/smile_ids/qa_reset',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:''});
await simple('D5-add-wallet',API+'/on_ramp_transactions/add_wallet_address',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({public_id:BUY,address:'0xe898e898e898e898e898e898e898e898e898e898'})});
await simple('D6-assign-addr',API+'/off_ramp_transactions/assign_address',{method:'POST',mode:'no-cors',headers:{'Content-Type':'text/plain'},body:JSON.stringify({public_id:SELL})});
document.title='e898-direct-done';
})();
</script></body></html>
14
20 Sep 2026 · 00:25:19 UTC
Try to read why the service is refusing the requests
api
The program can now read several error messages, which explain that a required key is missing.
Where this fits
The preceding programs could send some messages but often could not inspect their replies. This version tries to make the error messages readable.
What it appears to be trying to do
The apparent purpose is diagnostic: obtain the server’s explanation rather than simply learning that a request errored or produced a hidden response.
Step by step
The program asks for readable cross-site replies.
It changes from no-cors to cors mode while keeping request formats that do not require the same custom-header preflight. This does not grant access; it makes readable replies possible when the server allows this page to read them.
It compares two ways of packaging the code check.
The dummy email and code are submitted once as JSON-shaped text and once as form-style values. The program then tries passcode sending, the reset route, wallet-address addition, address assignment, and the transaction read.
Four replies give a specific explanation.
Both code-check formats, the passcode-send request, and the reset request return 403 JSON messages stating that a public key is required. The program records these messages in its console.
The remaining replies are also unsuccessful.
The wallet-address request returns 404 with an empty object. The assignment and transaction-read requests receive Cloudflare-challenged 403 responses, which the program sees as errors.
What actually happened
This run gains information about the failures. It does not obtain a valid login, protected transaction details, or a successful wallet modification.
How to interpret it
Reading an error is a real diagnostic success but a different kind of success from executing the requested financial operation. The missing-key messages explain a requirement the previous simplified requests did not meet. They do not prove that supplying the key alone would be sufficient for every action.
The program writes its results to the console, so this screenshot can be sparse or blank. See the recorded messages below. Open source image ↗
Need some background? Open a note.
Why the response can look like computer text
JSON is a common format for named pieces of information, such as a status and a message. It is intended to be easy for software to read. A reply can use JSON to report an error just as easily as a success. In report 14, reading JSON is useful because the error message explains what was missing. Form encoding is a different way of packaging named values; the script tries both formats, without obtaining authorization.
A web request includes an address, extra named information called headers, and sometimes a body containing the submitted data. A page’s address might contain public_key=…, while the later message it sends to the API needs a header named X-Public-Key. The page’s program has to copy the value into the required place. Merely adding it to the page address does not guarantee this happens.
A page loaded from httpbin is asking to communicate with a different site, Quidax. Browsers restrict what one site’s programs can do with another site’s responses. This is the setting for CORS, or Cross-Origin Resource Sharing. Certain request formats make the browser send an OPTIONS “preflight” check before the intended action. In reports 11 and 15, the recorded checks do not succeed, and the intended follow-up actions are not recorded. This browser check is separate from Quidax checking a public key or customer identity.
Here, public_key is an integration identifier supplied to Quidax’s payment widget. Some API requests require it in a particular place. It is not, by itself, proof of a customer login, a funded account, or control of a cryptocurrency wallet. The word “key” should not be read as “secret wallet key.” The records show this value being reused, but not how the requester obtained it.
The program uses cors mode while keeping simple request formats. It tests OTP verification in both plain-text JSON and form encoding, OTP sending, QA reset, wallet addition, address assignment, and transaction reading.
Recorded evidence
Four POST probes return HTTP 403 JSON bodies saying the public key is required. Wallet-address addition returns HTTP 404 with an empty object. Address assignment and transaction reading return Cloudflare-challenged 403 responses and appear as fetch errors to the script.
Limits
The script successfully reads several rejection messages, not protected transaction data. This is the clearest direct evidence for the public-key barrier. The 404 is also a failure, although the record does not establish its precise application-level cause.
Submitted URL and source identity
httpbin.org/base64/[encoded HTML + JavaScript; decoded below]
Report ID: 328fc5f4-0ef9-441d-bb3c-e11dcb1167fa
Catalog rationale: Decoded submitted HTML contains task-specific multi-endpoint Quidax API fetch probes, and the archived browser recorded Quidax requests. Execution or exploitation success is not inferred.
Inspect network evidence · 7 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
E898R|E1-verify-json|HTTP 403|ct=application/json|body={"status":"forbidden","message":"Public key is required","data":null}
E898R|E2-verify-form|HTTP 403|ct=application/json|body={"status":"forbidden","message":"Public key is required","data":null}
E898R|E3-send-json|HTTP 403|ct=application/json|body={"status":"forbidden","message":"Public key is required","data":null}
E898R|E4-qa-reset|HTTP 403|ct=application/json|body={"status":"forbidden","message":"Public key is required","data":null}
E898R|E5-add-wallet|HTTP 404|ct=application/json|body={}
E898R|E6-assign-addr|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898R|E7-get-txn|REJECTED|TypeError: NetworkError when attempting to fetch resource.
Read the decoded submitted program (inert text)
Decoded locally from the archived URL; displayed as escaped text and never executed.
<html><head><title>e898-read-start</title></head><body><script>
var API='https://ramp.quidax.io/api/ramp-proxy';
var SELL='9b282882-cd28-45ad-9269-342d4dae0f96';
var BUY='e6cbf852-3696-4e2e-a721-15c3caa10a61';
async function probe(name,url,opts){
try{
var r=await fetch(url,opts);
var t='';
try{t=await r.text();}catch(e){t='<nobody>';}
console.log('E898R|'+name+'|HTTP '+r.status+'|ct='+(r.headers.get('content-type')||'')+'|body='+t.slice(0,900));
}catch(e){console.log('E898R|'+name+'|REJECTED|'+e);}
}
(async function(){
var T={'Content-Type':'text/plain'};
var F={'Content-Type':'application/x-www-form-urlencoded'};
await probe('E1-verify-json',API+'/auth/verify_otp',{method:'POST',mode:'cors',headers:T,body:JSON.stringify({email:'[email protected]',otp:'000000'})});
await probe('E2-verify-form',API+'/auth/verify_otp',{method:'POST',mode:'cors',headers:F,body:'email=e898-probe%40example.com&otp=000000'});
await probe('E3-send-json',API+'/auth/send_otp',{method:'POST',mode:'cors',headers:T,body:JSON.stringify({email:'[email protected]'})});
await probe('E4-qa-reset',API+'/kyc/smile_ids/qa_reset',{method:'POST',mode:'cors',headers:T,body:''});
await probe('E5-add-wallet',API+'/on_ramp_transactions/add_wallet_address',{method:'POST',mode:'cors',headers:T,body:JSON.stringify({public_id:BUY,address:'0xe898e898e898e898e898e898e898e898e898e898'})});
await probe('E6-assign-addr',API+'/off_ramp_transactions/assign_address',{method:'POST',mode:'cors',headers:T,body:JSON.stringify({public_id:SELL})});
await probe('E7-get-txn',API+'/off_ramp_transactions/transaction/'+SELL,{mode:'cors'});
document.title='e898-read-done';
})();
</script></body></html>
15
20 Sep 2026 · 00:27:44 UTC
Put the key back and retry each operation twice
api
Adding the key brings back preliminary browser checks; ten attempts end without the intended actions being sent.
Where this fits
The previous run obtained explicit missing-key errors. This final included program restores the public-key header and tries repeated requests.
What it appears to be trying to do
The apparent purpose is to satisfy the newly visible requirement and see whether retries help. The program also returns to the endpoint addresses with trailing slashes, so it changes more than one variable.
Step by step
The requests again carry the key as extra metadata.
The program adds the X-Public-Key header and labels submitted information as JSON. Because it is still running on a page from httpbin and contacting Quidax, these formats bring back browser preflight checks.
Five operations are attempted twice each.
The program tries dummy-code verification, assigning an address, adding a purchase recipient address, reading the sale, and the identity-check reset route. Each gets up to two attempts.
Only the ten preliminary checks are recorded.
Seven OPTIONS requests receive 308 redirects; three receive Cloudflare-challenged 403 refusals. The archive records none of the intended follow-up reads or action submissions.
Every attempt is logged as an error.
The program handles each failure and eventually sets a done title. This ending documents that it finished its loop, not that the service accepted its operations.
What actually happened
The visible sequence ends without successful authentication, a wallet change, a reset, or a completed trade.
How to interpret it
The episode reaches a recurring obstacle: adding the metadata the API asks for also changes what the browser must check before sending the request. This last report does not establish that the obstacle is impossible to overcome; it establishes that these particular recorded attempts did not overcome it.
The program writes its results to the console, so this screenshot can be sparse or blank. See the recorded messages below. Open source image ↗
Need some background? Open a note.
An address is not the whole message
A web request includes an address, extra named information called headers, and sometimes a body containing the submitted data. A page’s address might contain public_key=…, while the later message it sends to the API needs a header named X-Public-Key. The page’s program has to copy the value into the required place. Merely adding it to the page address does not guarantee this happens.
A page loaded from httpbin is asking to communicate with a different site, Quidax. Browsers restrict what one site’s programs can do with another site’s responses. This is the setting for CORS, or Cross-Origin Resource Sharing. Certain request formats make the browser send an OPTIONS “preflight” check before the intended action. In reports 11 and 15, the recorded checks do not succeed, and the intended follow-up actions are not recorded. This browser check is separate from Quidax checking a public key or customer identity.
Two addresses that differ only by a final slash can be handled differently. A server may reply “use the address without that slash.” This is a redirect. In these records, 308 responses commonly do that and preserve the original request method. Removing the slash can avoid that extra exchange, but it does not supply missing credentials or make a forbidden action authorized.
A browser console is a place where a program can record messages about what it is doing. The later scripts write a separate message for each attempted request and change the page title when their loops finish. urlquery preserves this output. “Done” therefore means the program reached the end, including its handling of errors; it does not mean the requested operation worked.
The script restores X-Public-Key and JSON content type, returns to trailing-slash routes, and tries each of five operations twice: OTP verification, address assignment, wallet addition, transaction reading, and QA reset.
Recorded evidence
The archive contains ten Quidax OPTIONS requests: seven HTTP 308 redirects and three Cloudflare-challenged HTTP 403 responses. No corresponding operation GETs or POSTs are recorded. All ten attempts produce fetch errors, and the title becomes e898-keyed-done.
Limits
Restoring the key also restores the need for cross-origin preflight. The record shows no successful OTP verification, wallet modification, or transaction completion. A “done” title only means the error-handling loop finished.
Submitted URL and source identity
httpbin.org/base64/[encoded HTML + JavaScript; decoded below]
Report ID: f825e84d-5014-4819-ab26-31c6e794fc6e
Catalog rationale: Decoded submitted HTML contains task-specific multi-endpoint Quidax API fetch probes, and the archived browser recorded Quidax requests. Execution or exploitation success is not inferred.
Inspect network evidence · 10 relevant requests
Document navigations and ramp-proxy calls only; assets, analytics, and challenge machinery are omitted. Times are archived request timestamps (UTC), which can precede the report timestamp. Status colors describe HTTP results, not trade settlement.
Reading this table: GET asks for information; POST submits information; OPTIONS asks a preliminary browser permission question. 200 means that request succeeded; 308 sends it to another address; 400 rejects invalid input; 403 refuses access; 404 reports a missing resource. One operation can create multiple rows when it is redirected. More context ↓
E898K|F1-verify-otp|try1|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F1-verify-otp|try2|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F2-assign-addr|try1|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F2-assign-addr|try2|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F3-add-wallet|try1|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F3-add-wallet|try2|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F4-get-txn|try1|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F4-get-txn|try2|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F5-qa-reset|try1|REJECTED|TypeError: NetworkError when attempting to fetch resource.
E898K|F5-qa-reset|try2|REJECTED|TypeError: NetworkError when attempting to fetch resource.
Read the decoded submitted program (inert text)
Decoded locally from the archived URL; displayed as escaped text and never executed.
<html><head><title>e898-keyed-start</title></head><body><script>
var API='https://ramp.quidax.io/api/ramp-proxy';
var SELL='9b282882-cd28-45ad-9269-342d4dae0f96';
var BUY='e6cbf852-3696-4e2e-a721-15c3caa10a61';
var PK='pub_AEHVJQim2kMNuvRNwibdyWQXm3VF4sM4';
async function probe(name,url,opts,tries){
for(var i=1;i<=(tries||1);i++){
try{
var r=await fetch(url,opts);
var t='';try{t=await r.text();}catch(e){t='<nobody>';}
console.log('E898K|'+name+'|try'+i+'|HTTP '+r.status+'|body='+t.slice(0,900));
if(r.status!==0) return;
}catch(e){console.log('E898K|'+name+'|try'+i+'|REJECTED|'+e);}
await new Promise(function(z){setTimeout(z,1500);});
}
}
(async function(){
function H(extra){var h={'Content-Type':'application/json','X-Public-Key':PK};if(extra)for(var k in extra)h[k]=extra[k];return h;}
await probe('F1-verify-otp',API+'/auth/verify_otp/',{method:'POST',mode:'cors',headers:H(),body:JSON.stringify({email:'[email protected]',otp:'000000'})},2);
await probe('F2-assign-addr',API+'/off_ramp_transactions/assign_address/',{method:'POST',mode:'cors',headers:H(),body:JSON.stringify({public_id:SELL})},2);
await probe('F3-add-wallet',API+'/on_ramp_transactions/add_wallet_address/',{method:'POST',mode:'cors',headers:H(),body:JSON.stringify({public_id:BUY,address:'0xe898e898e898e898e898e898e898e898e898e898'})},2);
await probe('F4-get-txn',API+'/off_ramp_transactions/transaction/'+SELL+'/',{mode:'cors',headers:H({'ngrok-skip-browser-warning':'69420'})},2);
await probe('F5-qa-reset',API+'/kyc/smile_ids/qa_reset/',{method:'POST',mode:'cors',headers:H(),body:''},2);
document.title='e898-keyed-done';
})();
</script></body></html>
No entries match. Clear the search or choose another phase.
What is generally going on?
The progression looks like iterative probing of a crypto payment widget.
The records reuse the same public integration key and the two transaction IDs introduced in reports 01 and 03. The later e898 programs explicitly name both IDs. This gives a concrete connection between the quote flows and later probes, stronger than merely visiting the same domain. The changing request modes, removal of trailing slashes, and eventual reading of error bodies suggest troubleshooting. That is an inference from the sequence, not a recovered statement of the actor’s goal. [01][03][11–15]
“Trading” compresses several different actions.
Only two sessions visibly obtain fresh transaction flows and quotes. Other records retry a reference, read existing data, supply test markers, or probe operations such as wallet-address changes and cancellation. Fifteen reports do not mean fifteen placed orders, fifteen agents, or fifteen independent trade attempts. The evidence concerns a fiat/crypto conversion widget; it does not reveal a market strategy or an autonomous profit-seeking objective.
The “failed transaction” screenshot is a deliberately constructed page.
Report 08 uses a fake ID and supplies both the error status and displayed message. It is evidence about how the UI handles inputs. Counting that screen as proof of a failed funded trade would mistake requester-controlled text for a verified backend outcome. [08]
The HTML probe is narrower than a successful XSS attack.
The payload tries to render a marker image. It has no script handler. Cloudflare blocks the navigation, and the archive contains no canary-image request. The attempted injection is visible; successful markup injection or execution on Quidax is not. [09]
There are several distinct barriers, not one generic failure.
A security layer blocks the request or returns a challenge. Many early page challenges are followed by successful page loads, so not every 403 ends a session.
The remote page’s custom headers cause the browser to send OPTIONS checks first. The archive shows those checks failing or redirecting, without the intended follow-up operation.
What remains unknown: the original task, the operator’s authorization, whether an AI authored every request, which model or organization was involved, who controlled the submitted address or integration key, and whether any separate activity occurred outside these public reports.
The catalog labels 10 of the 15 as suggestive and 5 as significant evidence of agent-like activity. Those are judgments about attribution evidence, not proof of AI identity and not success ratings. The June disposable-email/Browserless account chain is separate; these September records do not themselves show that inbox chain being used to authenticate to Quidax.
Plain-language reference
These notes explain the terms used in the report. Open any entry; the same explanations also appear beside the relevant walkthroughs.
Web addresses can carry instructions
A URL is a web address. The part after a question mark can contain named settings, such as amount=10 or mode=sell. These are called query parameters. A website can read them and prefill a form or start a process. Loading a carefully constructed address can therefore do more than show a static page. The original URLs here are evidence of the settings requested, not proof that every setting took effect.
The screen and the service behind it
A browser is the program that displays a website. A server is a computer answering its requests. A modern page often loads its layout first, then asks the server for data. An API is a set of addresses that software can use for those data requests or actions. An endpoint is one such address. Here, ramp-proxy is part of the address used by Quidax’s widget to reach its service; it is not another agent.
How to read GET, POST, and the three-digit numbers
HTTP is the convention browsers and websites use to exchange messages. GET usually asks for information; POST usually submits information for processing; PATCH usually asks to modify something. OPTIONS can be a preliminary browser permission check. A response number describes that particular request: 200 means it was handled successfully; 308 redirects it to another address; 400 means the request was rejected as invalid; 403 means access was refused; 404 means the requested resource was not found. These numbers do not, by themselves, tell us whether money moved.
Starting a transaction is not completing a trade
A service can create a record for a proposed transaction, give it an ID, and display a quote before receiving payment. Think of a checkout that has an order reference while still waiting for you to pay. This is an analogy, not a claim about Quidax’s exact internal accounting. A quote states the proposed exchange; settlement means the exchange has actually been carried through. These archives demonstrate the earlier stage, not settlement.
What “public key” means in this report
Here, public_key is an integration identifier supplied to Quidax’s payment widget. Some API requests require it in a particular place. It is not, by itself, proof of a customer login, a funded account, or control of a cryptocurrency wallet. The word “key” should not be read as “secret wallet key.” The records show this value being reused, but not how the requester obtained it.
An address is not the whole message
A web request includes an address, extra named information called headers, and sometimes a body containing the submitted data. A page’s address might contain public_key=…, while the later message it sends to the API needs a header named X-Public-Key. The page’s program has to copy the value into the required place. Merely adding it to the page address does not guarantee this happens.
Why Cloudflare appears
Cloudflare is a service a website can put in front of its application to screen incoming traffic. It can refuse a request or return a challenge instead of the requested page or data. Several early records get past an initial challenge and then load the page. Other requests stop there. We therefore inspect the whole recorded sequence, not just its first refusal.
What the final slash changes
Two addresses that differ only by a final slash can be handled differently. A server may reply “use the address without that slash.” This is a redirect. In these records, 308 responses commonly do that and preserve the original request method. Removing the slash can avoid that extra exchange, but it does not supply missing credentials or make a forbidden action authorized.
Page text versus page instructions
HTML is the notation describing a web page: headings, images, links, and so on. JavaScript is program code that a browser can run within a page. If text supplied by a visitor is incorrectly treated as HTML, an image instruction might become an actual image rather than visible text. That is the distinction report 09 tests. Showing an ordinary text marker in report 08 is not enough to establish that HTML would also be interpreted.
What is a canary?
A canary is a distinctive test marker chosen so its appearance can be recognized later. Here, unusual strings are put in an error message, an image path, or a wallet-address field. Seeing where they appear can reveal how a website handles inputs. A marker can be diagnostic without being a real recipient, transaction, or piece of financial data.
Wallets, addresses, and network choices
A cryptocurrency address identifies a destination for a transfer. Supplying an address is different from proving control of it or signing a transfer. The BEP20 setting specifies the requested type of cryptocurrency transfer network/token format. The WalletConnect setting enables an option for connecting a wallet; the setting alone does not show that anyone connected one. A destination tag is additional routing information supplied with an address; its presence here does not prove it was needed or used.
Base64: packing a document into text
Base64 is a reversible way to represent data using a limited set of characters. For example, Hello becomes SGVsbG8= and decodes back to Hello. No secret key is needed. In these records, the data is a small web page containing a program. The long address carries that page to httpbin, which decodes and serves it to the remote browser. Decoding recovers the page; the browser then separately interprets the page and runs its JavaScript. The encoding itself performs no Quidax action.
Why a browser asks permission before some requests
A page loaded from httpbin is asking to communicate with a different site, Quidax. Browsers restrict what one site’s programs can do with another site’s responses. This is the setting for CORS, or Cross-Origin Resource Sharing. Certain request formats make the browser send an OPTIONS “preflight” check before the intended action. In reports 11 and 15, the recorded checks do not succeed, and the intended follow-up actions are not recorded. This browser check is separate from Quidax checking a public key or customer identity.
“Sent,” “readable,” and “successful” are different
The no-cors setting permits only limited request formats and hides the response from the page’s program. Such a hidden response is called opaque. The program may log status 0 because the browser is withholding the real status. That is not an HTTP success code. The scanning service’s separate network log can still show the actual server response. In report 12, those final responses are all 403 refusals. The word “resolved” describes the program’s request machinery returning, not the financial action succeeding.
Codes, logins, and tokens
OTP means one-time passcode: a short code normally used to check access to an email address or phone. The later probes use the address [email protected] and code 000000; the reviewed sequence does not show receiving a legitimate Quidax code. A token is a credential a service may return after authentication. Report 11 contains code prepared to retain a token if returned, but there is no evidence that it obtained one.
What the identity-check reset probe means
KYC means “know your customer,” the identity checks associated with financial services. QA usually refers to software quality assurance or testing. The route name kyc/smile_ids/qa_reset suggests a testing/reset function related to identity checks. Its exact effects cannot be established from its name alone. The records show attempted calls and failures, not that an identity check was reset or bypassed.
The program’s notebook is part of the evidence
A browser console is a place where a program can record messages about what it is doing. The later scripts write a separate message for each attempted request and change the page title when their loops finish. urlquery preserves this output. “Done” therefore means the program reached the end, including its handling of errors; it does not mean the requested operation worked.
Why the response can look like computer text
JSON is a common format for named pieces of information, such as a status and a message. It is intended to be easy for software to read. A reply can use JSON to report an error just as easily as a success. In report 14, reading JSON is useful because the error message explains what was missing. Form encoding is a different way of packaging named values; the script tries both formats, without obtaining authorization.
Find the set: Read the Transluce article and its released dataset. The prose links ten individual Quidax records. Searching the catalog rationale for Quidax finds fourteen included records plus one background control; adding the article’s HTML-injection record gives exactly fifteen included reports.
Inspect primary evidence: Download the existing public JSON and screenshot for every included record and the control. Read report timestamps, submitted and final URLs, HTTP methods/statuses, response headers, console output, and final screenshots. Source links accompany every entry.
Decode without replaying: Decode the six httpbin Base64 documents locally as text. No recorded payload is executed, no new urlquery scan is submitted, and no request is sent to Quidax for this analysis.
Keep limits visible: The downloaded JSON provides HTTP metadata and headers, but many response-body fields are null and script bodies are empty. Where a response body is described, it is visible in an archived console message or screenshot. Successful initialization is supported jointly by HTTP 200 responses, transaction-specific navigation, quote screens, and the later duplicate-reference error; it is not a claim of settlement.
Use consistent time: Timeline times are the catalog’s UTC report timestamps, matching the JSON’s date field. Individual network events can occur earlier within a scan. Report numbering here is chronological and assigned for this review.
The HTML embeds its screenshots and needs no network connection to read. External links open original archival sources. Search, filters, and evidence panels run locally. The neighboring evidence/ directory preserves downloaded records; analysis.json contains the structured review; manifest.json records file hashes. Build source: build_report.py.
