TEA: TEE attestation · Edge gateways · Anchor on Solana. Solana SVM settles; TEEs compute; digests only — never put GPU on-chain. Source: Solizardking/tea (public cut of clawd-tee).
Zero-std Rust program. Instructions: InitCounter (0), StoreProof (1, V1), StoreProofV2 (2). V2 stores a 372-byte TeeProofV2 PDA seeded by the signed payload hash, binding request ‖ response ‖ model ‖ nonce — plus sharded ProofCounterDay counters so proofs never fight over one global account.
Rust/axum OpenAI-compatible proxy. Each inference is hashed, signed inside the TEE boundary (secp256k1), attested (Intel TDX quote + NVIDIA NRAS for H100/H200 CC), and anchored via StoreProofV2 when a Solana keypair is configured. Replies carry a _clawd proof block + receipt headers. Hosted instance: clawd-tee-gateway-production.up.railway.app — live (checked from this desk 2026-11-13: ok:true, signing address 0x12d221eb…24209f; on-chain anchoring currently disabled on the hosted instance and SAS not yet initialized there — stated plainly, as the repo demands).
The redpill-verifier engine verifies TEE hardware across providers — Phala, NearAI, Chutes, Tinfoil — DCAP quote checks, signature verification, on-chain proof lookup. clawd-verifier (@clawd/tee-verifier) unifies verify + anchor in one package. Rewritten for self-hosted SVM anchoring, not someone else's black box.
The Arm TrustZone twin: an OP-TEE trusted application exposing the same signed_payload_hash shape as the TDX path, so TDX, OP-TEE, and future providers share one StoreProofV2 account model. Host ↔ TA ABI in optee/include/clawd_ta.h.
Verification levels stored on every TeeProofV2:
| Anchor | Address | Status |
|---|---|---|
| CLAWD-TEE proof program (live, per hosted gateway) | HvXe5RpCcduVYJWDyavmNKde4uEgUFEiYz99JYQT4DkP | devnet · executable — verified 2026-11-13 |
| Repo-default REDPILL_PROGRAM_ID | BnoUSPTE88ebzLb74RAnTogddDMzyBPtkmKxiRoRJG4L | declared in repo config — account not found on devnet/mainnet public RPC, checked 2026-11-13 |
| Solana Attestation Service (SAS) | 22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG | mainnet · live (Solana Foundation) — verified 2026-11-13 |
Privacy-first DeFi on Solana: Zcash Sapling shielded wallets, encrypted pools, TEE agents attested via SAS. Source: Solizardking/Dark-Defi-1 · themusebook/dark402 · Dark Payments
| Program | Address | Cluster · status |
|---|---|---|
| Dark Percolator — private perps engine (Dark family) | Cf8dRz9xhvdwU825LBu6SGHa3gcHMiJwVh8LciJK1hPz | devnet · executable — verified 2026-11-13 |
| Dark Percolator — Market 0 | 64kBzfr4wFLLiNBAh5iZ1xQLsEpFvAmqETFArkUKSccN | devnet · market account exists — verified 2026-11-13 |
| Dark Protocol — shielded balances / encrypted assets | 3KWLFYco7T2rUZkzjSSthjHGmbWmo9HAsRmvupDTomGC | devnet · executable — verified 2026-11-13 |
| Dark Shielded Wallet program | 4753b1cCrPzwr7taWWD8yrcM8dc98fTR7wCFdv1TsAbg | devnet · executable — verified 2026-11-13 |
| Dark Protocol note pool — Anchor program (deposit · withdraw · shielded_transfer) | E8zL7h9qHjC7sMf2WCYhdqS5iLkYhPJ9yAhTfevo74jm | devnet · built + executable — mainnet deploy pending funding (repo status) |
| Solana Attestation Service — Dark agent identity + inference receipts | 22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG | mainnet · live (Solana Foundation) |
Status chips above attempt a live read-only getAccountInfo from your browser against the public Solana RPC on load. If the read can't complete, the chip falls back to the desk-verified facts dated 2026-11-13 — nothing here is faked live. Credential name for Dark agent attestations: Dark Protocol Agents.
ShieldedWallet (deposit / transfer / balance), Sapling ZIP-32 HD keys, ChaCha20-Poly1305 note encryption, CommitmentTree + NullifierSet, PrivateSwapManager (Jupiter Ultra), price oracle. npm i @openclawdsol/dark-protocol-sdk
Confidential agents in TEEs: ClawdTeeAgent — sealed converse + shielded trade, quote verification before a single byte is sent, x402 dark-shielded payments, SAS identity + inference receipts.
Low-level protocol primitives: DarkProtocolClient, Sapling + note-encryption modules, privacy utilities, swap routing, AIAgentManager. Umbrella meta-package: dark-defi. SAS client (sas-lib) ships as a local workspace package.
Dark Payments (umbrella) — live at percolator.musebook.trade. Dark x402 — shielded x402 settlement, code public at themusebook/dark402. Dark Percolator / Dark Perps — private perps on the devnet program above. dark-x402-terminal — the cypherpunk CLI in the Dark-Defi-1 tree.
Attested-inference console for trading analysis. Prompts are sent to our own server-side proxy (/api/redpill/chat), which forwards them to the RedPill TEE gateway (api.redpill.ai, OpenAI-compatible) — the API key never touches your browser. Inference runs inside provider TEEs in the RedPill lineage (Phala / NearAI / Chutes / Tinfoil). Reading this page is public; running the console is gated to $CLAWD holders (wallet sign-in below).
This console spends real inference credits, so running it is for $CLAWD holders only. Browsing the terminal — every panel, every program chip — stays open to everyone. Connect your Solana wallet and sign a message to unlock the console. The signature proves wallet control only; it authorizes no transaction and no spend.
If the model proposes a trade, its parameters are transcribed here as an unsigned description for your own review. Submitting anything on-chain remains a separate, manual, wallet-signed step outside this terminal.
The network design that sits above this terminal's trust substrate. Clients publish AI or general compute jobs; independent providers compete to execute them; auditors evaluate results under task-specific rules; model and data publishers register provenance and usage terms; applications consume models through open gateways; and Solana programs coordinate identity, escrow, commitments, disputes, reputation, and settlement. Architecture & protocol specification — draft v0.1, filed with the Clawd Confidential Compute guide package.
FIVE SURFACES — one protocol, five interoperable parts:
Matches jobs with providers offering GPUs, CPUs, memory, storage, bandwidth, and supported runtimes. One-time batch jobs, long-running training jobs, evaluation jobs, embedding and indexing jobs, persistent inference capacity, and private or locality-constrained jobs.
Model training, adaptation, evaluation campaigns, and federated learning rounds: full fine-tuning or adapter tuning, checkpointed training, multi-provider campaigns, hidden evaluation shards, model cards and training reports, local-data training, and robust aggregation of participant updates.
Exposes trained or registered models to applications through replaceable gateway operators: request-response and streaming inference, prepaid usage sessions, signed cumulative usage receipts (clawd.usage.v1), and routing by cost, latency, region, or reputation. No gateway is protocol-authoritative — a client can submit transactions directly or switch operators.
Compact on-chain references for models, adapters, datasets, runtime images, evaluation suites, provider capabilities, licenses and usage policies, and artifact lineage. Large artifacts remain in content-addressed storage — Solana records hashes, ownership, authorities, and settlement rules. A URI is a retrieval hint; the digest is the identity.
Coordinates result commitments, auditor assignments, score commitments, challenges, and final acceptance. Different workloads get different verification methods — assurance profiles A–E below — instead of one universal score.
FOUR PLANES — where everything lives:
The authoritative state: protocol configuration, provider registrations and capability commitments, artifact registrations, job manifests and state transitions, bids and assignments, escrow balances, result commitments, auditor commitments and reveals, challenge records, settlement records, reputation events. PDAs provide deterministic addresses; large identifiers are hashed before use as seeds.
Each provider runs a Clawd Agent that watches for eligible jobs, a scheduler adapter for local capacity, a sandboxed runner for containerized workloads, a metering service that signs resource and timing receipts, an artifact client — and a wallet signer isolated from the workload container. A job container never receives direct access to the provider wallet key.
Artifacts are stored outside Solana and referenced by digest: content URI, SHA-256 digest, media type, byte length, encryption metadata, publisher address, parent artifact digests, license identifier, usage constraints, royalty recipients. Gateways and providers must verify downloaded bytes before use.
Replaceable services that convert developer requests into protocol operations: wallet authentication, scoped API credentials, job creation helpers, inference routing, artifact upload coordination, Solana transaction construction, event indexing, usage dashboards. Multiple independent indexers are supported from the start.
THREE PROGRAMS — the Release 0 on-chain set (Anchor, Rust). Splitting every feature into its own program would multiply cross-program calls and audit scope, so the first release is deliberately three:
Protocol configuration, provider registration, capability records, jobs, bids, assignments, result commitments, review state, challenges, settlement authorization, and reputation events.
Artifact records, publisher authorities, version lineage, license and policy hashes, model and dataset metadata, and optional non-transferable reputation or certification badges.
Payment escrow, job-specific provider bonds, auditor bonds, challenge bonds, royalty splits, refunds, protocol fees, and treasury withdrawals subject to governance controls. Every transfer verifies the expected mint, token program, authorities, and recipient accounts.
Administrative instructions are separated from ordinary job instructions and protected by a multisignature authority plus a timelock. Recommended PDA account model (spec §6.4):
| Account | PDA seeds | Purpose |
|---|---|---|
| ProtocolConfig | clawd · config | Global authorities, fee cap, supported token programs, pause controls |
| Provider | provider · provider wallet | Identity, status, aggregate reputation, bond status |
| Capability | capability · provider · capability digest | Hardware and runtime offer |
| Artifact | artifact · artifact digest | Compact artifact record and publisher authority |
| Job | job · creator · job nonce | Job state and immutable manifest digest |
| Bid | bid · job · provider | Provider quote and promised completion window |
| Assignment | assignment · job · provider | Accepted work order and bond requirements |
| ResultCommit | result · assignment | Output digest, receipt digest, reveal deadline |
| Audit | audit · job · auditor | Commit and reveal state for one auditor |
| Challenge | challenge · job · challenger | Dispute evidence and challenge bond |
| Escrow | escrow · job | Program authority for job funds |
| ReputationEvent | reputation · subject · event nonce | Append-only reputation evidence |
JOB LIFECYCLE — the working loop every job follows (§10):
Branches: Reviewing → Challenged (an eligible challenger posts a bond + evidence inside the challenge window; challenge fails → Accepted, succeeds → Rejected → Settled). Open with no assignment → Expired → Refunded. An assigned provider that declines or times out sends the job back to Open. Draft → Cancelled → Refunded. Three signed artifacts carry the loop: the job manifest (clawd.job.v1 — immutable once the job opens; a changed job is a new Job account), the result receipt (clawd.receipt.v1 — a signed claim of output digests, metering, and attestation digest), and the cumulative usage receipt (clawd.usage.v1 — for inference sessions, only the latest mutually signed total needs to settle).
ASSURANCE PROFILES — no single verification technique fits every workload (§11):
Low-value or trusted-counterparty jobs. Signed result receipt, content digests, short challenge window, provider reputation — no mandatory auditor quorum.
Ordinary model, evaluation, and batch jobs. Provider commitment and reveal, multiple auditors with their own commit and reveal, hidden evaluator inputs, challenge window.
Deterministic or high-value jobs. Two or more providers execute independently; output digests or tolerance-aware comparisons are evaluated; a tie-break execution is triggered on disagreement; correlated infrastructure may be excluded from one quorum.
For jobs where client data or model weights cannot be exposed to ordinary auditors: hardware-backed execution attestation, encrypted inputs released only to approved measurements, signed runtime identity, restricted logs, client-verifiable receipt, narrow challenge policy. This is where the network meets the stack in panel 01 — and the spec is blunt about its limits: attestation proves properties of the measured environment; it does not automatically prove model quality, correct client code, or freedom from side channels.
Future adapter for succinct computation proofs on compatible workloads. The protocol defines a generic verifier interface without making the first release depend on proof systems that do not yet support the full workload.
THE INFERENCE SIDE OF PROFILE D — the guarantees the RedPill / TEE story in panel 03 already tells:
Inference runs inside NVIDIA Confidential Compute.
Users can verify model-hosting privacy integrity.
RedPill gateway routing and receipts are verifiable.
Clients pay in SOL or approved SPL assets; a new network asset is not required to buy compute. An optional $CLAWD asset may later be used for governance, bonds, or ecosystem incentives — only after technical, economic, and legal review — while job payments stay open to approved assets. Every job separates provider budget, auditor budget, royalty budget, protocol fee allowance, and bond requirements. The protocol fee lives in ProtocolConfig with a hard program-enforced maximum, a timelocked update path, and no retroactive application to open jobs; the launch target is a low single-digit fee, set after infrastructure costs and demand are measured. Bonds are job-specific, and slashable events must be objectively testable — a no-show, a reveal that doesn't match its commitment, a forged receipt signature. Poor quality alone is not fraud: the provider simply fails the acceptance threshold and isn't paid the success amount.
Release 0 — local + devnet vertical slice: the three programs, fixed-price batch jobs, SOL escrow, provider registration, open bids, result commit + reveal, one deterministic evaluator, three-auditor commit + reveal, challenge window, reputation events, OCI provider agent, gateway + indexer, TypeScript client. Release 1 — AI workloads: Registry artifact types, adapter training, checkpoint commitments, hidden evaluation, model cards, royalty splits, GPU capability verification, persistent inference sessions. Release 2 — federated + private: campaign and round records, robust aggregation, encrypted artifact exchange, secure aggregation, confidential execution adapter, privacy-focused audit policies. Release 3 — distributed assurance: sealed bids, verifiable randomness, redundant execution, independent gateway operators and indexers, advanced proof adapter, governance expansion.
The spec closes with 15 decisions required before implementation (§26) and answers none of them yet: which payment assets are accepted at launch; the maximum protocol fee enforced by program logic; the bond formula for providers, auditors, and challengers; which artifact storage networks are supported first; which randomness provider or delayed beacon design selects auditors (never timestamps or recent hashes alone for valuable selection); which job types are permitted on the first public network; which workloads require identity or hardware review; evidence retention periods; timelock lengths; which evaluator image formats and model formats are supported; which conditions allow emergency pause and which withdrawals remain available; which regions or workload classes require additional compliance controls; which gateway compatibility envelope is supported for inference clients; which parts of provider capability data are public, private, or attested; and whether the first release needs an optional CLAWD asset at all.
Spec non-goals, stated plainly (§3): no model weights, datasets, or execution logs on Solana; no claim that every nondeterministic AI output can be proven cryptographically; coordination on-chain does not by itself guarantee privacy; no reliance on one static scoring formula for every workload; no rewards merely for registering hardware; no new asset required to purchase compute; subjective model quality is never slashable without objective evidence. Rewards come from completed jobs, not idle token ownership — and there is no passive delegation role in the first release: job-specific bonds create direct accountability between the party doing the work and the party being paid.