← All specs

Trustless deployment — the substrate apps ship through

> **Status: DRAFT — proposed-pending Madara.** This file was referenced by > [ethos.md](./ethos.md) and [tokenomics.md](./tokenomics.md) from their first > commits but never written (flagged as an …

Trustless deployment — the substrate apps ship through

Status: DRAFT — proposed-pending Madara. This file was referenced by ethos.md and tokenomics.md from their first commits but never written (flagged as an infra gap 2026-06-06; authored 2026-06-10 from the ratified trust-infra derivation). Everything below restates decisions already ratified in the canon (wiki/canon/infra-requirements.md, wiki/canon/deep-infra-foundations-workflow.md) or marks itself OPEN. Nothing here invents new policy.

What this is

The deployment substrate is how an app — anyone’s app — enters the Stoka ecosystem: gets identity, permits, compute, settlement, provenance, and a place in the stake market, without trusting the operator. It is the productized form of Software-Tsukuyomi (“StokaSoftware admin”): the capability plane plus the superimposed permission layer, pointed at any server, including your own.

Load-bearing proof (ethos §“the system uses itself”): StokaSoftware’s own surfaces are deployed through this same substrate. If the substrate cannot bootstrap the platform that defines it, it cannot be trusted with anyone else’s app. Phase 1’s N=1 solo tool is this bootstrap running at N=1.

The deployment contract

Every deployed app runs inside a signed, bounded, expirable permission contract (ethos). Concretely, per the ratified primitives:

  1. Identity — the app’s operator is a pseudonym (actor-id), never a raw user_id/legal identity. Context-only subjects; no cross-context map exists anywhere (F1, deployed in product via the StokaTerminal IdP slice).
  2. Permits — the app’s capabilities are holder-bound verifiable credentials: expiry-first, scoped-accumulator revocation, no ambient un-revocable authority — including for the platform itself (F3; ratified, migration of the live admin RBAC pending).
  3. Compute — the app draws chakra (compute) from the coordination layer: the operator’s own server (“point it at your own server”, free) or the Phase-3 marketplace (bonded probabilistic verification; deferred).
  4. Settlement — usage settles in the shielded credit ledger behind the same interface as the eventual $STOKA (F2; BN254 + PLONK/Halo2 stack, ratified 2026-06-09). Custody decreases over time; unlinkability constant.
  5. Provenance + rebate — first compute spend generates the on-chain- anchorable provenance that triggers the deployment rebate (tokenomics §deployment-rebates): shielded-default attestation on the one merkle-batched anchor shared with settlement (F4).
  6. Stake market entry — a deployed app becomes stakeable: backers stake $STOKA on it and share its upside (tokenomics). The app’s standing rides on its pseudonymous operator’s non-transferable reputation.

What “trustless” rules out

  • No god-account ACL over deployed apps (F3 invariant).
  • No server-side correlation of an app’s operator across contexts (F1).
  • No plaintext-dependent platform features on app data (F5 honeypot discipline: opaque versioned envelopes, wean-ready stores).
  • No retention-shaped distribution: discovery ranks by interest-development, decoupled from the contribution economy (§VIII; algorithm substrate deferred, client-side measurement mandatory when it comes).

Phasing (matches the five-phase plan)

PhaseDeployment substrate state
1 (now)N=1 bootstrap — Shay’s own surfaces deploy through the private capability plane; identity spine live (F1)
2StokaSoftware admin public: permits-as-VC + shielded credits; apps deploy onto operator/BYO compute
3Compute marketplace backs the peg; deployment rebates flow on-anchor
4–5Governance/dissolution: the substrate’s own authority is held credentials, diffusing out of the genesis wallet

OPEN (Madara) — not yet decided here

  • Permit credential scheme (BBS+/Idemix-family; “shielded-compatible” is the only irreversible bit) and delegation depth defaults.
  • Rebate verification authority mechanics at Phase 2 (WZ-curate → BZ-judge as audited oracle; caps/rubrics per the pressure-test corrections).
  • Compute-peg oracle source (Stoka-set vs market vs hybrid).

See also