This tutorial teaches you to build DevProof (or "unruggable") applications using Dstack — apps where even the developer can't cheat users.
If you follow typical Dstack guides, you'll get an ordinary server where you (the admin) can still "rug" your users. The app runs in a TEE, but the developer retains backdoors.
DevProof is a different threat model: we assume the developer themselves might be malicious, and design the system so they can't betray users even if they wanted to.
This is what smart contracts and DeFi aspire to, but TEEs let us apply it to practical, general-purpose code — not just on-chain logic.
| Application | DevProof property |
|---|---|
| Oracle for prediction markets | Developer can't manipulate how bets settle |
| Verifiable credentials (zkTLS) | Developer can't forge credentials |
| User consent collection | Developer can prove they collected N consents |
| Data handling | Developer can prove no user data was exposed |
Smart contracts achieve DevProof design through:
- Open source code
- On-chain codehash compared against verifiable builds
- Users expected to DYOR (do your own research)
- Auditors verify source and on-chain deployment match
- Immutable by default; upgrade mechanisms become audit surfaces
- Upgrade policies with on-chain "due process" (timelocks, multisig)
TEE apps need similar patterns — this tutorial shows how.
Throughout this tutorial, we build a price oracle for prediction markets:
- Fetches prices from external APIs
- Proves the data came from a specific TLS server
- Signs results with TEE-derived keys
- Verifiable on-chain
Each section adds a layer until we have a fully DevProof oracle.
You can complete the entire tutorial without TDX hardware. The simulator provides everything needed to develop and test locally.
| Tool | Purpose | Install |
|---|---|---|
| Docker | Run apps | docker.com |
| Phala CLI | Simulator + deploy | npm install -g @phala/cloud-cli |
| Python 3 | Test scripts | System package |
| Foundry | On-chain testing (04) | getfoundry.sh |
# Start the simulator (provides mock KMS + attestation)
phala simulator start
# Run any tutorial section
cd 02-kms-and-signing
docker compose build
docker compose run --rm -p 8080:8080 \
-v ~/.phala-cloud/simulator/0.5.3/dstack.sock:/var/run/dstack.sock \
app
# Run tests
pip install -r requirements.txt
python3 test_local.pyThe simulator provides:
getKey()— deterministic key derivationtdxQuote()— mock attestation quotes- Signature chains verifiable against simulator KMS root
For 04-onchain-oracle, use anvil for local contract testing:
anvil & # Local Ethereum node
forge create TeeOracle.sol # Deploy verification contract# Phala Cloud (managed TDX)
phala deploy -n my-app -c docker-compose.yaml
# Self-hosted TDX
# See https://docs.phala.com/dstack/local-developmentNote: A DevProof design minimizes dependency on any single provider. The verification techniques work regardless of where you deploy.
| Language | Install | Docs |
|---|---|---|
| JavaScript/TypeScript | npm install @phala/dstack-sdk |
sdk/js |
| Python | pip install dstack-sdk |
sdk/python |
- 01-attestation — Build a TEE oracle and verify its attestation end-to-end
- 01a-reproducible-builds — Make builds verifiable for auditors
- 02-kms-and-signing — Derive persistent keys and verify signature chains
- 03-gateway-and-tls — Self-signed TLS with attestation-bound certificates
- 04-onchain-oracle — AppAuth contracts and multi-node deployment
- 05-hardening-https — OCSP stapling, CRL checking, CT records
- 06-encryption-freshness — Encrypted storage, integrity, rollback protection
- 07-lightclient — Verified blockchain state via Helios light client
- 08-extending-appauth — Custom authorization contracts (timelocks, NFT-gating, multisig)
- Dstack Documentation
- Phala Cloud
- trust-center — Attestation verification
- dstack GitHub