Developers

Give your agent an identity and a wallet in one MCP call.

One remote MCP server gives Claude, ChatGPT and any MCP client a verified owner, named agents under a spending policy, private facet proofs and x402 payment. A REST API and SDKs cover servers and merchants.

In development Every sample on this page is illustrative. Package names, hosts and fields are subject to change. Nothing here is available yet.
MCP servermcp.silsacommerce.com/mcpIn development
REST APIapi.silsacommerce.com/v1Planned
SDKs@sils/sdk · silsPlanned
Payment schemesils-proofIn development

Quickstart

From zero to a paid request in four steps.

Connect the server. Verify the owner once. Create an agent with a policy. Let the agent pay a 402 endpoint. Each step shows the MCP call an assistant makes, and the same call from TypeScript, Python and cURL.

Who signs what.The MCP server and the API hold no user keys. Owner actions, such as completing verification, creating agents and changing policy, go to a passkey approval page. Agents pay with a session key bounded by their policy.8
Step 1 of 4In development

Connect the remote MCP server.

Add one URL to your assistant. The client discovers the authorization server and runs OAuth on its own. Servers and scripts use a secret key from the console instead.

// Claude: claude_desktop_config.json, or Settings > Connectors > Add custom connector
// ChatGPT: Settings > Connectors > Create, then paste the same URL
{
  "mcpServers": {
    "sils": {
      "type": "http",
      "url": "https://mcp.silsacommerce.com/mcp"
    }
  }
}
Illustrative. Subject to change. Package names, hosts and key prefixes are placeholders.
Step 2 of 4In development

Verify the owner.

Verification happens once, off chain, with regulated identity partners. SILS returns a one-time link. The owner completes document and liveness checks in the browser and comes back with a .revo name. The chain stores a commitment, never the documents.8

// tools/call: sils.start_verification
{ "name": "rob", "level": "L2" }

// result.structuredContent
{
  "session": "ver_7Qm2xK",
  "verificationUrl": "https://verify.silsacommerce.com/s/ver_7Qm2xK",
  "expiresIn": 900
}
// result.content[0].text
// "Tap this link to verify."

// tools/call: sils.status, after the owner returns
{ "session": "ver_7Qm2xK" }
// => { "state": "verified", "name": "rob.revo", "level": "L2" }
Illustrative. Subject to change. Levels follow the Revolution Name Service verification levels.
Step 3 of 4In development

Create an agent with a policy.

Each agent is a soulbound child name of its owner. The policy sets caps per transaction and per period, allowed categories, required counterparty facets, an approval threshold and an expiry. The agent cannot exceed it. The owner approves the creation with a passkey.

// tools/call: sils.create_agent
{
  "parent": "rob.revo",
  "label": "shopping",
  "purpose": "Buy books and household items",
  "policy": {
    "perTx": "25.00 USDC",
    "perMonth": "200.00 USDC",
    "categories": ["retail", "books"],
    "counterpartyFacets": ["entity.verified"],
    "approvalOver": "40.00 USDC",
    "expires": "2027-01-01"
  }
}

// result, after the owner approves with a passkey
{
  "agent": "shopping.rob.revo",
  "status": "active",
  "policyHash": "0x9c1e...4b7a",
  "explorer": "https://explorer.example/tx/0x31d0...a2"
}
Illustrative. Subject to change. Example names and limits are not real accounts.
Step 4 of 4In development

Pay a 402 endpoint.

Point the agent at any x402 resource. SILS reads the PAYMENT-REQUIRED header, checks the policy, builds the payment and retries with PAYMENT-SIGNATURE. If the request breaks the policy, nothing moves.

// tools/call: sils.pay  (annotated destructive)
{
  "agent": "shopping.rob.revo",
  "resource": "https://acme.example/api/v1/report",
  "maxAmount": "25.00 USDC"
}

// result.structuredContent
{
  "status": "settled",
  "amount": "24.00 USDC",
  "payTo": "sales.acme.revo",
  "receipt": "rcpt_4hT9wQ",
  "explorer": "https://explorer.example/tx/0x8a4c...19"
}
// result.content[0].text
// "Paid 24.00 USDC to sales.acme.revo. Proof valid. Owner verified. Within policy."
Illustrative. Subject to change. In the proof of concept, sils.pay settles transparently. The private sils-proof scheme is in development.

Reference

MCP tools.

Every tool returns a plain-language summary next to its structured fields, so the assistant can narrate without inventing. Every mutating tool returns an explorer link. Every tool is idempotent on retry. Read tools are annotated read-only. Value-moving tools are annotated destructive and ask the owner when policy requires it.

ToolInputsReturnsSignerStatus
sils.start_verificationdesired name, level (L1 or L2)one-time verification URL, session idOwner, in browserIn development
sils.statussession idverified or pending, .revo name, level, wallet addressRead-onlyIn development
sils.create_agentparent, label, purpose, optional policyagent name, agent account, policy hash, explorer linkOwner passkeyIn development
sils.set_policyagent, cap per tx and per period, categories, counterparty facets, approval threshold, expirynew policy hash, delegation idOwner passkeyIn development
sils.prove_facetfacet, verifier URL or address, challenge nonceproof, nullifier, verification resultAgent session keyIn development
sils.payagent, resource URL or payTo name, amount or max, asset, memosettlement status, receipt id, explorer link, feeAgent session key, within policyIn development
sils.resolveany .revo nameowner chain, level, status, policy summary, created dateRead-onlyIn development
sils.list_agentsowner name, optional status filteragents with status and policy summaryRead-onlyPlanned
sils.revoke_agentagent name, reasonrevocation record, effective at the next transactionOwner passkeyPlanned
sils.fetch_receiptreceipt id or settlement idamount, payTo, facets proven, timestamp. No payer data.Read-onlyPlanned

Illustrative. Tool names follow the MCP naming rules: 1 to 128 characters from letters, digits, underscore, hyphen and dot.3 Execution errors return isError: true with a readable message.

Security

MCP auth.

The SILS MCP server follows the MCP specification revision 2025-11-25. It is a remote server over Streamable HTTP and an OAuth 2.1 protected resource.

  • Streamable HTTP. One endpoint for POST and GET. The server validates the Origin header and tracks sessions with MCP-Session-Id.1
  • OAuth 2.1 with PKCE. Authorization code flow with PKCE using the S256 method. Client ID Metadata Documents are preferred. Dynamic client registration is the fallback.2, 11
  • Protected resource metadata. The server publishes RFC 9728 metadata so clients find the authorization server without configuration.9
  • Audience-bound tokens. Clients send an RFC 8707 resource parameter. Tokens are bound to https://mcp.silsacommerce.com/mcp and rejected anywhere else.10
  • No token passthrough. The server never forwards the client's token to an upstream API. It holds no user keys.2, 8
  • Owner-signed actions use a passkey. Verification, agent creation, policy changes and revocation open an approval page. The owner signs there. The assistant never sees the key.8
POST /mcp HTTP/1.1
Host: mcp.silsacommerce.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.silsacommerce.com/.well-known/oauth-protected-resource"
Illustrative. Subject to change. Hosts and scope names are placeholders.

Protocol

The x402 v2 exchange, with sils-proof.

SILS Proof ships as a scheme inside x402 v2, not as a new protocol. The three v2 headers carry Base64-encoded JSON: PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE.4, 5 The merchant can offer sils-proof next to exact. The agent picks one.

1The agent requests the resource.
request
GET /api/v1/report HTTP/1.1
Host: acme.example
Accept: application/json
Illustrative. Subject to change.
2The merchant answers 402 and names its terms.
402 · PAYMENT-REQUIRED (decoded)
// HTTP/1.1 402 Payment Required
// PAYMENT-REQUIRED: base64(json below)
{
  "x402Version": 2,
  "resource": {
    "url": "https://acme.example/api/v1/report",
    "description": "Quarterly market report",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "sils-proof",
      "network": "eip155:<revolution-chain-id>",
      "asset": "USDC",
      "amount": "24000000",
      "payTo": "sales.acme.revo",
      "maxTimeoutSeconds": 60,
      "extra": {
        "facets": ["human.verified", "age.over.21", "jurisdiction.in:US"],
        "nonce": "b41f9a07c3e2...e0"
      }
    },
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "USDC",
      "amount": "24000000",
      "payTo": "0x5c1b...a9F2",
      "maxTimeoutSeconds": 60
    }
  ]
}
Illustrative. Subject to change. amount is in atomic units (24.00 USDC). asset is shown as a symbol. On the wire it is the token contract address.
3The agent retries with a proof bound to that nonce.
retry · PAYMENT-SIGNATURE (decoded)
// GET /api/v1/report
// PAYMENT-SIGNATURE: base64(json below)
{
  "x402Version": 2,
  "accepted": {
    "scheme": "sils-proof",
    "network": "eip155:<revolution-chain-id>",
    "asset": "USDC",
    "amount": "24000000",
    "payTo": "sales.acme.revo"
  },
  "payload": {
    "agent": "shopping.rob.revo",
    "nonce": "b41f9a07c3e2...e0",
    "facets": ["human.verified", "age.over.21", "jurisdiction.in:US"],
    "proof": "AAECAwQF...opaque...9f",
    "nullifier": "0x2e7d...c41b"
  }
}
Illustrative. Subject to change. The proof is opaque to the merchant. It carries no wallet address, balance or history.
4The merchant verifies, settles and returns the resource.
200 · PAYMENT-RESPONSE (decoded)
// HTTP/1.1 200 OK
// PAYMENT-RESPONSE: base64(json below)
{
  "success": true,
  "network": "eip155:<revolution-chain-id>",
  "settlement": "stl_Vb82kQ",
  "nullifier": "0x2e7d...c41b",
  "result": "Proof valid. Owner verified. Within policy."
}
Illustrative. Subject to change. A standard settlement response names the payer. Under sils-proof that field is left out by design.
CAIP-2 network ids.x402 v2 names networks with CAIP-2 ids, for example eip155:8453 for Base.6, 12 The Revolution chain id is not final. eip155:<revolution-chain-id> is a placeholder until Revolution publishes it.

What is proven

A settlement exists. It matches the stated amount, asset and recipient. It has not been presented before. It is bound to this merchant's nonce. Each requested facet holds. The proof system and circuit design are not published.8

Facilitator endpoints

EndpointRole in the exchangeStatus for sils-proof
POST /verifyChecks the payload against the stated terms and the nullifier set before the merchant does workIn development
POST /settleSettles on chain, spends the nullifier and returns the settlement responseIn development
GET /supportedLists supported scheme and network pairs, including sils-proof on RevolutionIn development

Endpoint names from the x402 v2 specification.4 SILS plans to use Revolution's open-source x402 facilitator.

Merchants

Accept agent payments in one middleware.

requireProof answers 402 with your terms. verifyPayment checks the retry through the facilitator. confirmOrder settles after you fulfil, so a failed order never charges the agent. Adapters are planned for Express, Hono and Next.js.8

import express from "express";
import { requireProof, verifyPayment, confirmOrder } from "@sils/sdk/merchant";

const app = express();

app.get(
  "/api/v1/report",
  requireProof({
    payTo: "sales.acme.revo",
    amount: "24.00",
    asset: "USDC",
    facets: ["human.verified", "age.over.21", "jurisdiction.in:US"],
  }),
  async (req, res) => {
    const payment = await verifyPayment(req); // facilitator POST /verify
    const report = await buildReport();
    const receipt = await confirmOrder(payment); // facilitator POST /settle
    res.set("PAYMENT-RESPONSE", receipt.header).json(report);
  },
);
Illustrative. Subject to change. SILS Merchant is in development. Adapters are not available yet.

Reference

Facets.

A facet is a yes or no claim about the owner, proven without the underlying data. The facet set is governance-set on Revolution. Parameterized facets take a value after a colon.8

FacetThe merchant learnsExampleStatus
human.verifiedA verified person stands behind the agenthuman.verifiedIn development
entity.verifiedA verified business stands behind the agententity.verifiedIn development
age.over.18The owner is over 18. Not the birth date.age.over.18In development
age.over.21The owner is over 21. Not the birth date.age.over.21In development
jurisdiction.inThe owner is in one of the listed countries. Not which one.jurisdiction.in:US,CA,GBIn development
jurisdiction.not.inThe owner is in none of the listed countriesjurisdiction.not.in:XX,YYIn development
sanctions.clearThe owner passed sanctions screeningsanctions.clearPlanned
investor.accreditedThe owner holds an accreditation credentialinvestor.accreditedPlanned
reputation.aboveThe agent's SILS Score clears a threshold. Not the score.reputation.above:700In development
kya.certifiedThe agent holds a Know Your Agent credentialkya.certifiedPlanned
mandate.coversThe purchase falls inside the owner's signed mandate. Not the budget.mandate.coversIn development

Illustrative. Facet strings from Revolution Network Whitepaper v2.0 §6.4 and §8.6. Threshold values and country codes in the examples are placeholders.

Platform

Platform conventions.

The REST API is Planned. These are the conventions it is designed around, so integrations stay predictable.

ConventionDesignStatus
Idempotency keysIdempotency-Key header on every write: verifications, agents, proofs, payments. A replay returns the saved result. A reused key with different parameters returns an error.Planned
Signed webhooksSILS-Signature header with a timestamp and an HMAC-SHA256 signature. Retries with backoff. No ordering guarantee. Deduplicate by event id.Planned
OpenAPI 3.1One public spec for the REST API. SDKs are generated from it.Planned
VersioningDate-based API versions. Semantic versions for SDKs.Planned
Rate limitsSeparate limits for sandbox and live keys, published per key and per MCP tool. 429 with Retry-After. Back off with jitter.Planned

Webhook events

identity.verifiedidentity.revokedagent.createdagent.revokedpolicy.updatedproof.verifiedsettlement.finalizednullifier.spent
webhook · settlement.finalized
// POST https://acme.example/webhooks/sils
// SILS-Signature: t=1791043200,v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd
{
  "id": "evt_3Nc81z",
  "type": "settlement.finalized",
  "created": "2026-10-03T14:00:00Z",
  "data": {
    "settlement": "stl_Vb82kQ",
    "amount": "24000000",
    "payTo": "sales.acme.revo",
    "facets": ["human.verified", "age.over.21"]
  }
}
Illustrative. Subject to change.

Reference

Errors.

Every error has a stable type and code, a sentence a person can read, and a request id for support. MCP tools return the same object inside a result marked isError: true.

403 · policy error
{
  "error": {
    "type": "policy_error",
    "code": "spend_cap_exceeded",
    "message": "Shopping tried to spend 250.00 USDC. The cap is 200.00 USDC. Blocked.",
    "param": "amount",
    "agent": "shopping.rob.revo",
    "requestId": "req_9Lx2Qe",
    "docUrl": "https://docs.silsacommerce.com/errors/spend_cap_exceeded"
  }
}
Illustrative. Subject to change.
TypeWhenExample code
auth_errorMissing, expired or wrong-audience tokentoken_audience_mismatch
policy_errorThe request breaks the agent's policyspend_cap_exceeded
proof_errorA facet does not hold, or the nullifier was already spentnullifier_spent
approval_requiredThe owner must approve with a passkeyover_approval_threshold
idempotency_errorA key was reused with different parameterskey_reused
rate_limit_errorToo many requests for this key or toolrate_limited

Sandbox

Testnets.

Test keys will not work on live networks. No real funds move. Each network is labeled with how SILS will verify payments on it.

NetworkCAIP-2 idUse in sandboxStatus
Revolution Virtus testneteip155:<placeholder>Names, agents, policy, facet proofs, sils-proof settlementPlanned
Base Sepoliaeip155:84532USDC payments with the exact schemePlanned
Solana devnetsolana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1USDC payments, verified by labeled attestationPlanned

Revolution's Virtus public testnet is in setup. Its chain id is not yet published.8 Base Sepolia and Solana devnet ids follow x402 network naming.7

Docs for agents

Docs your coding agent can read.

Most integrations will be written with an assistant in the loop. The docs are planned to be machine-readable from the start.8

llms.txt

An index of every docs page with a one-line summary, at the docs root.

IndexPlanned

Markdown twin of every page

Append .md to any docs URL to get clean Markdown with code intact.

Plain textPlanned

Docs MCP server

Search and fetch the docs from Claude, ChatGPT or an IDE agent over MCP.

MCPPlanned

Open in Claude, Open in ChatGPT

One button on each page opens it in an assistant with the page loaded as context.

ButtonsPlanned
llms.txt
# SILS
> Verified owners, agent policy, private proofs and x402 payment for AI agents.

## Quickstart
- [Connect the MCP server](https://docs.silsacommerce.com/quickstart/connect.md)
- [Verify the owner](https://docs.silsacommerce.com/quickstart/verify.md)
- [Create an agent](https://docs.silsacommerce.com/quickstart/agents.md)
- [Pay a 402 endpoint](https://docs.silsacommerce.com/quickstart/pay.md)

## Reference
- [MCP tools](https://docs.silsacommerce.com/reference/mcp-tools.md)
- [sils-proof scheme](https://docs.silsacommerce.com/reference/sils-proof.md)
- [Facets](https://docs.silsacommerce.com/reference/facets.md)
Illustrative. Subject to change. These URLs do not resolve yet.

Changelog

What changed, and when.

  1. Website and brand system published

    The SILS site and design system went public. This page describes interfaces in development. No API is open yet.

  2. Aligned with Revolution Network Whitepaper v2.0

    Identity moved to .revo names on Revolution Name Service. Private payment proofs are specified as a scheme inside x402, published here as sils-proof.

  3. MCP proof of concept tool surface defined

    Seven tools named and scoped: start_verification, status, create_agent, set_policy, prove_facet, pay and resolve. Three more planned.

A public status page is Planned.

Build with SILS before it ships.

Preview members get testnet keys as each network opens, and a say in the interface while it can still change.

Sources

  1. Model Context Protocol Specification 2025-11-25, "Transports," accessed Oct 3, 2026. modelcontextprotocol.io/specification/2025-11-25/basic/transports
  2. Model Context Protocol Specification 2025-11-25, "Authorization," accessed Oct 3, 2026. modelcontextprotocol.io/specification/2025-11-25/basic/authorization
  3. Model Context Protocol Specification 2025-11-25, "Tools," accessed Oct 3, 2026. modelcontextprotocol.io/specification/2025-11-25/server/tools
  4. x402 Foundation, "x402 Specification v2," Dec 9, 2025. github.com/x402-foundation/x402
  5. x402 docs, "HTTP 402," accessed Oct 3, 2026. docs.x402.org/core-concepts/http-402
  6. x402 docs, "Migration Guide: V1 to V2," accessed Oct 3, 2026. docs.x402.org/guides/migration-v1-to-v2
  7. x402 docs, "Networks & Token Support," accessed Oct 3, 2026. docs.x402.org/core-concepts/network-and-token-support
  8. Revolution Network Whitepaper v2.0, October 2026, draft for review: §6.2, §6.4, §8.6, §11, §11.5, §11.6, §14.
  9. IETF, RFC 9728, "OAuth 2.0 Protected Resource Metadata." rfc-editor.org/rfc/rfc9728
  10. IETF, RFC 8707, "Resource Indicators for OAuth 2.0." rfc-editor.org/rfc/rfc8707
  11. IETF, RFC 7636, "Proof Key for Code Exchange by OAuth Public Clients." rfc-editor.org/rfc/rfc7636
  12. Chain Agnostic Standards Alliance, "CAIP-2: Blockchain ID Specification." chainagnostic.org/CAIPs/caip-2