Quickstart

These are real commands with real responses. You can run them now. The dashboard UI is still being finished, so everything here is the CLI.

Install

npm i -g @singularity-layer/cli

Auth is a Solana wallet signature. The CLI uses ~/.config/solana/id.json by default, or pass --keypair. Your key never leaves your machine.

singularity whoami

No keypair? Use a compute API key instead. Everything below can also be done over plain HTTP with an x402c_… key, which is how an agent manages processors without holding a wallet. See Managing with an API key at the end of this page.

1. Scaffold

mkdir my-processor && cd my-processor
singularity processors init my-processor

You get two files: processor.json (the manifest) and processor.js (your code).

2. Write the function

processor.js

export default {
  async fetch(request) {
    const { input } = await request.json();
    return Response.json({ greeting: `hello ${input.name}` });
  }
}

TypeScript and npm packages

If you want imports, types, or a package from npm, add --bundle:

npm i zod
singularity processors deploy --bundle --entry processor.ts

The bundling happens on your machine, with esbuild, and we ship the result. We deliberately never run npm install for you: a postinstall script is arbitrary code, and executing it on infrastructure that holds platform credentials is not something scanning makes safe. Your bundle crosses the boundary; your node_modules never does. Because the target is an isolate, a dependency reaching for fs, child_process or raw sockets fails here, on your terminal, naming the file that imported it, rather than inside a run a buyer already paid for.

3. Declare what it needs

processor.json

{
  "manifest_version": 1,
  "slug": "my-processor",
  "name": "My Processor",
  "description": "One sentence buyers and agents will read.",
  "lane": "managed",
  "price_usd": "0.01",
  "input_schema":  { "type": "object", "properties": { "name": { "type": "string" } } },
  "output_schema": { "type": "object", "properties": { "greeting": { "type": "string" } } },
  "limits": { "timeout_ms": 5000, "cpu_ms": 1000, "subrequests": 1 },
  "egress": { "allow": [] },
  "secrets": []
}

Keep limits tight. The ceiling we hold before each run is derived from timeout_ms, so a 5-second processor reserves a fraction of what a 600-second one does. Declaring honestly is directly cheaper.

4. Deploy

singularity processors deploy

deployed  my-processor

invoke token (shown once, saved to .singularity.json):
  sk-sglproc_ECpZQbXq-1aENejIPsY0QnXyVhUvhcXRbSmurMotun0

The invoke token is shown once. It is your server-side credential, the one you put behind your own product if you resell. Rotate it with singularity processors rotate.

5. Run it

singularity processors run '{"name":"world"}'

{ "greeting": "hello world" }

Runs typically complete in under 200ms plus your own work. Anything slower than the sync window returns 202 with a poll_url and a run token; send Prefer: respond-async to get that immediately.

6. See what happened

singularity processors logs

7 runs   failure rate 0.0%   platform faults 0

2026-08-07 07:38:37  completed  186ms
2026-08-07 07:38:35  completed  199ms

Your failure rate is public. It appears on your listing, because buyers pay for runs that fail after starting. Platform faults are ours and are excluded, so a bad day on our side never counts against you.

Your own console output

Whatever your code printed is captured per run, which is how you actually debug one:

singularity processors logs --logs <run_id>

     0ms  log   parsing input with zod
   184ms  log   calling the model
   611ms  error rate limited, retrying

Every console.log / warn / error / info / debug call is captured, capped, stripped of terminal escape sequences, and deleted with the run after 30 days. Anything you printed is here, including anything a caller sent you, if you printed it. It is best-effort observability, not an audit trail: it records what your code asked console to print, so code that writes output another way is not captured. singularity processors logs --follow tails new runs as they happen.

7. Go live

singularity processors publish

Now it is in the catalogue, callable by anyone, and exposed as an MCP tool.

Your Solana payout wallet must be able to receive USDC. If it has never held any, publishing is refused with instructions, send any amount of USDC to it once, then publish again. This is a Solana rule: you cannot transfer a token to an account that does not exist yet. It does not apply to Base or Robinhood.

By default buyers pay you in USDC on Solana, at the wallet you deployed with. To also accept USDC on Base or USDG on Robinhood Chain, add a payout block, see which chains buyers can pay on. One price_usd covers every chain.

Calling a published processor

Without payment, you get the price:

curl -X POST https://processors.x402compute.cc/processors/my-processor/run \
  -H 'content-type: application/json' -d '{"input":{"name":"world"}}'

{
  "x402Version": 1,
  "accepts": [{ "payTo": "<the publisher's wallet>", "maxAmountRequired": "10000", "asset": "EPjFW…Dt1v", "network": "solana" }],
  "error": "payment required"
}

Pay it and retry with an X-Payment header. Any x402 client does this automatically. The money goes straight to the publisher. accepts carries one entry per chain that publisher accepts, so a processor with a payout block returns several. Pick the one whose network you can sign for, solana, base, or robinhood. And pay that entry. maxAmountRequired is the same integer on all of them, because every asset is a 6-decimal stablecoin.

Calling your own, from your own product

Use the invoke token. No payment, because you are paying for the compute yourself:

curl -X POST https://processors.x402compute.cc/processors/my-processor/run \
  -H "Authorization: Bearer $SGL_PROCESSOR_TOKEN" \
  -H 'content-type: application/json' -d '{"input":{"name":"world"}}'

Common rejections

Response	Meaning
`400 input_required`	body must be `{"input": …}`
`402`	it is a paid processor and you sent no payment
`404 not_found`	unknown, unlisted, or deleted, deliberately indistinguishable
`429 too_many_concurrent_runs`	at the per-processor concurrency cap
`402 insufficient_runtime_credits`	your own balance cannot cover the run’s ceiling

Managing with an API key

An agent with no Solana keypair can still deploy and manage processors. Mint a key in the dashboard with the processors:write scope (or processors:read for read-only) and send it as X-API-Key:

curl https://processors.x402compute.cc/processors -H "X-API-Key: $SGL_API_KEY"

curl -X POST https://processors.x402compute.cc/processors \
  -H "X-API-Key: $SGL_API_KEY" -H 'content-type: application/json' \
  -d '{"manifest":{"manifest_version":1,"slug":"my-processor","name":"My processor",
       "description":"…","lane":"managed","price_usd":"0.01","methods":["POST"],
       "input_schema":{"type":"object","properties":{}},
       "output_schema":{"type":"object","properties":{}},
       "limits":{"timeout_ms":5000,"cpu_ms":1000,"subrequests":1}},
       "code":"export default { async fetch(req){ return new Response(\"{}\"); } }"}'

The same key then works on PATCH, DELETE, /secrets, /rotate-token, /pause, /listing, /webhook, /runs, /earnings and /kv.

processors:write is full control of that wallet’s processors, delete and secrets included, the same as a Cloudflare API token. If you want a credential that cannot change anything, mint processors:read.Three things to know before you rely on it:

Compute API keys do not expire. A leaked key works until you revoke it.
There is no audit log of what a key did.
Delete is permanent. Unlike redeploying a Worker under the same name, the code is wiped and the slug is burned forever. A leaked key can destroy a name you can never reclaim.

Two routes never accept a key, and neither is a publisher action:

Route	Why
`POST …/suspend`	moderation, admin wallets only
`POST /processors/auth-session`	minting a read session from a bearer adds nothing and would outlive revocation

Running is separate. POST …/run does not treat a key as an ownership claim. It is the one route with both a money path and an anonymous buyer lane. Use the invoke token from deploy. Deploying needs a Solana-backed key. owner_wallet becomes the x402 payTo and the runtime-billing account, so a key minted on an EVM wallet gets 400 solana_wallet_required when creating a processor. It can still manage processors its wallet already owns.

Overview

User Guide

Slayer Agent

Core flows

Staking Engine

Singularity Cloud Network

Contract Addresses

ERC8004

Skills

Singularity Payments

Agentic Fundraisers

Enterprise

Install

1. Scaffold

2. Write the function

TypeScript and npm packages

3. Declare what it needs

4. Deploy

5. Run it

6. See what happened

Your own console output

7. Go live

Calling a published processor

Calling your own, from your own product

Common rejections

Managing with an API key

​Install

​1. Scaffold

​2. Write the function

​TypeScript and npm packages

​3. Declare what it needs

​4. Deploy

​5. Run it

​6. See what happened

​Your own console output

​7. Go live

​Calling a published processor

​Calling your own, from your own product

​Common rejections

​Managing with an API key

Install

1. Scaffold

2. Write the function

TypeScript and npm packages

3. Declare what it needs

4. Deploy

5. Run it

6. See what happened

Your own console output

7. Go live

Calling a published processor

Calling your own, from your own product

Common rejections

Managing with an API key