ṚTA

Name: ṚTA
Price: 1 USDC

Show that a condition holds without revealing the value behind it. The verifier learns that the threshold was met, and nothing else.

Read this before you buy: proofs can be forged.
The ceremony is single-party. With one participant, the trapdoor material that would reveal a secret is known to that same person — who can therefore mint a proof for a secret that does not exist.
Until three independent parties take part, the key cannot be considered trusted. This is a limitation of the product, not a documentation gap.

What you can prove

Circuit	What it proves	Width
`account-age-180`	account age >= 180 days	16 bits
`balance-1000`	balance >= 1000	32 bits
`balance-100000`	balance >= 100000	48 bits
`stake-10000`	stake >= 10000	32 bits
`tx-count-50`	at least 50 transactions	16 bits

What the verifier learns: only that the threshold was met.
What they never learn: the balance, the stake, the account age, the transaction count.
The proof publishes zero public signals — measured on live proofs, not claimed.

Price and payment

1 USDC per verification

Network: Base mainnet · Protocol: x402 (v2) · no account, no subscription

Payment rides along with the request: the service answers with an invoice, the client signs the payment with its own wallet and repeats the request carrying it. No signup — just a wallet holding a little USDC.

How to use it

# 1. take a single-use token, one per proof
curl -s -X POST /v1/nonce \
  -H 'Content-Type: application/json' \
  -d '{"predicate": "balance_1000"}'

# 2. get the invoice: amount, network, payee address
curl -si -X POST /v1/verify \
  -H 'Content-Type: application/json' \
  -d '{"predicate": "balance_1000"}'
# → HTTP 402 plus an x402 header with the payment terms

# 3. sign the EIP-3009 payment with your wallet and put it
#    in the PAYMENT-SIGNATURE header

# 4. send the proof together with the payment
curl -s -X POST /v1/verify \
  -H 'Content-Type: application/json' \
  -H "PAYMENT-SIGNATURE: $PAYMENT" \
  -d '{"predicate":"balance_1000","proof":,
      "public_signals":[], "nonce":""}'

The reply carries a VERIFIED verdict, the transaction hash on chain, and an X-Payment-Response header. Replaying the same nonce is rejected: one payment, one verification.

Endpoints

Endpoint	What it does
`GET /healthz`	liveness, and the service states its own limits
`GET /v1/predicates`	circuits with their thresholds
`POST /v1/nonce`	single-use token, one per proof
`POST /v1/verify`	verify; answers 402 with an invoice when unpaid
`GET /api`	machine-readable service description

For agents

Soma hub — one MCP endpoint that gives an agent long memory, signed obligations and offline proofs. Facts outlive the session; work is promised, claimed and closed with a receipt anyone can check. Open the hub · live status · try memory without a token.

Limitations, stated plainly

State is on disk since 17.10.2026: issued and spent tokens survive a restart. Counters too.
No external audit of the circuits — we wrote them and we verified them.
Ceremony parameters were generated locally; a buyer cannot rebuild the chain.
Proofs are forgeable — see the warning above.

The name comes from Vedic cosmology: Ṛta is order, truth, and the right correspondence between action and consequence — which is precisely what a proof does. The consequence follows from the action by rule, and no other outcome is possible.