Purpose: Prescriptive release process ensuring transparency and attestation for every Xordi deployment.
Key Principle: A deployment is NOT complete until transparency logging is verified.
- All changes committed to
tokscope-xordi-perfbranch - Record the commit SHA:
____________________________________________ - Verify CI passes (if configured)
- No secrets in source code (use appropriate KMS for secrets)
-
Build image with SHA tag:
export SHA=$(git rev-parse --short HEAD) docker build -t yourorg/xordi:$SHA . docker tag yourorg/xordi:$SHA yourorg/xordi:latest
-
Push to DockerHub:
docker push yourorg/xordi:$SHA docker push yourorg/xordi:latest -
Record image digest:
____________________________________________
- Verify
docker-compose.ymluses correct image tag - Verify KMS configuration is correct
- Verify no sensitive environment variables are hardcoded
CRITICAL: Use Base on-chain KMS for transparency logging
# Option A: New deployment
phala cvms create \
--name xordi-prod \
--compose docker-compose.yml \
--vcpu 4 \
--memory 8192 \
--env-file .env.encrypted
# Option B: Upgrade existing deployment
phala cvms upgrade \
--app-id 8b7f9f28fde9764b483ac987c68f3321cb7276b0 \
--compose docker-compose.yml- Deployment command executed successfully
- Record CVM ID:
____________________________________________ - Record App ID:
____________________________________________
- Service is responding:
curl https://api-a.jordi.io/health - Basic functionality verified (test QR code generation)
- No error logs in initial 5 minutes
A deployment is NOT complete until these steps are verified.
- Visit Trust Center: https://trust.phala.com/app/{APP_ID}
- Verification status shows "Completed"
- All 30 data objects verified (App, KMS, Gateway)
- Attestation timestamp is after deployment time
This is the critical step that ensures transparency.
-
If using Base KMS: Verify upgrade event on Base blockchain
# Query the KMS contract for recent events cast logs --address 0x... --from-block latest -
If using Pha KMS:
⚠️ STOP - Switch to Base KMS before proceeding- Pha KMS does NOT publish events publicly
- Deployment without transparency logging is NOT acceptable
Record the following in the release notes:
| Item | Value |
|---|---|
| Git Commit SHA | |
| Docker Image Tag | |
| Docker Image Digest | |
| App ID | |
| CVM ID | |
| Trust Center URL | |
| On-Chain TX Hash | |
| Deployment Timestamp |
- Update VERIFICATION-REPORT.md with new attestation data
- Create GitHub Release with attestation proof attached
- Update any public documentation
- Post in #flashbots-x-core with:
- Commit SHA
- Trust Center link
- On-chain verification link (if applicable)
If issues are discovered after deployment:
- Do NOT panic-deploy - this creates unverified code
- Revert to previous known-good commit
- Follow full release checklist (including transparency steps)
- Document the incident
phala cvms info --app-id 8b7f9f28fde9764b483ac987c68f3321cb7276b0phala cvms attestation --app-id 8b7f9f28fde9764b483ac987c68f3321cb7276b0curl -X POST https://cloud-api.phala.network/api/v1/attestations/verify \
-H "Content-Type: application/json" \
-d '{"hex": "QUOTE_HEX"}'From Andrew Miller (Dec 30, 2025):
"my fear has happened, which is that, because we didn't have a release process prescriptively, Ian just never released it in a way where we're generating evidence"
"It is about making a transparency log, which we're just not making right now"
Without this checklist:
- Deployments happen without transparency logging
- No evidence of what code is running
- Cannot prove non-custodial access to users
With this checklist:
- Every deployment creates an on-chain record
- Users can verify upgrade history
- Evidence exists that code matches published source
| Date | Version | Changes |
|---|---|---|
| 2026-01-05 | 1.0 | Initial release checklist |