What you’ll need
- A funded wallet with MOR + ETH on Base Mainnet (or Base Sepolia for testnet).
- The wallet’s private key — this stays encrypted inside the TEE.
- An RPC endpoint for Base Mainnet (e.g.
wss://base-mainnet.g.alchemy.com/v2/<your_key>). - Your AI model backend reachable via a private URL (e.g.
http://my-model:8080/v1/chat/completions). - A SecretVM account at https://secretai.scrtlabs.com — sign up to get an API key.
- (Recommended)
secretvm-cli:sudo npm install --global secretvm-cli. - (Recommended) MyProvider for registration and bidding after the VM is healthy.
Step 0: Pick the model you will serve
Before minting anything on chain, see what already exists and at what price:- If a matching model
Idalready exists and (for TEE) it carries ateetag — plan to bid on thatIdand put it inMODELS_CONFIG_CONTENTbelow. - If you need TEE and no suitable
tee-tagged model exists — you will register a new model with tagteeafter deploy (Step 5). - Or browse the human UI: active.mor.org/status.
Step 1: Get the Docker Compose file
Each CI/CD build produces a deployed compose file pinning the TEE image by SHA-256 digest — that’s what SecretVM uses to compute RTMR3. Downloaddocker-compose.tee.deployed.yml from the latest GitHub Release — the digest is already filled in. You can also use the template at proxy-router/docker-compose.tee.yml and replace the image tag yourself.
The compose includes a Traefik TLS sidecar that uses SecretVM’s auto-generated certs to serve the API on HTTPS port 443. The full compose body is reproduced in TEE reference → Step 1.
Step 2: Prepare your secrets
Create a.env file with your 5 provider-specific secrets:
MODELS_CONFIG_CONTENT must be single-line JSON. Schema: models-config.json.
If Step 0 already gave you an existing on-chain Id, put that value in modelId now. If you will mint a new tee model after deploy, use a placeholder and replace it via MyProvider Model Configuration Sync (Step 5) before posting a bid you care about.
Step 3: Deploy on SecretVM
- Web portal
- CLI (recommended)
- Go to https://secretai.scrtlabs.com/secret-vms/create
- Docker Compose: paste the contents of your compose file.
- Encrypted Secrets: enter your 5 variables.
- Advanced features:
- Click Deploy.
Step 4: Verify the node is running
Once provisioned (typically 2-3 minutes):Step 5: Register via MyProvider (recommended)
SecretVM already terminates TLS on port 443, so the hosted GUI at myprovider.mor.org can talk to your node without mixed-content issues.1
Open MyProvider
Go to myprovider.mor.org. Connect with:
- URL:
https://<your-secretvm-url>/ - Username / password: from
COOKIE_CONTENT(e.g.admin:yourpassword)
2
Register provider
Provider tab → verify the public
:3333 endpoint → create provider (min 0.2 MOR stake). Approve Diamond spend if prompted.3
Bid — prefer an existing model
If Step 0 found a suitable model (including
tee when you need TEE): Models & Bids → Available Models → Add Bid using that Id. Set price from the competitor check.4
Only if needed — create a tee-tagged model
If no suitable
tee model exists, use Create Model & Bid and include tag tee (comma-separated tags field). The tee tag is what triggers consumer-side attestation; without it, consumers treat you as a standard provider.5
Sync models-config
Use Model Configuration Sync to generate updated
MODELS_CONFIG_CONTENT, then update SecretVM encrypted secrets and redeploy/restart if the on-chain modelId changed from your Step 2 placeholder. Details: MyProvider GUI.https://<your-secretvm-url>/swagger/index.html — same contract calls as Register on chain. Click Authorize with your COOKIE_CONTENT / .cookie credentials first (API auth).
Step 6: Verify your attestation
Quick check (SecretVM portal)
- Go to https://secretai.scrtlabs.com/attestation
- Paste your compose file contents.
- Enter your VM URL.
- Click Verify.
Programmatic check (cosign)
What consumers see, what your P-Node does
The two-hop trust chain — see TEE overview for the full conceptual breakdown.- Phase 1 (consumer ↔ your P-Node): the consumer’s proxy-router fetches your
:29343/cpuquote, verifies via SecretAI portal, checks TLS binding, compares RTMR3 against the cosign-signed golden values, and re-checks with a ~50 ms fast path on every prompt. - Phase 2 (your P-Node ↔ backend): your P-Node resolves the backend’s attestation endpoint (probes
:21434first, falls back to:29343), fetches/cpu, verifies the TLS binding (SPKI or full-certificate digest inreportData), replays workload RTMR3 from/docker-compose, verifies GPU evidence via NVIDIA NRAS (mandatory — a failed or unreachable NRAS fails attestation), and re-checks per prompt. Per-model state is exposed atGET /v1/models/attestation.
Troubleshooting
Updating your node
/healthcheck and the attestation portal.