MultiAgency × Secret Network Foundation · Discovery findings
Secret³ specifies the protocol plane in exact detail — admission, registries, rentals, vaults, checkpoints, the operator burn — and says nothing about how a developer ships anything, what a name is, or how a stranger checks what is running. That silence is where the product goes. Most of what it needs already exists, unclaimed, inside a dependency the paper has already adopted.
Eight findings · each verified against a primary source
The paper is exact about the protocol plane. It is silent on the thing a developer touches: what a deployment is, what a name is, what you get back, and how someone who did not deploy it can check any of it. That silence is correct scoping for an architecture paper. It is also the entire product gap, and it is what a PRD is for.
Secret Zone is greenfield on dstack. It is not a succession of SecretVM, and an earlier version of this page argued that it was. The evidence says otherwise: the product mockup names SecretVM zero times and ships its own zone command surface, and the runtimes differ — SecretVM builds its own Poky image, while the paper puts the runtime on dstack, measured OS included. Building for wire compatibility would have meant emulating the API of a system this product does not run.
We changed the premise rather than the conclusion. The product gap is real either way; what changed is what fills it.
The white paper is unambiguous: “Other CosmWasm apps have to be rewritten as CVM apps, or they stop.” We searched the entire live documentation repository for any trace of that direction.
We tested it twice — across the 644-file source repository, and again across the rendered corpus of roughly 509 published pages. “Secret3” appears exactly once, under a page headed “Setting up a node/validator — these docs are under construction,” pointing operators at the new releases page. “Community continuance” appears nowhere. Every deprecation match concerns old secretjs versions or CosmWasm 0.10→1.0 type changes.
The precise version of this is more useful than the blunt one: the documentation was updated after the handover — someone redirected node operators to the new repository — and the direction still was not stated. That is a choice about what to say, not neglect.
This is not an isolated gap. On 1 September a staker posted to the forum asking how to claim the new Arbitrum token and whether their SCRT would stay in their Cosmos wallet — five weeks after that migration was rejected. One post, no replies. When someone cannot tell that a rejected proposal was rejected, the problem is reach, not documentation.
Saying something — even “we are evaluating, decision by a date” — costs nothing and is the highest-value item in the first phase of any roadmap here.
We read dstack’s contracts and security documentation directly. It states its own limits plainly:
“Neither filesystem proves that an attached disk represents the latest application state. An infrastructure operator can withhold, delete, replace, or restore an earlier valid encrypted disk image. Applications that require rollback-resistant state must anchor a monotonic version or state commitment in an external trusted service, ledger, or equivalent freshness mechanism.”
dstack — security model
Secret³’s checkpoint design is exactly that anchor. The ledger holds the hash of the sealed-log head; a replacement CVM hydrates from it. Phala Cloud plus any chain leaves rollback resistance as an exercise for the developer, because the two halves are not integrated. Secret can make it a platform property — and the competitor’s own documentation is the evidence that the gap is real.
Today it appears to serve the money program. Exposing it to ordinary tenants turns a protocol property into a product feature.
We read the continuance allocations off-chain rather than from reporting, and reconciled every destination address against the upgrade handler’s own table.
Press reporting of the mint covered six buckets totalling 992M and omitted two worth 87M. The ecosystem and builder-and-relayer allocations are plain accounts with no vesting schedule — the funding question for migration work is a mechanism question, not a money question.
The product’s promise is that your work lives on a name. dstack-gateway already implements exactly that: Zero Trust HTTPS with TLS terminating inside the attested environment, ACME dns-01 run in-process, CAA records pinning issuance to its own account, and content-addressed domains.
The paper names dstack’s components and decides each one — it takes the VMM, the guest agent and the supervisor, says it takes the measured OS, and explicitly refuses the key service. The gateway is not among them. It is not mentioned at all.
This is more than a saved component. If TLS terminates anywhere outside the CVM, plaintext exists somewhere the tenant never attested, and the confidentiality claim breaks at the network edge — quietly, and in the one place a customer is most likely to look. The gateway is an answer that already exists, is already audited by its own project, and costs a decision rather than a quarter.
Verification is the strongest thing this platform has, and the documentation tells a third party exactly how to exercise it: “Clone the secret-vm-build repository and follow instructions to build the four artifacts.” We tested every scrtlabs repository linked from the live documentation — 42 of them. Five return 404, and three are the trust model itself: the reproducible build artifacts, the KMS contract source, and the attestation REST server.
The immediate fix is cheap. The structural point is bigger: this fragility is inherent whenever measurements can only be checked against a registry the platform itself owns. One dead repository and the claim is unfollowable.
The paper’s §3 says the runtime is dstack, measured OS included. Take that literally and the property changes character: Secret’s published measurements match dstack’s upstream references, so a third party verifies a Secret workload by rebuilding from the public dstack repository — with no Secret-owned registry anywhere in the path. Keep a divergent image instead and measurements stay checkable only against Secret, and Secret owns the kernel choice forced by RTMR support, TDVF over td-shim, and the entropy pinning, indefinitely.
The paper has not chosen. It is the highest-leverage open decision in it, it is nearly free to make deliberately, and it will otherwise be settled by whoever writes the first build pipeline.
dstack’s key service refuses to release keys to a machine whose trusted computing base is not current — tcbStatus must read UpToDate. That is the correct security posture, and it has a consequence nobody has written down.
A TCB recall is an availability event on Intel’s schedule, not Secret’s. Machines that booted yesterday stop booting, and no change to Secret’s own code or governance caused it. The paper’s threat model is candid about physical attacks and lists compensating controls for them; TCB currency is not among them.
This needs monitoring, a published policy, and notice to tenants before a floor moves — decided in advance, not discovered during an incident. It is a small piece of work and it is invisible until the day it is not.
In August the chain reportedly stopped producing blocks when the largest validator went offline, after delegations were concentrated onto it. A forum analysis at the time held that bonded stake had passed both critical thresholds: one third, above which a single operator halts the chain by going offline, and one half, above which it decides governance alone.
We checked that against the chain today, and it no longer holds. Across 26 bonded validators, the largest holds 20.9% — below the one-third threshold. It now takes four validators to halt and eight to control governance. The most likely explanation is the continuance mint itself: the new allocations are staked, and they diluted the concentration that caused the August event.
The concern does not disappear — four operators out of twenty-six is still thin, and Secret’s emergency-signer design has halt modes that are not simply a function of stake share. But it is materially better than the August framing, and we would rather correct a number in your favour than repeat a striking one. The practical point stands either way: no product helps when blocks stop, so base-layer availability belongs in the uptime conversation before any tenant commitment, not after.
Sequenced by regret, not ambition
One thing worth saying first, because it changes how everything else should be read. The obvious framing of the last month is a new team proposes demolishing the old architecture. Set against the release history, that framing is wrong — and the accurate one is stronger.
Removing SGX from the consensus path was Labs’ own project, and they shipped two releases of it: v1.24.1 “Removed MRSIGNER requirement” and v1.25.0 shipped non-SGX nodes paired through a permissionless on-chain registry — both verbatim from the release notes. (The readings that MRSIGNER removal was for third-party enclave development, and that non-SGX validators were the intended next stage, come from Labs’ own 2026 roadmap — their stated intent, not a release note.) Secret³’s central architectural move is the endpoint of a road the predecessor built half of. That is more accurate, it is far easier to defend in governance than a clean-slate proposal, and it means the engineering risk is lower than the paper’s own framing suggests. Nobody is telling this story, and it is the cheapest credibility available to the continuance.
The founding document is nonetheless a draft, and committing engineering to an unratified design would be unwise. So the work that should go first is the work that holds its value whether or not Secret³ is ratified: a deploy-name-prove surface, verification made portable and usable by strangers, and telling developers what is happening. Protocol engineering stays with Secret3dev.
Direction here is set by a known process — the Foundation drafts an annual roadmap, takes community feedback, finalises it, and hands implementation to the core dev team. Read our roadmap as a candidate input to that process, not as a consultant’s deliverable. It is written to be argued with.
Five decisions gate most of it, and four cost nothing but a published answer:
| Decision | Why it gates |
|---|---|
| Guest image | dstack’s measured OS wholesale, or a divergent one. Decides whether verification is portable or checkable only against Secret — Finding 06. Made by default if left open |
| Gateway | Adopt dstack-gateway for naming and TLS, or specify where TLS terminates instead and why the confidentiality claim survives it — Finding 05 |
| Key release | Two-of-two custody means one custodian offline halts all new boots network-wide. dstack delegates the same decision to a two-endpoint webhook, which may remove the need for a bespoke committee entirely |
| CosmWasm, publicly | Every week of silence is a week of developers building on a stack a draft proposes to retire — Finding 02 |
| Ownership | The product is branded Secret³ · Secret.Zone while the domain belongs to a private company. Foundation-funded work should know which it is building |
Access, not analysis, is the constraint
All of the above was produced without a single stakeholder conversation or any product access. That ceiling is now reached — everything of further value needs people.
Every figure on this page was read from a primary source: the chain, the contract source, the package registries, the documentation repository, and the governance forum. Nothing here rests on a press summary — we found reporting of the mint had omitted two allocations entirely.
That last source came later than it should have. We built most of this from chain state and code before reading the forum properly, and the forum turned out to hold the naming answer, the exploit specifics, the halt, and the roadmap process — much of it in one thread, public since 5 August. Recording it because a method is only worth describing if you also say where it slipped.
We also keep a written record of our own errors. During this engagement we retracted a contract count that came from an endpoint returning plausible but incomplete data, corrected a misreading of a live governance proposal within minutes of making it, and replaced this page’s central premise when the product’s own design contradicted it. Twenty such corrections are logged.
An advisor who documents what they got wrong is one whose remaining claims can be checked. That is the same argument this platform makes about attestation, and we would rather demonstrate it than assert it.