QA report: external/nexorafi.app at hosted
Core API publishing and policy configuration workflows are broken by hanging submission states and an empty settings view.
Testing covered 12 scenarios evaluating core API publishing, cryptographic payment receipts, playground simulations, developer dashboard persistence, and form validation rules. Eight scenarios passed, three failed with confirmed issues, and one scenario checking duplicate submission prevention was blocked due to budget exhaustion.
The primary functional breakdowns affect core publisher and consumer lifecycles. Monetized API publishing stalls indefinitely in a disabled state during route submission, and the policy settings view renders blank, preventing users from setting the policies needed to purchase marketplace services. In addition, the publishing form lacks endpoint validation and accepts malformed URLs into the marketplace.
Until the publishing lifecycle handles state transitions cleanly, the policy settings page is restored, and input validation is enforced, users cannot reliably publish services or complete paid API requests.
Run summary
| Metric | Count |
|---|
| Scenarios executed | 12 |
| Passed | 8 |
| Failed | 3 |
| Blocked | 1 |
| Findings raised | 3 |
| Issues after the audit | 3 |
| Withdrawn by the audit | 0 |
| Critical / high / medium / low | 0 / 2 / 1 / 0 |
Target: https://nexorafi.app · Testing level: deep_feature · Stack: unknown
Issues
High severity
F1 · Publish monetized API submission hangs indefinitely on 'Publishing routes…'
Severity: high · Type: functional · Verdict: confirmed · Scenario: S1
Navigated to /marketplace/new, filled in the form inputs as specified, and clicked the 'Publish on 3 networks' button. The UI entered a disabled state displaying 'Publishing routes…' and the message 'Route 1 of 3: confirm the switch to Arc Testnet, then publish the service.' and hung indefinitely without completing the request or showing any other confirmation.
Expected: The service should register successfully and either display a completion confirmation or redirect to the published service / marketplace page.
Actual: The form enters a perpetual disabled state showing 'Publishing routes…' and 'Route 1 of 3: confirm the switch to Arc Testnet, then publish the service.' without finishing or providing fallback feedback.
Steps to reproduce:
- Navigate to https://nexorafi.app/marketplace/new
- Enter 'AI Webhook Validator' into Service name
- Enter 'https://api.example.com/v1/validate' into Endpoint hash / manifest URI
- Enter 'Automated API for validating webhook payloads and signatures.' into Description
- Enter '0.05' into Price per unit in USDC
- Click 'Publish on 3 networks'
Evidence: screenshots/S1-2.png, screenshots/S1-11.png
F2 · /settings/policies renders empty main view preventing required policy configuration for marketplace purchases
Severity: high · Type: functional · Verdict: confirmed · Scenario: S2
I navigated to /marketplace, selected the Website Analyzer API service, and clicked the "Fix" link next to "On-chain policy recorded". The application redirected to /settings/policies, but the page rendered an empty <main> area containing only the generic operator sidebar, completely missing the policy configuration tools.
Expected: The policies settings page should render policy configuration tools to allow users/operators to record or save agent policies on Arc Testnet.
Actual: The /settings/policies page renders an empty <main> area with only the generic operator sidebar and footer, preventing policy configuration and blocking marketplace service purchases.
Steps to reproduce:
- Navigate to https://nexorafi.app/marketplace
- Select an API service (e.g. Website Analyzer)
- Click 'Buy · $0.03' or click the 'Fix' link next to 'On-chain policy recorded'
- Observe the rendered content at https://nexorafi.app/settings/policies
Evidence: screenshots/S2-2.png, screenshots/S2-4.png, screenshots/S2-6.png
Medium severity
F3 · API publishing form accepts malformed endpoint URL without validation
Severity: medium · Type: functional · Verdict: confirmed · Scenario: S6
The evidence confirms the input 'not-a-valid-url' was accepted and published without format validation.
Expected: Form validation should reject the input as an invalid URL format and prevent submission.
Actual: The form accepted 'not-a-valid-url' without any format validation, published the route, and added the service to the marketplace.
Steps to reproduce:
- Navigate to /marketplace/new
- Enter 'Test API' in 'Service name'
- Enter '5' in 'Price per unit in USDC'
- Enter 'not-a-valid-url' in 'Endpoint hash / manifest URI'
- Click 'Publish on 3 networks'
Evidence: screenshots/S6-7.png, screenshots/S6-10.png, screenshots/S6-12.png
Scenario results
| Scenario | Priority | Result | Issues |
|---|
| S1 Publish a new x402 API service successfully | high | fail | F1 |
| S2 Execute a paid API request via x402 | high | fail | F2 |
| S3 View and verify individual cryptographic payment receipt | high | pass | none |
| S4 Validation on missing required fields for Publish API | medium | pass | none |
| S5 Validation on invalid price format for Publish API | medium | pass | none |
| S6 Validation on malformed Endpoint URL | medium | fail | F3 |
| S7 Verify service persistence in Developer Dashboard | medium | pass | none |
| S8 Simulate payment flow in x402 Playground | medium | pass | none |
| S9 Empty state handling on API Developer dashboard | low | pass | none |
| S10 Check Builders directory for publisher updates | low | pass | none |
| S11 Prevent duplicate submission on Publish API form | low | blocked (Tool-call budget was exhausted before executing the double-click submission and verifying whether duplicate services were created in the marketplace.) | none |
| S12 Page load integrity and 429 console error absence | low | pass | none |
The audit
The Critic reviewed 3 findings and re-verified 4 of them live in the browser, replaying the reported steps on a fresh page.
- F1 was withdrawn because the test harness failed to handle the standard Web3 wallet prompt to switch networks.
- S12 claims the absence of 429 errors as a passed validation, but S9 explicitly logged a 429 error on the /developer route.
- Coverage for duplicate submissions was missed entirely because S11 was blocked by tool-call budget exhaustion.
- A possible defect in S9 ("429 Too Many Requests error logged on Developer dashboard") was not promoted: the live replay came back not-reproduced.
- A possible defect in S10 ("404 Not Found error logged on Builders directory") was not promoted: the live replay came back not-reproduced.
What to fix first
- Resolve the route publishing stall so API submissions complete and handle network confirmation states gracefully (F1).
- Fix the /settings/policies view to render policy configuration controls and unblock marketplace purchases (F2).
- Implement URL format validation on the API publishing form to reject malformed endpoints (F3).
Coverage and caveats
In scope: x402 API Marketplace listing and discovery; API publishing form and input validation; Paid API execution via x402 protocol; Cryptographic payment receipt verification; Developer dashboard and metrics.
Not covered: Agent wallets and spending policies (Excluded to focus deeply on Marketplace and x402 monetization); Escrow contracts (Excluded as it belongs to a separate product pillar); Yield Earn strategies (Excluded as it is outside the API marketplace scope); Decentralized token swap (Excluded to maintain focus on the deep feature).
- The test wallet auto-connects to the Arc Testnet and has sufficient USDC balance to execute paid APIs.
- A fresh or scoped test wallet is available to verify the empty state on the Developer dashboard.
- The test environment allows API registration without requiring manual backend approval.
- The APIs listed in the marketplace actually respond to requests during execution tests.
- S11 could not be executed: Tool-call budget was exhausted before executing the double-click submission and verifying whether duplicate services were created in the marketplace..
By the numbers
| Metric | Value |
|---|
| Scenarios | 8 passed, 3 failed, 1 blocked of 12 (43 planned steps) |
| Browser actions | 226 (36 clicks, 22 inputs, 54 navigations, 114 snapshots) |
| Screenshots | 41 (4 explore, 33 scenario, 4 critic), 33 captioned |
| Coverage | 16 pages, 6 forms, 7 flows, 1 console errors |
| Audit | 3 findings, 4 re-verified live, 3 confirmed, 0 promoted, 0 withdrawn |
| Model calls | 207 |
| Tokens | 1,743,443 input, 11,953 output, 19,856 thinking |
| Time | 15 min |
| Wallet | 3 transactions, 1 signatures, 0 refusals on chain 5042002 |
| Stage | Calls | Input | Output | Thinking | Seconds |
|---|
| explore | 24 | 222,026 | 2,901 | 1,287 | 118 |
| plan | 1 | 5,025 | 2,153 | 3,720 | 48 |
| test | 159 | 1,401,849 | 5,388 | 9,013 | 605 |
| critique | 22 | 112,744 | 1,237 | 5,074 | 112 |
| report | 1 | 1,799 | 274 | 762 | 11 |
