Proof of payment without the payer's history.

01 · Principles

Seven rules shape every component.

SILS builds on the Revolution Network design. These principles come from the Revolution whitepaper.¹ SILS adopts them as its own engineering constraints.

02 · Architecture

Six layers. Each depends on the layers below it.

The stack follows the Revolution layer model: identity, then payments, then discovery and enforcement, on top of the chain.⁷ SILS adds the access surfaces and a multichain settlement layer. The SILS Proof verifier is the point where payment, identity and policy meet.

Figure 1. SILS system layers. Status shown per layer. Revolution V2 is the planned primary settlement network, subject to a definitive agreement. Base, Ethereum and Solana are planned.

03 · Lifecycle

One private payment, end to end.

Standard x402 settles with a transfer authorization that names the payer, so the payer address is indexed on chain and visible to the merchant.¹³ SILS keeps the x402 v2 exchange and its three headers: PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE.¹⁴ It replaces what the payment payload carries. The merchant receives a proof, not a wallet.

Figure 2. Lifecycle of a private payment. Numbers match the steps below. Dashed arrows are responses. Illustrative. SILS Proof is in development.

// HTTP/1.1 402 Payment Required. Header decoded from Base64.
{
  "x402Version": 2,
  "resource": { "url": "https://api.acme.example/api/v1/report" },
  "accepts": [{
    "scheme": "sils-proof",
    "network": "eip155:<revolution-chain-id>",
    "asset": "USDC",
    "amount": "24000000",
    "payTo": "sales.acme.revo",
    "maxTimeoutSeconds": 120,
    "extra": {
      "facets": ["human.verified", "age.over.21", "jurisdiction.in:US"],
      "nonce": "b41f...e0"
    }
  }]
}

// Retry. Header decoded from Base64.
{
  "x402Version": 2,
  "accepted": { "scheme": "sils-proof", "network": "eip155:<revolution-chain-id>" },
  "payload": {
    "proof": "0x1f9a...c3",
    "nonce": "b41f...e0",
    "agent": "shopping.rob.revo"
  }
  // no payer address, no transfer authorization
}

// HTTP/1.1 200 OK. Header decoded from Base64.
{
  "success": true,
  "network": "eip155:<revolution-chain-id>",
  "payer": null,   // not disclosed
  "result": { "payment": "valid", "owner": "verified", "policy": "within" }
}

05 · Identity

Verified owners, soulbound agents, provable facets.

An owner verifies once, off chain. The chain records commitments, never attributes.⁵ The owner then creates agents as children of its .revo name: rob.revo owns shopping.rob.revo. Agent identities are soulbound. There is no transfer function. Revocation is permanent, and suspending a parent suspends every child.⁵ Each agent is mirrored read-only into the ERC-8004 registry with transfer disabled, so standard agent tooling can find it.^5,18

Verification levels

Levels are governance-set.⁵ SILS ID In development

Facets reference

A facet is one provable attribute of a verified identity. Each issuer commits credentials as leaves in a Merkle tree. The agent proves that a leaf satisfies the predicate and is not in the issuer's revocation set. Each proof carries a nullifier bound to the settlement, so it cannot be replayed.¹⁷ The initial set is governance-set.

Eleven initial facets.¹⁷ Facet proofs In development

On-chain state per identity

Nothing else is stored per identity. Routine root updates aggregate on a short cadence, with a planning figure of every 10 minutes. Revocations and high-value changes post immediately.¹⁷

06 · Policy

Policy is enforced at three points.

The owner signs a standing Mandatum for each agent. Its minimum fields are a per-transaction cap, a per-period cap, allowed categories, an optional counterparty allowlist, a human-approval threshold, an expiry and a kill switch. It is stored off chain with its hash on chain. The agent never holds the owner's key.¹⁰

• Netted micro-payments are checked as a batch against the caps on chain.¹¹
• Revocation posts immediately. A revoked identity or mandate fails at the next transaction, not the next batch.¹⁹
• Purchase-specific authorizations use the AP2 form of Intent, Cart and Payment mandates. Their hashes are anchored with agent identity and expiry.¹⁰

07 · The chain

Revolution V2: a ZKsync OS rollup on Ethereum.

Revolution V2 is a regenesis onto ZKsync OS, not an upgrade of V1.¹² ZKsync OS is EVM equivalent and works with standard EVM tooling.²⁰ From public testnet onward, batches carry Airbender validity proofs. Airbender is a RISC-V proof system using STARK and FRI, with the final proof wrapped for on-chain verification.^21,22 Data goes to Ethereum as blobs.

08 · Verifying nodes

Independent machines replay every block.

A verifying node is an external node run by a staked, approved operator. It replays every block and co-signs each batch before commit. The signatures add an execution check that is independent of the proof system, and they keep committed data on independent machines.²⁷ Operators are admitted through a business identity on Revolution Name Service, an on-chain allowlist, a stake and governance approval.²⁷

A SILS node gives SILS a locally verified view of settlements and nullifiers without trusting a third-party RPC.²⁸ Whether SILS becomes one of the independent mainnet signers is subject to Revolution governance.

09 · Cross-chain

Each network is verified differently. SILS says how.

Revolution is the planned primary settlement network. SILS plans to verify USDC payments on Base, Ethereum and Solana. The verification method, and the trust it requires, is not the same on each one.

Every SILS Proof is single use, whatever network carries the payment.

10 · Proof system

Selection criteria, not a choice.

SILS has not chosen a proving system for SILS Proof. Candidates will be benchmarked on the Revolution public testnet before a choice. Design details will be published after counsel review. Airbender is the chain's batch prover. It is separate from SILS Proof.

• Composition: payment, age, jurisdiction and mandate checks in one verification.⁶
• Mobile proving time, because agents and owners prove on their own devices where possible.
• Verification cost on Revolution. ZKsync precompiles include ecAdd, ecMul and ecPairing,²⁴ which pairing-based verifiers need.³⁴
• Setup trust: per-circuit setups add a ceremony for every circuit change.
• Audit maturity of the toolchain.

Reference figures for candidate systems

Figures come from public sources on different hardware and circuits. They are not comparable head to head and are not SILS measurements. SILS Proof In development Proving system not yet chosen.

11 · Threat model

Known threats and their mitigations.

Most rows come from the Revolution threat model.⁴¹ SILS adds rows for proof presentation and assistant access.

12 · Security commitments

Commitments before any value moves.

No audit of SILS or Revolution contracts or circuits is complete today. These are commitments, labeled as such. Circuit bugs such as under-constrained signals are a documented class of failure.⁴⁴