ASPForge

I kept seeing the same OKX.AI failure mode: builders ship real agent services, then lose time because the listing draft is not review-ready. A wrong service type, vague service copy, bad endpoint, weak fee logic, or missing proof can block a launch even when the product is valid. ASPForge is the pre-submit review loop I wanted before listing an Agent Service Provider.

ASPForge is not an OKX submission bot, wallet tool, or fake marketplace wrapper. It is a readiness reviewer for OKX.AI Agent Service Providers where the rule is simple: catch the rejection before the reviewer does.

Live app · App docs · Validate draft · Generate launch pack · OKX.AI listing · Repository

The product

ASPForge is a productized review loop for people building OKX.AI Agent Service Providers.

It gives builders four things before they submit:

Product surface	What it does	Why it matters
Readiness scorecard	Reviews identity and service fields against confirmed OKX.AI listing expectations	Catches blockers before the official review
Launch pack generator	Converts OpenAPI 3.x operations into draft OKX.AI services	Turns existing APIs into cleaner ASP candidates
MCP server	Exposes the same review engine to agent clients	Lets coding agents review services while they build
OKX Wallet integration	Connects an injected OKX EVM wallet, requests X Layer, verifies chain 196, and supports local disconnect and reconnect	Prevents Solana or wrong-network sessions from being treated as payment-ready
OKX x402 integration	Protects scorecard and launch-pack routes with X Layer payment challenges shared by the web app and MCP tools	Gives browser users and agents one payment protocol and one protected backend
Optional Groq rewrite layer	Improves weak service copy and X-post positioning	Gives the product a reasoning layer without letting the model decide truth

The hard checks are deterministic. The model-backed layer is optional and advisory.

The problem

OKX.AI Genesis asks builders to ship useful Agent Service Providers, not just demos. To stay eligible, the ASP must be listed and usable on OKX.AI.

That creates a practical problem during a short hackathon window:

Builder action	Risk
Writes a service description	Too vague for a buyer or reviewer
Picks a service mode	A2A vs A2MCP mismatch
Sets a fee	Too high, too low, or poorly justified
Adds an endpoint	Missing, invalid, or not agent-friendly
Wraps an existing API	Unsafe routes or bad tool names leak into the service draft
Submits to OKX.AI	Review time is lost if the draft is rejected

ASPForge turns that review risk into a fast pre-submit check.

How it works

A builder enters either a draft ASP or an OpenAPI spec. ASPForge runs the same core engine behind the web app and MCP server, then returns structured findings and a copyable scorecard.

Operation	Result
Validate identity	Checks name, description, and profile-readiness signals
Validate service	Checks service name, description, type, fee, and endpoint
Generate launch pack	Converts OpenAPI 3.x operations into draft OKX.AI services
Flag risky routes	Marks destructive or admin-looking operations before they become services
Recommend pricing	Gives heuristic fee bands with clear caveats
Recommend mode	Helps choose A2A or A2MCP based on how the service is used
AI rewrite suggestions	Uses Groq to rewrite weak copy without overriding rule findings
Export scorecard	Produces markdown for internal review or an #OKXAI build post

ASPForge is advisory only. It never calls OKX's real onchainos CLI or submits anything on the user's behalf. Paid reviews use user-approved x402 signatures on X Layer, without custody of wallet keys.

Latest integrations

• OKX Wallet EVM discovery: prefers OKX's EVM provider, rejects non-0x accounts, and does not accept a Solana account for an X Layer payment.
• X Layer Mainnet enforcement: requests chain ID 196 (0xc4), adds X Layer when the wallet reports it missing, and verifies eth_chainId before showing a connected state.
• Wallet lifecycle controls: shows connection progress, reports stalled wallet requests, and provides a Disconnect button that clears the local ASPForge session so the user can reconnect cleanly.
• Pre-payment form validation: incomplete scorecard and launch-pack forms are blocked before any wallet request, chain switch, payment signature, or protected API call.
• Paid AI suggestion entitlement: Groq suggestions require a short-lived, input-bound token delivered only with a settled scorecard or launch pack, preventing the public route from becoming an unauthenticated credit drain.
• OKX x402 protected routes: /api/scorecard returns a $0.50 challenge and /api/launchpack returns a $1.00 challenge on eip155:196.
• Shared MCP payment path: score_asp and generate_launch_pack call the same protected HTTPS routes, return the x402 challenge to the agent, and accept a generated PAYMENT-SIGNATURE on retry.
• Server-side settlement boundary: facilitator credentials remain server-only, paid results are withheld unless settlement succeeds, and EIP-3009 authorization nonces prevent a settled payment from being replayed. ASPForge never requests a private key or recovery phrase.

The x402 challenge path, network, amounts, invalid-signature rejection, and MCP challenge propagation are verified. A real wallet-funded settlement is still pending because no test wallet balance was available during final verification.

Try it in 2 minutes

ASPForge has two verification paths: a web path for quick review and an MCP path for agent-native usage.

Web path

1. Run the current branch locally or deploy it to an HTTPS environment, then open /validate.
2. Connect an EVM wallet and switch to X Layer.
3. Paste a draft ASP identity and service.
4. Approve the displayed $0.50 payment and generate the scorecard.
5. Read the field-level findings: pass, warning, or block.
6. Open aspforge.xyz/launchpack and paste an OpenAPI 3.x spec.
7. Approve the displayed $1.00 payment and generate the launch pack.

Expected result: a copyable markdown scorecard that tells the builder what to fix before submitting to OKX.AI.

MCP path

1. Clone and install the repo.
2. Start the MCP server with npm run mcp.
3. Add the server to an MCP-capable client with this command:

node --import tsx src/mcp/server.ts

4. Call score_asp with a draft OKX.AI identity and service.
5. Complete the returned x402 challenge with an Onchain OS or Agentic Wallet flow.
6. Retry with the generated PAYMENT-SIGNATURE value.
7. Call generate_launch_pack the same way for an OpenAPI 3.x spec.

Expected result: an agent client can review ASP submissions without leaving the builder's coding environment.

Proof and verification

Proof	Link or command	Status
OKX.AI marketplace listing	ASPForge agent #4895	Active
Primary domain	www.aspforge.xyz	Live
App documentation	www.aspforge.xyz/docs	Live
Validate flow	www.aspforge.xyz/validate	Live
Launch pack flow	www.aspforge.xyz/launchpack	Live
OKX Wallet and X Layer integration	web/lib/x402-client.ts and web/components/WalletPayment.tsx	Typecheck, lint, build, and mocked connect/disconnect flow passing
Invalid-form payment guard	Scorecard and launch-pack submit flows	Empty required forms trigger browser validation with zero wallet requests
x402 scorecard challenge	POST /api/scorecard	Verified in production on eip155:196 for $0.50
x402 launch-pack challenge	POST /api/launchpack	Verified in production on eip155:196 for $1.00
MCP x402 propagation	score_asp and generate_launch_pack	Both tools verified through the MCP protocol against the production API
Wallet-funded settlement	User-approved facilitator settlement	Pending funded-wallet verification
Unit tests	npm test	90 passing
TypeScript check	npm run typecheck	Passing
Core build	npm run build	Passing
Web build	npm run build --workspace=web	Passing
AI suggestions	Server-side Groq call with fallback when GROQ_API_KEY is missing or unavailable	Live in production
CI	GitHub Actions	Passing
CodeQL	CodeQL workflow	Passing
Secret scan	Full Git history scanned with Gitleaks	No findings
SAST	Semgrep community rules	No application-code findings

Product screenshots

Landing page	Readiness scorecard

OpenAPI launch pack

Demo video

<iframe src="https://platform.twitter.com/embed/index.html?iframe=true&id=2078038556539277428&lang=en&single=false&modules=none" width="560" height="600" frameborder="0" scrolling="no" sandbox="allow-scripts allow-same-origin"></iframe>

Watch the walkthrough on X.

Documentation

Document	Purpose
User Guide	How to use the validator, launch-pack flow, MCP server, and submission checklist.
API and Integration Reference	HTTP routes, MCP tools, trust boundaries, and operational checks.
Architecture	Core validation architecture and transport boundaries.
Deployment	Deployment and production operations notes.

Sponsor integration

OKX.AI Genesis

ASPForge is built around the OKX.AI Genesis requirement that a project must be a real Agent Service Provider listed on OKX.AI Agent Marketplace.

• Listed ASP: ASPForge #4895
• Service: ASP Readiness Review
• Price: 0.5 USDT
• Category fit: Software Utility and Best Product

OKX.AI listing rules

The validator encodes confirmed OKX.AI ASP listing fields:

• identity name
• identity description
• profile picture readiness
• service name
• service description
• service type
• fee
• endpoint

Findings use OKX-style dot notation such as service[0].fee, so a builder can map each issue back to the field they need to fix.

Model Context Protocol

ASPForge ships as an MCP server using the official @modelcontextprotocol/sdk.

Tools:

• score_asp - validate a draft ASP identity and services
• generate_launch_pack - turn an OpenAPI 3.x spec into draft services and score them

This matters because ASP builders often work inside agentic coding tools. ASPForge can review an ASP from the same environment where the builder is creating it. This means ASPForge can work inside Claude Code, Hermes Agent, OpenClaw, and Codex.

Groq reasoning layer

The product has a real model-backed path.

• Deterministic code owns pass, warn, and block findings.
• Groq rewrites copy, explains positioning, and drafts safer submission language.
• If Groq is missing or unavailable, the core validator still works.
• Groq never overrides a scorecard finding.

Proof and attack suite

Case	Outcome	Proof
Missing identity picture	Blocks the draft	test/validate.test.ts
A2MCP service with no fee	Blocks the service	test/validate.test.ts
A2A service with endpoint attached	Blocks the service	test/validate.test.ts
Malformed, credential-bearing, localhost, private IPv4, or private IPv6 endpoint	Blocks the endpoint	test/validate.test.ts
Optional authentication or inherited OpenAPI path parameters	Preserves the document's real semantics	test/launchpack.test.ts
OpenAPI route with destructive method	Adds exclusion warning before draft service creation	test/launchpack.test.ts
Groq key missing	Returns a safe fallback while scorecard still works	local API verification
Groq live in production	Returns AI rewrite suggestions from llama-3.3-70b-versatile	production API verification

What is real

The shipped path is real: the web app is deployed on the custom domain, the OKX.AI listing is active, the MCP server is implemented, product screens exist in the repo, Groq suggestions work in production, and the test/build commands pass locally.

The operational boundaries and current evidence limits are listed explicitly below.

Honest limitations

• ASPForge has not received an independent security audit.
• A passing scorecard does not guarantee that OKX.AI will approve a listing.
• Endpoint reachability is not checked. ASPForge validates endpoint structure, not live availability.
• Pricing recommendations are heuristics, not marketplace data or evidence of buyer demand.
• Generated launch-pack services are drafts. Builders must review fees, permissions, authentication, and route safety.
• ASPForge does not submit listings, call the onchainos CLI, sign transactions, or manage wallets.
• ASPForge does not yet keep a durable paid-response cache. If a client loses the response after settlement, retrying the same authorization is rejected safely rather than returning the previous result automatically.
• The public OKX.AI listing currently has zero sales and zero reviews.

How this differs

Alternative	What it does	Why ASPForge is different
Reading OKX docs manually	Builder checks fields by hand	ASPForge runs executable checks on the actual draft.
Generic launch checklist	Gives broad advice	ASPForge returns field-level findings and fixes.
OpenAPI generator	Converts routes into tools	ASPForge filters risky routes, drafts OKX services, and scores them.
Generic LLM copywriter	Rewrites text without knowing the platform rules	ASPForge combines deterministic OKX checks with optional Groq suggestions.
Wallet automation bot	Tries to act for the user	ASPForge stays advisory and avoids signing risk.
Waiting for OKX review	Finds issues after submission	ASPForge catches issues before review time is burned.

Architecture

flowchart LR
  subgraph Clients
    A[MCP client]
    B[Browser]
  end

  subgraph Transports
    C[MCP server stdio]
    D[Next.js web app]
  end

  E[src/core validation and pricing]
  F[OKX.AI platform rules]
  G[OpenAPI launch-pack parser]
  H[Groq rewrite route]

  A -->|score_asp| C
  A -->|generate_launch_pack| C
  B -->|POST /api/scorecard| D
  B -->|POST /api/launchpack| D
  B -->|POST /api/suggestions| H
  C -->|paid HTTPS request| D
  D --> E
  D --> G
  G --> E
  E --> F
  H --> E

Loading

Trust boundaries:

• src/core is pure validation and pricing logic.
• The public MCP server is a thin client for the hosted paid API.
• The Groq route is server-side only and optional.
• User input is parsed and rendered safely. The web UI must not echo user content through innerHTML.
• x402 settlement is verified server-side. ASPForge never stores wallet private keys or recovery phrases.
• Exact EVM payments use expiring EIP-3009 authorizations. The token contract records each authorization nonce, and the facilitator rejects a nonce that has already been used.
• Payment headers are size-limited and gateway verification is rate-limited before the facilitator call. If settlement starts but its final status cannot be confirmed, ASPForge tells the user not to retry instead of claiming that no payment occurred.
• There is no OKX submission side effect or hidden custody flow.

Run locally

git clone https://github.com/mystiquemide/aspforge.git
cd aspforge
npm ci
npm test
npm run dev --workspace=web

AI reasoning suggestions:

GROQ_API_KEY=your_groq_key npm run dev --workspace=web

MCP server:

npm run mcp

Paid routes require the server-side variables shown in .env.example. The MCP server calls the hosted API and returns the x402 challenge when payment is required.

Production checks:

npm run typecheck
npm run lint --workspace=web
npm run build
npm run build --workspace=web

Tech stack

• TypeScript
• Node.js 20+
• Next.js web workspace
• official @modelcontextprotocol/sdk
• OKX x402 Payment SDK
• viem
• Groq API
• zod
• js-yaml
• Node test runner through tsx
• Vercel deployment

Roadmap

• Add endpoint reachability checks as warning-level evidence.
• Add more sample ASP templates for common categories.
• Add optional local export bundles for teams preparing several services.
• Expand the PlatformRules seam to other agent marketplaces.
• Add privacy-safe KPI logging for scan counts and pass/warn/block trends.

License

All rights reserved. See LICENSE.