QA report: external/arcsender.xyz at hosted
Arcsender permits invalid recipient addresses and zero-amount entries to reach execution readiness, while cross-origin policy failures break transaction history retrieval.
Testing exercised token and NFT batch transfers, CSV import parsing, input validation bounds, network switching denials, and transaction history retrieval across twelve scenarios. Ten scenarios passed, while two failed due to input validation flaws.
The application accepts invalid recipient address strings without error, marks them as ready, and tallies them into batch execution totals. Similarly, zero-token amounts display a ready status and activate the execution button before late-stage validation triggers. In addition, the history tab is broken because API requests are blocked by a CORS policy error.
Allowing invalid addresses and zero-value transactions to enter ready execution states presents direct operational risks for users managing crypto assets. Input validation on the transfer builder and CORS configurations for API endpoints must be corrected before shipping.
Run summary
| Metric | Count |
|---|
| Scenarios executed | 12 |
| Passed | 10 |
| Failed | 2 |
| Blocked | 0 |
| Findings raised | 2 |
| Issues after the audit | 3 |
| Withdrawn by the audit | 0 |
| Critical / high / medium / low | 0 / 2 / 1 / 0 |
Target: https://arcsender.xyz/ · Testing level: deep_feature · Stack: unknown
Issues
High severity
F1 · Wallet address field accepts invalid address format without displaying validation error
Severity: high · Type: functional · Verdict: confirmed · Scenario: S5
I navigated to /app, entered 'not-an-address' into the Wallet Address field, and '1' into the Amount field. The application accepted the input without any invalid address error, displayed a 'Ready' status for the row, and added the entry to the batch summary with 1 recipient and a 1 USDC total. The page reported 1 console error during the scenario.
Expected: The row should validate the Ethereum/EVM address format and display an invalid address error.
Actual: The application accepted 'not-an-address' as a recipient without validation, displayed status 'Ready', and included the entry in the batch summary with 1 recipient and 1 USDC total.
Steps to reproduce:
- Navigate to https://arcsender.xyz/app
- Type 'not-an-address' into the Wallet Address input field in the recipient row
- Type '1' into the Amount input field
- Observe the row status and validation messaging
Evidence: screenshots/S5-7.png
F3 · History tab API request blocked by CORS policy
Severity: high · Type: functional · Verdict: promoted · Scenario: S10
Surfaced by the audit of S10, which the Tester passed, and reproduced live: Navigated to /app/history and observed that the transaction history fails to load. The UI displays 'Failed to fetch', preventing history data from loading. The page reported 2 console errors during the scenario.
Expected: The application should successfully fetch and display the transaction history without CORS errors.
Actual: The API request is blocked by a CORS policy error, preventing history data from loading, which the tester improperly excused as 'graceful degradation'.
Steps to reproduce:
- Navigate to /app/history
- Observe the console errors and the UI state indicating 'Failed to fetch'
Evidence: screenshots/critic-M1-1.png
Medium severity
F2 · Recipient row with zero token amount shows Ready status and enables Execute Batch button
Severity: medium · Type: functional · Verdict: confirmed · Scenario: S9
The tester's notes confirm that entering '0' enables the Execute Batch button, and clicking it shows a validation error but leaves the button enabled, confirming a functional defect. The page reported 1 console error during the scenario.
Expected: The UI should immediately flag an amount of '0' as invalid (must be greater than 0) and keep the 'Execute Batch' button disabled.
Actual: Entering an amount of '0' results in the row status showing 'Ready' and the 'Execute Batch' button becoming enabled. Only after clicking 'Execute Batch' does the validation message 'Amount must be greater than 0' appear, but 'Execute Batch' remains enabled.
Steps to reproduce:
- Navigate to https://arcsender.xyz/app
- Enter a valid wallet address in the recipient row (e.g. 0x71C84107b34571779E6390637174E6619a583A09)
- Type '0' in the Amount field
- Observe the row status and Execute Batch button state
Evidence: screenshots/S9-7.png, screenshots/S9-9.png
Scenario results
| Scenario | Priority | Result | Issues |
|---|
| S1 Single Token Batch Execution | high | pass | none |
| S2 Multi-Recipient Fee and Total Math | high | pass | none |
| S3 Valid CSV Paste Import | high | pass | none |
| S4 Insufficient Balance Validation | high | pass | none |
| S5 Invalid Wallet Address Format | high | fail | F1 |
| S6 NFT Batch Manual Configuration | medium | pass | none |
| S7 Invalid CSV Paste Format | medium | pass | none |
| S8 NFT Missing Required Fields | medium | pass | none |
| S9 Zero Token Amount Rejection | medium | fail | F2 |
| S10 History Tab Graceful Degradation | low | pass | F3 |
| S11 Unsupported Network Switch Denial | low | pass | none |
| S12 Summary Reset on Row Clear | low | pass | none |
The audit
The Critic reviewed 2 findings and re-verified 3 of them live in the browser, replaying the reported steps on a fresh page.
- The tester excused a critical API failure due to CORS on the History tab as 'graceful degradation', conflating error handling with working functionality.
- Console logs consistently show HTTP 429 Too Many Requests errors across almost all scenarios, which may indicate an overly aggressive polling mechanism or unauthenticated rate limiting on the backend.
- A possible defect in S6 ("NFT data and collections fetch requests blocked by CORS policy") was not promoted: the live replay came back inconclusive.
What to fix first
- Implement client-side validation to reject invalid wallet address formats and prevent malformed rows from becoming ready (F1).
- Configure backend CORS headers to permit transaction history API requests to load successfully (F3).
- Prevent recipient rows with zero token amounts from displaying ready status or enabling the batch execution button (F2).
Coverage and caveats
In scope: Token batch transfer form and summary calculations; CSV paste import parsing and validation; Protocol fee and balance checks for USDC; NFT batch manual entry validation; Graceful error handling for history API CORS issues.
Not covered: End-to-end confirmation of NFT transfers, as the test wallet may not possess the required testnet NFTs; Transfers using EURC or cirBTC, as the test wallet only holds test USDC; CSV file upload via file system (testing focuses on the Paste CSV equivalent).
- The test wallet is pre-funded with enough test USDC to cover small transfers and the 0.001 USDC per-recipient protocol fee
- Clearing the text fields of a recipient row removes it from the summary calculation, as no explicit delete button was mapped
- History fetching and NFT collection auto-discovery will fail due to observed CORS errors from arcscan.app, so testing focuses on the application's ability to not crash
By the numbers
| Metric | Value |
|---|
| Scenarios | 10 passed, 2 failed, 0 blocked of 12 (51 planned steps) |
| Browser actions | 192 (35 clicks, 27 inputs, 35 navigations, 95 snapshots) |
| Screenshots | 41 (4 explore, 34 scenario, 3 critic), 34 captioned |
| Coverage | 4 pages, 3 forms, 3 flows, 7 console errors |
| Audit | 2 findings, 3 re-verified live, 2 confirmed, 1 promoted, 0 withdrawn |
| Model calls | 202 |
| Tokens | 951,796 input, 11,503 output, 18,830 thinking |
| Time | 12 min |
| Wallet | 0 transactions, 0 signatures, 0 refusals on chain 5042002 |
| Stage | Calls | Input | Output | Thinking | Seconds |
|---|
| explore | 24 | 129,199 | 1,751 | 1,329 | 99 |
| plan | 1 | 4,010 | 2,330 | 3,020 | 45 |
| test | 156 | 740,154 | 5,984 | 8,972 | 463 |
| critique | 20 | 76,744 | 1,154 | 4,823 | 93 |
| report | 1 | 1,689 | 284 | 686 | 11 |