Skip to content

[Extension]: Add pay-x402 v1.1.0 (update to existing catalog entry) #4446

Description

@shawn93676

Extension ID

pay-x402

Extension Name

AgentPay x402 — Spend Controls for Spec Kit Agents

Version

1.1.0

Description

Set USDC spending caps, check a counterparty's credit before paying it, and pay x402-enabled APIs during spec implementation. Settles on Base or Solana.

Author

AgentPay Team

Repository URL

https://github.com/shawnhvac/spec-kit-pay-x402

Download URL

https://github.com/shawnhvac/spec-kit-pay-x402/archive/refs/tags/v1.1.0.zip

License

MIT

Homepage

https://x402-agent-pay.com

Documentation URL

https://github.com/shawnhvac/spec-kit-pay-x402#readme

Changelog URL

https://github.com/shawnhvac/spec-kit-pay-x402/blob/main/CHANGELOG.md

Required Spec Kit Version

=0.1.0

Required Tools

None. The commands are agent prompts; they use plain HTTP and the agent's existing signer.

Number of Commands

3

Number of Hooks

1

Tags

payments, x402, budget, usdc, api, solana

Key Features

  • Spend cap per spec/speckit.pay-x402.budget sets the most an agent may spend on one implementation, enforced before signing rather than reconciled afterwards. Offered automatically via an optional after_plan hook.
  • Counterparty credit check/speckit.pay-x402.trust reads the recipient wallet's credit file from SolvScore before any money moves. Free, no key, accepts Solana or Base addresses. A wallet too new to price returns an explicit refusal with a reason rather than a misleading zero.
  • Payment execution over x402/speckit.pay-x402.pay reads the endpoint's live 402 terms, signs a payment for the chosen rail, retries with the X-Payment header, and confirms a settlement transaction hash came back.
  • Two verified rails — Base (eip155:8453, EIP-3009 transferWithAuthorization) and Solana mainnet (partially-signed TransferChecked with a facilitator fee payer, per the x402 exact scheme for SVM).
  • Terms always come from the endpoint — amount, recipient and facilitator are read from each live 402, so stale documentation in the extension cannot cause a wrong payment.

Testing Checklist

  • Extension installs successfully via download URL
  • All commands execute without errors
  • Documentation is complete and accurate
  • No security vulnerabilities identified
  • Tested on at least one real project

Submission Requirements

  • Valid extension.yml manifest included
  • README.md with installation and usage instructions
  • LICENSE file included
  • GitHub release created with version tag
  • All command files exist and are properly formatted
  • Extension ID follows naming conventions (lowercase-with-hyphens)

Testing Details

Tested against Spec Kit v1.0.4 (installed from git+https://github.com/github/spec-kit.git@v1.0.4).

Fresh project created with specify init --here --force --non-interactive --integration copilot --ignore-agent-tools, then installed from the published release archive:

specify extension add pay-x402 --from https://github.com/shawnhvac/spec-kit-pay-x402/archive/refs/tags/v1.1.0.zip

Result:

✓ Extension installed successfully!
AgentPay x402 — Spend Controls for Spec Kit Agents (v1.1.0)
Provided commands:
  • speckit.pay-x402.budget
  • speckit.pay-x402.trust
  • speckit.pay-x402.pay
✓ 3 agent skill(s) auto-registered
Config scaffolded:
  • .specify/extensions/pay-x402/pay-x402-config.yml

specify extension list then reports Commands: 3 | Hooks: 1 | Priority: 10 | Status: Enabled.

Manifest validated against the schema in extensions/EXTENSION-API-REFERENCE.md: schema_version 1.0, all three command names match ^speckit\.[a-z0-9-]+\.[a-z0-9-]+$, every file: path exists in the archive, 6 tags, one after_plan hook.

Every HTTP endpoint named in the command files was checked live before submitting:

Endpoint Result
GET https://x402-agent-pay.com/facilitator/supported 200 — lists base, eip155:8453, Solana mainnet
POST https://x402-agent-pay.com/facilitator/verify 200 — MALFORMED_PAYLOAD on an empty body (route live, not a 404)
GET https://solvscore.com/api/agentworld/slrb/wallet/<addr> 200 — verdict: scored, trust_score: 53
GET https://solvscore.com/api/agentworld/slrb/wallet/rules 200 — published scoring policy

Example Usage

# After /speckit.plan — set the cap (the after_plan hook offers this automatically)
/speckit.pay-x402.budget
> Cap: $5.00 USDC on Base. Facilitator: https://x402-agent-pay.com/facilitator

# Before paying a service for the first time — check who is being paid
/speckit.pay-x402.trust
> Firecrawl pays to 0x1f9d…4b2c — SolvScore 53/100
>   (682 days old, 440 transactions, 23 counterparties, 95.7% clean)
>   Proceeding with the $0.20 payment.

# During /speckit.implement — pay and continue
/speckit.pay-x402.pay
> Paid $0.20 USDC to Firecrawl on base. Settlement tx 0x7c632375…
> Remaining cap: $4.80

If SolvScore declines to score the recipient, the trust command says so plainly instead of returning a zero:

> SolvScore declines to score 9xQe…7Vm: under 7 days old with fewer than 25
>   transactions, too new to price. Recommend a minimum first payment or
>   asking for delivery before payment.

Proposed Catalog Entry

"pay-x402": {
  "name": "AgentPay x402 — Spend Controls for Spec Kit Agents",
  "id": "pay-x402",
  "description": "Set USDC spending caps, check a counterparty's credit, and pay x402 APIs during spec implementation. Settles on Base or Solana.",
  "author": "AgentPay Team",
  "version": "1.1.0",
  "download_url": "https://github.com/shawnhvac/spec-kit-pay-x402/archive/refs/tags/v1.1.0.zip",
  "repository": "https://github.com/shawnhvac/spec-kit-pay-x402",
  "homepage": "https://x402-agent-pay.com",
  "documentation": "https://github.com/shawnhvac/spec-kit-pay-x402#readme",
  "changelog": "https://github.com/shawnhvac/spec-kit-pay-x402/blob/main/CHANGELOG.md",
  "license": "MIT",
  "category": "integration",
  "effect": "read-write",
  "requires": {
    "speckit_version": ">=0.1.0"
  },
  "provides": {
    "commands": 3,
    "hooks": 1
  },
  "tags": [
    "payments",
    "x402",
    "budget",
    "usdc",
    "api",
    "solana"
  ],
  "verified": false,
  "downloads": 0,
  "stars": 0,
  "created_at": "2026-08-17T00:00:00Z",
  "updated_at": "2026-09-04T00:00:00Z"
}

Additional Context

This is an update to an existing catalog entry, not a new submission — pay-x402 was added in #4175 (merged 2026-08-17). Filed through this template per the guidance on #3741, where @mnriem noted that extension submissions should use the issue template rather than a direct PR.

Two things in v1.0.0 were wrong, and I would rather disclose them than have them found:

  1. The pay command documented an endpoint that does not behave as described. It told agents to POST https://x402-agent-pay.com/pay with a recipient and amount to receive a payment header back. That URL is itself a paid x402 resource, so an agent following those instructions received a 402 asking it to pay — not a usable payment header. There is no pay-on-behalf API, and there should not be one: in x402 the paying agent signs its own payment. The command now documents that real flow.

  2. It claimed XRPL support the facilitator never had. Removed. Supported rails are now stated as exactly what GET /facilitator/supported returns, and the command instructs agents to check that endpoint themselves before signing rather than trusting the extension's documentation.

The new trust command also follows the facilitator-discovery order in the x402 spec — accepts[0].extra.facilitator, then accepts[0].facilitator, then root — before any fallback, so a buyer is never routed to a default facilitator that cannot settle the payment it was handed.

Note on accounts: I am filing from this account; the extension repository shawnhvac/spec-kit-pay-x402 is under my other GitHub account. Same person, same extension as the existing catalog entry.

Happy to make any changes maintainers would like.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions