Open provider network · sell

Run a service? Plug it in and get paid per call.

The runtime routes paid agent calls to independently registered providers. You register one public HTTPS /execute endpoint and the capabilities you serve; an operator reviews and activates it; paid x402 calls route to you by reputation with failover; settlement happens only when you succeed; your revenue share (up to 80%) is paid out on-chain in USDC on Base automatically. Today the two active providers are first-party. Founding providers wanted.

Free: discovery + 20 tool calls per UTC day, no key needed Then: from $0.01 USDC per call (Base mainnet; $0.02 for a verified answer with a signed attestation) via x402, or from 3 credits per call with a spend key Pricing Buy credits ($1.00 = 400) Set up your client
Supply side of naxytra

What the network is

Agents discover a capability on naxytra, pay once with x402 (gasless USDC on Base) or spend credits, and the xytara runtime executes the call. Execution is not locked to first-party code: any registered, activated provider that serves the capability can be the one the call is routed to. The runtime verifies the payment before dispatch, POSTs the job to your endpoint, settles on-chain only when you return success, reconciles your share in the ledger and pays it out. The runtime never holds your keys.

  • Routing by reputation: lifetime success rate, with new providers given a fair first shot and health checks that exclude an unhealthy endpoint temporarily.
  • Failover: on a clean 'did not process' answer (408, 429, 503, connection refused) the runtime retries or fails over to another provider.
  • Honest money: you see your own accrued, owed and paid balances with your owner_secret; payouts are idempotent and double-pay-safe.

What agents buy (demand side) · Provider contract JSON · Provider directory

APIs · data · models · tools

Who should register

Anything an agent would pay a cent or two per call for, reachable over HTTPS, that you can answer deterministically within the call budget.

  • APIs: a lookup, a conversion, a validation, a computation you already run as an HTTP service.
  • Data: a dataset, an index or a feed answered per query (prices, records, documents, reference data).
  • Models: an inference endpoint (classification, extraction, embedding, summarization) wrapped as a tool.
  • Tools: deterministic utilities and chain-adjacent checks of the kind the first-party MCP executor already serves.
  • Not a fit: anything that needs a browser session, a long-running job, or a private network address.

Capability catalog · Acceptable use

POST https://xytara.onrender.com/v1/provider-network/register

Register your service

Open registration: no API key. Send your public HTTPS /execute URL, the capabilities you serve (at least one of task_refs, tool_names, integration_ids), your revenue share in basis points (cap 8000 = up to 80%) and where to pay you. The response returns your provider_id and a one-time owner_secret: store it, it is required for every update and for reading your earnings. Provider endpoints must be public HTTPS; private, loopback and link-local addresses are refused.

register.json (replace the placeholders)
{
  "label": "YOUR_SERVICE_NAME",
  "endpoint_url": "https://your-service.example.com/execute",
  "task_refs": ["adapter.mcp.invoke"],
  "tool_names": ["your.tool.name"],
  "integration_ids": [],
  "revenue_share_bps": 8000,
  "payout_address": "0xYOUR_BASE_ADDRESS",
  "payout_network": "eip155:8453",
  "payout_asset": "USDC",
  "auth_token": "A_SECRET_YOUR_EXECUTE_ENDPOINT_CHECKS"
}
send it
curl -s -X POST https://xytara.onrender.com/v1/provider-network/register \
  -H "content-type: application/json" \
  -d @register.json
# -> {"ok":true,"provider_id":"<your id>","status":"pending","owner_secret":"prvown_... (shown once)","provider":{...}}
  • provider_id is optional: omit it to be assigned one, or set a stable id you will keep. Re-registering an existing id always requires its owner_secret.
  • auth_token is a bearer the runtime presents to your /execute so you can authenticate the runtime; it is never shown publicly.
  • The full field list and the current operator cap are in the contract JSON, which is authoritative.
Review → activation → traffic → earnings → payouts

What happens next

Registration lands your provider in status pending; it is not routable yet. From there:

  • Review: an operator checks the endpoint, the capabilities and the acceptable-use fit. Email the address below with your provider_id to start it.
  • Activation: status becomes active. Only active providers are routable.
  • Routed traffic: when a buyer pays for a capability you serve, the runtime POSTs the job to your /execute and returns your deliverable to the buyer with a settlement receipt and a signed delivery receipt.
  • Earnings: on your success the x402 payment settles on-chain and your revenue share accrues in the ledger, reconciled to the cent.
  • Payouts: accrued balances are paid out on-chain in USDC on Base to your payout_address automatically; read accrued, owed and paid any time with your owner_secret.

On-chain proof of settlement and payouts · Start the review

What the runtime sends you and what it expects back

The /execute contract, in short

One HTTP POST per routed call. The body carries the task, the buyer's input and a sanitized payment context (scalar facts only; never the buyer's signed authorization or settlement material). Answer within your timeout (capped at 30 s, inside a 50 s call budget) with the deliverable. The contract JSON is the authoritative, versioned description.

request the runtime POSTs to your endpoint
POST https://your-service.example.com/execute
content-type: application/json
authorization: Bearer <your auth_token>      # only if you registered one

{
  "command": "<command label>",
  "task_ref": "adapter.mcp.invoke",
  "body": { "tool_name": "your.tool.name", "arguments": { "...": "the buyer's input" } },
  "account_id": "<buyer account ref>",
  "quote": { "...": "the priced quote for this call" },
  "authorization_context": { "ok": true, "verification_mode": "...", "payment_payload": { "...": "scalar facts only" } }
}
what you return
# success: HTTP 2xx with the deliverable
{ "result": { "output": { "...": "your real result" } } }
# or
{ "output_payload": { "...": "your real result" } }

# failure: any non-2xx. 408 / 429 / 503 (and connection refused / DNS) mean "did not process":
# the runtime may retry you or fail over to another provider. Any other failure is ambiguous and
# is NOT retried. Make /execute idempotent per request.
  • Redirects are never followed; URLs with embedded credentials are refused; the host is re-checked by DNS at dispatch.
  • Capability matching: a call routes to you if its task_ref is in your task_refs, or its body.tool_name is in your tool_names, or an integration id matches.
Revenue share up to 80% · settlement only on success · on-chain payouts

Money

You set revenue_share_bps up to the operator cap (8000 = up to 80% of each settled amount). Settlement only on your success; a failed call is not charged and earns nothing. Your share is reconciled in the ledger per settled call and paid out on-chain in USDC on Base automatically (idempotent, double-pay-safe; the payout transactions are public on Basescan). Prices today are $0.01 USDC on Base mainnet ($0.001 USDC on Base Sepolia testnet), or $0.02 for the two attesting tools per call.

read your own earnings (owner_secret, never an operator bearer)
curl -s https://xytara.onrender.com/v1/provider-network/providers/<provider_id>/earnings \
  -H "x-provider-owner-secret: YOUR_OWNER_SECRET"
# -> payout_state (accrued / paid / pending / available / owed), your settlement rows, your payout history
  • The header is x-provider-owner-secret (or Authorization: Bearer <owner_secret>). Lost the secret? Email naxytra@gmail.com from the address you registered with.
  • Settlement, the split and the payouts are proven on Base mainnet; see the proof page for the transactions.

Proof · Terms · Refunds

Founding providers

Become a founding provider

Where the network stands today: Today the two active providers are first-party. Founding providers wanted. The routing, settlement, revenue split and automated on-chain payouts are live and proven on Base mainnet; what is missing is you. Founding providers get direct help with the /execute contract, a review within days, and a say in what the network prices and routes next.

  • Register with the request above, then email naxytra@gmail.com with your provider_id and what you serve; the review and activation happen there.
  • Your endpoint must be public HTTPS; keep the owner_secret and your auth_token out of the email.
  • Revenue share up to 80%, settlement only on your success, payouts on-chain in USDC on Base.