How each actor uses SEED Clearance now

This page is the role-level operating guide for the current Clearance surface. It keeps bounded P2/P3 evidence separate from A3-G8 canary economic evidence, production wallet payout, and private payment.

Truth boundary

• P2/P3 has bounded evidence: challenge, BBS+ verification, replay protection, and signed receipt.
• A3-G8 canary evidence is bounded: product-origin consume, materialize, fund, release, claimable-balance query, canary `MsgClaim`, replay guard, holder-vault credit and 45/30/15/10 reconciliation are evidenced for the bounded lineage.
• Earth/Mars validator runtime alignment is proven on e63c2a0, and G8 remediation evidence records the c4a2735 release running on Earth and Mars.
• Hosted rewards, production wallet payout, public claim actions outside the canary, 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 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.

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-G8 proves a bounded canary claim and holder-vault credit, but it is still not a hosted rewards center or production 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
  -> 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, local-contract accounting lookup when the service bridge is explicitly configured, and read-only display of A3-G8 canary evidence when clearly labeled. It is not yet a private-note wallet and does not execute production 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.
• Before proof/state closure, show only: Private Commanded Payment: proof backend pending.

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-G8 canary lineage, but product copy must label it as canary evidence and must not generalize it into production provider-paid claims.

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 labeled as A3-G8 canary evidence only.

Operator / validator

Operators keep runtime truth separate from product claims. Earth and Mars validators were aligned for the G4 runtime and the G8 remediation evidence records the c4a2735 release running on Earth and Mars. A3-G8 is bounded canary claim evidence, not a production economic payout claim, not a blanket validator-paid product claim, and not a permission for wallet payout UX.

• 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.

Private value handoff

Private Value Rail is in protocol closure. The current source surface validates inputs and then fails closed while the proof backend is pending; it is not private payment execution. The product wallet UX waits for frozen proof and state contracts, then for wallet storage, generated clients and E2E evidence.

Private Value Rail is in protocol closure.
Simple private spend does not depend on compute.
Command-bound spend uses compute proof when a command requires verified computation.
Partial payment is a full note spend plus a change note, not mutation of an existing note.
Degraded privacy exit after T_max is opt-in and non-private.
Backend evidence is in-process only.
Private earn payout is not live.
Vault custody is not live.

Product UX before proof/state closure:
  Private Commanded Payment: proof backend pending

The product must not claim:
  hidden amount reward
  private earn payout
  vault custody
  private payment
  degraded exit as private settlement
  shielded wallet live
  public token payout