Modes d'emploi

How each actor uses SEED Clearance now

This page is the role-level operating guide for the current Clearance surface. It keeps the live P2/P3 clearance path separate from bounded A3-G4/G7 chain evidence, future wallet payout, and W7 private payment.

Truth boundary

P2/P3 is public-live: challenge, BBS+ verification, replay protection, and signed receipt.
A3-G4/G7 is bounded-live: product-origin consume, materialize, fund, release, claimable-balance query and hosted proof are evidenced for the current lineage.
Earth/Mars validator runtime alignment is proven on e63c2a0, and the public hosted proof route returns `200`.
`MsgClaim`, wallet payout, hosted rewards, public claim action, hidden amounts, and private payment are not live.

Consumer service

A consumer service is any app that requires a cleared user or agent before writing its own state. The current reference is `seed-survey`: it creates a challenge, accepts a receipt id, fetches the signed receipt server-side, checks the expected verifier, policy, schema, issuer, and claim type, then stores only a receipt hash with the vote.

consumer-flow.txt

consumer service
  -> POST /v1/challenge
  -> holder presents BBS+ proof to seed-clear
  -> service receives receipt_id from holder
  -> GET /v1/receipt/{receipt_id}
  -> verify signed receipt and policy fields
  -> write app state
  -> reject duplicate receipt hash

The consumer must not trust browser-side clearance. API keys stay server-side. An unknown receipt, wrong verifier, wrong policy, wrong schema, or replay must fail closed.

Holder human

A human holder gets a BBS+ credential from an issuer such as GitHub, Email OTP, or ShuftiPro, then presents only the required claim to a verifier challenge. The holder should not reveal raw login, email, token, wallet key, provider payload, or stable holder id to the consumer service.

holder-human-flow.txt

human holder
  -> obtains credential from issuer
  -> receives verifier challenge
  -> creates selective-disclosure presentation
  -> sends presentation to seed-clear
  -> receives signed receipt
  -> gives receipt_id to consumer service

If a local-contract economic test needs a subject reference, it is receipt-scoped: `subject:receipt:<sha256(receipt_id)>`. That avoids a stable universal holder identifier. A3-G4/G7 can prove a bounded claimable balance, but it is still not a public rewards or wallet payout surface.

AI assistant

An AI assistant is a holder only when it is acting through the local SEED permission layer or presenting a holder-controlled clearance receipt. It does not receive raw holder credentials, wallet keys, issuer secrets, claim secrets, or reusable proof material.

assistant-flow.txt

assistant
  -> requests a controlled action through local SEED bridge
  -> receives only allowed tool result or denial
  -> may pass receipt_id to a consumer when holder policy allows it
  -> never handles raw credential or private key material

Assistant integrations stay MCP/localhost bridge based. No hosted publication, autonomous payout, or private-payment claim is created by connecting an assistant.

Wallet/runtime

The current wallet/runtime responsibility is credential storage, presentation creation, receipt handling, and local-contract accounting lookup when the service bridge is explicitly configured. It is not yet a private-note wallet and does not execute payouts.

Store credentials and metadata locally.
Create BBS+ presentations bound to verifier challenge nonce.
Verify signed receipts offline with the pinned receipt key.
Use receipt-scoped subjects for local-contract accounting tests.
Do not present hidden amount, note, shielded spend, or private payment UI before W7 evidence.

Provider / issuer

A provider or issuer produces claim evidence and signs or supports BBS+ credential issuance. The hosted control-plane already consumes external live adapter evidence for GitHub OAuth, ShuftiPro accepted webhook, and Email OTP Resend. The current product can route a provider share in the bounded A3-G4 chain lineage, but public provider-paid wallet claims remain closed.

provider-law.txt

provider/issuer must:
  - own its issuer key material or configured adapter path;
  - fail closed on missing live config;
  - never return raw provider payload to the consumer;
  - publish/pin issuer public key through the approved trust path;
  - keep provider-paid language closed until claim evidence exists.

Operator / validator

Operators keep runtime truth separate from product claims. Earth and Mars validators now run the e63c2a0 runtime with binary alignment proved by ops. A3-G4/G7 is bounded claimable-query and hosted-proof evidence, not a public economic payout claim and not a blanket permission for wallet payouts.

No VPS mutation, restart, Caddy change, chain tx, or release switch without explicit GO.
Verify release manifests and binary paths before any rollout.
Record whether evidence is read-only, staged, canary, or live.
Keep seed-clear metrics private; public `/metrics` must refuse.

W7 handoff

W7 private payment starts only after explicit GO. If it starts before A3-G8 `MsgClaim`/wallet payout, it inherits the narrower claimable-only boundary and cannot claim paid wallets. It will add private notes, nullifiers, command binding, and REAP/RISC Zero proof verification. W7 does not lower the current ambition: it makes the economic rail private only after the proof backend, wallet storage, generated clients, and E2E evidence are real.

w7-entry-law.txt

W7 is held until explicit GO.
A3-G4/G7 no longer block by bridge absence or public 404.
A3-G8 MsgClaim / wallet payout remains open unless explicitly waived.
Read-only audit/spec work may continue.

Future W7 target contracts after explicit unlock:
  MsgShield
  MsgPrivateSpend
  MsgUnshield
  PrivateNoteV1
  SpendNullifierV1
  CommandBoundSpendProofV1

W7 must not claim:
  hidden amount reward
  private payment
  shielded wallet live
  public token payout