Daski Gateway

The Daski gateway is the wallet-agnostic entry point to the Daski marketplace. Every paid outcome uses x402 V2 Exact-EVM with one externally operated standard facilitator. Daski policy, order state, release evidence, provider dispatch, and reputation remain outside the facilitator.

The gateway does not implement a local x402 facilitator and never holds a buyer private key. Fixed outcomes use stock Exact-EVM authorizations. Outcomes with buyer input use the published deterministic nonce recipe while retaining the standard Exact-EVM wire format.

Buying through Daski

Agent documentation and the MCP server live on the website, at https://sandbox.daski.io/skills/setup.md and https://sandbox.daski.io/mcp for Testnet (https://daski.io on mainnet). The website owns the guides and MCP tool definitions. Its tools call this gateway's REST API; payment validation, quotation, settlement, order state, authorization, and dispatch stay here.

The gateway's old guide URLs redirect to the website. Its configured MCP path returns a method-preserving HTTP 307 to the website's /mcp, so existing clients can follow the redirect without rewriting a signed request. The gateway's /.well-known/mcp.json remains the runtime authority for CLI versions, wallet capabilities, and signing metadata, and advertises the website MCP address.

Load the full setup guide through daski_get_setup_guide or a raw fetch. Diagnose the existing signer or set up the default Circle agent wallet, discover contextual intake, obtain the actual quote, and approve it through the gateway-pinned daski buy flow. Once a signer is configured, the steady-state prompt is Use Daski to [your task].

Public surfaces

• POST /outcomes/:providerAgentId/:outcomeId/requirements and MCP daski_get_outcome_requirements return the published schema, conditional intake requirements, normalized selectors, and missing fields for a partial request. This catalog read creates no quote or order.
• /.well-known/mcp.json publishes the buyer CLI pin, the accepted payer account types (payerAccounts: plain wallets always, deployed contract accounts when enabled, never counterfactual ones), the delivery confirmation modes (confirmation: sponsored for EOA payers, direct for contract payers, three attestations per order, revocation always), the signer CLI versions Daski's adapters are tested with (signerClis), and EAS confirmation signing metadata. Authorized order responses include the onchain order key used by the CLI's delivery-review flow, and order status carries the confirmationFinal state read at the configured finality tag.
• POST /outcomes/:providerAgentId/:outcomeId issues a payment requirement and accepts the identical paid retry.
• /orders/:handle/actions/* exposes payer-authorized lifecycle actions.
• /wallet/* exposes wallet-authorized orders, reputation, assets, and asset actions.
• POST /v1/owner-swaps accepts a provider-signed ProviderOwnerSwapV1 notice that an asset's owner changed and grants the new payer eligibility for that provider's owner-only reads and actions; see docs/owner-swaps-v1.md. Off by default.
• /.well-known/x402 and /public/v2/* publish the active signed legacy rail and listing artifacts.
• /.well-known/daski-chain.json publishes metadata envelope v3 with outcomeSchemaVersion: 1. Consumers must ignore additive fields; removals, renamed fields, type changes, and semantic changes require a new schema version. The reputation projection behind it is refreshed in the background (CHAIN_PROJECTION_REFRESH_MS, 60 seconds by default) and after every finalized reputation write, so requests never wait on the chain. Responses carry Cache-Control: public, max-age=30, stale-while-revalidate=300, an ETag, and DASKI-PROJECTION-REFRESHED-AT.
• /public/v3/activity?limit=50 publishes the compact marketplace activity projection from the same warm data: the newest purchases across services with service and skill names, marketplace totals, the safe block, and the contract addresses. limit accepts 1 to 200. New orders preserve checkout service and skill names in their immutable listing snapshot, and activity shows exactly those names, including for superseded listings. A purchase whose local order is missing displays an unknown skill, never another skill from the same service.
• /public/v3/services publishes the service-first dynamic catalog when the registration route group is enabled.
• /public/v2/registry/* exposes read-only ERC-8004 identity, Daski provider and service catalog state.
• POST /outcomes/:providerAgentId/:outcomeId/quote returns the prepared challenge and payer preflight. POST .../purchase accepts { request, payerAddress?, paymentPayload? }, retaining the complete payment in JSON rather than requiring a large HTTP header. Both use the existing checkout service and gateway-bound authorizations.
• POST /public/v2/outcomes/search provides bounded catalog search and vocabulary hints; GET /public/v2/outcomes/:providerAgentId/:outcomeId provides the complete detail with capped recent-purchase history.
• POST /wallet/orders accepts an optional paymentIdentifier for payer-authorized reconciliation.
• /mcp redirects to the website's MCP server.
• /health/live and /health/ready report process and dependency readiness.

The website MCP surface also exposes read-only provider discovery, identity resolution, and service lookup tools. Identity and catalog registration remain independent of payment. Standard purchases register transaction-linked reputation against the configured ReputationStorage; provider outcomes and payer confirmations complete that record asynchronously.

There is no alternate payment rail, native facilitator endpoint, or legacy paid MCP workflow. Direct on-chain provider/service registration remains valid; gateway enrollment controls only discovery and orchestration in this gateway.

Requirements

• Node.js 22 or newer (nvm use selects the development version)
• PostgreSQL 16
• Reviewed standard-rail manifests and signer bindings
• Coinbase CDP facilitator credentials
• Base RPC access for finalized chain evidence
• A gas-funded reputation relayer

Local setup

git clone https://github.com/daski-io/gateway.git
cd gateway
npm install
cp .env.example .env
# Replace every placeholder. Do not use production or Testnet secrets locally.
npm run build
npm test

The runtime always starts the standard rail. PAYMENT_RAIL is intentionally not a configuration option.

Configuration

See .env.example for the complete Base Sepolia template. The core groups are:

• Runtime and database: NODE_ENV, CHAIN_ID, CHAIN_FINALITY_TAG (the block tag read as final: safe on Base Sepolia and finalized on Base mainnet by default), PUBLIC_URL, DATABASE_URL, MIGRATION_DATABASE_URL, and TRUST_PROXY. DOCS_URL is the public website origin used for guide and MCP links, defaulting to https://sandbox.daski.io on Base Sepolia and https://daski.io on Base mainnet. Override it for local or preview sites; it never changes payment audiences or signed resource URLs.
• Standard facilitator: CDP_API_KEY_ID, CDP_API_KEY_SECRET, and the signed facilitator profile in STANDARD_RAIL_MANIFEST_JSON.
• Evidence and screening: BASE_RPC_URL, optional BASE_RPC_FALLBACK_URLS, STANDARD_RAIL_SPLITTER_FACTORY_RUNTIME_CODE_HASH, STANDARD_RAIL_SPLITTER_CREATION_CODE_HASH, and SANCTIONS_ORACLE_ADDRESS.
• Signing role: FACILITATOR_PRIVATE_KEY for protocol artifacts and gas-funded Testnet reputation writes.
• Dynamic catalog: DYNAMIC_SERVICE_REGISTRATION_ENABLED, CATALOG_OPERATOR_TOKEN, and CATALOG_REFRESH_INTERVAL_MS. Registration routes are enabled by default and require an operator token. Disabling the route group does not stop checkout or refresh of existing registrations. Refresh runs every 240 seconds by default; use per-service operator visibility to stop discovery and new commerce for a service.
• Public projection: CHAIN_PROJECTION_REFRESH_MS sets how often the public reputation projection behind the chain document and the activity endpoint is refreshed in the background.
• Payer accounts: PAYER_ACCOUNT_TYPES (eoa by default; eoa,contract admits deployed contract accounts whose isValidSignature verifies the EIP-712 hash through one bounded eth_call) and PAYER_SIGNATURE_VERIFY_TIMEOUT_MS (5000), the single deadline covering the code lookup, the call, and one RPC failover. Signatures are at most 4,096 bytes; the call runs with 1,000,000 gas, a 16 KB response bound, and at most 8 concurrent verifications per process. On Base mainnet, contract requires CONFORMANCE_EVIDENCE_RECORDED=1.
• Owner swaps: OWNER_SWAPS_ENABLED (false) and OWNER_SWAPS_PER_PROVIDER_PER_DAY (50).

The HTTP listener binds every interface, including the unspecified IPv6 address in dual-stack mode, so Railway private networking (http://gateway.railway.internal:PORT) reaches the gateway without the public edge. TRUST_PROXY only affects requests that carry forwarding headers; private-network callers are rate limited by their own address.

The runtime rejects mock chain mode, unknown USDC domains, missing standard artifacts and configuration that does not match the signed marketplace manifest.

Verification

npm run typecheck
npm run build
npm test

The tests include a complete clean-schema migration smoke and PostgreSQL-backed evidence-locator behavior: one aggregated release event may cover multiple orders, while each deposit is globally single-use. Deployment coordination lives in daski-io/deploy-testnet.

Architecture

• src/standardRail/ contains signed artifacts, standard payment handling, evidence verification, state transitions, dispatch, reputation, and recovery.
• src/marketplace/ contains payment-independent finalized identity and service-registry reads.
• src/serviceRegistration/ contains provider-authenticated enrollment, safe card loading, immutable preparation, evidence verification, refresh, visibility, and the service-first public catalog.
• src/http/ mounts only the standard HTTP surface.
• src/mcp/ retains request context and compatibility result helpers; the MCP server and tool definitions belong to the website repository.
• src/db/ contains migration history and the standard runtime database boundary.

The provider workflow and signed wire contract are documented in docs/service-registration-v1.md; the provider owner-swap notice in docs/owner-swaps-v1.md. Checkout uses active database-backed skill listings. Registration and activation require live chain authority; new commerce requires successful authority and card validation within five minutes. Existing orders retain their immutable listing snapshots.

License

MIT

Contributing

See CONTRIBUTING.md. Report security issues through GitHub's private vulnerability reporting. Before pushing to develop, satisfy docs/release-readiness.md; develop must always be releasable.