Every AI assessment tool I’ve ever seen has the same problem: it asks you to trust a privacy policy.
“We don’t store your conversations.” Okay — but the inference provider can still read them. “We use encryption in transit.” Sure, but the model host decrypts before running inference. Somewhere in that chain, there is a machine where your raw conversation exists in plaintext, and someone with enough access can look at it. The privacy claim rests entirely on organizational promises.
I’ve been building PAICE — a tool that assesses how well humans collaborate with AI — and the privacy problem kept nagging me. PAICE conversations are personal. People describe how they actually work, where they get stuck, what they’ve tried. If I can’t prove the conversation is unreadable during inference, I’m just another company asking for trust.
So I built the integration I wanted: a three-layer model cascade running inside hardware-secured TEE enclaves, with every score hashed and written to a smart contract on NEAR. Nobody can read the conversation during inference — not me, not the cloud provider, not NEAR. And anyone can verify the final score wasn’t tampered with by checking the on-chain hash.
Live demo (GitHub Pages, API key pre-loaded): https://snapsynapse.github.io/paice-near-integration/demo/cascade.html
📺 Video walkthrough: https://youtube.com/watch?v=bXad5mMFTEs 🏆 NEARCON Innovation Sandbox submission: https://devspot.app/projects/1096
{% embed https://youtube.com/watch?v=bXad5mMFTEs %}
{% github snapsynapse/paice-near-integration %}
How the privacy guarantee actually works
Two layers stacked together.
🔒 TEE inference via NEAR AI Cloud NEAR AI Cloud runs open-weight models inside hardware-secured Trusted Execution Environments. The enclave decrypts the request, runs inference, encrypts the response, and returns it — conversation data never exists in plaintext outside the enclave. NEAR itself can’t read it. The GPU operator can’t read it. I can’t read it.
⛓️ On-chain attestation
After the assessment completes, the score payload (dimensional scores, tier, timestamp, models used) gets serialized with sorted keys, SHA-256 hashed, and written to a Rust smart contract at paice.near. Anyone can recompute the hash from a score and call verify() on the contract to check integrity. No trust in me required.
The two layers together give you something uncommon: private during processing, verifiable after the fact.
The three-layer cascade
PAICE separates concerns across dedicated model layers, each running in its own TEE enclave:
| Layer | Primary | Role |
|---|---|---|
| Chat | GPT OSS 120B | Conducts the assessment conversation |
| Middleware | Qwen3 30B | QA-validates every AI response |
| Evaluation | GLM 4.7 | Scores the full transcript across 5 dimensions |
Each layer has a fallback model. If GPT OSS 120B hiccups mid-conversation, DeepSeek V3.1 takes over. The cascade structure matches how production PAICE already separates concerns — one model shouldn’t grade its own homework.
The evaluation layer is the interesting one. I tested several models and GLM 4.7 was the most calibrated scorer — it gave a rich 5-turn conversation 550/1000 where GPT OSS 120B cheerfully handed out 700/1000 for the same input. Calibration matters more than raw capability when the output is a score someone will act on.
The pipeline, end to end
- Browser connects to NEAR AI Cloud
- Chat layer runs the conversation (TEE-protected)
- Middleware QAs each response (TEE-protected)
- Evaluation layer scores the transcript (TEE-protected)
- SHA-256 hash the score payload
- Sign the attestation client-side via
near-api-jsand write to the contract - Verify on-chain
All seven steps run from a single self-contained HTML file. No backend. The testnet demo uses an embedded keypair (testnet NEAR has no monetary value, so key exposure is fine), and the mainnet version runs against paice.near.
Tech stack
- Smart contract: Rust, NEAR SDK 5.6.0 (~80 lines)
- Service layer: Python, for the inference + cascade + attestation logic
- Browser client: Vanilla JS +
near-api-jsv4.0.4, no framework - Inference: NEAR AI Cloud (OpenAI-compatible
/v1/chat/completions)
The non-obvious decision: I kept the browser demo frameworkless. React would have let me structure state more cleanly, but a single HTML file you can open locally and read top-to-bottom is a better artifact for something that needs to be auditable. If the privacy story is “trust the code, not me,” the code needs to be readable.
Cost
A full 25-minute assessment — three model layers, ~12 conversational turns, on-chain attestation — costs $0.02 to $0.05. The evaluation layer (GLM 4.7 with extensive internal reasoning) dominates at ~60% of cost. The NEAR transaction fee is a rounding error: fractions of a cent.
Why NEAR specifically?
This integration needed four things that no other chain offers together:
- TEE inference baked into the cloud product, not a bolted-on sidecar
- Cheap, fast on-chain state for attestations
- Human-readable named accounts (
paice.nearreads like trust;0xAbCd…does not) - OpenAI-compatible API so I didn’t have to rewrite the LLM abstraction layer
Ethereum has the state layer. Modal and Fireworks have fast inference. But the combination of TEE-protected open-weight models + cheap on-chain writes + named accounts + OpenAI API compatibility only lives on NEAR right now.
Try it
The cascade demo is a single HTML file with a pre-loaded API key. Open it and run the 7-step pipeline yourself:
👉 https://snapsynapse.github.io/paice-near-integration/demo/cascade.html
Prefer to watch first? Video walkthrough: https://youtube.com/watch?v=bXad5mMFTEs
Full source, smart contract, and docs: https://github.com/snapsynapse/paice-near-integration
Submitted to NEARCON Innovation Sandbox 2026: https://devspot.app/projects/1096 — already running on mainnet at paice.near.
Question for you
How are you currently proving privacy claims in AI products you build or use? “Trust our policy” vs “verify the cryptography” — where do you actually draw the line, and has a customer ever pushed you on it? Drop it in the comments 👇