# Agent authority Source: https://docs.neus.network/agents/agent-delegation Grant an agent specific actions, a spend cap, and an expiration. Set spend and action limits for an agent. A signed-in-profile agent can act after identity is on file. A separate spend account also needs this permission record. The record shows who approved the agent, what it may do, how much it may spend, and when access expires. **Verifier ID:** `agent-delegation` **`controllerWallet`** is the approving account, the address that signs this step. See [Agent concepts](./concepts). ## Setup **`neus_context`** → **`neus_agent_link`** **`neus_agent_create`**. Leave out **`controllerWallet`** when the signed-in profile account should approve. **`neus_agent_link`** until **`linked: true`** Or finish on NEUS via [hosted verify](../cookbook/auth-hosted-verify). ## SDK ```javascript theme={"dark"} await client.verify({ verifier: 'agent-delegation', data: { controllerWallet: '0x...', controllerChainRef: 'eip155:8453', agentWallet: '0x...', agentChainRef: 'eip155:8453', scope: 'global', allowedActions: ['read_proofs'], }, walletAddress: '0x...', }); ``` Both accounts need a CAIP-2 network reference (`controllerChainRef`, `agentChainRef`) unless the request already includes `chain` or `chainId`. ## App link One-time user approval lets your backend create proofs without asking for a signature on every request. This is different from creating a **listing** in your profile for hosted verification. See [Integrations](../cookbook/integrations). 1. User signs in on NEUS 2. User approves the permissions once 3. Your app stores the proof ID in **`qHash`** 4. Your backend calls verification with **`x-neus-app`**. No per-request signature ```javascript theme={"dark"} await client.verify({ verifier: 'agent-delegation', data: { controllerWallet: userWallet, agentWallet: userWallet, scope: 'app-link', permissions: [ 'app:your-app-id', 'origin:https://yourapp.com', ], expiresAt: Date.now() + 90 * 24 * 60 * 60 * 1000, }, walletAddress: userWallet, }); ``` **Permissions:** * `app:`: matches your `x-neus-app` header * `origin:`: restrict to your domain * `origin:*`: any origin Send `x-neus-app: your-app-id` and matching site origin on verification requests. On Node, set `appOrigin: 'https://yourapp.com'` on `NeusClient` (or pass `Origin` via `extraHeaders`). ## Payment limits `maxSpend` is a whole-number string in token base units. For USDC (6 decimals), 25 USDC = `"25000000"`. Use `toAgentDelegationMaxSpend('25', 6)` from `@neus/sdk`. When `scope: "payments:x402"` and `allowedPaymentTypes: ["x402"]` are set, the agent can settle metered API calls via x402 without a NEUS account. The calling application enforces the `maxSpend` cap client-side before signing each payment. The protocol does not decrement `maxSpend` server-side. When the cap is exhausted, the application stops signing payments and the agent is refused. See [x402 pay-per-call](../platform/x402) for the full settlement flow. ```javascript theme={"dark"} import { toAgentDelegationMaxSpend } from '@neus/sdk'; await client.verify({ verifier: 'agent-delegation', data: { controllerWallet: '0x...', agentWallet: '0x...', scope: 'payments:x402', allowedActions: ['execute_payments', 'read_proofs'], maxSpend: toAgentDelegationMaxSpend('100.50', 6), allowedPaymentTypes: ['x402'], receiptDisclosure: 'summary', expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000, }, walletAddress: '0x...', }); ``` ## Fields | Field | Required | Description | | --------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------- | | `controllerWallet` | Yes | Approving account (must match signer) | | `controllerChainRef` | Yes\* | CAIP-2 chain for the controller wallet. \*Optional if the request supplies `chain` or `chainId` | | `agentWallet` | Yes | Agent address | | `agentChainRef` | Yes\* | CAIP-2 chain for the agent wallet. \*Optional if the request supplies `chain` or `chainId` | | `agentId` | No | Linked identity id | | `scope` | No | Permission scope (default: `global`) | | `permissions` | No | App-link scope tags (e.g. `app:`, `origin:`). For action allow/deny lists, use `allowedActions`/`deniedActions` instead. | | `allowedActions` | No | Explicit action allowlist | | `deniedActions` | No | Explicit action denylist | | `maxSpend` | No | Spend cap in token base units | | `allowedPaymentTypes` | No | Payment rails (e.g. `x402`) | | `receiptDisclosure` | No | `summary`, `full`, or `none` | | `expiresAt` | No | Expiration (Unix ms) | | `instructions` | No | Policy text (16000 chars) | | `skills` | No | Up to 48 skill objects | | `runtimePolicy` | No | Provider/model limits and human-approval requirement | | `approvalPolicy` | No | Approval requirements for new claims or content | The protocol accepts bounded action strings in **`allowedActions`** and **`deniedActions`**. `deniedActions` always wins over `allowedActions`. Use **`permissions`** only for app-link scope tags (`app:`, `origin:`). ## Human approval pattern Your application enforces the limits recorded in the permission proof: ```javascript theme={"dark"} const permissions = { controllerWallet, agentWallet, agentId: 'data-analyst', scope: 'global', allowedActions: ['read_data', 'draft_report'], deniedActions: ['send_message', 'approve_payment'], runtimePolicy: { requiresHumanApproval: true, }, approvalPolicy: { humanApprovalRequiredForNewClaims: true, preApprovedContentOnly: true, }, maxSpend: '15000000', expiresAt: Date.now() + 30 * 24 * 60 * 60 * 1000, }; ``` At runtime: 1. Check the current permission proof before the tool call. 2. Apply **`deniedActions`** first. 3. Pause when the policy requires human approval. 4. Continue only after approval is confirmed. Schema: [`agent-delegation.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/agent-delegation.json). ## Result A proof ID returned in **`qHash`**. Check it with **`neus_agent_link`** or **`neus_proofs_check`** before an action. ## Revoke ```javascript theme={"dark"} await client.revokeOwnProof(qHash, walletAddress); ``` Set **`expiresAt`** and **`maxSpend`** when money or high-risk actions are in scope. # Agent identity Source: https://docs.neus.network/agents/agent-identity Give an agent a name on your profile. Identity alone grants no extra spend power. Create or import an agent identity linked to your profile. **Verifier ID:** `agent-identity` Listed `skills` are metadata only. They do not install MCP servers. ## Setup Call **`neus_context`**, then **`neus_agent_link`** with **`agentId`** and the agent account. If **`linked: true`**, you are done. Call **`neus_agent_create`** with a stable **`agentId`**. Omit **`agentWallet`** to use your profile, or set it to **`"generate"`** for a dedicated key. Follow the returned **`next_action`**. Call **`neus_agent_link`** again until **`linked: true`**. ```json theme={"dark"} { "agentId": "my-assistant" } ``` **`agentWallet: "generate"`** returns the dedicated key once. Store it in Vault or your key manager. NEUS does not keep it. [Agent create](../mcp/agent-create) and [Agent verification flow](./agent-verification-flow) ## SDK For server-side or custom signing: ```javascript theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient({ apiUrl: 'https://api.neus.network' }); await client.verify({ verifier: 'agent-identity', data: { agentId: 'my-assistant', agentWallet: '0x...', agentChainRef: 'eip155:8453', agentType: 'ai', description: 'My AI assistant', }, walletAddress: '0x...', }); ``` The agent wallet signs this proof, so `agentChainRef` (CAIP-2, e.g. `eip155:8453`) is required unless your request already carries `chain` or `chainId`. With optional metadata: ```javascript theme={"dark"} await client.verify({ verifier: 'agent-identity', data: { agentId: 'my-agent', agentWallet: '0x...', agentType: 'ai', description: 'My AI assistant', capabilities: { search: true, mcp: true }, instructions: 'Operating instructions (max 16000 chars)', skills: [{ id: 'web-search', kind: 'mcp' }], services: [{ name: 'metrics', endpoint: 'https://metrics.example.com/v1', version: '1.0' }], }, walletAddress: '0x...', }); ``` Or use [hosted verify](../cookbook/auth-hosted-verify). ## Fields | Field | Required | Description | | --------------- | -------- | --------------------------------------------------------------------------------------------------------------- | | `agentId` | Yes | Unique id (1–128 chars) | | `agentWallet` | Yes | Agent wallet address in that chain's native format | | `agentChainRef` | Yes\* | CAIP-2 chain for the agent wallet (e.g. `eip155:8453`). \*Optional if the request supplies `chain` or `chainId` | | `agentLabel` | No | Display name | | `agentType` | No | `ai`, `bot`, `service`, `automation`, or `agent` | | `description` | No | Short description (500 chars) | | `capabilities` | No | Feature flags. See schema | | `instructions` | No | System prompt and policy (16000 chars) | | `skills` | No | Up to 48 skill objects (`id` required) | | `services` | No | Up to 16 endpoints (`name` + `endpoint`) | Full schema: [`agent-identity.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/agent-identity.json). ## Result You get a proof **`qHash`**, signed by the agent address. This registers identity only. Add [`agent-delegation`](./agent-delegation) for permissions. ## Check status ```bash theme={"dark"} GET /api/v1/proofs/check?verifierIds=agent-identity&address=0x... ``` In MCP: **`neus_agent_link`** or **`neus_proofs_check`**. # Agent verification flow Source: https://docs.neus.network/agents/agent-verification-flow Create or import an agent. Confirm it is ready. Then run work on NEUS. Ask: > Create or import an agent on my NEUS profile. Use generate if I need a separate spend account. Set spend and action limits. Then confirm it is ready. Then chat now, or start a Pro job in the background or on a schedule. Open **Connections** to link apps. ## Setup order Add `https://mcp.neus.network/mcp`, then click **Connect**. Ask NEUS, or **`neus_agent_create`**. Default is your signed-in profile. Use **`generate`** only for a dedicated spend key. **`neus_agent_link`** until **`linked: true`**. Chat or **New job**. Other runtimes can use the same agent. Ready means identity is on file. A separate spend account also needs signed permissions. [Do the work](./overview) · [Agent create](../mcp/agent-create) · [Connections](../cookbook/connector-integrations) ## Related Install Proofable and click Connect. Create or import, then do the work. Link apps in Connections. Spend, actions, expiry. # Agent concepts Source: https://docs.neus.network/agents/concepts Create or import an agent on your profile. Optional spend limits. Other tools can check that record. Create or import the agent on your profile. Add spend and action limits only when you need them. Then do the work on NEUS or in your editor. Other tools check the record instead of starting over. Default is your signed-in profile. Use `"generate"` only when the agent needs its own spend account. ## Limits | Need | Field | | ------------------------- | -------------------------------------------------------- | | Allowed / blocked actions | `allowedActions` / `deniedActions` | | Spend cap | `maxSpend` (whole-number string; USDC uses six decimals) | | Where it applies | `scope` (default `global`) | | End date | `expiresAt` | Ready means identity is on file. A separate spend account also needs signed limits. Full field list: [Permissions](./agent-delegation). ## Next Start here. Several agents on one profile. Full field reference. Create, confirm, work. # Discover agents Source: https://docs.neus.network/agents/named-agent-card Public agent pages, JSON profiles, and A2A / EIP-8004 cards. Other marketplaces can list the same agent. Every registered NEUS agent has a **public card**: owner, identity, capabilities, and current status other apps can check. That card is the portable record. Other marketplaces can list the same agent. NEUS keeps identity, control, and proof state in one place. ## Discovery paths | Path | URL | Returns | | -------------------- | ------------------------------------------------------------------------ | ------------------------------- | | Agent page | `https://neus.network/agent/{agentId}` | Human-readable profile | | Universal JSON | `https://neus.network/api/agent/{agentId}?format=json` | Identity + permissions + proofs | | A2A (per agent) | `https://neus.network/api/agent/{agentId}?format=a2a` | Agent-to-Agent card | | A2A (platform) | `https://neus.network/.well-known/a2a/agent-card.json` | Platform-wide A2A card | | EIP-8004 (platform) | `https://neus.network/.well-known/agent-card.json` | Ethereum registry card | | EIP-8004 (per agent) | `https://api.neus.network/.well-known/agent-card.json?agentId={agentId}` | Per-agent ERC-8004 bridge | Per-agent EIP-8004 cards resolve to `GET https://api.neus.network/api/v1/agents/card/{agentId}`. The platform A2A card is also available at `/api/agent/config?format=a2a`. ## Examples ```bash theme={"dark"} # Human profile # https://neus.network/agent/my-support-agent # Full NEUS JSON curl https://neus.network/api/agent/my-support-agent?format=json # A2A card for this agent curl https://neus.network/api/agent/my-support-agent?format=a2a # Platform A2A card curl https://neus.network/.well-known/a2a/agent-card.json ``` ## What a card shows | Field | Source | Visible | | ------------------ | ---------------- | --------------- | | `agentId` | Identity proof | Public | | `agentWallet` | Identity proof | Public | | `agentLabel` | Identity proof | Public | | `description` | Identity proof | Public | | `capabilities` | Identity proof | Public | | `skills` | Identity proof | Public | | `controllerWallet` | Permission proof | Public | | `scope` | Permission proof | Public | | `allowedActions` | Permission proof | Owner-view only | | `deniedActions` | Permission proof | Owner-view only | Public cards do not expose full allow/deny lists. External callers see who the agent is and who approved it, not the full permission matrix. ## Platform A2A card The platform card includes registered skills, MCP / REST / payment interfaces, auth options (OAuth and profile access keys for servers), and networks listed by CAIP-2 id. ## Cross-chain identifiers | Network | CAIP-2 | | -------------- | ----------------------------------------- | | Base Sepolia | `eip155:84532` | | Base Mainnet | `eip155:8453` | | Solana Mainnet | `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` | | Solana Devnet | `solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1` | ## CORS and caching Discovery endpoints return `Access-Control-Allow-Origin: *`. Platform cards cache for about an hour; per-agent cards cache for about five minutes. ## How to use it 1. **Discover**: fetch the card for the agent you need. 2. **Confirm**: check the permission proof before a sensitive action. 3. **Connect**: call the agent through MCP, A2A, or your own runtime. ## Next Register an agent so it appears in discovery. One approving account, many agents. Mount a verified agent into a project. Check proofs and resolve agents at runtime. # Agents Source: https://docs.neus.network/agents/overview Install Proofable. Click Connect. Create or import an agent. Open Connections. Chat now. Pro jobs run in the background. Agents are becoming portable. Their identity, context, permissions, and history should be too. Install Proofable, click **Connect**, then ask: > Create or import an agent on my Proofable profile. Use generate if I need a separate spend account. Set spend and action limits. Then confirm it is ready. That call uses **`neus_agent_create`**. Default is your signed-in account. Use **`generate`** only for a dedicated spend key. Confirm with **`neus_agent_link`**. ## Do the work Call `neus_context`, then create or import an agent. Open **Connections** on [proofable.me](https://proofable.me) to link apps. Chat now. **New job** (Pro) runs in the background or on a schedule. Cursor, Claude Code, Codex, Hermes, and Grok use the same endpoint. Optional project mount: ```bash theme={"dark"} npx -y -p @neus/sdk neus mount --apply cursor ``` Valid `--apply` values: `cursor`, `claude`, `codex`. See [Connect agent context](./runtime-mount). **Private cloud.** Point the runtime at the same URL. [Private Cloud Trust Harness](../cookbook/private-cloud-agents). | Need | Do this | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------- | | First run | Install Proofable. Click Connect. Optional: `neus setup` | | Create or import | Ask Proofable, or `neus_agent_create` on your signed-in profile | | Dedicated spend key | `agentWallet: "generate"` | | Ready? | `neus_agent_link` until `linked: true` | | Connections | Open **Connections** on [proofable.me](https://proofable.me). Link apps. [Guide](../cookbook/connector-integrations) | | Background or scheduled work | **New job**. Included with Pro | | List it elsewhere | Public agent card. Other marketplaces can list the same agent. | Keep Okta or your enterprise sign-in. Proofable records what the agent may do and runs the jobs those systems do not cover. ## Set it up Add `https://mcp.neus.network/mcp`, then click **Connect**. Optional: `neus setup`. Omit **`agentWallet`** to use your profile. Use **`"generate"`** for a dedicated spend key. Open **Connections** on [proofable.me](https://proofable.me). Link the apps the work needs. [Connections](../cookbook/connector-integrations) Chat now, or start a Pro job. Limits, expiry, and revoke live on the agent. [Permissions](./agent-delegation). ## Next Install Proofable and click Connect. neus\_agent\_create. Optional dedicated spend key. Link apps in Connections. Several agents on one profile. Same agent on a laptop, server, or confidential VM. Public card. Same agent can be listed elsewhere. # Connect agent context Source: https://docs.neus.network/agents/runtime-mount Optional. Load this agent into Cursor, Claude Code, or Codex after MCP Connect. This is optional. First-run is [MCP setup](../mcp/setup): add the endpoint, click **Connect**, then call `neus_context`. To load the same agent into an editor project: ```bash theme={"dark"} npx -y -p @neus/sdk neus setup npx -y -p @neus/sdk neus mount my-agent --apply cursor ``` Same command for `claude` or `codex`. VS Code uses `--apply cursor`. This writes `.neus/mount.json` and the host adapter. Start a new session so the project picks it up. The editor runs the tools. NEUS supplies identity, limits, and proofs. Cursor Cloud Agents can use the hosted MCP endpoint the same way. NEUS does not spawn those VMs for you. ## From the agent card **Connect in** copies: ```bash theme={"dark"} npx -y -p @neus/sdk neus mount --apply ``` Valid `--apply` values are `cursor`, `claude`, or `codex`. VS Code uses `--apply cursor`. Run it in the project. If the host is not connected yet, run `neus setup` first. The browser never downloads a static rules file. ## Assistant tool When signed in, call **`neus_agent_mount`** with `agentId`. You can also use `agentWallet` or the identity proof ID in `identityQHash`. Suggested order: 1. `neus_context` 2. `neus_agent_mount` when acting as a specific agent 3. `neus_proofs_check` / `neus_verify_or_guide` before sensitive actions ## SDK ```javascript theme={"dark"} import { resolveRuntimeBundleFromMcp } from '@neus/sdk/runtime-mount'; import { applyRuntimeBundle } from '@neus/sdk/runtime-adapters'; ``` Use `resolveRuntimeBundleFromMcp` with your MCP transport, then `applyRuntimeBundle(host, bundle, cwd)` for project files. The same bundle shape is returned by the `neus_agent_mount` MCP tool and the `neus mount` CLI. ## Where permissions are enforced | Surface | What NEUS provides | | ------------------------ | --------------------------------------------------------------------------- | | **NEUS agent tab** | Enforces permissions, tool access, and proof checks | | **MCP clients** | Loads project rules and trust context; start a new session after connecting | | **Workers and backends** | Returns the bundle for your application to enforce in its own tool loop | Your client controls its own tools. NEUS supplies verified context and permissions; your host remains responsible for enforcement. ## Related * [Agent identity](./agent-identity) * [Agent delegation](./agent-delegation) * [Connect Proofable](../mcp/setup) # Team agents Source: https://docs.neus.network/agents/team-agents Several agents on one profile. Each one has its own limits. Install Proofable, click **Connect**, then ask: > Create agents research, writer, and ops on my NEUS profile. Use generate if any need a separate spend account. Set limits. Confirm they are ready. ## Do the work Chat now, or create a Pro job that runs in the background or on a schedule. Open **Connections** to link apps. [Connections](../cookbook/connector-integrations) Cursor, Claude Code, Codex, Hermes, and Grok use the same endpoint. **Private cloud.** Point the runtime at `https://mcp.neus.network/mcp`. [Private Cloud Trust Harness](../cookbook/private-cloud-agents). ## Set it up Add `https://mcp.neus.network/mcp`, then click **Connect**. **`neus_agent_create`** per agent. Default is your signed-in profile. Use **`agentWallet: "generate"`** only when that agent needs its own spend account. **`neus_agent_link`** until **`linked: true`**. Revoke one agent without touching the others. ## Next Install Proofable and click Connect. Create or import, then do the work. Spend, actions, expiry, revoke. Link apps in Connections. # Deliver the gate reward after verification and payment Source: https://docs.neus.network/api-reference/gates/deliver-the-gate-reward-after-verification-and-payment /openapi/public-api.json post /api/v1/profile/gates/{gateId}/fulfill Post-verify reward delivery. Requires a verified proof (qHash) for the caller wallet. Paid gates also require paymentCheckoutSessionId (Stripe) or paymentTxHash (USDC). Returns the fulfillment payload and optional rewardProof / rewardPack. Payments are bound to a single gateId + qHash pair. Reuse returns 409 PAYMENT_ALREADY_USED. # Get a published gate snapshot (checkout contract) Source: https://docs.neus.network/api-reference/gates/get-a-published-gate-snapshot-checkout-contract /openapi/public-api.json get /api/v1/profile/gates/{gateId} Returns the public gate snapshot: requirements, monetization charge, schedule, checkout plan, and artifact metadata. Never includes the secret reward value. # List public, discoverable marketplace gates Source: https://docs.neus.network/api-reference/gates/list-public-discoverable-marketplace-gates /openapi/public-api.json get /api/v1/profile/gates/discoverable Returns public gates that are active, deployed, and tagged as marketplace listings. Bounded scan; a dedicated gate index is the post-launch optimization if listing volume grows. # Health check Source: https://docs.neus.network/api-reference/health/health-check /openapi/public-api.json get /api/v1/health # Get available payment methods Source: https://docs.neus.network/api-reference/payments/get-available-payment-methods /openapi/public-api.json get /api/v1/payments/methods # Get pricing information for all payment types Source: https://docs.neus.network/api-reference/payments/get-pricing-information-for-all-payment-types /openapi/public-api.json get /api/v1/payments/pricing # Check gate eligibility or proof criteria (server-side) Source: https://docs.neus.network/api-reference/proofs/check-gate-eligibility-or-proof-criteria-server-side /openapi/public-api.json get /api/v1/proofs/check Primary server-side integrator and x402 v2 resource for pre-action trust decisions. Pass gateId from your deployed gate, or explicit verifier/criteria filters. Unpaid public calls receive HTTP 402 with base64-encoded PAYMENT-REQUIRED instructions; retry the identical request with PAYMENT-SIGNATURE. Returns eligible plus matched proof references without exposing private proof payloads. # Erase all proofs for a wallet Source: https://docs.neus.network/api-reference/proofs/erase-all-proofs-for-a-wallet /openapi/public-api.json post /api/v1/proofs/erase-all # Get proof record by id Source: https://docs.neus.network/api-reference/proofs/get-proof-record-by-id /openapi/public-api.json get /api/v1/proofs/{qHash} Returns the proof record and verification state. Payload is shaped for the caller (public vs owner vs private). # Get proofs by wallet or DID Source: https://docs.neus.network/api-reference/proofs/get-proofs-by-wallet-or-did /openapi/public-api.json get /api/v1/proofs/by-wallet/{address} # Revoke a proof you control Source: https://docs.neus.network/api-reference/proofs/revoke-a-proof-you-control /openapi/public-api.json post /api/v1/proofs/revoke-self/{qHash} # Batch get verification status (minimal) Source: https://docs.neus.network/api-reference/verification/batch-get-verification-status-minimal /openapi/public-api.json post /api/v1/verification/status-batch # Get supported verifiers and configuration Source: https://docs.neus.network/api-reference/verification/get-supported-verifiers-and-configuration /openapi/public-api.json get /api/v1/verification/verifiers Returns the public verifier catalog: supported verifier IDs, sanitized public metadata (input schemas + direct-vs-hosted capabilities), and backend chain configuration (hub chain, asset allowlists). Non-public transport/provider fields are not exposed here. # Phase 1: build the standard signing string Source: https://docs.neus.network/api-reference/verification/phase-1:-build-the-standard-signing-string /openapi/public-api.json post /api/v1/verification/standardize Raw HTTP verification uses a strict two-phase handshake. First send the exact verification body here, sign the returned signerString, then submit the same body plus signature to POST /api/v1/verification. # Phase 2: submit a verification request Source: https://docs.neus.network/api-reference/verification/phase-2:-submit-a-verification-request /openapi/public-api.json post /api/v1/verification For raw HTTP callers, this request must continue a prior POST /api/v1/verification/standardize call using the same body and signedTimestamp. Do not treat this as a one-step schema-only POST; sign the exact signerString from phase 1 and submit that signature here. # Connections Source: https://docs.neus.network/cookbook/connector-integrations Link apps in Connections on your NEUS profile. **Connections** links apps and custom server URLs to your NEUS profile. Chat and Pro jobs use only the access you approve. **Connect** in Cursor, Claude, or another assistant signs that host into the same profile. It does not replace Connections. ## Open Connections On [neus.network](https://neus.network), open **Connections** from your profile. ## Link an account 1. Open **Connections**. 2. Pick an app. 3. Choose capabilities (for Gmail: Read, Send, Drafts; Delete stays off unless you turn it on). 4. Click **Connect** on the app and finish the provider window. You can link more than one account per app. Each connection is separate. Change capabilities any time. Removing one takes effect immediately. Adding one that needs broader provider permissions may require reconnecting. ## Use them Once linked, chat or start a Pro job: * "Read my latest emails" * "Find the Q3 roadmap in Drive" * "Send a Slack message to engineering" * "Create a GitHub issue for this bug" * "Open a pull request for this fix" If an app is not linked yet, the assistant tells you to open **Connections**. Pro jobs keep running after you leave. ## Custom server URL For an app that exposes its own server URL: 1. Open **Connections**. 2. Click **Add connection**. 3. Paste the server URL and API key if it requires one. ## Same stack, other paths | Path | What you do | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Hosted | Sign in on neus.network. Open Connections. Chat or start a Pro job. | | Assistant | Add `https://mcp.neus.network/mcp`, click **Connect**, then work in that host. Open Connections when the work needs an app. [MCP setup](../mcp/setup) | | Private cloud | Point the runtime at the same MCP URL. [Private Cloud Trust Harness](./private-cloud-agents) | | Your product | Hosted sign-in, SDK, or API. Same proofs. Connections still holds the app accounts chat and jobs use. | ## Security * NEUS does not store provider sign-in tokens. * Only enabled capabilities run. * Sends, creates, and deletes still go through your agent permissions. * Every action is saved as a result you can review. Disconnect any account from **Connections**. **Next:** [Agents](../agents/overview) · [MCP setup](../mcp/setup) # Verify a domain Source: https://docs.neus.network/cookbook/domain-verification Confirm domain control with a DNS TXT record. Check: [`ownership-dns-txt`](../verification/ownership-dns-txt). Optional. Not required to [sell access](../quickstart) or run VerifyGate. ## Steps 1. **TXT** at `_neus.` (DNS host/name is often `_neus` when the zone is your apex or subdomain). ```text theme={"dark"} wallet= ``` Example for Ethereum (use **lowercase** hex so it matches what NEUS expects): ```text theme={"dark"} wallet=0x... ``` The check reads **`wallet=`** only (not `neus=` or other prefixes). 2. **Request:** include at least `domain` in `data`. You may omit `data.walletAddress` when the same request carries a verified **top-level** `walletAddress` (typical signed flow); the service fills in that signer address before the DNS check. The TXT line must use the same wallet or account address NEUS uses for the check. ```javascript theme={"dark"} const proof = await client.verify({ verifier: 'ownership-dns-txt', data: { domain: 'example.com', walletAddress: '0x...' }, walletAddress: '0x...', }); ``` 3. **Check** ```bash theme={"dark"} GET /api/v1/proofs/check?verifierIds=ownership-dns-txt&address=0x... ``` DNS can take minutes to propagate (sometimes longer per provider). # Integrations Source: https://docs.neus.network/cookbook/integrations Backend proof creation and profile access keys when Hosted Verify is not enough. Most products use [Sell access](../quickstart) or [Hosted sign-in](./auth-hosted-verify): **VerifyGate** or **Hosted Verify**, then **`gateCheck`** on the server with the visitor’s **account address**. Use this page only when your backend creates proofs directly, or when you automate NEUS as your own profile. ## When you need this | Need | Use | | ----------------------------------------------------- | ------------------------------------------- | | Visitor verifies in the browser; you only check later | [Sell access](../quickstart). No access key | | Your server creates proofs for an approved user | `verifyFromApp` after one-time approval | | MCP, CI, or raw HTTP as **your** NEUS profile | Profile access key (`npk_*`) | ## Backend proof creation (`verifyFromApp`) After a user approves your product once (app-link permission), your server can create proofs for them without a per-request signature. ```javascript theme={"dark"} import { NeusClient } from "@neus/sdk"; // Server only. Never put this config in a browser bundle const client = new NeusClient({ appId: process.env.NEUS_APP_ID, // Must match the origin the user approved (or use origin:* on the approval) appOrigin: process.env.NEUS_APP_ORIGIN, // e.g. https://yourapp.com // Optional: bills/automates as your builder profile apiKey: process.env.NEUS_ACCESS_KEY, }); const proof = await client.verifyFromApp({ user: { walletAddress: user.accountAddress }, verifier: "ownership-basic", content: { claim: "User completed onboarding", source: "your-app" }, }); ``` Requirements: * Active user approval for your `appId` and site origin ([Agent permissions: App link](../agents/agent-delegation)) * `X-Neus-App` (from `appId`) and matching `Origin` on the request (`appOrigin` sets both for Node) If approval is missing, send the user through [Hosted Verify](./auth-hosted-verify) first. This is **not** the same as creating a **listing** under Profile → **Listings**, which bills hosted verification to your account. ## Profile access keys Create keys under [Profile → Account](https://neus.network/profile?tab=account). Pass the key to `NeusClient` as `apiKey` on the **server**. The SDK sends `Authorization: Bearer npk_...`. Never ship keys in browser bundles. Access keys identify **your builder profile** for automation. They do not replace per-user approval for backend proof creation. ## Billing Published gates are the default billing source. Pass **`gateId`** on hosted checkout and `gateCheck`; NEUS resolves owner, usage, and payment from that gate. `appId` is public attribution for advanced server flows. It does not bill your account by itself. See [Billing](../platform/billing). **Next:** [API Authentication](../api/authentication) # NFT gating Source: https://docs.neus.network/cookbook/nft-gating Require NFT ownership before content or rewards. Use the [NFT ownership](../verification/nft-ownership) check. Ownership is point-in-time. Set the contract, token policy, and recency in your published gate. ## Widget ```jsx theme={"dark"} import { VerifyGate } from '@neus/sdk/widgets'; export function NFTGatedContent() { return ( ); } ``` ## Next * [Sell access](../quickstart) * [NFT ownership check](../verification/nft-ownership) # Cookbook Source: https://docs.neus.network/cookbook/overview Step-by-step recipes for gates, sign-in, agents, and servers. New here? [Start](/). Selling access is a [recipe](../quickstart). ## Flows Portable trusted agents. Same identity, permissions, proofs, and Vault on a laptop, server, or confidential VM. Sign-in and checks at `/verify`. Social + human gates. Set identity and authority before tools run. DNS or org ownership. Creator and platform handles. Backend results and access keys. Link apps in Connections. Holder gates for on-chain ownership. Set the checks, set the price, embed one link. ## Related Assistants that use your NEUS account. Credits, Pro, and what checks cost. Full live catalog. # Private Cloud Trust Harness Source: https://docs.neus.network/cookbook/private-cloud-agents The portable trust harness for AI on a laptop, server, private cloud, or confidential VM. Same identity, permissions, proofs, context, and Vault. Same agent, wherever it runs. **Do the work** 1. Add `https://mcp.neus.network/mcp`, click **Connect**. 2. Create or import the agent (`neus_agent_create`). 3. Open **Connections** if the work needs an app. 4. Chat now, or start a Pro job. On NEUS, hosted jobs use the Operator engine. For an isolated coding computer (OpenCode, Hermes, Claude ACP), pin that harness on a machine you control. NEUS does not spawn that computer on shared Azure. For Cursor Cloud Agents, connect NEUS MCP inside that client. NEUS does not launch those VMs. For a laptop, VPS, or confidential VM, deploy below. The agent keeps one identity, one set of limits, and one history across environments. ## Deploy a private cloud agent with NEUS ### 1. Write your agent runtime definition Package your agent as a Docker Compose file. Include the system prompt, model config, tool list, and environment variables. ```yaml theme={"dark"} # docker-compose.yml services: agent: image: your-agent-image:latest environment: - NEUS_MCP_URL=https://mcp.neus.network/mcp - NEUS_ACCESS_KEY=${NEUS_ACCESS_KEY} ``` `NEUS_ACCESS_KEY` is a profile access key from your NEUS Profile. Use it for agents in headless environments. For interactive agents, use OAuth. ### 2. Deploy anywhere Run the compose file on a laptop, a VPS, on-prem, or a production cluster. The agent connects to `https://mcp.neus.network/mcp` from wherever it runs. NEUS loads the agent's identity, permissions, and saved proofs. Before any sensitive action, NEUS checks authority and reuses existing proofs. The agent can call any NEUS MCP tool: `neus_context`, `neus_proofs_check`, `neus_verify`, `neus_agent_mount`, `neus_secret_create`, `neus_secret_list`, `neus_secret_revoke`. ### 3. Move the agent, keep the trust state Redeploy the same compose file on a different backend. AWS, GCP, Azure, Phala Cloud, bare metal. The trust state stays the same across all of them. ### 4. Verify the trust chain * **NEUS** provides the agent identity and permission proofs. Verify with `neus_proofs_get` or `GET /api/v1/proofs/{qHash}` (proof ID). * **The access key** ties the deployed agent to a NEUS Profile. The profile owns the identity, permissions, and proof history. * **The environment** can optionally prove it is genuine (see confidential compute below). ## Optional: confidential compute If you need to prove the environment itself is genuine before it receives keys, run the agent inside a TEE-attested confidential VM. The hardware quote covers the full app hash: system prompt, model digest, tool list, and environment. Keys are sealed against that hash and released only after attestation passes. No host process sees plaintext keys. The trust state still lives in NEUS and travels with the agent. Confidential compute adds a proof that the environment matches what you expect. ### Phala dstack [dstack](https://phala.com/dstack) boots a Docker Compose app inside an Intel TDX confidential VM. The TDX quote covers the full compose hash. Keys are sealed against that hash and released only after attestation passes. NEUS already uses Phala-backed TEE inference for hosted AI. ```bash theme={"dark"} npx phala deploy ``` Verify the TDX quote with `@phala/dcap-qvl` against the Phala PCCS. Proves the compose hash and hardware. ### Other confidential compute runtimes If your runtime supports Intel TDX, AMD SEV-SNP, or an equivalent TEE with remote attestation over the app image, point the agent at the NEUS MCP endpoint. The trust chain is the same: hardware quote over the app hash, sealed keys, NEUS identity and authority checked before action. ## Agent framework examples ### Hermes Hermes ships six terminal backends. Docker is one of them. ```yaml theme={"dark"} # docker-compose.yml services: hermes: image: nousresearch/hermes-agent:latest environment: - NEUS_MCP_URL=https://mcp.neus.network/mcp - NEUS_ACCESS_KEY=${NEUS_ACCESS_KEY} - HERMES_MODEL=deepseek/deepseek-v4-flash-0731 ``` Hermes handles planning, memory, and skill creation. NEUS handles identity, permissions, and proof verification before sensitive actions. ### OpenClaw ```yaml theme={"dark"} # docker-compose.yml services: openclaw: image: openclaw/runtime:latest environment: - NEUS_MCP_URL=https://mcp.neus.network/mcp - NEUS_ACCESS_KEY=${NEUS_ACCESS_KEY} ``` OpenClaw orchestrates channels and subagents. NEUS adds the trust layer that checks who is acting and what they are allowed to do. ### Custom agent Any agent that speaks MCP can connect. Package it as a Docker Compose, deploy anywhere, point it at the NEUS endpoint. ## Portability Move the same agent from a laptop to a VPS or production cluster. The trust state stays the same. Confidential compute can attest each environment. ## Related The portable trust harness for AI. Install Proofable and click Connect. Agent identity and authority. Live Private Cloud Trust Harness. # Abuse and layered access Source: https://docs.neus.network/cookbook/sybil-resistance Layer account, social, and proof of human for stronger assurance than a single signal. One weak signal is easy to game. Publish a listing that **layers** hosted account signals so visitors must pass more than one requirement. | Layer | Verifier ID | When | | --------------------- | ------------------------------------------- | ------------------------------------------------------------- | | Social / work account | `ownership-social` or `ownership-org-oauth` | Linked identity most products need first | | Human | `proof-of-human` | Anti-bot and fair access | | Account uniqueness | `ownership-basic` | Baseline uniqueness when you also need a signed account check | Prefer social + human for consumer apps. Add `ownership-basic` or `wallet-risk` only when your threat model needs them. ## Publish the layered gate In **Profile → Listings**, require the verifiers above, set pricing, and publish. Visitors never see your API key. They only need your `gateId`. ## VerifyGate ```jsx theme={"dark"} { // persist result.qHash for replay protection }} > ``` ## Server eligibility ```javascript theme={"dark"} const layered = await client.gateCheck({ gateId: 'gate_layered', address: user.accountAddress, // from Hosted Verify / proof subject }); ``` Configure recency on the gate for point-in-time checks. Store proof IDs (`qHash`) where replay matters. **Next:** [Sell access](../quickstart), [Hosted Verify](./auth-hosted-verify), [Pricing](../platform/pricing) # Build a verifiable agent Source: https://docs.neus.network/cookbook/verifiable-agents Create or import an agent, then chat or start a Pro job. Create or import the agent on your profile. Then do the work. Chat now. Pro jobs run in the background or on a schedule. Open **Connections** to link apps. [Connections](./connector-integrations) Cursor, Claude Code, Codex, Hermes, and Grok can execute the same agent. Default is your signed-in profile. Use **`generate`** only for a dedicated spend key. To bill hosted verification through your product, complete [Sell access](../quickstart). Field reference: [Agent concepts](../agents/concepts). ## MCP **`neus_context`** → **`neus_agent_link`** with both **`agentWallet`** and **`agentId`**. Done if **`linked: true`**. **`neus_agent_create`** when results are missing. Follow **`next_action`**. Use **`generate`** only for a dedicated spend key. **`neus_agent_link`** until **`linked: true`**. ## SDK For a dedicated agent wallet, keep the identity result from the agent-signed step, then build a delegation-only hosted callback: ```javascript theme={"dark"} import { getHostedAgentCreateUrl } from '@neus/sdk'; const hostedUrl = getHostedAgentCreateUrl({ agentId: 'workflow-orchestrator', agentWallet, controllerWallet, identityQHash, allowedActions: ['read_context', 'execute_jobs'], deniedActions: ['send_message'], runtimePolicy: { requiresHumanApproval: true }, returnUrl: 'https://app.example.com/agents/callback', }); ``` | Step | Page | | --------- | --------------------------------------------- | | Identity | [Agent identity](../agents/agent-identity) | | Authority | [Agent authority](../agents/agent-delegation) | | Billing | [Billing](../platform/billing) | | Start | [Start](/) | Schemas: **`docs/verifiers/schemas/`** ## Agent that pays To let an agent pay for metered APIs on its own, give its authority a spend cap and the payments scope, then let it settle pay-per-call requests: 1. Grant authority with `scope: 'payments:x402'`, `allowedPaymentTypes: ['x402']`, and a `maxSpend` cap. See [Agent authority](../agents/agent-delegation). 2. The agent calls your priced endpoint; a `402` returns the price. 3. The agent pays and retries with a `PAYMENT-SIGNATURE` header. Full flow: [Pay per call](../platform/x402). The `maxSpend` cap is enforced as a hard stop, so the agent cannot exceed its budget. ## Related Start here. Tool list and auth. # Verified creator handles Source: https://docs.neus.network/cookbook/verified-handles Bind a pseudonymous handle to a wallet, display a verified badge, and gate creator actions with NEUS Proofs. Use Proofable to make creator handles portable and verifiable. A user claims a handle, Proofable binds it to their wallet with the `ownership-pseudonym` verifier, and your app gets a reusable proof ID it can badge, link, and gate. ## When to use this * Creator platforms, media networks, or launchpads that need handle ownership proof. * Pseudonymous identity without legal identity exposure. * Gating drops, founders tables, or premium calls behind a verified handle. ## What you need * A published NEUS gate with `ownership-pseudonym` enabled (or use direct verification with in-app signing). * The user's wallet address. * A `namespace` to isolate your handles from the default `neus` namespace. ## Flow 1. User claims a handle in your app. 2. Your app asks NEUS to bind `handle` + `namespace` + `walletAddress`. 3. NEUS returns a proof ID in `qHash` and a proof URL. 4. Your app stores the proof ID with the user record. 5. Surface a verified badge that links to the public proof page. 6. Before any privileged action, check the proof on your server. ## Direct verification (in-app signing) Use `NeusClient.verify()` when your app already handles wallet signatures. ```js theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient(); const proof = await client.verify({ verifier: 'ownership-pseudonym', data: { pseudonymId: 'alice123', // 3-64 lowercase chars namespace: 'acme', // isolate from default neus namespace displayName: 'Alice', metadata: { platform: 'acme' } }, wallet: window.ethereum // EVM provider }); // Store proof.qHash with the user record // proof.proofUrl === https://neus.network/proof/{qHash} ``` `pseudonymId` must match `^[a-z0-9._-]{3,64}$` (3–64 lowercase chars). ## Hosted Verify (no in-app signing) Send the user to NEUS and get the proof ID back on return. ```js theme={"dark"} import { getHostedCheckoutUrl } from '@neus/sdk'; const url = getHostedCheckoutUrl({ gateId: 'gate_acme-handles', returnUrl: 'https://acme.network/handle/callback', }); window.location.assign(url); ``` Read the proof ID from the `qHash` field in the callback URL or popup message and store it. ## Show the badge Drop the SDK widget next to the handle. ```jsx theme={"dark"} import { ProofBadge } from '@neus/sdk/widgets'; export function CreatorHandle({ handle, qHash }) { return (
@{handle}
); } ``` The badge links to `https://neus.network/proof/{qHash}` and shows live proof status. ## Gate creator actions on the server Always check the proof server-side before allowing privileged actions. ```js theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient(); const result = await client.gateCheck({ gateId: 'gate_acme-handles', address: walletAddress }); if (result.data?.gate?.allRequiredSatisfied !== true) { throw new Error('Handle not verified'); } ``` Or call the HTTP API directly: ```bash theme={"dark"} curl "https://api.neus.network/api/v1/proofs/check?gateId=gate_acme-handles&address=0x...&namespace=acme" ``` ## Namespace policy Namespaces other than `neus` require the namespace owner to confirm DNS control with `ownership-dns-txt`, or NEUS admin approval. Contact NEUS to reserve a production namespace for your platform. ## Optional: link social accounts Layer `ownership-social` to also confirm a linked X, Discord, Telegram, GitHub, or other social account. Social checks are interactive and hosted-only, so they usually run through `VerifyGate` or Hosted Verify rather than direct signing. ```jsx theme={"dark"} import { VerifyGate } from '@neus/sdk/widgets'; { console.log(result.qHash || result.qHashes); }} > ``` ## Full example See the [verified-handle-react example](https://github.com/neus/network/tree/main/examples/verified-handle-react) for a complete React + Vite app. ## Next * [Username](../verification/ownership-pseudonym) * [SDK Quickstart](../quickstart) * [Hosted Verify](./auth-hosted-verify) * [API: GET /proofs/check](../api/overview) # Don't restart from zero. Source: https://docs.neus.network/index The portable trust harness for AI. Identity, permissions, private context, and proof — wherever your agent runs. Portable Trust Infrastructure for Humans and AI. Proofable is the portable trust harness for AI. Identity. Permissions. Private context. Proof. Private cloud. The primitives agents need so trust does not restart from zero. Portable Proof carries verified identity, authority, and action evidence across apps, agents, and networks. The receiving product owns the decision and enforces the result. Cursor, Claude, ChatGPT, Hermes, OpenClaw. Install Proofable. Click Connect. Who the agent is, what it may do, what it already proved. Private by default. Same agent on a laptop, a server, or a confidential VM. ## Connect Install Proofable in your editor or chat. Click **Connect**. `https://mcp.neus.network/mcp` ```json theme={"dark"} { "mcpServers": { "neus": { "url": "https://mcp.neus.network/mcp" } } } ``` Then ask: > Reuse what I already have. Before a sensitive action, check my current proofs. Proofable answers **Passed**, **Action needed**, or **Blocked**. One-click: [proofable.me/install](https://proofable.me/install). Full steps: [Connect Proofable](./mcp/setup). Verify once. A connected app reuses the Proof before access, payment, or execution. One connection for chat, IDEs, listings, and proofs. Create or import an agent. Open Connections. Chat, start a Pro job, or publish a listing. Open a hosted flow for supported identity, ownership, risk, or permission checks. Publish the checks and price once. Add one component to your app. ## Verify once. Prove everywhere. 1. **Verify once.** Use the hosted screen, MCP, or SDK. 2. **Prove everywhere.** Proofable saves the result with its current status and expiration when one applies. 3. **Enforce before action.** Connected apps require that proof before access, payment, or execution. Read the flow in [How verification works](./verification/how-it-works) and [Standards](./learn/standards). ## Where Proofable sits Keep your sign-in, identity provider, payment, and agent framework. Add Proofable via MCP, SDK, or API. Work accounts, domains, social accounts, and passkeys all work. Browse [Solutions](https://proofable.me/solutions). ## Release status Published APIs and verifier schemas may change between minor versions. Breaking changes are listed in the [changelog](https://github.com/neus/network/blob/main/CHANGELOG.md). # DMCA Source: https://docs.neus.network/learn/legal/dmca DMCA policy and designated agent for copyright infringement notices. NEUS Network, Inc. ("NEUS", "we") respects the intellectual-property rights of others. If you believe material available through our websites, apps, documentation, or services infringes your copyright, send a notice to our Designated Agent using the instructions below. ## Designated Agent * **Name/Title**: DMCA Agent, Designated Agent * **Company**: NEUS Network, Inc. * **Address**: 1111B S Governors Ave STE 39950, Dover, DE 19904, USA * **Email**: `dmca@neus.network` * **Phone**: +1 (302) 265-4043 ## What to Include in a DMCA Notice Your notice must include: * A physical or electronic signature of the copyright owner or authorized agent * Identification of the copyrighted work claimed to have been infringed (e.g., a URL to the original or a clear description) * Identification of the material to be removed or disabled and information reasonably sufficient to locate it on NEUS (precise URL, proof/ID, transaction hash, IPFS CID, etc.) * Your contact information (name, address, phone, and email) * A statement that you have a good-faith belief the use is not authorized by the copyright owner, its agent, or the law * A statement that the information in the notice is accurate and, under penalty of perjury, that you are the copyright owner or authorized to act on the owner's behalf Send to the Designated Agent above. We accept digital signatures and notices by email. ## Important Limitations Some material referenced through NEUS (e.g., blockchain transactions, IPFS CIDs) may be stored on public networks we do not control. While we cannot delete on-chain content, we can delist it from NEUS interfaces, unpin IPFS content we control, and block access through our hosted services when we receive a valid notice. ## Repeat-Infringer Policy NEUS terminates or restricts accounts/wallets that are the subject of multiple valid DMCA notices. We track strikes over a rolling 36-month window and may disable proofs, keys, or UI access, and/or block resubmission. ## Counter-Notice Process If your material was removed due to error or misidentification, submit a counter-notice containing: * Your physical or electronic signature * Identification of removed material and prior location * A statement under penalty of perjury that you have a good-faith belief the material was removed due to mistake or misidentification * Your name, address, phone number, and email * A statement that you consent to the jurisdiction of the Federal District Court for your address, or if outside the U.S., to the courts of Delaware, and that you will accept service of process from the person who sent the original notice or that person's agent If we receive a valid counter-notice, we will forward it to the original complainant and restore the material in 10 - 14 business days unless we receive notice that the complainant has filed a court action. ## Misrepresentations Submitting false notices or counter-notices may result in liability for damages and attorneys' fees. ## Subpoenas & Disclosures We may disclose account information as required by law (e.g., valid subpoena, court order). ## Contact For DMCA notices: * **Email**: `dmca@neus.network` * **Address**: NEUS Network, Inc., 1111B S Governors Ave STE 39950, Dover, DE 19904, USA * **Phone**: +1 (302) 265-4043 # Legal Source: https://docs.neus.network/learn/legal/index Policy and legal terms for NEUS public services, docs, APIs, and hosted application flows. Governing policies for NEUS public docs, APIs, and hosted verification. ## Policies * [Terms of Use](./terms-of-use) * [Privacy Policy](./privacy-policy) * [Security Disclosure](./security-disclosure) * [DMCA](./dmca) # Privacy Policy Source: https://docs.neus.network/learn/legal/privacy-policy How NEUS collects, uses, protects, and shares personal information. Effective date: July 26, 2026. Last updated: August 9, 2026. This Privacy Policy explains how NEUS Network, Inc. ("NEUS," "we," "us," or "our") handles personal information when you use the NEUS website, application, APIs, hosted Model Context Protocol (MCP) service, verification services, and related products (collectively, the "Service"). NEUS Network, Inc. is the company responsible for the personal information covered by this policy. This policy does not govern public blockchains, third-party websites, wallets, artificial-intelligence providers, or accounts that you connect to NEUS. Those services have their own privacy practices. ## Information We Collect | Category | Examples | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account and authentication | Wallet address, decentralized identifier, passkey public credential, email address or a protected email-derived identifier, third-party account identifier, name, username, profile image, authentication method, and session information | | Profile and workspace | Display name, biography, avatar, public handles, organization domain, workspace membership, preferences, and information you choose to publish | | Proof and verification | Information you submit for verification, proof results, verifier used, status, timestamps, hashes, signatures, visibility choices, and related records | | Connected accounts | Provider, account identifier, granted permissions, connection status, encrypted access or refresh token, and information returned when you ask NEUS to use the connection | | Assistant and agent content | Prompts, messages, files, tool requests and results, agent instructions, jobs, outputs, and private chat or execution proofs | | Payments | Plan, credits, transaction identifiers, wallet transactions, purchase and payout status, and limited billing records. Payment-card and payout onboarding details are collected by Stripe, not NEUS | | Device and service activity | IP address or a protected derivative, browser and device information, page or feature used, referring page, performance data, request time, error details, and security events | | Communications | Contact requests, support messages, newsletter subscription, security reports, and related correspondence | | Public and third-party sources | Public blockchain records, public profile or repository information, domain records, and information returned by a provider you ask us to use | Do not send NEUS a private key, seed phrase, account password, or information that is not needed for the feature you are using. Some identity checks use a third-party service to create a privacy-preserving proof. In those flows, the provider may inspect an identity document, while NEUS is designed to receive the proof result or derived identifier rather than the document itself. The provider's notice applies to its processing. ## How We Use Information We use personal information only for the following purposes: | Purpose | Legal basis where required | | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Provide accounts, profiles, proofs, connected accounts, assistants, agents, APIs, payments, and support | Perform our contract with you | | Authenticate users, protect private information, prevent fraud and abuse, enforce limits, and investigate incidents | Perform our contract and pursue our legitimate interest in securing the Service | | Process a provider connection or optional communication you request | Your direction or consent | | Maintain reliability, diagnose errors, measure feature performance, and improve the Service | Our legitimate interest in operating a reliable product | | Process purchases, maintain financial records, and meet legal requests | Perform our contract and comply with law | | Send product or policy notices and, where you request them, newsletters | Perform our contract, pursue our legitimate interest in service communications, or obtain your consent, as applicable | We do not use personal information for advertising profiles, targeted advertising, or data-broker services. We do not sell personal information or share it for cross-context behavioral advertising, and we have not done so in the preceding 12 months. We use account credentials and other sensitive personal information only to provide and secure the feature you request. We do not use it to infer personal characteristics. ## Google User Data Signing in with Google and connecting Google as an agent capability are separate choices: * **Google sign-in** requests basic identity information, such as your Google account identifier, name, profile image, and email address, to authenticate you and link the sign-in method to your NEUS account. * **Google connection** requests `Gmail read-only` and `Google Drive read-only` access. This permits NEUS to retrieve Gmail messages and Drive files, including Google Sheets files, only when you ask an assistant or agent to use that connection. NEUS does not request permission to send email, modify mail, or edit or delete Drive files through this connection. NEUS handles Google user data as follows: * **Access:** NEUS accesses data only through the permissions you approve and only to provide the user-facing feature you request. * **Use:** Retrieved data is used to answer your request, perform the tool action, and show or save the result in your private NEUS session or proof when that feature is enabled. * **Storage:** OAuth tokens are stored as encrypted private records. Retrieved content may be retained in a private chat, job, or execution proof if it forms part of that record. * **Sharing:** Data may be processed by the NEUS hosting stack and, when needed to answer your request, by the hosted AI provider or the AI provider you selected. It is not shared for advertising or unrelated purposes. * **AI training:** NEUS does not use raw or derived Google Workspace data to train or improve a generalized artificial-intelligence or machine-learning model. * **Hosted model isolation:** When you use NEUS-hosted assistant inference (the Default and Advanced tiers), NEUS sends the model request through RedPill's confidential-computing gateway. NEUS requires a verified serving path and, for each completed model call, checks the gateway identity and the signed receipt's exact request and response hashes. When the gateway forwards to a separate model host, NEUS also checks the cited serving-session record, its evidence digest, claims, and channel binding. The chat shows **TEE verified** only when every model call that contributed to the answer passed the checks that apply to its serving path. This verifies the recorded processing path; it does not mean the browser-to-model request is end-to-end encrypted. NEUS-side retention of the conversation or proof is separate and described above. When you supply your own AI provider key (bring-your-own-key), NEUS sends your request to the provider you selected. The same **TEE verified** checks can apply when that provider is RedPill's verified gateway; they do not apply to other bring-your-own-key providers. The selected provider's terms and privacy policy govern its processing. * **Control:** You can disconnect Google in NEUS. NEUS removes the local connection and attempts provider-side revocation. You can also revoke access from your [Google Account connections](https://myaccount.google.com/connections). ## Limited Use Compliance The use of raw or derived user data received from Google Workspace APIs will adhere to the [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), including its Limited Use requirements. NEUS does not use, transfer, or sell Google user data, including raw, aggregated, or derived data, to create, train, or improve foundational or generalized artificial-intelligence or machine-learning models. This commitment applies to both NEUS-hosted inference and any third-party AI provider integration described in this policy. ## Other Connected Providers NEUS may offer sign-in or connected-account access from providers such as Microsoft and GitHub. * A **Microsoft connection** may request basic identity information plus read-only access to Outlook mail and OneDrive files. * A **GitHub connection** may request profile, organization, repository, and file access. GitHub's `repo` permission can cover private repositories when you approve it. * Other sign-in providers may supply the account identifier and basic profile information shown on their consent screen. NEUS stores the granted permissions and encrypted connection credential. It uses the connection only when you request the related feature. Disconnecting removes the NEUS connection and, where supported, requests revocation from the provider. You can also revoke access in the provider's account settings. You may add a remote MCP service or your own API key for an AI or tool provider. In that case, NEUS sends the information needed for your request directly to the service you selected. When you connect a provider with your own key and then ask an assistant to use Google Workspace data in that turn, you direct the transfer of that data to the provider you selected. That provider's terms and privacy policy apply, and you are responsible for confirming the provider's terms permit your intended use of the data. NEUS does not control and is not responsible for how a third-party provider processes data you send to it with your own key. ## AI and Automated Processing NEUS sends prompts, relevant conversation context, and requested tool results to an AI provider when you use assistant or agent features. * NEUS-hosted inference uses RedPill. For completed hosted model calls, NEUS can verify the gateway's hardware identity, measured software, key-release chain, and TLS channel, plus the exact request and response hashes in its signed receipt. For forwarded calls, NEUS also checks the cited serving-session record. * If you provide your own key, NEUS sends the request to the provider you selected, such as OpenAI, Anthropic, Google Gemini, OpenRouter, or another configured provider. * Information from Gmail, Drive, Outlook, OneDrive, GitHub, or another connected service is included in model context only when needed to complete the action you requested. NEUS may retain private chat and agent execution proofs in your account. Do not include sensitive information in a prompt unless it is necessary for the task. Some verification and access features automatically compare submitted, public, or provider-confirmed information with the rules selected for a proof or access gate. The result may be a pass or fail proof that a user or third party relies on to allow access or continue a transaction. You can contact us if you believe an automated result is incorrect. NEUS does not use automated processing to make employment, credit, housing, insurance, or similarly significant decisions about you. ## Third-Party AI Providers NEUS offers two inference paths with different data-isolation guarantees. **NEUS-hosted inference (Default and Advanced tiers).** When you use the included NEUS assistant without supplying your own key, NEUS sends the model request through RedPill's confidential-computing gateway and requires verified serving. For every completed model call, NEUS can check the gateway's hardware-backed identity, measured software, key-release chain, and TLS channel, plus the exact request and response hashes in its signed receipt. When the gateway forwards to a separate model host, NEUS also checks the cited serving-session record, its evidence digest, claims, and channel binding. A **TEE verified** label means all model calls that contributed to that answer passed the checks that apply to their serving paths. The session check relies on the approved gateway's attested verification result; NEUS does not separately rerun every model host's provider-specific attestation process. The checks do not independently prove exclusive custody of the gateway's private keys. The label does not claim end-to-end encryption or prove how a model developer handles data outside this serving path. NEUS-side retention of the conversation or proof is separate and described above. **Bring-your-own-key inference.** When you supply your own AI provider key, NEUS sends your request to the provider you selected, and that provider's terms and privacy policy apply. A RedPill key can use the same verified gateway and **TEE verified** checks described above. Other bring-your-own-key providers do not receive that label. If you connect Google Workspace and then select a bring-your-own-key provider for a turn that uses Google data, you direct the transfer of that data to the provider, and you are responsible for confirming the provider's terms permit your use. The following third-party AI providers may be available as bring-your-own-key integrations, each governed by the provider's own terms: OpenRouter, OpenAI, Google Gemini, Anthropic, DeepSeek, Groq, RedPill, Ollama Cloud, NEAR AI, Alibaba DashScope, Featherless AI, Mistral, Together, xAI, NVIDIA NIM, and Fireworks AI. NEUS does not control how a provider processes data you send with your own key. The NEUS-hosted path uses RedPill as its sole platform-managed provider and requires the verified serving path described above. ## When We Disclose Information We disclose personal information only as needed: * to service providers that host, secure, support, or process the Service; * to a connected provider or AI provider when you direct the interaction; * to another user or the public when you choose public visibility or submit information to a public network; * to an organization administering a workspace you join; * to comply with law, enforce our agreements, or protect users, NEUS, and others; or * as part of a merger, financing, acquisition, or sale, subject to appropriate confidentiality protections. Our principal provider roles are: | Provider or system | Role and information processed | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Microsoft Azure** | Protocol API hosting, account and proof database, cache and job coordination, operational logs, monitoring, and incident response | | **Vercel** | Web application hosting, server-side assistant execution, request logs, and public or private file storage | | **Cloudflare** | Domain and network protection and, on forms where enabled, Turnstile abuse prevention | | **RedPill and its confidential-computing infrastructure** | NEUS-hosted AI inference for prompts and relevant context | | **Google, Microsoft, GitHub, and user-selected providers** | Authentication or connected-account data requested by the user | | **Stripe** | Card payments, subscriptions, creator payout onboarding, fraud controls, and legally required payment records | | **Resend** | Transactional email, support delivery, and newsletters requested by the user | | **Reown / WalletConnect and wallet providers** | Wallet connection and wallet-request routing | | **Alchemy and public blockchains** | Blockchain reads, transactions, addresses, and public proof references | | **Pinata / IPFS and Vercel Blob** | Public content selected for publication and private file storage, respectively | | **context.dev** | Web search or webpage retrieval requested through assistant tools | | **Verification providers** | Information needed to perform an optional proof, subject to the provider notice shown for that flow | Providers may process information in the United States and other countries. Those countries may have different privacy laws. Where applicable law requires a transfer safeguard, we use the safeguard available for the relevant provider arrangement. Contact us if you need information about a transfer that affects you. ## Public Networks and Visibility You control whether supported profile, proof, and file content is private or public. Before publishing: * public proof references, wallet addresses, transaction records, and smart-contract events may be permanently visible on a blockchain; * public files may be stored through IPFS or public object storage and copied by others; and * deleting your NEUS profile cannot erase data already written to a public blockchain or copied outside NEUS. Deleting or revoking a public proof removes or limits it in NEUS-controlled views where technically possible. It does not rewrite a public network. ## Cookies and Similar Storage NEUS uses first-party cookies and local browser storage that are necessary for authentication, security, wallet connection, preferences, and continuity of a requested flow. The primary authentication cookie is protected from browser-script access and is sent only with qualifying requests. Connected providers may set their own cookies when you visit their sign-in or consent pages. NEUS does not use third-party advertising cookies. Because we do not sell data or use it for targeted advertising, the Service does not currently respond differently to browser "Do Not Track" signals. ## Retention and Deletion We keep information only for the period needed for the purposes described above: * account, profile, private proof, connection, chat, and agent records remain until you delete or revoke them, delete your profile, or they are no longer needed; * connected-provider credentials remain until you disconnect, reconnect and replace them, the provider invalidates them, or you delete your profile; * authentication and OAuth transaction data expires after the applicable security period; * service, security, and diagnostic records remain for the period needed to operate, secure, and audit the Service; and * payment, dispute, and compliance records remain as required by tax, accounting, fraud-prevention, and other laws. When you delete your profile, NEUS deletes the profile record and revokes associated proofs from NEUS-controlled access where technically possible. We may retain limited records when required by law, needed to protect the Service, or present on a public network that NEUS cannot alter. ## Security NEUS uses administrative, technical, and organizational measures designed to protect personal information. These include: * encrypted network connections; * server-side credentials and protected authentication cookies; * encryption of connected-account tokens and user-provided secrets; * authenticated access to private files and private proof content; * signed service-to-service requests and scoped access controls; * rate limits, abuse controls, security monitoring, and incident logging; and * separation of public and private storage paths. No system can guarantee absolute security. If you believe your account or information is at risk, contact us promptly. ## Your Privacy Rights Depending on where you live, you may have the right to: * access or receive a copy of your personal information; * correct inaccurate information; * delete personal information; * restrict or object to certain processing; * withdraw consent, without affecting earlier lawful processing; * receive portable data; * appeal our response to a request; and * complain to your local data-protection authority. You may update or delete profile information in the Service and disconnect providers from your account. You may also email `info@neus.network`. We may need to verify your account, wallet control, or identity before completing a request. An authorized agent may submit a request where local law permits. We will not discriminate against you for exercising a privacy right. NEUS does not offer an opt-out of sale or targeted advertising because NEUS does not engage in those activities. ## Children The Service is not directed to children under 13, and we do not knowingly collect personal information from a child under 13. If you believe a child has provided personal information to NEUS, contact us so we can investigate and delete it where required. Users must also meet any higher minimum age required by local law or by a connected provider. ## Changes to This Policy We may update this policy when the Service or legal requirements change. We will post the updated policy with a new date. If a change materially affects how we use information already collected, we will provide additional notice and obtain consent where required before using that information for the new purpose. ## Contact For privacy questions or requests: * **Email:** `info@neus.network` * **Mail:** NEUS Network, Inc., 1111B S Governors Ave STE 39950, Dover, DE 19904, USA If applicable, you may also complain to the privacy or data-protection regulator where you live. # Security Disclosure Source: https://docs.neus.network/learn/legal/security-disclosure Responsible disclosure policy for reporting security vulnerabilities. NEUS supports responsible, private vulnerability disclosure. ## Reporting Channel Do not open public issues for undisclosed vulnerabilities. * Primary contact: `dev@neus.network` * Secondary contact: `info@neus.network` * Include affected component, impact, reproduction details, and mitigation suggestions. ## Disclosure Expectations * We acknowledge valid reports and triage based on severity. * We aim to respond to valid reports within 48 hours. * Please provide reasonable remediation time before public disclosure. * Avoid actions that could harm users, infrastructure, or third parties. ## Scope Examples * API authentication and authorization flaws * Signature verification bypasses * Proof visibility/privacy escalation issues * Replay/rate-limit bypasses * Smart-contract and verifier integrity issues ## Out-of-Scope Examples * Social engineering * Denial-of-service traffic without exploit details * Issues requiring physical access to user devices * Vulnerabilities in third-party services outside NEUS control ## Safe Harbor NEUS does not pursue legal action against good-faith researchers who follow this policy, avoid privacy violations, and promptly report findings. # Terms of Use Source: https://docs.neus.network/learn/legal/terms-of-use Terms governing use of NEUS Network APIs, services, and documentation. These Terms of Use ("Terms") govern your use of the NEUS Network APIs, services, documentation, and related tools (collectively, the "Service") provided by NEUS Network, Inc., a Delaware corporation ("NEUS," "we," "us," or "our"). ## 1. Service Provider These Terms constitute a legally binding agreement between you and NEUS Network, Inc. By accessing or using the Service, you agree to be bound by these Terms. ## 2. Service Description NEUS Network provides hosted services for identity, ownership, and permission checks, reusable results, and related developer tools. The Service includes: * Developer tools and integration examples * Software development kits (SDKs) and documentation * API services for checks and result reads * On-chain contracts and related infrastructure where applicable ## 3. No Investment Promises or Financial Rights IMPORTANT: The Service is not an investment product, security, or financial instrument. * Utility Only: Any tokens, NFTs, or digital assets are for utility and access purposes only * No Ownership Rights: Access to the Service does not grant ownership in NEUS Network, Inc. * No Investment Advice: Nothing in the Service constitutes investment or financial advice * No Financial Returns: Use of the Service confers no right to profits, dividends, or financial returns ## 4. Acceptable Use ### Permitted Uses * Contribute to open-source components under applicable licenses * Build tools and applications using our SDKs and APIs * Integrate NEUS APIs and tooling into applications and services * Create verification proofs for legitimate purposes ### Prohibited Uses * Violate intellectual property rights of others * Submit false or misleading verification data * Attempt to circumvent rate limits or security measures * Use the Service for illegal activities or fraud ## 5. Service Availability and Limitations ### No Uptime Guarantees * Blockchain networks may experience delays or failures outside our control * We may suspend or discontinue the Service at any time * The Service is provided "as-is" without warranties of availability ### Rate Limits * Excessive usage may result in temporary or permanent restrictions * API usage is subject to rate limiting and fair use policies ## 6. Privacy and Data Protection * Users authenticate through supported account and session methods. Wallet authentication is optional where applicable. * All data handling is governed by our [Privacy Policy](./privacy-policy) * We collect only essential technical data and user-provided profile data (when users choose to share) * NEUS is designed to minimize data collection and processing ## 7. Intellectual Property ### Our Rights * Trademark "NEUS" is owned by NEUS Network, Inc. * Public NEUS software is licensed under the license included with the applicable repository or package. The current public NEUS reference implementation, SDK, and reference smart contracts are Apache-2.0. CAIP-380 is published separately under CC0. * NEUS Network, Inc. owns all rights to the Service infrastructure ### Your Rights * Your use of open-source components is governed by their respective licenses * You grant us necessary rights to process verification requests * You retain ownership of content you verify through the Service ## 8. Limitation of Liability TO THE MAXIMUM EXTENT PERMITTED BY LAW: * WE ARE NOT LIABLE FOR BLOCKCHAIN NETWORK FAILURES, THIRD-PARTY SERVICE OUTAGES, OR USER ERROR * OUR TOTAL LIABILITY SHALL NOT EXCEED \$100 OR THE AMOUNT YOU PAID FOR THE SERVICE IN THE PRECEDING 12 MONTHS * NEUS NETWORK, INC. SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES ## 9. Indemnification You agree to indemnify and hold harmless NEUS Network, Inc. from any claims, damages, or expenses arising from: * Content you submit for verification * Your violation of any third-party rights * Your violation of these Terms * Your use of the Service ## 10. Governing Law and Disputes ### Governing Law These Terms are governed by the laws of Delaware, without regard to conflict of law principles. ### Dispute Resolution Any disputes shall be resolved through binding arbitration under the rules of the American Arbitration Association in Delaware, except that either party may seek injunctive relief in court for intellectual property violations. ## 11. Changes to Terms We may update these Terms at any time. Continued use of the Service after changes constitutes acceptance of the new Terms. Material changes will be announced through our official communication channels. ## 12. Termination We may terminate or suspend your access to the Service at any time for violation of these Terms or for any other reason. You may discontinue use at any time. ## 13. Refund Policy ### Credit Purchases Credit purchases are final and non-refundable. Credits are consumed upon use for verification operations and cannot be returned. Payment Method: Depending on product flow and availability, payments may be processed via blockchain transactions (for example ETH/USDC) and/or Stripe card checkout. Confirmed on-chain transactions and completed card charges are generally irreversible. Exceptional Circumstances: In exceptional circumstances (e.g., service outages preventing credit usage, duplicate charges due to technical errors), refunds may be considered on a case-by-case basis. Contact `info@neus.network` with your transaction details. Chargebacks: Attempted chargebacks or payment reversals for successfully delivered services may result in service restrictions while the dispute is reviewed. ## 14. Contact Information For questions about these Terms: * Address: NEUS Network, Inc., 1111B S Governors Ave STE 39950, Dover, DE 19904, USA * Email: `info@neus.network` By using the NEUS Network Service, you acknowledge that you have read, understood, and agree to be bound by these Terms of Use. # Proof links and versioning Source: https://docs.neus.network/learn/proof-links Optional patterns for linking portable proofs with typed references and supersedes tags. Use these patterns when an integration needs linked proofs, version history, or tag-based lookup. **Proof ID** in API responses is `qHash`. ## Typed reference: `reference.type: "qhash"` The `ownership-basic` check accepts a `reference` object with `type: "qhash"` and `id` set to another proof's ID. That creates a typed link from one proof to another. ```json theme={"dark"} { "verifierIds": ["ownership-basic"], "data": { "owner": "0x...", "reference": { "type": "qhash", "id": "0xe1a2b3c4d5e6f7081920212232425262728292a2b2c2d2e2f303132333435363", "title": "Agent identity proof" } } } ``` Reference payloads for the same target commonly hash from `qhash:{targetId}` in the signed content. Confirm current behavior in the [ownership-basic](../verification/ownership-basic) capability reference and live API responses. Do not invent proof IDs. ## Version chain: `supersedes:` tag When you update a memory or instruction proof, NEUS can tag the new proof with `supersedes:`. Newer proofs point back to older ones. ```text theme={"dark"} Proof A → supersedes:none Proof B → supersedes:0xA (replaces A) Proof C → supersedes:0xB (replaces B) ``` Use `neus_proofs_get` to walk the chain and read history. ## Tag prefixes for discovery Tag prefixes help you filter related proofs. Common prefixes include subject facets (`topic:`, `domain:`) and review state (`quality:draft` / `quality:approved`). Query tagged proofs with [`neus_proofs_get`](../mcp/proofs-get). To attach an agent profile to a project, see [Connect agent context](../agents/runtime-mount). ## Large content Inline proof content has a size limit (about 50,000 characters). For larger artifacts, store the canonical file elsewhere and attach a short proof that references it (`reference` URL or content hash), or split content across multiple proofs only when your integration explicitly supports that pattern. ## Next How proofs work on NEUS. Check permissions before a tool runs. Query proofs by tag and scope. Check inputs for content and references. # Portable proofs Source: https://docs.neus.network/learn/standards/caip-380 Move a verified result between apps without repeating the check. CAIP-380 is an open [ChainAgnostic](https://standards.chainagnostic.org/CAIPs/caip-380) standard at **Draft** status. NEUS is a reference implementation. This page describes the portable envelope emitted for wallet-signed NEUS verification requests. See [Standards & interoperability](/learn/standards) for how NEUS uses this format with other protocols, and the [whitepaper](/whitepaper#standards-and-interoperability) for the architecture. The CAIP-380 specification text in this document is released under [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/). Reference implementation code, schemas, and fixtures elsewhere in this repository are Apache-2.0. ## Scope of the proposal One wallet-signed envelope; apps validate off-chain; stable **qHash**. * Networks use CAIP-2 (`eip155:1`, `solana:mainnet`, `near:mainnet`, ...) * Account ids use CAIP-10 (`eip155:1:0x...`, `solana:mainnet:...`, `near:mainnet:alice.near`) where an `*AccountId` field is emitted * Stable profile and proof URLs use W3C `did:pkh` (`did:pkh:eip155:1:0x...`) ## Identity and chain glossary | Term | Shape | NEUS usage | | --------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CAIP-2 | `namespace:reference` | Network context. Use `chain` for any non-EVM signing and account identity, for example `solana:mainnet` or `near:mainnet`. | | CAIP-10 | `namespace:reference:account` | Account id fields such as `agentAccountId` and `controllerAccountId`. | | `did:pkh` | `did:pkh:namespace:reference:account` | Stable DID for profiles, proof subjects, and `/u/[did]` URLs. It is derived from the same chain and account context, but is not a bare CAIP-10 string. | | `chainId` | number | EVM-only compatibility field. For signer context it can be omitted by standard EVM integrations because NEUS resolves the hub chain. For asset verifiers, set the verifier-specific `chainId` inside `data`. | Rule of thumb: EVM browser flows can rely on hosted verify or pass an explicit EVM provider. Any non-EVM flow passes the wallet or provider explicitly and includes `chain` as a CAIP-2 value. The envelope is chain-agnostic by design. Any namespace that publishes a CAIP-2 reference and a signing profile can participate. ## NEUS anchor **`qHash`** (0x…) is SHAKE-256 (256-bit) of the canonical subset `did`, `verifierIds`, `data`, `signedTimestamp`, and exactly one of `chainId` or `chain`. Every field inside `data`, including a nonce or timestamp, remains bound to the hash. [Proofs](../../platform/proofs) ## Inputs (conceptual) Account + chain, `verifierIds`, `data` (canonical JSON), `signedTimestamp`, EVM `chainId` or any non-EVM `chain` (CAIP-2). Canonical JSON normalizes strings and keys to NFC, sorts object keys by Unicode code point, preserves array order and `null`, and rejects `undefined`, sparse arrays, non-finite numbers, functions, symbols, and bigint values. An envelope must contain exactly one of `chainId` or `chain`. ## Signer string Six-line UTF-8, LF. The wallet must sign these exact bytes. **`POST /api/v1/verification/standardize`** returns **`signerString`** for raw HTTP and debugging; the SDK **`verify()`** path builds the same message client-side (or use **`standardizeVerificationRequest`** when you need the API round-trip). ```text theme={"dark"} Portable Proof Verification Request Wallet:
Chain: Verifiers: Data: Timestamp: ``` Same as [Signing format](../../verification/signing-format). ## What the envelope proves The wallet signature and `qHash` prove the integrity and signer authorization of the request envelope. They do not, by themselves, prove that a particular verifier ran or that NEUS produced a result. A NEUS portable proof adds verifier results and status around that request anchor. Session-authorized and service-authorized verification can still produce NEUS proofs, but those results are not CAIP-380 envelopes because they do not contain a verified wallet signature. Creation responses use `receipt.format: "caip-380-envelope"` only for qualifying envelopes and `receipt.format: "neus-receipt"` otherwise (legacy response field retained for compatibility). ## Offline verification Keep `portableProof` from the verification creation response. NEUS does not persist the complete request envelope by default. ```javascript theme={"dark"} import { verifyPortableProofEnvelope } from '@neus/sdk'; import envelope from '../../../examples/caip-380/minimal-evm.json' with { type: 'json' }; const result = await verifyPortableProofEnvelope(envelope); if (!result.valid) throw new Error(result.errors.join('; ')); ``` The helper recomputes `qHash`, checks the DID and chain binding, reconstructs the six-line message, and verifies the signature locally. Each chain uses its native signing scheme. EIP-1271 smart accounts require chain state; pass an ethers provider as `options.provider`. Use the [small EVM fixture](https://github.com/neus/network/blob/main/examples/caip-380/minimal-evm.json) for adapter tests. Its timestamp is historical, so `fresh` can be false while its hash and signature remain valid. ## Signing profiles The envelope is chain-agnostic. Any chain with a CAIP-2 namespace and a signing scheme can produce a valid envelope. NEUS ships the profiles below and adds more as ecosystems publish signing specs. | Chain family | CAIP-2 example | Signature | Status | Offline fixture | | ------------ | ---------------- | ----------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | EVM | `eip155:1` | EIP-191 / EIP-1271 / EIP-6492 | Live | [minimal-evm.json](https://github.com/neus/network/blob/main/examples/caip-380/minimal-evm.json) | | Solana | `solana:mainnet` | Ed25519 | Live fixture | [minimal-solana.json](https://github.com/neus/network/blob/main/examples/caip-380/minimal-solana.json) | | NEAR | `near:mainnet` | NEAR `near_sign` (Ed25519) | Profile defined by CAIP-2 namespace | Pending | | Other | Any CAIP-2 | Profile-specific | Add a profile when the ecosystem publishes a signing spec | Pending | To add a profile, extend the SDK verifier with the chain's signature scheme and ship an offline fixture. The `qHash` canonicalization, six-line signer string, and CAIP-2 / CAIP-10 / `did:pkh` binding stay the same across every profile. ## Freshness NEUS rejects a new request if `signedTimestamp` is older than 5 minutes or more than 60 seconds in the future. Historical offline verification reports freshness separately from cryptographic validity. ## Spec and lifecycle [CAIP-380 (ChainAgnostic)](https://standards.chainagnostic.org/CAIPs/caip-380). Status: Draft. NEUS is the reference implementation. CAIP-380 is at Draft status in the official CASA registry. Advancing to Review and Accepted requires at least two independent implementations and editor advancement. See [Standards & interoperability](/learn/standards) and the [whitepaper](/whitepaper#standards-and-interoperability). # Standards & interoperability Source: https://docs.neus.network/learn/standards/index How NEUS works with existing identity, authority, execution, payment, and evidence standards. NEUS is portable trust infrastructure. Keep your sign-in, policy, agent tools, and payments. NEUS adds reusable proofs that those systems can require before access, payment, or action. Wallet-signed checks use the [CAIP-380](/learn/standards/caip-380) format. The [Technical Whitepaper](/whitepaper#standards-and-interoperability) covers the architecture. A signed CAIP-380 request proves who signed and that the request was not changed. A NEUS proof records the check result and whether it is still current. Those are related, not the same. ## How NEUS uses these standards | Standard | What it provides | How NEUS uses it | Status | See | | ----------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CAIP-2 / CAIP-10 | Network and account identifiers | Accounts, agents, and profiles use the same chain and account IDs | Available | [Portable proofs](/learn/standards/caip-380), [Discover agents](/agents/named-agent-card) | | CAIP-380 Portable Proof | A wallet-signed request format with a stable proof ID | Wallet-signed NEUS checks use this format. Other signed-in checks still create NEUS proofs | Draft | [CAIP-380 spec](https://standards.chainagnostic.org/CAIPs/caip-380), [Portable proofs](/learn/standards/caip-380), [Examples](https://github.com/neus/network/tree/main/examples/caip-380) | | MCP | Tools and context for any MCP client | Hosted MCP carries profile, proofs, listings, permissions, and checks before sensitive tools run | Available | [MCP setup](/mcp/setup) | | OAuth / OIDC | Sign-in for people and MCP clients | Hosted MCP and app Connect | Available | [MCP setup](/mcp/setup) | | ACP | Client to a coding harness | Optional self-hosted job pin (OpenCode, Hermes, Claude ACP). Hosted jobs use the Operator engine. NEUS does not spawn ACP on Azure | Works with | [Private Cloud Trust Harness](/cookbook/private-cloud-agents) | | Enterprise Agent SSO | App access for agents with an active user | Keep Okta or your IdP. NEUS records agent limits and runs background jobs those systems do not cover | Works with | [Agents](/agents/overview) | | A2A | Agent discovery cards | Public cards show who the agent is and who approved it | Available | [Platform A2A card](https://neus.network/.well-known/a2a/agent-card.json), [Discover agents](/agents/named-agent-card) | | AuthZEN | A standard way to ask whether an action is allowed | A NEUS proof can be the evidence that decision uses | Works with | [First guarded action](/mcp/guarded-action), [Whitepaper](/whitepaper#standards-and-interoperability) | | AARM | Runtime checks before an agent acts | NEUS checks identity, limits, and current permission before an action, then records the result | Works with | [Agent setup](/agents/agent-verification-flow) | | ATF | Identity, behavior, access limits, and how to stop or revoke | NEUS covers those with identity, permission checks, deny, and revoke | Works with | [Agent setup](/agents/agent-verification-flow), [Proof lifecycle](/verification/lifecycle) | | ERC-8004 | Public agent discovery | NEUS publishes compatible discovery cards and keeps its own proof and permission model | Available | [Platform agent card](https://neus.network/.well-known/agent-card.json), [Discover agents](/agents/named-agent-card) | | x402 | Pay for a single HTTP call | Payment settles the call. NEUS can still require a current proof before the call proceeds | Available | [Pay per call](/platform/x402) | | Phala | Confidential compute | Hosted AI can run in a Phala-backed confidential environment. The same proofs work on a private deploy | Available | [Private Cloud Trust Harness](/cookbook/private-cloud-agents) | NEUS uses these standards. It does not replace them. [CAIP-380](https://standards.chainagnostic.org/CAIPs/caip-380) remains the open specification for the signed request format. ## Check an example Use a signed request from a check, or the published example: ```javascript theme={"dark"} import { verifyPortableProofEnvelope } from '@neus/sdk'; import envelope from '../../../examples/caip-380/minimal-evm.json' with { type: 'json' }; const result = await verifyPortableProofEnvelope(envelope); if (!result.valid) throw new Error(result.errors.join('; ')); ``` This checks the proof ID, account binding, and signature on your machine. Current status still comes from NEUS or another service that stores the result. See [Portable proofs](/learn/standards/caip-380). ## Next How the signed request format works. Architecture and trust model. Check permission before a tool runs. Public agent pages and discovery cards. # Agent Create (`neus_agent_create`) Source: https://docs.neus.network/mcp/agent-create Create or import an agent on your profile. Optional separate spend account and controls. Create or import an agent linked to your NEUS profile. Default is your signed-in account. Add a separate spend account and limits only when you need them. Fastest dedicated key: set **`agentWallet`** to **`"generate"`**. Store the returned key once. NEUS does not keep it. | Step | Action | | ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **`neus_agent_link`** with **`agentId`** and **`agentWallet`** (use the signed-in account from **`neus_context`** unless you already have a dedicated key) | | 2 | **`neus_agent_create`** with the same stable identifiers | | 3 | Follow the returned **`next_action`** exactly | | 4 | **`neus_agent_link`** until **`linked: true`** | Leave out **`controllerWallet`** when the signed-in account from **`neus_context`** should own the agent. Ask: > Create or import an agent on my NEUS profile. Use generate if I need a separate spend account. Set spend and action limits. Then confirm it is ready. [Agent concepts](../agents/concepts) ## Account options ### Signed-in profile (default) Omit **`agentWallet`**. The agent lives on your signed-in account. Identity is enough. Several agents on one account need **`agentId`** on every link and mount call. ### Dedicated key (`generate`) **`agentWallet: "generate"`** creates a separate spend account and returns the private key once. Store it in Vault (`neus_secret_create`) or your own key manager before you continue. ```json theme={"dark"} { "agentId": "data-analyst", "agentWallet": "generate", "delegationAllowedActions": ["read_context", "read_proofs"], "delegationDeniedActions": ["send_message"], "delegationRuntimePolicy": { "requiresHumanApproval": true }, "maxSpend": "15000000" } ``` Use this when you want independent spend, revocation, or offboarding without bringing a key of your own. ### Bring your own account Pass an existing **`agentWallet`**. The agent account signs identity. The approving profile signs spend and action limits. ```json theme={"dark"} { "agentId": "data-analyst", "agentWallet": "0xAgent...", "delegationAllowedActions": ["read_context", "read_proofs"], "delegationDeniedActions": ["send_message"], "delegationRuntimePolicy": { "requiresHumanApproval": true }, "maxSpend": "15000000", "expiresAt": 1798761600000, "returnUrl": "https://app.example.com/agents/callback" } ``` When the signed-in account does not control that key: 1. Sign and submit the returned identity step with the agent key. 2. Repeat **`neus_agent_create`** unchanged. 3. The approving account completes permissions in-session or through the returned hosted URL. A controller session cannot self-attest for a different agent account, so identity always comes first. ## What each result means Every non-validation result includes **`path`** and **`next_action`**. | `path` | Meaning | `next_action` | | ----------------------- | ------------------------------------------------------------- | ----------------------------- | | `already_linked` | Identity and the permissions this account needs already exist | `ready` | | `session_auto_complete` | Signed-in session completed the missing step(s) | `call_neus_agent_link` | | `signatures_required` | A signature is still required | `submit_remaining_signatures` | | `hosted_required` | Browser handoff is required | `open_hosted_verify` | | `payment_required` | The account paying for the current step needs more credits | `complete_billing_then_retry` | **`sessionProgress.identityComplete`**, **`delegationRequired`**, and **`delegationComplete`** show which step is required and already saved. On **`payment_required`**, add credits and retry the same request. This is an account billing requirement, not a signature failure. ## Hosted callback Use the SDK helper instead of assembling query strings: ```javascript theme={"dark"} import { getHostedAgentCreateUrl } from '@neus/sdk'; const url = getHostedAgentCreateUrl({ agentId: 'data-analyst', agentWallet, controllerWallet, identityQHash, // required here because the accounts differ allowedActions: ['read_context', 'read_proofs'], deniedActions: ['send_message'], runtimePolicy: { requiresHumanApproval: true }, returnUrl: 'https://app.example.com/agents/callback', }); ``` With **`identityQHash`**, Hosted Verify requests only permissions. The callback receives the new permission **`qHash`**, **`agentId`**, and **`agentWallet`**. Keep the identity **`qHash`** from step 1. Do not combine agent creation with **`gateId`** or **`intent=login`** on one URL: * Login: **`intent=login&returnUrl=...`** * Gate checkout: **`gateId=...&returnUrl=...`** * Agent setup: **`getHostedAgentCreateUrl(...)`** ## Billing Billing follows the signer for each proof unless a validated sponsor or pay-per-call proof overrides it: * Agent identity: the **agent account** pays. * Permissions (separate spend account only): the **approving profile** pays. * Hosted completion: the signed-in account pays for the step it signs. * Sponsor grant or pay-per-call: the validated sponsor/caller pays. Hosted sign-in itself is free. See [Billing](../platform/billing). Optional fields include **`instructions`**, **`skills`**, **`services`**, scope, expiry, spend cap, runtime policy, approval policy, and allowed/denied actions. See [Agent identity](../agents/agent-identity) and [Agent delegation](../agents/agent-delegation). ## Related [Auth](./auth), [Agent link](./agent-link), [Overview](./overview), [Agent setup](../agents/agent-verification-flow) # Agent readiness (`neus_agent_link`) Source: https://docs.neus.network/mcp/agent-link Confirm the agent is linked to your profile with the identity and permissions it needs. Checks the agent on your profile before agent work. Pass the signed-in account from **`neus_context`**, or the dedicated spend account if you created one. **`linked: true`** means the agent is on your profile. A signed-in-profile agent needs verified identity. A separate spend account also needs signed limits. If a required step is missing, you get **`link_required`**, **`missingVerifiers`**, and a hosted URL for only that step. | State | Meaning | | ------------------- | -------------------------------------------------------- | | **`linked: true`** | Identity and required permissions are on file. Continue. | | **`link_required`** | Open **`hostedVerifyUrl`** or follow **`nextSteps`** | **`agentId`** is optional only when the account identifies one agent unambiguously. Pass it whenever one account hosts several agents. Optional **`principal`** hints the **owner** account (not the agent account). [Agent concepts](../agents/concepts) When you need to create or import first, see [Agent create](./agent-create). ## Input ```json theme={"dark"} { "agentWallet": "0x…", "agentId": "data-analyst" } ``` ## Related [Agent create](./agent-create) and [Agent verification flow](../agents/agent-verification-flow) # MCP auth Source: https://docs.neus.network/mcp/auth Host Connect for interactive MCP clients, access key fallback, and token security. Interactive MCP clients sign in through the host. Register `https://mcp.neus.network/mcp`, click **Connect**, and finish browser sign-in. The host runs OAuth 2.0 with PKCE and can refresh the session for up to 30 days. For servers, CI, and environments that cannot open a browser, use a durable profile access key instead. ## Sign in 1. Register the hosted remote once (plugin, registry listing, or URL-only MCP config). 2. Click **Connect** in the host MCP panel. Optional terminal installer (writes the same URL): ```bash theme={"dark"} npx -y -p @neus/sdk neus setup ``` See [Connect Proofable](./setup). OAuth-capable hosts discover NEUS metadata from the hosted MCP server: ```text theme={"dark"} GET https://mcp.neus.network/.well-known/mcp.json → authorization.resource_metadata_url GET /.well-known/oauth-protected-resource GET /.well-known/oauth-protected-resource/mcp GET https://neus.network/.well-known/oauth-authorization-server → /oauth/authorize (HostedLoginFlow) → Token exchange → Authenticated MCP session (Bearer on protected MCP requests) ``` `tools/list` and `ping` stay public so marketplaces can list tools. Unauthenticated `initialize` and every `tools/call` return `401` + `WWW-Authenticate` so the host shows **Connect**, stores the access token, and sends it on later calls. A GET probe on `/mcp` is not a login challenge. For full OAuth mechanics, see [MCP OAuth](./oauth). ## Access key (fallback) Use a **profile access key** from [Access Keys](https://neus.network/profile?tab=account) when browser OAuth is not available: servers, CI, and automation. ```bash theme={"dark"} neus setup --access-key ``` ## Choose an auth mode | Mode | Best for | | ------------------------ | ---------------------------------------------------------------------------------------- | | **Host Connect (OAuth)** | Interactive clients: browser sign-in, no manual keys, silent refresh for 30 days | | **Access key (`npk_*`)** | Servers, CI, and automation with stable environment variables. Durable and never expires | Both modes send the same `Authorization: Bearer ` header against the same NEUS Profile and Account. `npk_*` keys are long-lived credentials. OAuth sessions are long-lived too. The host refreshes the short-lived access token silently for up to 30 days via the `offline_access` refresh token. Anonymous proof checking and verifier catalog reads stay available through the web UI and the HTTP API. ## Authorization header ```http theme={"dark"} Authorization: Bearer ``` OAuth tokens and access keys both use the `Bearer` scheme. Authenticated MCP sessions should reuse existing proofs before any browser step. See [MCP Overview](./overview) for the reuse-first flow. ## Disconnect ```bash theme={"dark"} neus disconnect --access-key ``` Disconnect revokes OAuth MCP tokens through the OAuth revocation endpoint. For `npk_*` credentials, it revokes the Profile access key through the NEUS API, then removes the local MCP header from configured clients. ## MCP server auth challenge When a client calls a **protected** method without credentials, the server returns: ```http theme={"dark"} HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="https://mcp.neus.network/mcp/.well-known/oauth-protected-resource", scope="neus:core neus:profile neus:secrets" ``` Hosts that support MCP OAuth follow that metadata and open Connect. Stateless streamable HTTP has no GET SSE stream: GET and DELETE on `/mcp` return **405** with no `WWW-Authenticate`. Do not treat a GET probe as a sign-in prompt. ## Interactive verification flows [Hosted Verify](../cookbook/auth-hosted-verify): passkey, wallet, OAuth, and social verification steps run **on NEUS**. If a tool returns **`hostedVerifyUrl`**, open it once, then continue in MCP. ## Security | Topic | Rule | | ----------------- | ------------------------------------------------------------------------------------------------ | | OAuth tokens | Stored by the MCP host, never in query strings | | Access keys | Server or automation configuration only. Never in interactive host `mcp.json` when Connect works | | Browser exposure | Never expose tokens or access keys in browser code | | Rotation | Re-issue access keys from [Access Keys](https://neus.network/profile?tab=account) if exposed | | Refresh tokens | Rotated on each use, old token invalidated | | `hostedVerifyUrl` | Send the user to the returned NEUS hosted flow | # Context (neus_context) Source: https://docs.neus.network/mcp/context Start here for the signed-in profile, available verifiers, and recommended workflow. Call **`neus_context`** once at the start of a Proofable MCP session. It returns setup links, available verifiers, the recommended workflow, and **profile details when the connection is signed in**. After Connect, one call covers the signed-in profile. No separate profile tool. Profile context can include `profileSummary.proofsSummary`: a compact proof summary with totals, verifier counts, and recent proof references. Use **`neus_proofs_get`** for full records or more pages. ## What it returns | Field | Use | | ------------------- | ---------------------------------------------------------------------- | | `setup.mcpEndpoint` | The hosted MCP endpoint in use (`https://mcp.neus.network/mcp`) | | `sessionWallet` | Signed-in account address. Omit `wallet` on later tools when signed in | | `runtimeContract` | Recommended tool order and stopping conditions | | `verifierSummary` | Compact list of available verifiers | | `tools` | Map of available NEUS MCP tools | | `profileSummary` | Signed-in profile context, including `proofsSummary` | When signed in, let account-based tools use the current profile. Ownership proofs finish with **`neus_verify`**. Share a hosted link only when a tool returns one. See [Overview](./overview). Reuse existing proofs first. Use a hosted link only when the next step needs an outside login, payment, or a different account. # Discovery & Endpoints Source: https://docs.neus.network/mcp/endpoints MCP transport, OAuth discovery, hosted verify, and well-known URLs. The **MCP URL** and the **HTTP API** use different transports and base paths. Discovery and the [agent card](https://neus.network/.well-known/agent-card.json) list what your integration needs. ## MCP endpoint | URL | Role | | ------------------------------ | --------------------- | | `https://mcp.neus.network/mcp` | MCP. [Setup](./setup) | ## OAuth discovery | URL | Role | | ------------------------------------------------------------------- | ----------------------------------------------------- | | `https://mcp.neus.network/.well-known/oauth-protected-resource` | Protected resource metadata (RFC 9728 origin) | | `https://mcp.neus.network/.well-known/oauth-protected-resource/mcp` | Protected resource metadata (RFC 9728 path insertion) | | `https://neus.network/.well-known/oauth-authorization-server` | Authorization server metadata (RFC 8414) | ## OAuth endpoints | URL | Role | | --------------------------------------------- | ---------------------------------------- | | `https://neus.network/oauth/authorize` | Authorization endpoint (browser login) | | `https://neus.network/api/v1/auth/mcp/token` | Token endpoint (code exchange + refresh) | | `https://neus.network/api/v1/auth/mcp/revoke` | Token revocation | Full OAuth reference: [MCP OAuth](./oauth). ## Other discovery | URL | Role | | ----------------------------------------------------------- | -------------------------------------------------------------------------------------- | | `https://mcp.neus.network/.well-known/mcp` | MCP discovery (extensionless handshake) | | `https://mcp.neus.network/.well-known/mcp.json` | MCP discovery | | `https://neus.network/.well-known/mcp` | Same discovery card on the product domain (`url` stays `https://mcp.neus.network/mcp`) | | `https://mcp.neus.network/.well-known/mcp/server-card.json` | MCP server card | | `https://mcp.neus.network/.well-known/glama.json` | Glama connector claim | | `https://neus.network/.well-known/a2a/agent-card.json` | Platform A2A agent card. [Docs](../agents/named-agent-card) | | `https://neus.network/.well-known/agent-card.json` | EIP-8004 agent registration | OAuth flow reference. Install and configure. # Run your first guarded action Source: https://docs.neus.network/mcp/guarded-action Load current agent permissions and make one allow or deny decision before a host tool runs. This flow proves that the host can stop a tool call when the current agent permission does not allow it. ## 1. Create a bounded agent After [MCP setup](./setup), ask your assistant: > Create or import an agent named `guarded-demo`. Allow `read_proofs`, deny `send_message`, and require human approval for irreversible actions. The assistant uses `neus_agent_create` and returns the one required setup step when signing is still needed. ## 2. Load current permissions Run this in the project where the host will enforce the decision: ```bash theme={"dark"} npx -y -p @neus/sdk neus mount guarded-demo --apply ``` `` is `cursor`, `claude`, or `codex`. The command writes the current `neus.runtime-mount.v1` bundle to `.neus/mount.json`. ## 3. Evaluate before the tool call ```javascript theme={"dark"} import fs from 'node:fs'; import { evaluateRuntimeAction } from '@neus/sdk/runtime-mount'; const bundle = JSON.parse(fs.readFileSync('.neus/mount.json', 'utf8')); const decision = evaluateRuntimeAction(bundle, 'send_message', { irreversible: true, }); if (!decision.allowed) { throw new Error(`${decision.code}: ${decision.message}`); } await sendMessage(); ``` For the permission above, `send_message` returns: ```json theme={"dark"} { "decision": "denied", "allowed": false, "action": "send_message", "code": "ACTION_DENIED" } ``` `read_proofs` returns `ACTION_ALLOWED`. An expired or missing permission fails closed. An irreversible action returns `HUMAN_APPROVAL_REQUIRED` when the permission requires approval. ## Decision order `evaluateRuntimeAction` applies the mounted permission in this order: 1. Require a valid runtime mount and current permission proof. 2. Apply `deniedActions`. 3. Apply a non-empty `allowedActions` list. 4. Require approval for an irreversible action when configured. 5. Allow the host tool call. The SDK evaluates one action. The host still owns the tool call and must stop when `allowed` is `false`. Runnable source: [`examples/guarded-agent-action`](https://github.com/neus/network/tree/main/examples/guarded-agent-action). # MCP OAuth Source: https://docs.neus.network/mcp/oauth OAuth 2.0 with PKCE for MCP client authentication: discovery, authorization, token exchange, refresh, and revocation. NEUS MCP uses **OAuth 2.0 Authorization Code with PKCE** for MCP clients. The user signs in on NEUS (same passkey/wallet flow as the product). **Default:** add `https://mcp.neus.network/mcp` and click **Connect**. Optional terminal installer: `npx -y -p @neus/sdk neus setup`. Use this page for custom MCP hosts, security review, standalone sign-in, or raw HTTP integration. ## Flow overview ```text theme={"dark"} MCP client discovers NEUS MCP → GET /.well-known/oauth-protected-resource → GET /.well-known/oauth-protected-resource/mcp → GET /.well-known/oauth-authorization-server → GET /oauth/authorize (validates OAuth params; redirects to hosted login if needed) → User authenticates on neus.network (passkey, wallet, or Google/Microsoft) → Browser returns to /oauth/authorize with session; backend issues auth code → Redirect to client callback with code → POST /api/v1/auth/mcp/token (exchange code for access token) → Client uses Bearer token on MCP requests ``` `/oauth/authorize` validates OAuth parameters. Without a session it redirects to `https://neus.network/verify?intent=mcp&returnTo=/oauth/authorize?...`. After login it issues a single-use code (10-minute TTL) and redirects to `redirect_uri`. Repeated identical `resource` values are accepted (RFC 8707). Token exchange and revocation are public OAuth endpoints on `neus.network`. ## Discovery ### Protected resource metadata ```http theme={"dark"} GET https://mcp.neus.network/.well-known/oauth-protected-resource GET https://mcp.neus.network/.well-known/oauth-protected-resource/mcp ``` ```json theme={"dark"} { "resource": "https://mcp.neus.network/mcp", "authorization_servers": ["https://neus.network"], "scopes_supported": [ "neus:core", "neus:profile", "neus:secrets" ], "resource_documentation": "https://docs.neus.network/mcp/overview" } ``` `tools/list` and `ping` stay public for marketplace listing. Unauthenticated `initialize` and every `tools/call` return: ```http theme={"dark"} HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="https://mcp.neus.network/mcp/.well-known/oauth-protected-resource", scope="neus:core neus:profile neus:secrets" ``` ### Authorization server metadata ```http theme={"dark"} GET https://neus.network/.well-known/oauth-authorization-server ``` ```json theme={"dark"} { "issuer": "https://neus.network", "authorization_endpoint": "https://neus.network/oauth/authorize", "token_endpoint": "https://neus.network/api/v1/auth/mcp/token", "revocation_endpoint": "https://neus.network/api/v1/auth/mcp/revoke", "registration_endpoint": "https://neus.network/oauth/register", "response_types_supported": ["code"], "grant_types_supported": ["authorization_code", "refresh_token"], "code_challenge_methods_supported": ["S256"], "token_endpoint_auth_methods_supported": ["none"], "scopes_supported": [ "neus:core", "neus:profile", "neus:secrets", "offline_access" ], "resource_indicators_supported": true, "authorization_response_iss_parameter_supported": true } ``` ## Authorization The example below shows the **NEUS SDK CLI** loopback flow (`neus auth --oauth`). Host MCP clients use the same endpoint with the `client_id` issued to them by DCR and their own loopback `redirect_uri`. Never use `neus-cli` for host clients. ```http theme={"dark"} GET https://neus.network/oauth/authorize ?response_type=code &client_id=neus-cli &redirect_uri=http://127.0.0.1:PORT/callback &code_challenge=BASE64URL(SHA256(code_verifier)) &code_challenge_method=S256 &state=RANDOM_CSRF_VALUE &scope=neus:core neus:profile neus:secrets offline_access &resource=https://mcp.neus.network/mcp ``` | Parameter | Required | Description | | ----------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------- | | `response_type` | Yes | Must be `code` | | `client_id` | Yes | Registered client identifier | | `redirect_uri` | Yes | Must exactly match a registered URI | | `code_challenge` | Yes | PKCE challenge (BASE64URL of SHA-256 of code\_verifier) | | `code_challenge_method` | Yes | Must be `S256` | | `state` | Yes | CSRF protection: returned verbatim | | `scope` | No | Default: `neus:core neus:profile neus:secrets offline_access` | | `resource` | No | Missing defaults to `https://mcp.neus.network/mcp`. Repeated identical canonical values are accepted (RFC 8707). | | `iss` | Returned | The AS returns `iss=https://neus.network` on the callback. Clients MUST validate it matches the expected issuer (RFC 9207). | ## Token exchange ```http theme={"dark"} POST https://neus.network/api/v1/auth/mcp/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code code=AUTH_CODE redirect_uri=http://127.0.0.1:PORT/callback client_id=neus-cli code_verifier=ORIGINAL_CODE_VERIFIER resource=https://mcp.neus.network/mcp ``` Response: ```json theme={"dark"} { "access_token": "eyJ...", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "rt_...", "scope": "neus:core neus:profile neus:secrets" } ``` ## Refresh tokens ```http theme={"dark"} POST https://neus.network/api/v1/auth/mcp/token Content-Type: application/x-www-form-urlencoded grant_type=refresh_token refresh_token=rt_... client_id=neus-cli resource=https://mcp.neus.network/mcp ``` Refresh tokens rotate on each use. Include `offline_access` in the initial scope to receive one. ## Token claims The MCP access token is a JWT: | Claim | Value | Description | | ----------- | ------------------------------ | -------------------------------------------- | | `iss` | `https://neus.network` | Token issuer | | `aud` | `https://mcp.neus.network/mcp` | Resource audience: MCP server validates this | | `sub` | Profile subject ID | Unique user identifier | | `did` | `did:pkh:...` | Decentralized identifier | | `azp` | Client ID | Client that requested the token | | `scope` | Space-separated | Granted scopes | | `token_use` | `mcp_access` | Token type: MCP server rejects other values | | `iat` | Unix seconds | Issued at | | `exp` | Unix seconds | Expires at | OAuth access tokens are valid only when `aud` is `https://mcp.neus.network/mcp`, `iss` is `https://neus.network`, `token_use` is `mcp_access`, and the token is not expired or revoked. ## Scope model | Scope | Description | Default | | ---------------- | ------------------------------------------------------------ | ------- | | `neus:core` | Public protocol tools (context, catalog, public proof reads) | Yes | | `neus:profile` | Signed-in profile context and ownership checks | Yes | | `neus:secrets` | Portable encrypted secrets in Vault | Yes | | `offline_access` | Refresh token so the client can stay signed in | Yes | These four scopes are the complete public permission model. Profile access keys (`npk_*`) are a full-profile server credential. ## Revocation ```http theme={"dark"} POST https://neus.network/api/v1/auth/mcp/revoke Content-Type: application/x-www-form-urlencoded token=eyJ... token_type_hint=access_token client_id=neus-cli ``` Revoking an access token also invalidates all associated refresh tokens. ## Registered clients | `client_id` | Use | | --------------- | ------------------------------------------------------------------------- | | `neus-cli` | NEUS SDK CLI (`neus auth --oauth`): loopback redirect on `127.0.0.1` only | | `neus-mcp-host` | Host MCP clients: issued by DCR for non-loopback flows | Hosted MCP clients use a **URL-only** MCP config. The host discovers OAuth metadata via `/.well-known/oauth-protected-resource`, runs its own Dynamic Client Registration (DCR) against `/oauth/register`, and owns its PKCE + silent-refresh lifecycle. DCR returns `neus-cli` only for the CLI loopback `http://127.0.0.1:/callback`. Every other redirect URI receives `neus-mcp-host`. Do not pin `neus-cli` for host-owned OAuth. The OAuth examples above show `client_id=neus-cli` because they document the CLI loopback path (`neus auth --oauth`). Host clients receive their own `client_id` from DCR and send that instead, plus the same `resource=https://mcp.neus.network/mcp`. ## Security properties | Property | Enforcement | | ----------------------------- | ----------------------------------------------------------------------------- | | PKCE required | `code_challenge_method=S256` is mandatory | | Exact redirect\_uri match | Prevents open redirect attacks | | State parameter preserved | CSRF protection | | Resource indicator required | Prevents token misuse across services | | Issuer validation (RFC 9207) | Client confirms `iss` on auth response matches expected AS; closes IdP mix-up | | Token audience validated | MCP tokens cannot be used for other NEUS services | | Refresh token rotation | Old refresh token invalidated on each use | | Tokens never in query strings | Bearer header only | | Single-use auth codes | Code invalidated after first exchange | | Access key fallback | For servers and automation where browser is unavailable | Keys and headers. Install and configure. Discovery URLs. # Proofable MCP Source: https://docs.neus.network/mcp/overview The portable trust harness for AI. Keep identity, permissions, and context across tools. The portable trust harness for AI. Your agents should not reset when they change models, tools, or marketplaces. Register the hosted remote, then click **Connect**: `https://mcp.neus.network/mcp` Use a marketplace plugin or registry listing when the host offers one. `npx -y -p @neus/sdk neus setup` writes the same URL from a terminal. Then ask: > Reuse what I already have. Before a sensitive action, check my current proofs. Proofable answers **Passed**, **Action needed**, or **Blocked**. ## Do the work Call `neus_context`. Create or import an agent, or publish a listing. > Create or import an agent on my Proofable profile. Use generate if I need a separate spend account. Set spend and action limits. Then confirm it is ready. Open **Connections** on [proofable.me](https://proofable.me) to link apps. [Connections](../cookbook/connector-integrations) To sell: set payouts, then publish a listing. Full steps: [Connect Proofable](./setup). Chat now. Pro jobs run in the background or on a schedule. Cursor, Claude Code, Codex, Hermes, and Grok can connect to this endpoint. **Private cloud.** Point the runtime at the same URL. [Private Cloud Trust Harness](../cookbook/private-cloud-agents). Same install block: [Connect Proofable](./setup). ## Tools Call `neus_context` once. Reuse a current proof before you create another. | Job | Tool | What it does | | -------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------ | | Start | `neus_context` | Signed-in profile, what you can verify, and the recommended flow. Call once. | | List what you can verify | `neus_verifiers_catalog` | Required inputs and supported networks. | | Reuse a proof | `neus_proofs_check` | Read-only. Reports whether a current proof already satisfies the request. | | Finish what's missing | `neus_verify_or_guide` | Reuses a proof, or returns the next step. | | Create or refresh a proof | `neus_verify` | Creates the proof when a new one is needed. Signed-in ownership finishes here. | | Read a proof | `neus_proofs_get` | Current proof records and status. Request the body only when you need it. | | Create or import an agent | `neus_agent_create` | Links the agent to your profile. Optional separate spend account and controls. Use `generate` for a dedicated key. | | Confirm the agent is ready | `neus_agent_link` | Identity and the permissions that account needs. | | Load the agent | `neus_agent_mount` | Identity, permissions, skills, and current settings. | | Store a secret | `neus_secret_create` | Encrypted Vault secret. Confirm the name and proof ID. | | List secrets | `neus_secret_list` | Stored names and details. Never the secret itself. | | Revoke a secret | `neus_secret_revoke` | Removes a stored secret by proof ID. | Field names and per-tool pages: [MCP tools](./tools). ## Privacy Proofable returns the result and the proof. It does not return the private data used to complete it. Proofs are private by default. The client or runtime must enforce that result. What you can reuse across clients: * Your profile and current permissions * Completed checks that are still valid * Proofs another connected product can confirm * Vault context when you allow it To load an agent into a project, see [Connect agent context](../agents/runtime-mount). For a laptop, server, or confidential VM, see [Private Cloud Trust Harness](../cookbook/private-cloud-agents). # Proof reuse (`neus_proofs_check`) Source: https://docs.neus.network/mcp/proofs-check Confirm a current Proof already satisfies the request, without returning records or hosted links. **Yes/no lookup only.** Use this before you verify again or open a hosted handoff. It never creates proofs and never opens hosted flows. Private proofs count only for the signed-in account ([Auth](./auth)). Signed-in owners omit `wallet` and get `{ eligible, matchedCount }` from their own proofs without paying. Public third-party lookups may return `payment_required`. If **`eligible`** is true, continue. If false, use **`neus_proofs_get`** when you need exact state, or **`neus_verify_or_guide`**. When signed in, ownership proofs continue with **`neus_verify`**. ## Input Uses **`wallet`** (not `walletAddress`): ```json theme={"dark"} { "wallet": "0x...", "verifiers": ["ownership-basic"], "requireAll": true } ``` Optional `minCount` requires at least N matching verifiers instead of all-or-any. Optional `gateId` scopes a hosted listing. Optional `handle` and `namespace` filter handle-based verifiers. Omit `wallet` when signed in to use your profile wallet. ## Output `eligible`, `matchedCount`, `success`. # Read proofs (`neus_proofs_get`) Source: https://docs.neus.network/mcp/proofs-get Filtered proof records, tags, status, and optional content for a wallet or DID. Use when you have an **`identifier`** and need proof records, fields, tags, or delegated context. In the reuse-first flow, call this after **`neus_proofs_check`** when you need details beyond yes/no eligibility. Profile totals and account context come from **`neus_context`**. In user-facing replies, summarize the result in plain language and link only real proof URLs returned by NEUS. | Auth | Visibility | | ------ | ---------------------------------------------------------------- | | None | Public-scope view | | Bearer | Can include **private** proofs for that account ([Auth](./auth)) | ## Common Reads | Need | Use | | ------------------------ | ---------------------------------------------------------- | | Show prior proofs | Read recent proofs for the account | | Reuse assistant context | Filter by tags such as `memory`, `rules`, or `instruction` | | Confirm an agent handoff | Include `agentWallet` for delegated reads | | Continue a session | Filter by the tags your app saved on earlier proofs | Keep tag values short and product-facing in your own app. Avoid exposing private workflow names in assistant replies. ## Input ```json theme={"dark"} { "identifier": "0x...", "limit": 25, "offset": 0, "tags": "memory,rules,instruction", "agentWallet": "0x...", "include": "metadata" } ``` | Field | Notes | | ------------- | ------------------------------------------------------------------------------------ | | `identifier` | Wallet address or **`did:pkh:...`** | | `tags` | Comma-separated proof tag filter | | `agentWallet` | Delegation (**`x-agent-wallet`**) | | `include` | `metadata` for the minimal index; `content` only when full proof bodies are required | | `qHash` | When set, returns that one record instead of a vault page | When `identifier` is a DID, NEUS resolves the DID to its native account. Non-EVM signing and account context still use CAIP-2 `chain`; see [CAIP-380 Portable Proof](../learn/standards/caip-380). ## Response `include: "metadata"` returns a compact paginated proof index: proof id, status, check ids and outcomes, title, tags, timestamps, and content length when known. It does not include proof bodies, profile summary, or agent context. Use `include: "content"` for a specific proof or tightly filtered page when the body is required. Use the paginated `proofs` list for history and the profile summary from `neus_context` for aggregate totals. Never infer a total or absence from one page. ## Assistant Output Do: ```txt theme={"dark"} NEUS: Passed. Requirement satisfied. Result on file. Next: Continue. ``` Avoid raw JSON, private implementation tags, or guessed proof URLs. ## Next Confirm existing proofs before creating new ones. Install, session flow, and tool map. # Encrypted secrets Source: https://docs.neus.network/mcp/secrets Store, list, and revoke portable encrypted secrets through MCP. Three public MCP tools manage **encrypted secrets** tied to your NEUS Profile. Values are sealed with AES-256-GCM and **never returned in plaintext** through MCP. Sign in first with OAuth or a Profile access key ([Auth](./auth)). Use the signed-in profile context from **`neus_context`** before create or revoke. | Tool | Purpose | | ------------------------ | ---------------------------------------------------- | | **`neus_secret_create`** | Store a named secret as an encrypted proof | | **`neus_secret_list`** | List secret metadata (alias, qHash, type). No values | | **`neus_secret_revoke`** | Revoke a secret proof by qHash | When signed in, **omit `walletAddress`**. Secrets bind to your profile account from `neus_context`. ## Create (`neus_secret_create`) ```json theme={"dark"} { "alias": "OPENAI_API_KEY", "secretType": "single", "content": "" } ``` | Field | Notes | | --------------- | ---------------------------------------------------------------------------- | | `walletAddress` | Optional when signed in; must match the authenticated profile account if set | | `alias` | Letters, numbers, underscore; must start with a letter | | `secretType` | `single` (default) or `bundle` (JSON object string in `content`) | | `content` | Plaintext input. Encrypted at rest; never echoed back via MCP | ## List (`neus_secret_list`) ```json theme={"dark"} { "limit": 50, "offset": 0 } ``` Without Bearer auth, the tool returns an empty list and `authRequired: true`. It does not leak metadata. ## Revoke (`neus_secret_revoke`) ```json theme={"dark"} { "qHash": "..." } ``` Requires authenticated ownership of the secret proof. Omit `walletAddress` when signed in. ## Security * Never paste secret values into chat logs or public issues. * Prefer OAuth or Profile keys in MCP config only. Do not use them in app browser bundles. * Rotate or revoke through **`neus_secret_revoke`** and re-create if a value is exposed. How MCP sessions authenticate. Profile lookup and refresh. # Connect Proofable Source: https://docs.neus.network/mcp/setup Install Proofable in any editor, chat, or agent host. Click Connect and sign in. Proofable MCP is the hosted connection for every MCP client: chat, IDEs, jobs, and agent runtimes. Same profile, proofs, listings, permissions, and private context. Not a developer-only add-on. ## Install (one minute) 1. Open [proofable.me/install](https://proofable.me/install), or add `https://mcp.neus.network/mcp` in your editor, chat, or agent. 2. Click **Connect**. Sign in in the browser. 3. Ask for your profile and current proofs. Proofable answers **Passed**, **Action needed**, or **Blocked**. If the host already offers a Proofable plugin, install that. Have the CLI? ```bash theme={"dark"} neus setup ``` ## Any host Paste this URL in the host’s MCP settings: `https://mcp.neus.network/mcp` ```json theme={"dark"} { "mcpServers": { "neus": { "url": "https://mcp.neus.network/mcp" } } } ``` If the host requires the spec `type` field: ```json theme={"dark"} { "mcpServers": { "neus": { "type": "http", "url": "https://mcp.neus.network/mcp" } } } ``` ## Paste this prompt ```text theme={"dark"} # Proofable connect Connect this host to Proofable. MCP is how I use Proofable from any chat, IDE, or job runtime: profile, proofs, listings, permissions, and private context. 1. Install Proofable on this host (plugin, install page, or https://mcp.neus.network/mcp). Do not add a second neus entry. 2. Tell me to click Connect if sign-in is not done. 3. Call neus_context once. Reuse existing proofs before a new check. Before spend, publish, secrets, or a sensitive tool, check proofs first. Summarize as Proofable: Passed, Action needed, or Blocked. 4. If I want to sell: open payouts at https://proofable.me/profile?tab=treasury, then create a listing at https://proofable.me/profile/portals/new. Walk me through type, what to verify, price, and Listed. Do not invent proof IDs or verifier IDs. 5. If I need an agent, create or import it on my signed-in profile. Use generate only for a dedicated spend key. Canonical endpoint: https://mcp.neus.network/mcp Docs: https://docs.neus.network/mcp/setup ``` ## After Connect ### Check the connection Ask: > Reuse what I already have. Before a sensitive action, check my current proofs. Read a known proof with **`neus_proofs_get`**. Create or import an agent when you need one: ```text theme={"dark"} Create or import an agent on my NEUS profile. Use generate if I need a separate spend account. Set spend and action limits. Then confirm it is ready. ``` That uses **`neus_agent_create`**. Default is your signed-in account. Use **`generate`** only for a dedicated spend key. Confirm with **`neus_agent_link`**. Open **Connections** on [proofable.me](https://proofable.me) to link apps. [Connections](../cookbook/connector-integrations) Cursor, Claude Code, Codex, Hermes, and Grok use the same endpoint. Optional project mount: ```bash theme={"dark"} npx -y -p @neus/sdk neus mount --apply cursor ``` Valid `--apply` values: `cursor`, `claude`, `codex`. See [Connect agent context](../agents/runtime-mount). ### List and sell 1. **Payouts** (paid listings): [Treasury](https://proofable.me/profile?tab=treasury) → Set up payouts. 2. **New listing:** [Create listing](https://proofable.me/profile/portals/new). 3. Pick the type (AI service, skill, digital product, and the other live types). 4. Add what buyers must verify. Set a price or keep it free. Discovery: **Listed**. 5. Share the listing link. Job placeholders become buyer inputs. Buyers connect apps at checkout. Embed a gate in your own app: [Sell access](../quickstart). ## From a terminal Optional if you have the CLI. Writes the same hosted URL and the public workflow skill: ```bash theme={"dark"} neus setup ``` If you use npm and do not have the CLI on your PATH: ```bash theme={"dark"} npx -y -p @neus/sdk neus setup ``` If a Proofable plugin is already installed, setup skips a second `neus` entry. ## Advanced: access keys Use Connect for interactive clients. Use a [profile access key](https://proofable.me/profile?tab=account) only when browser sign-in is unavailable, such as a server or CI job. ```bash theme={"dark"} export NEUS_ACCESS_KEY=npk_... neus setup ``` Treat the key like a password. Never paste it into chat or commit it to a repository. ## Disconnect ```bash theme={"dark"} neus disconnect --access-key ``` ## Troubleshooting * **No tools appear:** restart the MCP client after the endpoint is registered. * **No Connect, or Unauthorized with Logout visible:** click **Logout**, then **Connect**. * **Host has no Connect:** use the host’s own MCP login after the endpoint is registered. * **Two neus servers:** a marketplace plugin and a user MCP config both registered NEUS. Remove the extra `neus` key from the host MCP config. If you used the CLI, run `neus setup` again to drop the leftover user entry. * **Confirm the connection:** `neus doctor --live` (Node). * **Agent permission missing:** create or refresh the agent permission on Proofable, then run `neus mount` again. * **Search-only endpoint:** use `https://mcp.neus.network/mcp`. `https://docs.neus.network/mcp` only searches documentation. [MCP overview](./overview) lists the twelve tools. For a laptop, server, or confidential VM, see [Private Cloud Trust Harness](../cookbook/private-cloud-agents). # MCP tools Source: https://docs.neus.network/mcp/tools Reuse a current proof before you create another. Call **`neus_context`** once, then pick the tool for the job. | Job | Tool | What it does | | -------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------ | | Start | `neus_context` | Signed-in profile, what you can verify, and the recommended flow. | | List what you can verify | `neus_verifiers_catalog` | Required inputs and supported networks. | | Reuse a proof | `neus_proofs_check` | Read-only. Reports whether a current proof already satisfies the request. | | Finish what's missing | `neus_verify_or_guide` | Reuses a proof, or returns the next step. | | Create or refresh a proof | `neus_verify` | Creates the proof when a new one is needed. | | Read a proof | `neus_proofs_get` | Current proof records and status. | | Create or import an agent | `neus_agent_create` | Links the agent to your profile. Optional separate spend account and controls. Use `generate` for a dedicated key. | | Confirm the agent is ready | `neus_agent_link` | Identity and the permissions that account needs. | | Load the agent | `neus_agent_mount` | Identity, permissions, skills, and current settings. | | Store a secret | `neus_secret_create` | Encrypted Vault secret. | | List secrets | `neus_secret_list` | Stored names and details. Never the secret itself. | | Revoke a secret | `neus_secret_revoke` | Removes a stored secret by proof ID. | | Topic | Detail | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Session context | Call **`neus_context`** first. After Connect it includes the signed-in profile. | | Create in-session | **`neus_verify`** when signed in and ownership can finish here. | | Interactive | **`neus_verify_or_guide`** reuses a proof, then continues with **`neus_verify`** or returns a hosted link for an outside login, payment, or different account. | ## Field names | Tool | Address field | Verifiers / filters | | ------------------------------------- | --------------- | -------------------------------------------- | | `neus_proofs_check` | `wallet` | `verifiers` | | `neus_verify`, `neus_verify_or_guide` | `walletAddress` | `verifierIds` | | `neus_proofs_get` | `identifier` | optional `tags` (comma-separated proof tags) | Wallet address in native format, or `did:pkh:…`. Delegated reads: **`agentWallet`** on **`neus_proofs_get`** (**`x-agent-wallet`** on the API). ## Order | Phase | Calls | | ------------- | --------------------------------------------------------------------------------------------------------------------------- | | Default | Connect → **`neus_context`** → **`neus_agent_link`** for agents → **`neus_proofs_check`** → continue if satisfied | | Project agent | **`neus_agent_mount`** or `neus mount --apply ` in the repo | | Details | **`neus_proofs_get`** for proof records, tags, delegated context, and proof fields | | Secrets | **`neus_secret_list`** / **`neus_secret_create`** / **`neus_secret_revoke`** when auth is configured ([Secrets](./secrets)) | | Fallback | **`neus_verify_or_guide`** only when something is missing | | Catalog | **`neus_verifiers_catalog`** only when you need raw schemas beyond the compact `verifierSummary` in `neus_context` | Same flow as [Overview](./overview). ## Reference pages Load profile, proofs, and workflow once per session. Live verifier schemas and required inputs. Reuse existing proofs before verifying. Create a proof in-session when possible. Reuse a proof or return the next step. Read proof records and current status. Create or import an agent. Optional separate spend account. Confirm an agent is ready to act. Load identity, permissions, and skills into a project. Store and revoke encrypted Vault secrets. # MCP verifier catalog Source: https://docs.neus.network/mcp/verifiers-catalog List what you can verify and what each one needs. | Situation | Tool | | ---------------------------------- | ------------------ | | Typical integration | **`neus_context`** | | Complete verifier list and schemas | This tool | ## Input ```json theme={"dark"} {} ``` ## Output An array of live verifier **IDs** (strings), e.g. `["ownership-basic", "proof-of-human", ...]`. Use it to confirm which verifiers exist before building a request. For input fields and schemas per verifier, see the [Verifiers](../verification/verifiers) pages and the JSON schemas in [`docs/verifiers/schemas/`](https://github.com/neus/network/tree/main/docs/verifiers/schemas), or call `GET /api/v1/verification/verifiers` for the full metadata response. # Create proof (`neus_verify`) Source: https://docs.neus.network/mcp/verify Create a saved proof from inside an MCP session. Use **`neus_verify`** to create a proof when the signed-in account can complete the check in-session. Ownership checks finish here. Share a hosted link only when this tool returns one. For an outside login, payment, or a different account, use **[`neus_verify_or_guide`](./verify-or-guide)**. Always run **`neus_proofs_check`** first and reuse an existing proof before creating a new one. When signed in, **omit `walletAddress`**. The tool uses your profile account from `neus_context`. For `ownership-basic`, omit `owner`. The signed-in account is filled in. ## Input | Field | Required | Notes | | ---------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `verifierIds` | Yes | One or more check IDs | | `walletAddress` | No | Omit when signed in; required only when acting for another account | | `data` | No | Check inputs (see each [check](../verification/verifiers)) | | `chain` | No | CAIP-2 chain when needed | | `signature` | No | Provided in the finalize step | | `signedTimestamp` | No | Provided in the finalize step | | `options.returnUrl` | No | Where to send the user if a hosted step is needed | | `options.publishToHub` | No | Record the proof on the hub chain. Offchain by default. Does not change who can see the proof. | ```json theme={"dark"} { "verifierIds": ["ownership-basic"], "data": { "content": "Hello NEUS" } } ``` Signed-in sessions do not send `signature` or `signedTimestamp`. Those fields exist only when the session cannot authorize the account. ## Output A plain-language **Passed**, **Action needed**, or **Blocked** result. On success, the tool also returns the proof ID in `qHash` for your server. A hosted link appears only when the check needs an outside step. # Reuse or verify (`neus_verify_or_guide`) Source: https://docs.neus.network/mcp/verify-or-guide Reuse a saved Proof, or return the next step. **Default reuse-or-verify tool.** Looks up existing proofs first. When signed in, ownership proofs continue with **`neus_verify`**. A hosted link is returned only for outside login, payment, or a different account. When signed in, **omit `walletAddress`** to use your profile wallet from `neus_context`. ## What it does 1. Looks up existing proofs for the required verifiers 2. If satisfied → `already_verified` (continue silently) 3. If not, and signed in for an instant verifier → `next_action: call_neus_verify` (no hosted link) 4. If not, and an outside step is required → one hosted link Summarize the outcome for users as **Passed**, **Action needed**, or **Blocked**. Do not ask the user to open a browser unless this tool returned a hosted link. ## Input `verifierIds` (required). Optional `walletAddress` when not signed in, `requireAll`, `chain`, `data`, and `options.returnUrl` (where to send the user after a hosted step). ```json theme={"dark"} { "verifierIds": ["ownership-basic"] } ``` ## Output `action` (`already_verified` | `verification_required`), `eligible`, `next_action`. `hostedVerifyUrl` only when a browser step is required. After hosted completion, read proof state with **`neus_proofs_get`**. Journeys: [MCP journeys](./journeys) # Billing Source: https://docs.neus.network/platform/billing Who pays for checks, gate checkout, and metered API calls. Checks cost credits. Your credits spend first. Visitors only pay when you turn on visitor checkout. [Pricing](./pricing) has the amounts and the live estimator. Sign-in never costs credits. Credits apply when a check runs, a result is saved, or hosted AI is used. ## How money moves on NEUS Three lanes cover every flow. Most products only use the first. | Lane | Who pays | Use it for | | --------------------------------- | ------------------ | ---------------------------------------------------------------------------------- | | **You pay for checks** | Your NEUS credits | Default. Checks through your gate bill your account | | **Charge visitors at a gate** | Your visitor | Paid content and member access. Card or USDC at [checkout](./hosted-gate-checkout) | | **Charge per API call (metered)** | The caller / agent | Metered APIs and agents that [pay as they go](./x402) (`x402`) | ## Default: you pay for visitor checks When you publish a gate, you own it, so checks through that gate bill **your** NEUS account by default. Visitors embed or link your checkout with one public `gateId`: ```jsx theme={"dark"} ``` There is no app ID or billing wallet to copy for this path. The gate carries the check policy and the payer. ## Server checks Confirm eligibility before you grant access with **`gateCheck`**. Pass the same `gateId` and the visitor's **account address** (from NEUS sign-in or the saved result): ```javascript theme={"dark"} const result = await client.gateCheck({ gateId: 'gate_your-app-name', address: user.accountAddress, }); if (result.data?.gate?.allRequiredSatisfied !== true) { // Send the visitor back to NEUS sign-in } ``` ## Charge visitors instead A gate can charge visitors directly. Turn it on in the gate's pricing step. **Card:** connect a payout account once from **Profile → Payouts**. Card payments for your paid gates then settle to that account. **USDC checkout (optional):** for products that already support stablecoin payers. Not required for account-based products. Until payouts are connected, paid gates offer USDC checkout only. Payment runs after verification by default. For the full checkout sequence, see [Hosted Gate Checkout](./hosted-gate-checkout). ## When your app creates agents for users Agent setup creates two separately signed proofs. Billing follows the signer for each step unless a validated sponsor or pay-per-call proof is present. | Step | Default payer | | ------------------------------------------ | ---------------------------- | | Agent signs `agent-identity` | Agent account | | Signed-in account signs `agent-delegation` | Signed-in approving account | | Server signs with its own profile | Builder profile account | | Valid sponsor grant | Sponsoring organization | | Valid pay-per-call proof | Caller that bought the proof | For a dedicated agent account, create identity first, then send the user through the delegation-only hosted callback. See [`neus_agent_create`](../mcp/agent-create). ## When credits run out Billable calls return **402** with a quote. Pay per call with x402 (no account needed; see [x402](./x402)) or complete payment and retry with `PAYMENT-SIGNATURE`. ## Advanced server integration Server-side proof creation and per-user approvals use separate flows. See [Integrations](../cookbook/integrations). **Next:** [Pricing](./pricing) and [x402](./x402) # Gate checkout Source: https://docs.neus.network/platform/hosted-gate-checkout Sell access, verify visitors, collect payment, and deliver content. A published listing is a reusable checkout: visitors complete the verifiers you configured, optionally pay, and receive the reward you attached. This page documents the full server contract behind hosted checkout so you can mirror it from your own app or backend. The simplest integrations do not need any of this directly. Use the [VerifyGate widget](../widgets/verifygate) or the hosted checkout link. Read on when you want to drive the flow yourself. ## Which API host? | Caller | Gate snapshot | Fulfill | | ---------------------------- | ------------------------------------ | --------------------------------------------- | | **SDK** (`NeusClient`) | `client.getGate(gateId)` | `client.fulfillGate(...)` | | **`api.neus.network`** | `GET /api/v1/profile/gates/{gateId}` | `POST /api/v1/profile/gates/{gateId}/fulfill` | | **`neus.network` (browser)** | `GET /api/v1/gates/{gateId}` | `POST /api/v1/gates/{gateId}/fulfill` | Prefer the SDK on your server. The `neus.network` paths are the same contract, proxied for same-origin browser calls. ## Lifecycle 1. **Snapshot**: load the public gate: requirements, price, schedule, and reward presence (not the secret reward value). Use `client.getGate(gateId)` or `GET /api/v1/profile/gates/{gateId}` on `api.neus.network`. 2. **Eligibility**: `GET /api/v1/proofs/check?gateId=...&address=...&includePrivate=true&includeQHashes=true` evaluates the visitor's existing proofs against every requirement. 3. **Verify**: if proofs are missing, the visitor completes them (hosted verify link, VerifyGate, or `POST /api/v1/verification` for signature-based verifiers). Pass `gateId` and reuse satisfied proofs via `options.reusedVerifierProofs`. 4. **Pay**: for paid gates, payment happens after verification by default (`executionOrder: "verifyThenCharge"`). Gates with a connected payout account settle through one Stripe checkout session. The visitor picks card or crypto there. Gates with a custom wallet settle by direct USDC on Base. 5. **Fulfill**: deliver the reward with the verified `qHash` (plus payment evidence for paid gates) via `client.fulfillGate(...)` or `POST /api/v1/gates/{gateId}/fulfill`. If the snapshot includes `requestedAccess`, also send the buyer-approved `accessGrant` (connected account + selected resource). Hosted checkout stamps that grant on the receipt. A configured return URL receives `grant` and `receipt` set to the same proof ID. The listing owner then calls `POST /api/v1/proofs/composio/execute` with `grant` set to that proof ID. NEUS runs the tool as the buyer and never returns the buyer’s credential. Missing, revoked, or out-of-scope grants return `403`. ```js theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient(); // 1. Snapshot const gate = await client.getGate('gate_your-listing'); // 2. Eligibility const check = await client.gateCheck({ gateId: 'gate_your-listing', address: visitorWallet, includePrivate: true, includeQHashes: true, }); // 5. Fulfill (after verify + pay) const reward = await client.fulfillGate({ gateId: 'gate_your-listing', qHash: verifiedQHash, walletAddress: visitorWallet, }); ``` ## Reading the gate check When `gateId` is passed, the response carries a per-requirement `data.gate` block. **`gate.allRequiredSatisfied === true` is the only signal that checkout is ready.** Top-level `eligible` and `matchedCount` exist for criteria-only checks and must not be used as gate readiness on their own. ```json theme={"dark"} { "success": true, "data": { "eligible": true, "gate": { "gateId": "gate_your-listing", "allRequiredSatisfied": true, "satisfiedVerifierIds": ["proof-of-human", "wallet-risk"], "missingVerifierIds": [], "reusedVerifierProofs": { "proof-of-human": "0xabc…", "wallet-risk": "0xdef…" } } } } ``` * `satisfiedVerifierIds` / `missingVerifierIds`: which requirements existing proofs cover. * `reusedVerifierProofs`: verifierId → qHash map (requires `includeQHashes=true`). Pass it as `options.reusedVerifierProofs` on `POST /api/v1/verification` so satisfied checks are not re-run. * Re-run the gate check after every interactive step (OAuth grant, personhood session) before treating checkout as complete. Interactive completions only count once the protocol confirms them here. ## Request-time vs proof-based rules Each requirement carries `match` rows (`{ path, op, value }`). They are enforced at two different moments: | Rule type | Examples | Enforced | | -------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | Request-time (`eq` on input fields) | `domain`, `contractAddress`, `chainId`, `minBalance`, `provider` | When the verification request is submitted. The locked value must match exactly | | Proof-based (`traits.*`, `claims.*`, risk fields, `gte`/`lte`) | `claims.age_min`, `claims.liveness_verified`, `riskLevel`, `overallRisk` | After verification, against the check result | Proof-based rows mean an existing proof may not satisfy a stricter gate. For example, a personhood proof created for a basic gate will not satisfy another gate that also requires `claims.age_min ≥ 21`. The visitor must complete the additional check. For `wallet-risk` gates, any proof-based row also requires `policyVerified` to be true. A failed risk check never satisfies a gate. ### Verification links In the gate builder, choose **Verification link**. The visitor pastes their own HTTPS URL; NEUS reads JSON from that URL or its conventional `.json` form and checks whether `verified` is `true`. Builders do not configure fetch targets, callbacks, or provider-specific connectors. The saved gate contains the portable match rows `reference.type = url` and `resolved.verified = true`. API clients can use other `resolved.*` output matches when a source exposes a different public JSON contract. Resolved-link proofs default to five-minute freshness so checkout does not silently reuse old source status. See [Content ownership](../verification/ownership-basic#verification-links-in-hosted-gates) for the wire shape and resolver safeguards. ## Paid gates The snapshot's `monetization.charge` describes pricing: * `amountUsd`, `label`, `methods` (`usdc`, `stripe`), `cardPayoutReady` * `executionOrder`: `verifyThenCharge` (default): verification completes first, then payment, then fulfill. Method semantics: * `stripe`: hosted Stripe Checkout (card). Available when the gate has a connected payout account. * `usdc`: direct on-chain USDC transfer on Base. The only method for custom-wallet payout gates. Fulfill payment evidence: * **Stripe**: `paymentCheckoutSessionId` from the checkout return. * **USDC**: `paymentTxHash` of the on-chain transfer. Payments are bound to one `gateId` + `qHash` pair and cannot be reused for another checkout (`409 PAYMENT_ALREADY_USED`). ## Fulfillment result ```json theme={"dark"} { "success": true, "data": { "gateId": "gate_your-listing", "qHash": "0xabc…", "fulfillment": { "delivery": "redirect", "type": "redirect_url", "value": "https://yourapp.com/members" } } } ``` `fulfillment.delivery` is one of `access_granted`, `redirect`, `download`, or `reveal`. The secret value appears only here, after verification (and payment) succeeded for the caller's wallet. ## Campaign windows Gates may carry a `schedule` (`startsAt` / `endsAt`). Outside the window, gate checks report the closed state and verification/fulfillment are refused server-side (`GATE_NOT_STARTED`, `GATE_ENDED`). Treat the window as enforced. It is not a UI-only hint. ## Next Drop-in checkout for published gates Plans and credits How verification and checkout charges work Full HTTP API surface Every check a gate can require # LLM and agent docs Source: https://docs.neus.network/platform/llm-docs Machine-readable entry points, MCP setup, and the shortest reading order. Start with the smallest source that answers the task. Use the text export for model context and the linked reference page for exact fields. ## Read first 1. [Home](/) — hosted MCP endpoint, then Connect 2. [Connect Proofable](../mcp/setup) — chat, IDEs, jobs, listings, and proofs 3. [Agent setup](../agents/agent-verification-flow) to set identity and permissions 4. [MCP tools](../mcp/tools) for exact tool behavior 5. [Trust](../verification/overview) for checks and reusable proofs 6. [Standards & interoperability](../learn/standards) for how NEUS uses existing protocols ## MCP **Product server:** `https://mcp.neus.network/mcp` for profile, proofs, listings, permissions, agents, and private context.\ **Not the product:** `https://docs.neus.network/mcp` for documentation search only (Mintlify). 1. Register `https://mcp.neus.network/mcp` in the host (marketplace, registry, or URL-only config). 2. Click **Connect** in the host. 3. Follow [Connect Proofable](../mcp/setup) and the [MCP workflow](../mcp/overview). Reuse proofs before you verify again. Profile access keys (`npk_*`) are for servers and CI only. ## Rules * **Browser → NEUS:** SDK (`NeusClient`, widgets) or **Hosted Verify**. Do not call `api.neus.network` from the browser with secrets or ad-hoc headers; use a **server proxy** when you need custom server-side calls. * **Server → NEUS:** `gateCheck`, eligibility, secrets, raw HTTP. [API overview](../api/overview) * Profiles, agents, listings, gates, and proofs: [Ecosystem](../platform/overview) * Default hosted sign-in: [Hosted Verify](../cookbook/auth-hosted-verify). Optional in-app signing: [Signing format](../verification/signing-format) * Do not use wallet **private keys** as MCP credentials. Sign in with **OAuth** or use **Profile access keys** (`npk_*`) for Bearer in MCP or server config only. * **402:** use the x402 retry pattern * Agents: [Overview](../agents/overview), [Agent setup](../agents/agent-verification-flow), [Discover agents](../agents/named-agent-card) * Use returned proof URLs or qHashes only when the API/tool response provides them. ## Exports ```bash theme={"dark"} # Page index for discovery curl https://docs.neus.network/llms.txt # Full documentation context curl https://docs.neus.network/llms-full.txt ``` ## MCP JSON Hosts that omit the spec `type` field (including Cursor) use a URL-only entry inside `mcpServers` and discover OAuth from the server's 401 challenge: ```json theme={"dark"} { "mcpServers": { "neus": { "url": "https://mcp.neus.network/mcp" } } } ``` Hosts that require the spec `type` field use `type: "http"`: ```json theme={"dark"} { "mcpServers": { "neus": { "type": "http", "url": "https://mcp.neus.network/mcp" } } } ``` Jump to [MCP overview](../mcp/overview), [MCP setup](../mcp/setup), or the [HTTP API](../api/overview) when you need detail beyond this reading order. # Platform Source: https://docs.neus.network/platform/overview Manage profiles, Connections, proofs, agents, listings, and integration paths. Create proofs, manage them in a profile, require them at product gates, sell qualified access, or use them with AI agents. ## Use Proofable Identity, proofs, and agents in one profile. Link apps in Connections. Create or import an agent. Set what it may do. Set the checks and the price. Share one link. Review, share, and revoke completed checks. ## Build on NEUS Hosted sign-in and check flow. Choose checks, set price, copy embed. Gate and require current proof before access. Store a proof ID, read current status. # Pricing Source: https://docs.neus.network/platform/pricing Free tier, Pro credits, or charge visitors at the gate. Credits pay for checks and saved results. Sign-in is always free. Credits apply when a check runs or a result is saved. ## Plans | Plan | Price | Credits / mo | API throughput | Start | | -------------- | ------------------------- | ------------ | ---------------------- | -------------------------------------------------------------- | | **Basic** | Free | 500 | 60 / min burst | [Start free](https://neus.network/verify?intent=login) | | **Pro** | $19.99 / mo, $199.90 / yr | 10,000 | 240 / min burst | [Start Pro](https://neus.network/profile?tab=credits) | | **Enterprise** | Custom | 500,000+ | 600 / min burst + SLAs | [Contact sales](https://neus.network/contact?topic=Enterprise) | **Pro adds:** hosted jobs in the background or on a schedule with connected apps, the agent workspace, advanced hosted models, more monthly credits, and priority support. Published listings can collect payment after required checks pass. Enterprise adds custom credit packages, rollout support, security review, and flexible billing. Full per-tier limits: [Rate limits](./rate-limits-and-retries). ## How credits map to cost One credit has a list price of **\$0.0025**. Each action uses a different number of credits: * **Check an existing proof (gate check):** 1 credit. **\$0.0025** per check. * **Create and save a new result:** 4–73 credits (**$0.01 to $0.18**) depending on the check type. Live estimator: **[neus.network/pricing](https://neus.network/pricing)**. Heavier checks (human, agent authority, wallet risk) use more credits than a simple ownership check. How credits apply to gates, visitors, and APIs: [Billing](./billing). **Next:** [Sell access](../quickstart) # Proofs Source: https://docs.neus.network/platform/proofs Save a completed check and reuse it at the next gate. A proof is the saved result of a completed check. Keep its proof ID so your app can read its current status, share it, or reuse it without repeating the full check. The API field for the proof ID is `qHash`. ## What to store Store the proof ID and the fields your product needs for access or display. Read the current proof before a protected action instead of rebuilding the original check. `contentHash` identifies the checked content or artifact. It is not the proof ID. ## Storage Proofs are private and offchain by default. A blockchain record is optional and must be requested explicitly with `options.publishToHub: true` or `targetChains`. Wallet-signed creates can also return a portable envelope that another system can check without calling NEUS. See [Portable proofs](../learn/standards/caip-380). ## Next * [How verification works](../verification/how-it-works) * [Proof lifecycle](../verification/lifecycle) * [Hosted Verify](../cookbook/auth-hosted-verify) * [Privacy](./security-and-trust) # Rate limits Source: https://docs.neus.network/platform/rate-limits-and-retries Per-tier request limits and what to do when you hit them. NEUS enforces per-minute and per-window limits to keep the API fast and fair. Higher tiers get higher limits. Most apps never hit them. ## Limits by tier Limits scale with your plan. Verification and sign-in have tighter windows because they run real checks. | Surface | Free | Pro | Enterprise | | ------------------------ | ----------- | ----------- | ----------- | | API calls (burst) | 60 / min | 240 / min | 600 / min | | API calls (sustained) | 30 / min | 120 / min | 300 / min | | Verification (new proof) | 50 / 15 min | 50 / 15 min | 50 / 15 min | | Sign-in attempts | 10 / 15 min | 10 / 15 min | 10 / 15 min | | Status reads | 100 / min | 100 / min | 100 / min | | Admin actions | 20 / min | 20 / min | 20 / min | Verification and sign-in limits are the same across tiers. A check is a check regardless of plan. API call throughput is where higher tiers scale. ## When you hit a limit APIs return **429 Too Many Requests**. Honor these response headers before retrying: | Header | Meaning | | ------------------ | -------------------------------------------------------- | | `Retry-After` | Seconds to wait before the next request | | `RateLimit` | IETF draft-7 remaining quota (`r`) and time window (`t`) | | `RateLimit-Policy` | IETF draft-7 quota (`q`) and window length (`w`) | CORS exposes `Retry-After`, `RateLimit`, and `RateLimit-Policy` so browsers and agents can read them. * **Exponential backoff:** wait, then double the wait on each retry. * **Creates:** do not blind-retry. Confirm the first request did not succeed before sending another. A duplicate proof costs credits. * **Polling:** wait a few seconds between polls. Back off on errors. ## Tips * **Reuse proofs.** A gate check (1 credit) reads an existing proof. Creating a new one (4–73 credits) is heavier and counts against the verification window. Cache the proof ID and check it instead. * **Gate checks, not raw verification.** Use `gateCheck` with your `gateId` for access decisions. It reads saved results first and only creates a new proof when needed. * **Need higher limits?** Pro raises API throughput 4×. Enterprise raises it 10× with SLAs and custom packages. See [Pricing](./pricing). ## 402 and credits When credits run out, billable calls return **402 Payment Required** with a quote, not 429. Pay per call with [Pay per call](./x402) (no account needed) or top up credits and retry. **Next:** [SDK errors](../sdks/error-handling) and [Pricing](./pricing) # Trust Center Source: https://docs.neus.network/platform/security-and-trust Zero-trust execution, private by default, minimum disclosure, server-side credentials, auditable actions, optional anchoring. Verify what is required. Expose only what is necessary. Authorize every action. Record the decision, not the sensitive data. NEUS does not add compliance. It proves the architecture is operating according to its trust model. ## Architecture ### Zero-trust execution Every action is authorized against identity, proof, policy, and delegated authority. Identity, ownership, login, or possession never automatically implies authority. Authority is checked against current policy and delegation at execution time. ### Private by default Proofs and receipts remain private unless explicitly shared. Public exposure, public indexing, IPFS, and chain anchoring are explicit choices. Off-chain is the default. ### Minimum disclosure A check returns the minimum claim or result required for the decision. The proof proves the decision without reproducing the underlying evidence. Apps and agents receive the result they need, not the sensitive source material. ### Server-side credentials Agents use connected tools without receiving the user's secrets. Credentials are resolved and injected inside trusted server execution. They are never intentionally handed to the model, exposed in a tool schema, proof, browser response, or public record. ### Auditable actions Critical decisions produce proofs that can be inspected, verified, and revoked without publicly exposing the underlying data. Store enough to reconstruct who authorized what, under which policy, against which proof, and what outcome occurred. ### Optional anchoring Off-chain is the default. Public or blockchain publication requires explicit intent. ## Invariants These are NEUS invariants. Deviation from any of them is a bug. * **No implicit authority.** Identity, ownership, login, or possession never automatically implies authority to perform an action. Authority is checked against current policy and delegation at execution time. * **Minimum disclosure.** A check returns the minimum claim or result required for the decision. The proof proves the decision without unnecessarily reproducing the underlying evidence. * **Private and off-chain by default.** Public exposure, public indexing, IPFS, and chain anchoring are explicit choices. * **Secrets never become agent context.** Credentials are resolved and injected inside trusted server execution. They are never intentionally handed to the LLM, exposed in a tool schema, proof, browser response, or public proof. * **Evidence is not public proof.** Private evidence can exist when it is necessary to make a proof auditable, but public consumers get the claim, status, or proof rather than the sensitive source material. * **Every privileged action has a policy decision.** Subject plus resource plus action plus policy plus context produces allow, deny, or approval. The proof records the decision and relevant non-sensitive metadata. * **Delegation is narrower than ownership.** Agents operate only inside explicitly delegated authority. Spend, secrets, tool access, and high-risk actions remain bounded. * **Auditability without surveillance.** Store enough to reconstruct who authorized what, under which policy, against which proof, and what outcome occurred. Do not interpret "audit log" as permission to retain arbitrary request bodies, prompts, OAuth payloads, or provider responses. NEUS provides evidence of control, not evidence about the person. That is stronger than calling it "privacy-first." ## A distinction that matters Zero trust is not zero data. You sometimes legitimately need private state, encrypted secrets, session state, private evidence, or proofs to provide the product. The standard is purpose-bound, least-privilege, minimum necessary, protected, auditable, and deletable where applicable. Not "the server may never possess data." For blockchain specifically, the EDPB's final July 2026 guidance makes the off-chain-first and optional-anchor direction especially valuable. ## One data model Every feature (OAuth, Gmail, Drive, GitHub, payments, identity, ZK proofs, agents, MCP, API keys, AI inference, social connections, jobs) fits into one existing model. Evidence → Proof → Policy → Authority → Action → Receipt Not a Google system, an AI safety system, a wallet system, a GDPR system, an agent approval system, and an audit system. That fragmentation would destroy the advantage already built. The complete flow: 1. Sensitive evidence is examined inside the appropriate trusted boundary. 2. It is minimized into a claim or proof. 3. It is checked against policy and delegated authority. 4. The action is allowed, denied, or approved. 5. The proof records what was decided. 6. Sensitive evidence remains protected or disappears according to its retention requirement. ## Privacy controls Use this section only to choose visibility. Most builders should stay private. ### Boundaries * Proof issuance runs in **NEUS**. * Return **only** what your product needs from checks. * **Private** reads need the owner signed in (or your sharing rules). ### Modes | Mode | `privacyLevel` | `publicDisplay` | Use | | --------------- | -------------- | --------------- | --------------------------------- | | Private | `private` | `false` | Default. Owner-only reads. | | Unlisted public | `public` | `false` | Public by link or id, not listed. | | Listed public | `public` | `true` | Discoverable public proof. | Saved **proof IDs** follow the visibility you chose. `privacyLevel` decides private vs public. `publicDisplay` only matters for public proofs. Unlisted public still works for anyone with the id. ### Defaults | Surface | Create default | | ----------------- | ------------------ | | `client.verify()` | `private` | | `VerifyGate` | Hosted gate policy | For browser checkout, publish a gate and pass `gateId`. Visibility overrides belong in advanced `client.verify()` flows. ### Never ship publicly Raw signatures, owner-only payloads, private proof enumeration. ## Smart contract audit NEUS smart contracts were audited by [SafeStack AI](https://safestackai.com) in March 2026. The audit completed with no critical, high, medium, or low severity findings. Scope: `NEUSVerifierRegistry.sol`, `NEUSVoucherHub.sol`, `NEUSVoucherSpoke.sol`, `NEUSToken.sol`. Public status is listed on the [Trust Center](https://neus.network/trust-center#smart-contract-audit). Contact [dev@neus.network](mailto:dev@neus.network) for the full report. ## Diligence material What NEUS processes and why. Service terms. Report a vulnerability. ## Checklist Decide access with gate checks. Respect verifier time windows. Interactive flows via `/verify`. Verifier list from live API catalog. Keep proofs private unless your product explicitly needs public visibility. ## Next Proof status, scope, and sharing. Where checks run in your stack. # Pay per call Source: https://docs.neus.network/platform/x402 Pay for a single check without creating an account. Pay for a single check without creating an account or API key. Three endpoints support this: | Resource | Method | What it does | Base cost | | ----------------------------------- | ------ | ------------------------------------------------ | ------------------------------------------ | | `/api/v1/proofs/check` | GET | Evaluate existing proofs at a gate | 1 credit (\$0.0025) | | `/api/v1/verification` | POST | Create a new proof | 3+ credits (gate + verifier + proof write) | | `/api/v1/verification/access/grant` | POST | Create a signed private-proof sharing capability | 2 credits | The exact price for each request is in the `PAYMENT-REQUIRED` header. It scales with the number of checks, query complexity, and optional add-ons (IPFS pinning, extra chains). ## Flow Send the normal request with the required parameters (address, check IDs, or gate ID). An unpaid request returns **HTTP 402**. Decode the base64 **`PAYMENT-REQUIRED`** response header as an x402 v2 `PaymentRequired` object. Use an x402-compatible client to select the payment method and sign the payload. Private key stays in the client or wallet. Repeat the identical method, URL, query, and body with the base64 **`PAYMENT-SIGNATURE`** request header. A successful paid call returns **HTTP 200**, the result, and a base64 **`PAYMENT-RESPONSE`** settlement header. ## Proof check Check existing proofs before granting access, releasing a payment, or allowing an agent action: ```http theme={"dark"} GET https://api.neus.network/api/v1/proofs/check ``` ```bash theme={"dark"} curl --include --get \ "https://api.neus.network/api/v1/proofs/check" \ --data-urlencode "address=0x1111111111111111111111111111111111111111" \ --data-urlencode "verifierId=ownership-basic" ``` A single-verifier gate check costs **1 credit (0.0025 USDC)**. The price scales with the number of verifier IDs requested, query complexity, and result limit: | Parameter | Effect on price | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------ | | `verifierId` | Base check (1 credit) | | `verifierIds=a,b,c` | 1 credit + 1 per additional verifier | | `gateId` | Uses the gate's check policy (creator pays by default) | | `traitPath`, `contentHash`, `contractAddress`, `domain`, `riskLevel`, `sanctioned`, `poisoned` | +2 credits (complex query surcharge) | | `sinceDays` or `since` | +1 credit (time-window surcharge) | | `limit` > 50 | +1 credit per 50 additional results | The `PAYMENT-REQUIRED` header always carries the exact amount for that request. ## Proof creation Create a new proof by paying per call: ```http theme={"dark"} POST https://api.neus.network/api/v1/verification ``` Cost = gate check (1 credit) + each verifier's weight + proof write (2 credits) + optional add-ons. Verifier weights range from 1 (ownership-basic) to 70 (wallet-risk). See [Verifiers](../verification/verifiers) for per-verifier credit amounts. ## Access grant Create a signed capability for private-proof sharing: ```http theme={"dark"} POST https://api.neus.network/api/v1/verification/access/grant ``` Base cost: 2 credits. No per-hour surcharge. ## Settlement | Property | Current production requirement | | -------- | ------------------------------ | | Scheme | `exact` | | Network | Base mainnet (`eip155:8453`) | | Asset | USDC on Base | Pricing is exact and sub-cent. A 1-credit gate check settles at its unit cost, not a rounded-up minimum. No settlement cap; pay for exactly the credits used. Per-credit price: see [Pricing](./pricing). Always enforce a client-side maximum before signing. Treat the decoded `PAYMENT-REQUIRED` header as the source of truth for the current amount, asset, recipient, and timeout. After payment, validate all of the following before accepting the result: * HTTP status is `200` * `PAYMENT-RESPONSE` is present and decodes successfully * settlement reports success on the selected network * the payer and transaction are present * the response body reports a completed operation ## Discovery The payment challenge includes the x402 v2 Bazaar extension with the HTTP input, JSON output example, and JSON Schema. After the facilitator completes a successful settlement, the resource can be indexed for agent and marketplace search. There is no separate Bazaar registration step. See [x402 Bazaar discovery](https://docs.cdp.coinbase.com/x402/bazaar). ## Agent spending limits Pair x402 with an agent permission proof to limit autonomous spending. * Grant `agent-delegation` with `scope: "payments:x402"` and a `maxSpend` cap. * `maxSpend` is a whole-number string in token base units. For USDC, 25 USDC is `"25000000"`. * Use `toAgentDelegationMaxSpend('25', 6)` from `@neus/sdk` when constructing the cap. * The calling application should also enforce a per-request maximum before signing any payment. Details: [Agent permissions](../agents/agent-delegation). ## Next Request and interpret a reusable trust decision. Credits, sponsorship, and who pays. Scope actions and spending for autonomous agents. # Sell access with one gate Source: https://docs.neus.network/quickstart Publish a free or paid access rule, add one component, and confirm the result on your server. This is the app-embed recipe. To connect Proofable in any chat or IDE, or to list on proofable.me, use [Connect Proofable](./mcp/setup). Adding sign-in to an app? [Use hosted sign-in](./cookbook/auth-hosted-verify). Publish once. One listing owns the verifiers, price, and hosted sign-in. Your app adds the listing and confirms the result; it never recreates the verify logic. Visitors never need an API key. ## Build it Sign in at [proofable.me](https://proofable.me) → **Listings**. Choose what to verify, set pricing, **Publish**. Copy your `gateId`. ```jsx theme={"dark"} import { VerifyGate } from '@neus/sdk/widgets'; ; ``` `VerifyGate` reuses a saved proof or opens hosted sign-in on Proofable when a new one is needed. Wallet, passkey, and OAuth all happen on Proofable, not inside your app. Pass the visitor's **account address** (from Proofable sign-in or the saved result; passkey and OAuth included): ```js theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient(); const result = await client.gateCheck({ gateId: 'gate_your-app-name', address: user.accountAddress, // from hosted sign-in / stored proof subject }); if (!result.data?.gate?.allRequiredSatisfied) { // send the user back to VerifyGate or Proofable sign-in } ``` The visitor’s proof is theirs. If they return or visit another listing that needs the same Proofs, they can reuse it. You choose who pays. Use your Proofable credits for free access, or turn on visitor checkout and set a price. See [Billing](./platform/billing) for card, USDC, and metered API options. ## Optional: show proof status ```jsx theme={"dark"} import { ProofBadge } from '@neus/sdk/widgets'; ; ``` Pass `showChains` only when on-chain status matters in your interface. ## Not using React? Send users to Proofable for sign-in ```js theme={"dark"} import { getHostedCheckoutUrl } from '@neus/sdk'; window.location.assign( getHostedCheckoutUrl({ gateId: 'gate_your-app-name', returnUrl: 'https://myapp.com/auth/callback', }), ); ``` Read the **proof ID** (`qHash`) from the callback URL or popup message, then store it. Details: [Hosted sign-in](./cookbook/auth-hosted-verify). ## Connect Proofable instead? [Connect Proofable](./mcp/setup) is the one path for chat, IDEs, jobs, and listings. After Connect, ask: **"Before I take a sensitive action, use Proofable. Reuse what I already have."** ## Next Props, modes, and OAuth. The browser flow on Proofable. Connect Proofable. Hosted sign-in for apps. Backend-created proofs after a one-time approval: [Integrations](./cookbook/integrations). # SDK authentication Source: https://docs.neus.network/sdks/authentication Sign people in on NEUS. Authenticate your server with a key or gate check. Default: no wallet or passkey code in your app. Visitors sign in or complete checks on `neus.network/verify` via `VerifyGate`, `getHostedCheckoutUrl`, or MCP OAuth. | Where | What | Wallets or keys in your app | | -------------------------- | ------------------------------------------------- | ----------------------------------------------------- | | Browser: access gate | `VerifyGate` + `gateId` | No | | Browser: sign-in | `getHostedCheckoutUrl` + `intent: 'login'` | No | | Server | `NeusClient` + `gateCheck` with the same `gateId` | No | | Automation as your profile | `NeusClient` + profile access key (`npk_*`) | No | | Advanced server | `verifyFromApp` after per-user approval | No | | Browser (exception) | `client.verify({ wallet })` | Yes. [Signing format](../verification/signing-format) | ## VerifyGate (browser) ```jsx theme={"dark"} import { VerifyGate } from '@neus/sdk/widgets'; ; ``` ## Hosted sign-in (browser) [Hosted sign-in](../cookbook/auth-hosted-verify). ```javascript theme={"dark"} import { getHostedCheckoutUrl } from '@neus/sdk'; const url = getHostedCheckoutUrl({ gateId: 'gate_your-app-name', returnUrl: 'https://yourapp.com/auth/callback', }); ``` **Sign-in only:** ```javascript theme={"dark"} const loginUrl = getHostedCheckoutUrl({ intent: 'login', returnUrl: 'https://yourapp.com/auth/callback', }); ``` ## Server reuse ```javascript theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient(); const result = await client.gateCheck({ gateId: 'gate_your-app-name', address: user.accountAddress, }); if (result.data?.gate?.allRequiredSatisfied !== true) { // Send the visitor back to VerifyGate or NEUS sign-in } ``` ## Profile access keys For servers, CI, and MCP when browser sign-in is unavailable. Create keys under [Profile → Account](https://neus.network/profile?tab=account). ```javascript theme={"dark"} import { NeusClient } from '@neus/sdk'; // Server only. Never ship npk_* in a browser bundle const client = new NeusClient({ apiKey: process.env.NEUS_ACCESS_KEY }); ``` The SDK sends `Authorization: Bearer `. ## IDE and MCP sign-in Run `neus setup`. Default is browser OAuth. Set `NEUS_ACCESS_KEY` first only for servers and CI. See [MCP setup](../mcp/setup). ## Advanced: `verifyFromApp` After one-time user approval ([app link](../agents/agent-delegation)), your backend can create proofs without a per-request signature: ```javascript theme={"dark"} const client = new NeusClient({ appId: 'acme-web', appOrigin: 'https://yourapp.com', apiKey: process.env.NEUS_ACCESS_KEY, // optional. Your builder profile }); await client.verifyFromApp({ user: { walletAddress: user.accountAddress }, verifier: 'ownership-basic', content: 'Hello NEUS', }); ``` Full detail: [Integrations](../cookbook/integrations). ## Advanced [API authentication](../api/authentication) # NEUS CLI Source: https://docs.neus.network/sdks/cli Set up hosted MCP, validate the connection, and load trusted agent context from the terminal. The official NEUS CLI ships in [`@neus/sdk`](https://www.npmjs.com/package/@neus/sdk). Product page: [https://neus.network/cli](https://neus.network/cli). ```bash theme={"dark"} npx -y -p @neus/sdk neus ``` | Command | Purpose | | ---------------------------------------- | --------------------------------------------- | | `npx -y -p @neus/sdk neus setup` | Register hosted MCP on the local client | | `npx -y -p @neus/sdk neus doctor --live` | Confirm the live connection | | `npx -y -p @neus/sdk neus auth` | Sign in when the host needs a profile session | After install you can use the short commands `neus setup`, `neus doctor --live`, and `neus auth`. The CLI configures hosted MCP and loads trusted agent context. HTTP agents should fetch [NEUS OpenAPI](https://api.neus.network/openapi.json). Assistants should use [NEUS MCP](https://mcp.neus.network/mcp). # SDK error handling Source: https://docs.neus.network/sdks/error-handling Retry and recovery for polling, private reads, hosted flows, and failed checks. ## When things fail | Class | Fix | | ------------ | ------------------------------ | | Validation | Fix request shape | | Interactive | Hosted `/verify` or VerifyGate | | Async | Poll with backoff | | Private read | Owner auth, retry | | Transient | Backoff; `Retry-After` | ## Error classes All SDK errors extend `SDKError` and carry a `.code` and `.details`. Import them from `@neus/sdk`: | Class | `isRetryable` | Use it for | | --------------------- | ------------------- | -------------------------------------------------------------------------------------- | | `ApiError` | `true` on 5xx / 429 | HTTP failures. Also has `.statusCode`, `.isClientError`, `.isServerError`, `.response` | | `ValidationError` | `false` | Bad request shape. Has `.field`, `.value` | | `NetworkError` | `true` | Transport / DNS / timeout | | `ConfigurationError` | `false` | Missing/invalid client config. Has `.configKey` | | `VerificationError` | `true` | Verifier failure. Has `.verifierId` | | `AuthenticationError` | `false` | Owner/session/key not allowed | ```javascript theme={"dark"} import { ApiError } from '@neus/sdk'; try { await client.gateCheck({ gateId: 'gate_your-app-name', address }); } catch (error) { if (error instanceof ApiError && error.isRetryable) { // back off and retry (5xx / 429) } else if (error.code === 'VALIDATION_ERROR') { // fix the request and do not retry } } ``` ## Polling Example ```javascript theme={"dark"} const final = await client.pollProofStatus(qHash, { interval: 3000, timeout: 60000 }); ``` ## Private Proof Read Example ```javascript theme={"dark"} const privateData = await client.getPrivateProof(qHash, window.ethereum); ``` * Don't loop-create on ambiguous errors. Keep stored qHashes for resume. * Say when a hosted step is required. Avoid generic "error" only. # SDK Source: https://docs.neus.network/sdks/overview Hosted flows, server checks, and React widgets. Most apps need a hosted handoff plus a server gate check. Assistants use the same APIs through [MCP](../mcp/overview). ## Default placement | Use case | Where | | ------------------------------- | ------------------------ | | Hosted verify URL, `VerifyGate` | **Browser** (or WebView) | | **`gateCheck`** with `gateId` | **Server** | | **`verifyFromApp`**, `npk_*` | **Server** | Avoid credentialed `fetch` to `api.neus.network` from the browser; use SDK helpers or your backend. ## API mapping | Need | Method | | -------------------- | -------------------------------------- | | Hosted handoff | `getHostedCheckoutUrl()`, `VerifyGate` | | Sign inside your app | `verify()` | | Wait | `pollProofStatus()` | | Allow / deny | `gateCheck()` (server) | Full reference, install, and code examples: [JavaScript SDK](./javascript). ## Defaults `client.verify()` and `VerifyGate` create results as **private** by default. [Security](./security) and [Privacy](../platform/security-and-trust) ## Next Client setup and common methods. Add hosted verification and protected content to React. Create, poll, and read proofs. Access keys and server auth. # Security Source: https://docs.neus.network/sdks/security Security best practices for NEUS SDK integrations. ## Auth by operation | Operation | Auth | | ---------------------------- | ------------------------------------------------------------------------------ | | `POST /api/v1/verification` | Signed standard string, or advanced server path with access key + `X-Neus-App` | | `GET /api/v1/proofs/{qHash}` | Public metadata for public/unlisted; private needs owner rules | | Private payload reads | Owner signature / SDK helpers | ## Do Not * Do not treat proof signatures as bearer tokens (they are request-bound) * Do not embed **secrets** in browser bundles * Do not call the NEUS API from browser JavaScript with hand-written `fetch` and custom headers; use SDK or Hosted Verify, or **proxy** through your server * Do not log or persist: * proof signatures * API keys * third-party auth credentials or provider tokens ## Defaults `client.verify()` defaults **private**. `VerifyGate` uses Hosted Verify with the published gate policy. [Privacy](../platform/security-and-trust) If you need proof reuse without owner-authenticated access, opt into unlisted public explicitly: ```javascript theme={"dark"} const proofOptions = { privacyLevel: 'public', publicDisplay: false, }; ``` Do not treat unlisted public proofs as secret. | Control | Purpose | | ---------------------- | ------------------------------------------------------------------- | | `privacyLevel` | Default private; switch to public only for intentional public reuse | | `publicDisplay` | Discovery vs unlisted | | `storeOriginalContent` | Advanced storage control | Unlisted public proofs are still public to anyone with the `qHash`. # Verify patterns Source: https://docs.neus.network/sdks/verifications Reuse, fresh, hosted checkout, and server verification. Default strategy: **`reuse-or-create`**. ## Privacy `client.verify()` is an advanced server or controlled-signing path. `VerifyGate` create opens **Hosted Verify** and uses the published gate policy. Full matrix: [Privacy](../platform/security-and-trust) | Option | When | | ------------------------- | ---------------------------------------------------------- | | `privacyLevel: 'private'` | Default; owner or authorized access for private reads | | `privacyLevel: 'public'` | Public reuse without owner auth; pair with `publicDisplay` | | `publicDisplay: false` | Unlisted - still public to anyone with id | | `publicDisplay: true` | Listed / discoverable (needs `public`) | `storeOriginalContent` and explicit visibility options are advanced `client.verify()` storage controls, not the default VerifyGate path. ## Reuse-first ```jsx theme={"dark"} ``` ## Fresh High-stakes actions - force new proof: ```jsx theme={"dark"} ``` ## Read-only gate ```jsx theme={"dark"} ``` ## Hosted interactive Hand off to `/verify` with a published gate: ```jsx theme={"dark"} ``` [Hosted Verify](../cookbook/auth-hosted-verify) ## Server check Prefer **`gateCheck`** over pulling full proofs for every decision: ```javascript theme={"dark"} const result = await client.gateCheck({ gateId: 'gate_your-app-name', address: '0x...', }); ``` ## Next Props. Loop. # Content safety Source: https://docs.neus.network/verification/ai-content-moderation Screen text or images before you publish or grant access. **Verifier ID:** `ai-content-moderation` Screen text or images for safety, then reuse the result before you publish. ## Use cases * User-generated content * AI-generated output * Moderation and publishing workflows ## Flow type External lookup. NEUS screens the content with a moderation provider and records the outcome. ## Fields | Field | Required | Notes | | ------------- | -------- | -------------------------------------------------------------------------- | | `content` | Yes | Raw text, base64, or an `ipfs://` / CID reference | | `contentType` | Yes | MIME type. See supported types below | | `provider` | No | Defaults by content: text → `google-perspective`, images → `google-vision` | **Supported `contentType` values:** `text/plain`, `text/markdown`, `text/x-markdown`, `application/json`, `application/xml`, `image/jpeg`, `image/png`, `image/gif`, `image/webp`. ## Example ```json theme={"dark"} { "content": "Text to screen, or a base64/ipfs:// reference", "contentType": "text/plain" } ``` Full schema: [`ai-content-moderation.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/ai-content-moderation.json). # Contract control Source: https://docs.neus.network/verification/contract-ownership Confirm a wallet controls a contract before you grant admin access. **Verifier ID:** `contract-ownership` ## Use cases * App ownership * Contract admin access * Partner and ecosystem trust ## Flow type Lookup. NEUS checks owner or admin authority on-chain. ## Required Fields | Field | Required | Notes | | ----------------- | -------- | ---------------------------------------------------------- | | `contractAddress` | Yes | EVM contract address | | `chainId` | Yes | EVM chain ID | | `method` | No | `owner`, `admin`, or `accessControl` (defaults to `owner`) | | `walletAddress` | No | Address to check; defaults to the signer | ## Example ```json theme={"dark"} { "contractAddress": "0x...", "chainId": 8453, "method": "owner" } ``` Full schema: [`contract-ownership.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/contract-ownership.json). # How it works Source: https://docs.neus.network/verification/how-it-works From request to a saved result you can reuse. ## Stages Hosted Verify, SDK, or API. Per verifier: sign, hosted step, or lookup. Store the proof ID. [Proofs](../platform/proofs). ## Modes | Mode | When | | ------------- | --------------------------------------------------- | | Hosted Verify | Login, OAuth, human, org | | SDK | Product-controlled flows | | Raw HTTP | Advanced / server-only | | Gate check | `GET /api/v1/proofs/check` | | Pay per call | No account needed. [Pay per call](../platform/x402) | ## You get * Response and status * A hosted link when a browser step is required * Poll when verification is async * A proof ID to store ## Related Browser, server, and assistant paths. Store and reuse completed proofs. Poll, reuse, revoke. Pick a verifier by outcome. # Lifecycle Source: https://docs.neus.network/verification/lifecycle Create, wait, reuse, or revoke a result. ## Stages | Stage | Meaning | | --------------- | --------------------- | | Start | Hosted, SDK, or API | | Accepted | Request in flight | | Processing | Async check | | Complete | Proof ID ready | | Reused | Checks / gates / MCP | | Stale / revoked | Policy or user revoke | ## Strategies | Strategy | Use | | ----------------- | ----------------------- | | `reuse-or-create` | Default. Reuse if valid | | `reuse` | Read-only checks | | `fresh` | Force a new result | ## Freshness * Point-in-time checks (balance, risk): respect recency. * Prefer cheap checks + `since` / `sinceDays`. Run a new check only when policy needs it. ## Revoke (owner) ```http theme={"dark"} POST /api/v1/proofs/revoke-self/{qHash} ``` ```javascript theme={"dark"} await client.revokeOwnProof(qHash, wallet); ``` ## Related Flow. qHash. Messages. Catalog. # NFT holder Source: https://docs.neus.network/verification/nft-ownership Gate access when a wallet holds a specific NFT. **Verifier ID:** `nft-ownership` ## Use cases * Token-gated access * Drops and collector-only content ## Flow type Lookup. NEUS checks on-chain ownership. ## Required Fields | Field | Required | Notes | | -------------------- | -------- | --------------------------------------- | | `contractAddress` | Yes | NFT contract or mint | | `tokenId` | Yes | Token ID | | `chainId` or `chain` | Yes | Chain id or CAIP-2 chain | | `tokenType` | No | `erc721` (default) or `erc1155` | | `ownerAddress` | No | Wallet to check; defaults to the signer | | `blockNumber` | No | Check ownership at a specific block | ## Example ```json theme={"dark"} { "contractAddress": "0x...", "tokenId": "1", "chainId": 8453 } ``` High-stakes access: pair with freshness checks or require a new proof when policy demands it. Full schema: [`nft-ownership.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/nft-ownership.json). # Trust Source: https://docs.neus.network/verification/overview Verify identity, ownership, permissions, and safety before an action. Verify identity, ownership, permission, or safety. Save a proof. Reuse it before access, payment, or an agent action. ## Outcomes | | Examples | | --------- | -------------------------- | | Identity | Login, social, team | | Ownership | Content, files, authorship | | Access | NFT, token thresholds | | Abuse | Human, wallet safety | | Agents | Identity, permissions | Agent proofs record who an agent is and what it may do. ## How you verify | Type | How | Examples | | ----------- | -------------------------------------------- | ----------------------------------------------------- | | Interactive | Hosted steps on NEUS (passkey, OAuth, human) | ownership-social, ownership-org-oauth, proof-of-human | | Instant | Account signs in-session | ownership-basic, agent-identity | | Lookup | Live state | NFT, balance, wallet-risk | Most product gates start with **Interactive**. Instant and Lookup are available when your threat model needs them. ## Terms | Term | Meaning | | ------------------ | -------------------------------------------------------------------------------------- | | Proof ID (`qHash`) | Saved proof reference. [Proofs](../platform/proofs) | | Verify | You verify. The result is a proof (the receipt). Schema field: `verifier` | | Account / subject | The NEUS account the result is about | | Signing string | Message the account signs when verify needs it | | Hosted Verify | Browser flow at `neus.network/verify`. [Hosted Verify](../cookbook/auth-hosted-verify) | Visibility: [Privacy](../platform/security-and-trust) ## Response * `qHash` * `status`: verified, processing, failed * Page: `https://neus.network/proof/[qHash]` ## Next Catalog of checks. End-to-end flow. Message format. Poll and revoke. # Content ownership Source: https://docs.neus.network/verification/ownership-basic Confirm you own the words, files, or releases. Reuse the result later. **Verifier ID:** `ownership-basic` ## Use cases Release notes, policy text, agent outputs, licensing claims, bounty submissions, and marketplace listings where **who said it** and **what the exact text was** must be verifiable later. ## Workflow 1. The owning wallet signs. 2. Attach **`content`** (full text, up to 50,000 characters) and/or **`reference`** (`{ type, id }`). 3. NEUS saves a durable result for check, link, and reuse. Visibility: private vault, link-only, or public. [Privacy](../platform/security-and-trust). ## Content and storage | Field | Required | Notes | | ------------- | -------- | ----------------------------------------------------------------------------------------- | | `owner` | Yes | Must match the signer wallet | | `content` | No | Text to bind to the account | | `reference` | No | Stable pointer `{ type, id }`. Not a bare string | | `contentHash` | No | NEUS verifier hash (`0x` + 64 hex) only if precomputed; otherwise omit and send `content` | | `provenance` | No | Advisory human / AI / mixed metadata | Send at least one of `content`, `contentHash`, or `reference.id`. ## Verification links in hosted gates A hosted gate can evaluate current JSON returned by a visitor-supplied HTTPS URL. Add an output match such as `resolved.verified = true`; `/verify` then reads JSON from the submitted URL or its conventional `.json` representation and evaluates the returned fields. ```json theme={"dark"} { "verifierId": "ownership-basic", "match": [ { "path": "reference.type", "op": "eq", "value": "url" }, { "path": "resolved.verified", "op": "eq", "value": "true" } ], "maxAgeMs": 300000 } ``` The visitor supplies only the URL. Resolver rules and expected output remain server-controlled. Ordinary URL references without `resolved.*` gate matches are not fetched. To store the exact string on the proof, set **`storeOriginalContent: true`** when you need to override defaults. Read back with **`proof.publicContent.content`**. [Privacy](../platform/security-and-trust) covers defaults. **Pre-hash:** Do not paste a generic SHA256 as `contentHash`. Send `content`, verify, and use the returned verifier hash from NEUS. ### Example payload ```json theme={"dark"} { "owner": "0x...", "content": "Release notes for v1.2", "reference": { "type": "url", "id": "https://example.com/releases/v1-2", "title": "Release notes v1.2" }, "provenance": { "declaredKind": "mixed", "aiContext": { "generatorType": "agent", "provider": "NEUS", "model": "release-workflow", "runId": "release-v1-2" } } } ``` If storage was off or only a hash/pointer was anchored, callers may see a resolution status such as `hash_only_not_recoverable` instead of full prose. Schema: [`ownership-basic.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/ownership-basic.json). # Domain ownership Source: https://docs.neus.network/verification/ownership-dns-txt Confirm domain control with a DNS TXT record on the account you control. **Verifier ID:** `ownership-dns-txt` ## Use cases * verified website on your profile * team workspace and branded handles * public trust pages for domains ## Flow Type Lookup. NEUS resolves DNS TXT at `_neus.` and compares it to the **account address** used for this verification (see below). ## DNS record (what builders publish) Create a **TXT** record: * **Name / host:** `_neus` (effective lookup: `_neus.`, e.g. `_neus.example.com` if the apex is `example.com`). * **Value:** a single line starting with `wallet=` followed by the **same wallet or account address** NEUS uses when it runs this check. Supported shapes today: | Format | When it matches | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `wallet=
` | Default. `
` must match the wallet or account address NEUS uses for this proof. For **Ethereum**, use **lowercase** `0x` plus 40 hex digits in DNS. | | `wallet=eip155::
` | Only if the verification run supplies a numeric **`chainId`** in verifier options so this form is generated for the check. | Other prefixes (for example `neus=`) are **not** read by this verifier. Use **`wallet=`** only. **Other networks:** Use the address format for that network. Copy the value exactly as NEUS shows it. Some networks are case-sensitive. Do not retype the address. ## Request `data` (API / SDK) | Field | In JSON Schema | What to know | | --------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `domain` | **Required** | Hostname to verify (apex or eTLD+1 style you control in DNS). | | `walletAddress` | **Optional** in `data` | **Still needed for a passing check:** the TXT line must match the **wallet or account address NEUS uses for this proof**. You may **omit** `walletAddress` inside `data` when the proof request already includes a verified **`walletAddress` at the request level** (signed flow); the service fills in the signer wallet before the DNS check. If you omit it **and** the request has no signer wallet, verification fails. If you **set** `walletAddress` in `data`, it must match the wallet that signs the proof (or follow your product's allowed delegation rules). Do not use someone else's address. | ## Example Minimal `data` when the proof request carries the signer wallet (typical browser / server signing): ```json theme={"dark"} { "domain": "example.com" } ``` Explicit `data` (custom clients, tests, or when you want the payload self-describing): ```json theme={"dark"} { "domain": "example.com", "walletAddress": "0x..." } ``` See also: [Domain verification cookbook](../cookbook/domain-verification), [JSON Schema](https://github.com/neus/network/blob/main/docs/verifiers/schemas/ownership-dns-txt.json). # Team and organization Source: https://docs.neus.network/verification/ownership-org-oauth Confirm Google or Microsoft org membership before you grant access. **Verifier ID:** `ownership-org-oauth` Confirm a person belongs to a Google Workspace or Microsoft 365 organization, then gate member-only apps, agents, and content. OAuth runs on NEUS. Use Hosted Verify or `VerifyGate`. Never build a custom OAuth UI. ## Use cases * Gating to members of a Google Workspace or Microsoft 365 organization * Org-scoped agents and apps * Member-only tools and partner portals ## Flow type Interactive, hosted-only. This verifier cannot be submitted directly from your backend, and it cannot be combined with other checks in one request. ## The simplest path ```text theme={"dark"} https://neus.network/verify?verifiers=ownership-org-oauth&returnUrl=https://app.example.com/verified ``` You get a proof ID in the `qHash` field. Store and reuse it. ## Fields | Field | Required | Notes | | --------------------- | ------------------- | ----------------------------------------------------------- | | `provider` | Yes | `google` or `microsoft` | | `internalSocialToken` | Yes (direct submit) | Short-lived token issued by the hosted OAuth step | | `expectedOrgDomain` | No | Restrict the proof to one company domain such as `acme.com` | | `walletAddress` | No | Subject override to bind membership to a wallet | Set `expectedOrgDomain` only when a single company domain should pass; omit it if any Workspace / M365 tenant is acceptable. Full schema: [`ownership-org-oauth.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/ownership-org-oauth.json). # Username Source: https://docs.neus.network/verification/ownership-pseudonym Bind a public handle to an account without a legal identity. **Verifier ID:** `ownership-pseudonym` Claim a portable handle with a wallet signature. A public name, not a legal identity. ## Use cases * Product handles * Portable public names * Pseudonymous creator identity ## Flow type Instant. The user signs once and the pseudonym binding is created. ## Fields | Field | Required | Notes | | ------------- | -------- | ----------------------------------------------------------------- | | `pseudonymId` | Yes | Handle, 3–32 chars, pattern `^[a-z0-9][a-z0-9._-]{1,30}[a-z0-9]$` | | `namespace` | No | Defaults to `neus` | | `displayName` | No | Human-readable label | | `metadata` | No | Optional object for app-specific attributes | ## Example ```json theme={"dark"} { "pseudonymId": "alice123", "displayName": "Alice" } ``` ## Expiry Pseudonym proofs are time-bound: the proof includes an `expiresAt`. Re-verify to refresh before it lapses. Full schema: [`ownership-pseudonym.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/ownership-pseudonym.json). # Linked social accounts Source: https://docs.neus.network/verification/ownership-social Confirm a social account before you grant access. Reuse the result. **Verifier ID:** `ownership-social` Confirm a person controls a social account, then reuse that result across your apps. OAuth runs on NEUS. You never handle tokens. ## Use cases * Trust pages and reputation * Community onboarding and gating * Linking a social handle to a wallet or profile ## Flow type Interactive, hosted-only. The user authorizes the provider on NEUS and returns with a result. This check cannot be submitted from your backend, and it cannot be combined with other checks in one request. ## Supported providers `discord`, `github`, `facebook`, `x`, `linkedin`, `telegram`, `coinbase`. ## The simplest path Send the user to Hosted Verify, then read the proof back: ```text theme={"dark"} https://neus.network/verify?verifiers=ownership-social&returnUrl=https://app.example.com/verified ``` You get a proof ID in the `qHash` field. Store it and reuse it. Do not re-run the flow on every visit. Never collect raw OAuth tokens. ## Fields | Field | Required | Notes | | --------------------- | ------------------- | ------------------------------------------------- | | `provider` | Yes | One of the supported providers above | | `internalSocialToken` | Yes (direct submit) | Short-lived token issued by the hosted OAuth step | | `walletAddress` | No | Subject override to bind the handle to a wallet | `internalSocialToken` is produced by the hosted flow. Your app does not create it. For almost all integrations, use Hosted Verify or `VerifyGate` and skip direct submission. Full schema: [`ownership-social.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/ownership-social.json). # Proof of human Source: https://docs.neus.network/verification/proof-of-human Confirm a person before rewards, drops, or high-value access. **Verifier ID:** `proof-of-human` ## Use cases * Sybil resistance * Rewards and trusted onboarding ## Flow type Interactive, hosted-only. The user completes the personhood step on NEUS and returns with a result. This check cannot be combined with other checks in one request. ## What you configure (hosted) | Field | Required | Notes | | ---------- | -------- | ----------------------------------------------------------- | | `provider` | Yes | Pin a supported provider (e.g. `zkpassport`) | | `scope` | No | Scope for the personhood identifier (defaults to `neus-v1`) | For direct API submission after a hosted proof, the request carries the provider `proofs` and `queryResult` returned by the hosted step. You do not assemble these yourself. Use Hosted Verify or `VerifyGate` for the standard path. ## Response Fields | Field | Visibility | Description | | ---------------- | ---------- | ---------------------------------------------------------------------------- | | `provider` | Public | Provider that verified (e.g. `zkpassport`) | | `assuranceLevel` | Public | Confidence level: `low`, `medium`, or `high` | | `claims` | Public | Privacy-preserving booleans (e.g. `personhood_verified`, `sanctions_passed`) | | `traits` | Public | Provider metadata (scope, domain, verifiedAt) | | `expiresAt` | Public | Expiry timestamp | ## Assurance Levels | Level | Criteria | | -------- | --------------------------------------------- | | `high` | Strict facematch verified | | `medium` | Facematch (non-strict) or KYC bundle verified | | `low` | Age/sanctions/personhood only | Full schema: [`proof-of-human.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/proof-of-human.json). # Propose a verifier Source: https://docs.neus.network/verification/propose-a-verifier How to add a new NEUS check. Spec the schema and catalog here, then wire it into the protocol. NEUS verifier schemas and the public catalog index live in **this repo**. A contributor opens a PR here to add a new check; once merged, the definition propagates to the protocol verifier registry. No private infrastructure access required. ## Before you write code Open a [Discussion](https://github.com/neus/network/discussions) describing: * **Who** the check is for (buyer, integrator, agent builder). * **What** it proves (identity, ownership, permission, safety). * **Inputs** the integrator supplies. No PII. Deterministic for identical inputs. * **Outcome** the buyer sees (verified, processing, failed) and what it unlocks at a gate. A reviewer will confirm whether the check belongs in the public catalog or is better handled by composing existing checks. ## What a new verifier needs All public artifacts live in this repo. The protocol picks up the verifier from here. | Artifact | Where | What it holds | | ------------------------- | ---------------------------------- | ----------------------------------------------------------------- | | Input JSON Schema | `docs/verifiers/schemas/.json` | Request shape an integrator sends | | Catalog index entry | `spec/VERIFIERS.json` | ID, description, flow, tier, interaction, API flags, schema path | | Capability reference page | `docs/verification/.mdx` | Buyer-facing guide; linked from `docs/verification/verifiers.mdx` | | OpenAPI examples | `docs/openapi/public-api.json` | Request and response examples if the shape is new or changed | | Changelog entry | `CHANGELOG.md` | Integrator-visible change under `[Unreleased]` | ## Conformance A public verifier must: * Return deterministic outputs for identical inputs. * Carry no PII in inputs or outputs. * Document external API usage with rate limits and error handling. * Note gas or performance considerations if it anchors on-chain. ## Submitting a PR 1. Add the input JSON Schema at `docs/verifiers/schemas/.json`. 2. Add the catalog entry to `spec/VERIFIERS.json` with `tier: "public"`, the schema path, flow, interaction, and API flags. 3. Add a capability reference page at `docs/verification/.mdx` and link it from `docs/verification/verifiers.mdx`. 4. Update `docs/openapi/public-api.json` examples if the request or response shape changed. 5. Add a `[Unreleased]` entry in `CHANGELOG.md` describing the integrator-visible change. Run the public validators before requesting review: ```bash theme={"dark"} npm run docs:validate npm --prefix sdk test node scripts/verify-release-versions.mjs ``` The merged verifier is then wired into the protocol verifier registry. ## What not to include * No wallet addresses or private env names. * No verifier outcomes that the live protocol does not return. Confirm from running code or tests before documenting a result. * No parallel verifier catalogs. `spec/VERIFIERS.json` is the single public index. ## Related Current public checks. Request shapes. How a request is signed. Propose before you code. # Signing format Source: https://docs.neus.network/verification/signing-format Wallet message format for signed checks. **Default:** [Hosted Verify](../cookbook/auth-hosted-verify) or **SDK** `client.verify()` - you do not need to read this page to ship. Use this reference when you implement **raw `POST /api/v1/verification`** or debug **`SIGNATURE_VERIFICATION_FAILED` / invalid signature** responses. ## Why The wallet agrees to the exact request; NEUS returns a **qHash** and the complete `portableProof` envelope to the creator. The signature authenticates the request, not the later verifier outcome. ## Raw HTTP only If you call the API without the SDK: 1. Build the verification **JSON body** you will submit. 2. **`POST /api/v1/verification/standardize`** with that body to **`signerString`** (exact bytes to sign). 3. Sign **`signerString`**. 4. **`POST /api/v1/verification`** with the **same body** + **`signature`**. Do not hand-edit the six-line text. Only sign what **`standardize`** returns (or SDK **`standardizeVerificationRequest`**) for that exact body. ## Troubleshooting * Re-run **`/standardize`** on the same payload and compare **`signerString`** to what the wallet signed. * **`walletAddress`**, **`verifierIds`**, **`data`**, **`signedTimestamp`**, and chain fields must match between standardize and submit. * Do not remove nonces or timestamps from `data` when recomputing `qHash`; every data field is bound. ## Shape UTF-8, **LF** newlines. ```text theme={"dark"} Portable Proof Verification Request Wallet:
Chain: Verifiers: Data: Timestamp: ``` ## SDK helpers ```javascript theme={"dark"} import { standardizeVerificationRequest, signMessage, verifyPortableProofEnvelope, } from '@neus/sdk'; ``` ## Wallets | Type | Standard | | -------------- | -------- | | EOA | EIP-191 | | Contract | EIP-1271 | | Counterfactual | EIP-6492 | ## Related Flow. HTTP. Ids. Envelope. # Token balance Source: https://docs.neus.network/verification/token-holding Gate access when a wallet holds a minimum balance. **Verifier ID:** `token-holding` ## Use cases * Balance-based access * Governance or membership tiers * Token utility products ## Flow type Lookup. NEUS checks current token balances. ## Required Fields | Field | Required | Notes | | -------------------- | -------- | -------------------------------------------------------------------------------------------------------- | | `contractAddress` | Yes | Token contract or mint | | `minBalance` | Yes | Human-readable token amount, e.g. `"10.5"`. Converted with the token's on-chain decimals, not base units | | `chainId` or `chain` | Yes | Chain id or CAIP-2 chain | | `ownerAddress` | No | Wallet to check; defaults to the signer | | `blockNumber` | No | Check the balance at a specific block | ## Example ```json theme={"dark"} { "contractAddress": "0x...", "minBalance": "100", "chainId": 8453 } ``` Full schema: [`token-holding.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/token-holding.json). # Available verifiers Source: https://docs.neus.network/verification/verifiers Choose a verifier based on the decision your product needs to make. ## By outcome | Need | Verifier | Type | | ----------------- | ------------------------------------------------ | ----------- | | Content ownership | [ownership-basic](./ownership-basic) | Instant | | Social link | [ownership-social](./ownership-social) | Interactive | | Domain | [ownership-dns-txt](./ownership-dns-txt) | Lookup | | Org / team | [ownership-org-oauth](./ownership-org-oauth) | Interactive | | Username / handle | [ownership-pseudonym](./ownership-pseudonym) | Instant | | Linked wallets | [wallet-link](./wallet-link) | Instant | | NFT gate | [nft-ownership](./nft-ownership) | Lookup | | Token gate | [token-holding](./token-holding) | Lookup | | Contract control | [contract-ownership](./contract-ownership) | Lookup | | Human | [proof-of-human](./proof-of-human) | Interactive | | Wallet risk | [wallet-risk](./wallet-risk) | Lookup | | Content safety | [ai-content-moderation](./ai-content-moderation) | Lookup | | Agent identity | [agent-identity](../agents/agent-identity) | Instant | | Agent authority | [agent-delegation](../agents/agent-delegation) | Instant | ## Types | Type | Behavior | Examples | | ----------- | ------------ | -------------------------------- | | Instant | Wallet signs | ownership-basic, agent-identity | | Interactive | Hosted flow | ownership-social, proof-of-human | | Lookup | Live state | nft-ownership, token-holding | ## By category ### Identity | Verifier | Confirms | | -------------------------------------------- | -------------- | | [ownership-social](./ownership-social) | Social account | | [ownership-dns-txt](./ownership-dns-txt) | Domain | | [ownership-org-oauth](./ownership-org-oauth) | Org membership | | [ownership-pseudonym](./ownership-pseudonym) | Username | | [wallet-link](./wallet-link) | Linked wallets | ### Ownership | Verifier | Confirms | | ------------------------------------------ | ---------------- | | [ownership-basic](./ownership-basic) | Content / claim | | [contract-ownership](./contract-ownership) | Contract control | ### Access | Verifier | Confirms | | -------------------------------- | ----------------- | | [nft-ownership](./nft-ownership) | NFT holder | | [token-holding](./token-holding) | Balance threshold | ### Abuse | Verifier | Confirms | | ------------------------------------------------ | -------------- | | [proof-of-human](./proof-of-human) | Human | | [wallet-risk](./wallet-risk) | Risk signal | | [ai-content-moderation](./ai-content-moderation) | Content safety | ### Agents | Verifier | Confirms | | ---------------------------------------------- | --------------------- | | [agent-identity](../agents/agent-identity) | Who the agent is | | [agent-delegation](../agents/agent-delegation) | What the agent may do | ## Bundles Ready-made `?preset=` bundles, or combine verifiers with `?verifiers=id1,id2`. See [Presets](../platform/presets). | Preset | Verifiers | For | | ---------------- | ----------------------------------------------------------------- | --------------- | | `agent-pack` | agent-identity + agent-delegation + wallet-risk | Scoped agents | | `project-pack` | contract-ownership + ownership-dns-txt | Project trust | | `creator-pack` | ownership-basic + ai-content-moderation | Content trust | | `workspace-pack` | ownership-social + ownership-basic + agent-identity + wallet-link | Team onboarding | ## Next First proof. Guided. Add one. # Linked wallets Source: https://docs.neus.network/verification/wallet-link Bind a secondary wallet to a primary account. Reuse the link later. **Verifier ID:** `wallet-link` ## Use cases * Multi-wallet identity * Agent and controller wallets * Account portability ## Flow type Instant. The secondary wallet signs the linking payload. ## Browser UX For end-user browser flows, prefer **Hosted Verify** at [`/verify`](https://neus.network/verify). The hosted flow now stages wallet linking first: 1. Connect the secondary wallet 2. Sign the wallet-link payload 3. Show **Linked** 4. Continue to create the proof Use direct/API mode only for advanced integrations that already control the secondary-wallet signature step. ## Required Fields | Field | Required | Notes | | ------------------------ | -------- | ----------------------------------------------- | | `primaryWalletAddress` | Yes | Primary wallet | | `secondaryWalletAddress` | Yes | Secondary wallet | | `signature` | Yes | Secondary wallet signature | | `signatureMethod` | Yes | `eip191` for EVM, `ed25519` for non-EVM | | `chain` | Yes | CAIP-2 chain | | `signedTimestamp` | Yes | Unix ms timestamp | | `relationshipType` | No | `linked` (default), `controller`, or `delegate` | | `label` | No | Display label for the link | Instead of `primaryWalletAddress` / `secondaryWalletAddress` + `chain`, you may pass CAIP-10 `primaryAccountId` and `secondaryAccountId`. ## Example Advanced direct/API payload after the secondary wallet has already signed: ```json theme={"dark"} { "primaryWalletAddress": "0x...", "secondaryWalletAddress": "0x...", "signature": "0x...", "signatureMethod": "eip191", "chain": "eip155:84532", "signedTimestamp": 1730000000000 } ``` Full schema: [`wallet-link.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/wallet-link.json). # Wallet risk Source: https://docs.neus.network/verification/wallet-risk Screen a wallet before payments, access, or high-value actions. **Verifier ID:** `wallet-risk` ## Use cases * Payment flows * Fraud checks * High-risk onboarding ## Flow type Lookup. NEUS checks wallet risk through an external provider. ## Required Fields | Field | Required | Notes | | -------------------- | -------- | ------------------------------------------------------------------------------------------------------ | | `walletAddress` | Yes | Wallet to assess | | `provider` | No | Example: `webacy` | | `chain` or `chainId` | No | Chain context: `eth`, `base`, `bsc`, `pol`, `opt`, `arb`, `sol`, `ton`, `sei`, `sui`, `btc`, `stellar` | ## Example ```json theme={"dark"} { "walletAddress": "0x...", "chain": "base" } ``` Full schema: [`wallet-risk.json`](https://github.com/neus/network/blob/main/docs/verifiers/schemas/wallet-risk.json). # Technical Whitepaper Source: https://docs.neus.network/whitepaper NEUS Portable Trust Infrastructure for humans and AI. ## Portable Trust Infrastructure for Humans and AI Architecture and Trust Model. Version 1.0, August 2026. **Author:** Christopher Leal, Founder and Protocol Architect, NEUS Network, Inc. **Contact:** [chris@neus.network](mailto:chris@neus.network) ## Abstract Trust decisions still reset at application boundaries. Users repeatedly prove control of accounts, domains, wallets, and assets, while AI agents often operate with credentials that say little about what they are allowed to do at the moment of action. NEUS turns completed identity, ownership, risk, eligibility, and authority checks into portable proofs that other systems can evaluate and reuse under their own policy. A gate evaluates those proofs immediately before a protected action. Missing, stale, expired, revoked, or out-of-scope proofs stop the action or trigger the required verification. Proofs are private and offchain by default. [CAIP-380](/learn/standards/caip-380) supports signed wallet verification requests, while NEUS stores verifier results and lifecycle state separately. This separates request integrity from verification outcomes and current authority. ## 1. Problem and design goals Authentication can identify a session. It does not carry a completed trust decision into the next system or define current authority for a sensitive action. Users and applications repeatedly rebuild checks for identity, ownership, eligibility, and risk. Agents add a more urgent problem: they are commonly given credentials that are broader than the action they need to perform. Possession of a session or API key says little about who approved a payout, which resource a grant covers, what limits apply, or whether approval is still current. NEUS treats trust as a current decision about a subject, an action, and a resource. It applies the same resource-centered principle used in zero-trust architectures: authority is not inferred from network location or possession of a broad credential. It is evaluated for the protected resource under current policy \[10, 11]. | Principle | Meaning | | ---------------------- | --------------------------------------------------------------------------------------------------- | | Reuse first | Look for an acceptable current proof before starting another check. | | Local policy | Each relying party decides which issuers, verifiers, freshness, scope, and assurance it accepts. | | Enforce at action time | Evaluate trust immediately before the protected action. | | Private by default | Routine proof creation and evaluation do not require public disclosure or a blockchain transaction. | ## 2. Trust model and roles NEUS reduces the flow to five steps: resolve, check, verify, evaluate, then act or stop. Reuse-first verification lifecycle: resolve, check current receipts, verify only missing or stale checks, evaluate policy, then act or stop. A proof can be reused only when the relying party accepts its source and it still satisfies current policy. NEUS does not create universal trust. It provides a common proof model that different systems can evaluate under their own policy. Related credential standards also separate issuers from verifiers; NEUS preserves that separation of roles \[9]. | Role | Responsibility | | ------------- | ---------------------------------------------------------------------------------------------------- | | Subject | The human, organization, account, agent, wallet, domain, asset, or other object the proof describes. | | Verifier | Runs a defined check and returns a result limited to that check. | | Issuer | Attributes the proof to the service or verification path that produced it. | | Controller | Grants authority to an agent when delegation is required. | | Relying party | Chooses what it trusts and which policy must hold before an action. | | Gate | Evaluates current proofs and policy at the protected boundary. | NEUS system architecture: integration surfaces feed the verification engine, which produces saved results that gates evaluate before protected actions. The protected system must enforce the gate on the server or inside the trusted runtime. Any path that bypasses the gate bypasses the protection. ## 3. Portable proofs A NEUS proof is a saved verification result that another accepted integration can evaluate without rerunning the original check. It records what was checked, the subject it applies to, the outcome, the issuer, current status, expiration, visibility, and any scope or constraints needed to evaluate the result. Portability means the result can move across integrations that choose to accept it. It does not mean every system must trust the issuer, that evidence becomes public, or that a historical copy remains valid forever. | State | Current use | | ------------------ | ----------------------------------------------------------------------------- | | Pending | Not acceptable until the required check has completed successfully. | | Passed and active | May be acceptable if issuer, subject, freshness, scope, and policy also pass. | | Failed | Does not satisfy a requirement that expects a passing result. | | Expired or revoked | Do not accept for future actions, even if the proof passed earlier. | Outcome and lifecycle are separate. A prior success never overrides expiry or revocation. High-value actions should check current status close to execution so that a decision does not rely on stale authority. ### Privacy and anchoring Proofs are private and offchain by default. Public proof pages are a disclosure choice, not a higher assurance level. Optional onchain anchoring can create a durable reference, but the anchor is not the verifier result and does not replace a current status check. ## 4. Agent identity and authority An agent needs two different records: one that identifies the agent and one that states what the agent may do. Combining them would turn descriptive capability into implied permission. Agent identity and authority model: agent identity receipt describes the agent, controller-signed delegation receipt grants specific actions and limits, runtime gate evaluates both before a protected tool call. Capabilities describe what an agent can do. Delegation determines what it is allowed to do. A payment-capable agent, for example, may still have no authority to pay a particular recipient or may be limited to a specific amount, network, resource, or time window. ### Delegation boundaries * Bind the controller to the exact agent account that receives authority. * State allowed actions and explicit denied actions. A denial takes precedence over a general allowance. * Scope authority to the relevant resource, environment, payment type, or operation. * Apply spend limits and expiry for payments and other high-impact actions. * Require human approval when policy calls for an additional approval step. Delegation narrows what an agent is allowed to affect. It does not guarantee safe reasoning. Sandboxing, output validation, rate limits, secret handling, and human approval remain necessary controls around the runtime. ## 5. Gate enforcement and security considerations A gate turns current proof state into an enforceable decision at the point where value, data, or infrastructure can change. The decision is local: two applications can evaluate the same proof differently because they accept different issuers, freshness windows, scopes, or risk levels. Gate evaluation pipeline: resolve policy and receipts, validate bindings and current lifecycle state, apply scope and constraints, then allow, require approval, or deny before execution. High-value decisions should bind policy to the exact action parameters. A payment can bind amount, asset, destination, and network. A deployment can bind repository, artifact, environment, and operation. This reduces the gap between what was approved and what actually runs. ### Security considerations The security model depends on four explicit assumptions: * The relying party controls which issuers and verifiers it accepts. * The protected action cannot execute through a path that bypasses the gate. * Controller and subject signing keys remain uncompromised. * Current status and revocation data are available when policy requires them. ### Threats addressed * **Replay and stale state.** Enforce freshness and current status. Expired or revoked proofs must not authorize a new action. * **Subject substitution.** Bind each proof to the actor and resource involved in the current action. * **Scope escalation.** Authority for one action, resource, destination, or amount does not imply broader authority. * **Gate bypass.** Do not expose an alternate path to the protected action that avoids evaluation. * **Verifier or issuer compromise.** Assurance is limited by the sources the relying party chooses to trust. * **Availability failure.** If required current status cannot be established, high-risk actions should fail closed. ### Out of scope NEUS does not replace authentication, endpoint authorization, payment settlement, runtime sandboxing, secrets management, rate limiting, or observability. It does not guarantee that an agent will reason safely. Integrators remain responsible for those controls and for ensuring that protected actions cannot bypass the gate. ## 6. Standards and interoperability NEUS uses existing standards for account identifiers, signatures, agent discovery, tool access, and payments rather than redefining those layers. ### CAIP-380 Portable Proof [CAIP-380](/learn/standards/caip-380) is a Chain Agnostic Improvement Proposal in Draft status \[1]. It defines a canonical signed envelope for wallet-based verification requests. NEUS implements the envelope for applicable requests and stores the verifier result separately as a NEUS proof. For CAIP-380 requests, `qHash` is a deterministic SHAKE-256 hash of the canonical request \[1, 12]. NEUS can use the same value to correlate that request with its stored proof. `qHash` establishes correlation, not the verifier outcome. A valid request signature does not prove that a verifier ran or that a stored proof is still active. CAIP-380 request envelope and NEUS proof: the signed envelope proves request integrity, the NEUS proof records the verifier outcome and lifecycle state, qHash correlates them but does not prove the result by itself. CAIP-380 uses CAIP-2 and CAIP-10 for chain and account identifiers \[1-4]. Signing follows the chain's native scheme. The envelope accepts any CAIP-2 namespace. Detailed canonicalization and validation rules remain in the CAIP and implementation documentation. | Protocol | Role beside NEUS | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CAIP-2 and CAIP-10 | Chain and account identifiers for cross-chain bindings \[2]. | | CAIP-380 | Signed request envelope for applicable wallet verification \[1]. | | MCP | Tool and context interface where proofs can be checked before sensitive actions \[5]. | | A2A | Agent discovery, authentication, and interaction surface. NEUS can expose agent cards with proof context \[6]. | | ERC-8004 | Draft agent identity, reputation, and validation registry standard. NEUS can expose compatible discovery data while retaining its own proof and authority model \[7]. | | x402 | HTTP-native payment challenge and settlement. NEUS authority remains separate from settlement and can be checked before payment \[8]. | These protocols solve different problems. An authenticated connection, discovery card, or payment rail is not proof of current authority. The relying party still evaluates accepted proofs and local policy before the protected action. See [Standards & interoperability](/learn/standards) for the current list and links. ## 7. Applications and implementation The same proof and gate model applies across browser flows, backend services, agent runtimes, and payment boundaries. * **Agent actions.** Check agent identity and scoped delegation before a tool call, write, deployment, payment, or private data access. * **Marketplace and partner access.** Combine ownership, risk, or eligibility proofs at the protected boundary and reuse them where the relying party accepts them. * **Organization and domain control.** Use domain, organization, account, and wallet proofs before partner handoff or sensitive API writes. * **Payments.** Evaluate identity, delegation, amount, asset, destination, and network before the settlement flow proceeds. ### Implementation and stewardship NEUS Network, Inc. develops and operates the hosted NEUS trust service and maintains its public developer interfaces and implementation. Open standards used by NEUS remain governed through their respective standards processes. The live verifier catalog, schemas, API behavior, and SDK methods are maintained in the NEUS documentation and public repository. ## Conclusion NEUS separates proof from policy and identity from authority. It does not require applications to share one trust policy; it gives them a common proof model and a common point of enforcement. Completed checks can be reused where accepted, while current authority is evaluated at the moment an action matters. For agents, that creates a narrow, revocable path from identity to delegated authority to execution without treating login, capability, or payment as permission. ### Implementation resources * Platform: [neus.network](https://neus.network) * Documentation: [docs.neus.network](https://docs.neus.network) * Public repository: [github.com/neus/network](https://github.com/neus/network) * Trust Center: [smart-contract audit](https://neus.network/trust-center#smart-contract-audit) ## References ### Specifications and standards * **\[1]** Chain Agnostic Improvement Proposals. [CAIP-380: Portable Proof](https://standards.chainagnostic.org/CAIPs/caip-380). Status: Draft. * **\[2]** Chain Agnostic Improvement Proposals. CAIP-2: Blockchain ID Specification; CAIP-10: Account ID Specification. * **\[3]** Ethereum Improvement Proposals. ERC-191 and ERC-1271. * **\[4]** Ethereum Improvement Proposals. ERC-6492: Signature Validation for Predeploy Contracts. * **\[5]** Model Context Protocol. Specification, 28 July 2026. * **\[6]** A2A Protocol. Specification v1.0. * **\[7]** Ethereum Improvement Proposals. ERC-8004: Trustless Agents. Status: Draft. * **\[8]** x402 Foundation. x402 Version 2 Specification. ### Informative references * **\[9]** W3C. Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 May 2025. * **\[10]** NIST. SP 800-207: Zero Trust Architecture. * **\[11]** Ward, R.; Beyer, B. BeyondCorp: A New Approach to Enterprise Security. ;login:, 39(6), 2014. * **\[12]** NIST. FIPS PUB 202: SHA-3 Standard. * **\[13]** Rescorla, E.; Korver, B. RFC 3552: Guidelines for Writing RFC Text on Security Considerations. # Widgets Source: https://docs.neus.network/widgets/overview Add React gates and status badges with one gate ID while keeping check logic out of your app. Put **VerifyGate** in front of protected content. Put **ProofBadge** where you show status. Same results your server trusts. * **VerifyGate** reuses a saved result, opens Hosted Verify only when needed, then shows your content. Pass one `gateId`. * **ProofBadge** shows status for any saved result. Pass a proof ID. ## Install ```bash theme={"dark"} npm install @neus/sdk react react-dom ``` | Export | For | | ------------------ | --------------------------------------------------------------- | | `VerifyGate` | Require a current check before content, payment, or a tool runs | | `ProofBadge` | Status badge | | `SimpleProofBadge` | Minimal verified badge | | `NeusPillLink` | Link to the result page | | `VerifiedIcon` | Standalone icon | Import from `@neus/sdk/widgets`. ## VerifyGate ```jsx theme={"dark"} import { VerifyGate } from '@neus/sdk/widgets'; export default function ProtectedPage() { return ( ); } ``` The published gate owns check inputs, pricing, and checkout. [Privacy](../platform/security-and-trust) ## ProofBadge ```jsx theme={"dark"} import { ProofBadge } from '@neus/sdk/widgets'; ``` ## Next Props, modes, and Hosted Verify handoff. Browser, server, and assistant paths. # VerifyGate Source: https://docs.neus.network/widgets/verifygate Drop-in checkout for a published NEUS gate. `VerifyGate` checks eligibility, opens **Hosted Verify** when a new check is needed, then renders your protected content. The default path is a **published gate**, not a manual check list. ## Quickstart 1. In [your profile → Listings](https://neus.network/profile?tab=portals), create a listing and choose the checks visitors must pass. 2. Publish the gate and copy your **checkout link** or **embed snippet**. 3. Paste the embed in your app, or send users to the hosted link. 4. Optionally run `gateCheck` on your server before granting access. ```jsx theme={"dark"} import { VerifyGate } from '@neus/sdk/widgets'; export function Page() { return (
Unlocked
 ); } ``` ```js theme={"dark"} import { getHostedCheckoutUrl } from '@neus/sdk'; const url = getHostedCheckoutUrl({ gateId: 'gate_your-app-name', returnUrl: 'https://yourapp.com/continue', }); ``` ```js theme={"dark"} import { NeusClient } from '@neus/sdk'; const client = new NeusClient(); const result = await client.gateCheck({ gateId: 'gate_your-app-name', address: user.walletAddress, }); ``` Billing and check policy come from the gate. You do not register an app or pass `billingWallet` for this path. ## Key props | Prop | What it does | | ------------------- | ------------------------------------------------------ | | `gateId` | Published gate handle (default) | | `strategy` | Reuse, reuse-or-create, or fresh proofs | | `mode` | Create vs access behavior | | `qHash` | Existing proof for access mode | | `hostedCheckoutUrl` | Override hosted verify base URL | | `oauthProvider` | Pre-select social or org sign-in on hosted verify | | `wallet` | Optional signer for private proof reuse or access mode | ## Default create behavior Create mode opens **Hosted Verify**. The published gate owns verifier inputs, pricing, and checkout policy. ## Hosted OAuth Social, organization, and human checks use **[Hosted Verify](../cookbook/auth-hosted-verify)**. Set `oauthProvider` when the user already picked a provider in your app. Allowed values: * **Social:** `x`, `twitter`, `github`, `discord`, `facebook`, `linkedin`, `telegram` * **Org:** `google`, `microsoft` ## Advanced server proofs For backend-created proofs after a one-time user approval, use the server-side `verifyFromApp` flow in [Integrations](../cookbook/integrations). Keep browser checkout on `gateId`. ## Next Server eligibility and paid gate checkout. Browser, server, and assistant paths. Create and poll proofs from code.