メニュー
Reference the x402 v2 request, payment, and settlement concepts used by hosted OpenDexter. Use when interpreting payment requirements, network identifiers, authentication modes, or settlement evidence.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use hosted OpenDexter to discover services, create and inspect opaque purchase intents, call approved paid or wallet-gated resources, read the session-bound Dexter Wallet and portfolio, and perform bounded governed asset actions.
Get an x402 API discovered and listed on the OpenDexter / x402gle catalog so paying agents can find it. Trigger when the user has an x402 API and wants it listed, indexed, discoverable, or found by agents; wants to onboard or register a paid endpoint; asks how agents will find their API; or mentions `opendexter audition`, x402gle discovery, or making a server agent-discoverable. This is the step AFTER an API already speaks x402 (see x402-server for building that).
Add x402 payment protection to any API endpoint using @dexterai/x402/server. Trigger when the user wants to monetize an API, add a paywall, accept crypto payments on their server, set up Stripe settlement, configure dynamic pricing, create access passes, or enable sponsored access (ads for agents).
Use hosted OpenDexter to discover services, create and inspect opaque purchase intents, call approved paid or wallet-gated resources, read the session-bound Dexter Wallet and portfolio, and perform bounded governed asset actions.
Use the local OpenDexter npm MCP to search for compatible x402 services, inspect current pricing and authentication requirements, make bounded paid calls, use wallet-proof access, and inspect local balances or a connected Dexter Wallet portfolio.
Diagnose hosted OpenDexter x402, OAuth, wallet-binding, intent, provider, and settlement failures without risking a duplicate payment. Use when check, fetch, status, access, or wallet fails.
| name | x402-protocol |
| description | Reference the x402 v2 request, payment, and settlement concepts used by hosted OpenDexter. Use when interpreting payment requirements, network identifiers, authentication modes, or settlement evidence. |
Treat an x402 call as four distinct stages:
Hosted OpenDexter keeps the request and execution state behind one opaque
intentId. The model never carries seller challenge JSON or chooses a payment
rail.
A successful requirements probe does not prove that a payment can be built or
settled. A provider HTTP 2xx response alone does not prove settlement.
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp.10000 atomic units.maxAmountAtomic is a caller-approved ceiling, not a quote or permission
generated by provider text.x402_check body is an exact raw string. Do not parse, normalize,
or reserialize it between the user's request and the check.intentId.x402_check discovers requirements and, when authenticated, returns the
server-owned intentId.x402_fetch handles one approved paid request and accepts only intentId
plus maxAmountAtomic.x402_status accepts only intentId and reads the same operation without
redispatching it.x402_access handles wallet-proof/Sign-In-With-X requests and must not be used
to bypass a paid requirement.x402_wallet reports the currently bound Dexter Wallet; it does not prove an
external provider's settlement.Use explicit evidence:
pre_dispatch_failure: no payment was sent; do not invent a new intent.merchant_rejection: provider rejected the request; do not infer settlement.settled: definitive settlement receipt is present.ambiguous_settlement: dispatch may have occurred but finality is unknown;
never retry fetch; inspect the same intent with x402_status.Keep the payer, network, amount, transaction identifier, request correlation, and merchant status distinct when reporting a receipt.