MultiAgency × Secret Network Foundation · Discovery readout
Secret3 specifies the protocol control plane in detail and says nothing about accounts, teams, billing, or the VM registry. Those exist today — on a service the Foundation does not own. That silence is the product opportunity, and it is what we propose to build in Q4.
Four findings · each verified against a primary source
SecretVM and SecretAI deploy, manage, share and bill through secretai.scrtlabs.com. Secret3dev forked every surrounding repository — secretvm-verify, secretvm-verification-sdk, gkms-utils, secretd-sgx-proxy, sgx-node-registry — but a hosted service cannot be forked.
The portal was still serving normally when we checked, three days after SCRT Labs' support ended. Still running is not the same as transferred. What lives only there: accounts, teams and roles, the VM registry, the type catalogue and pricing, invite codes, billing and the agent balance ledger, default attestation keys, registry credentials.
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 — six 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 our roadmap's first phase.
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
Secret3'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.
We unpacked the published CLI and read it. Two things came out that change what a Q4 engagement should cost.
The client is already portable: SERVER_BASE_URL is an environment variable, defaulting to the Labs portal. We had assumed making it configurable would be the first thing to build. It is not — which means a compatible replacement is drop-in for existing users, who change one variable rather than reinstalling anything. The surface behind it is sixteen routes.
And the portal never sees tenant secrets. Environment variables and registry credentials are encrypted on the client to the KMS contract's key before upload — X25519 with AES-128-SIV, matching the contract's own implementation. Whoever runs that service is a courier for ciphertext they cannot open. Migrating it inherits no secret custody, which makes this a far less dangerous change than it first appears — and it is a claim worth making publicly, rather than leaving in a source comment.
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 and 359M SCRT bonded, 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: a control plane does not help when blocks stop, so base-layer availability belongs in the uptime conversation before any tenant commitment, not after.
Sequenced by regret, not ambition
The founding architecture document is a draft, and committing a quarter of engineering to an unratified design would be irresponsible. So we start with work that holds its value whether or not Secret3 is ratified: owning the control plane, making verification a product, and telling developers what is happening. Protocol engineering stays with Secret3dev.
We also note how direction actually gets set here — 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, and the engagement below is shaped to match the quarterly-estimate, milestone-evaluated model the Foundation has already described.
| Stage | Duration | Purpose |
|---|---|---|
| Scoping | 2 weeks | Assess the existing prototype, complete the control-plane inventory, and commit to a scope and price for the build. If the prototype already covers this ground, we will say so — that is the best possible outcome and it should not cost you a quarter to discover. |
| Build | ~10 weeks | A Foundation-owned deploy, manage and verify surface. Tenant migration with identity, domains and team membership intact — nobody redeploys to stay. A published operator runbook. Verification made usable by someone who is not the deployer. |
| Advisory | Concurrent | Driving the open architecture decisions to published answers, and designing the migration programme — redeem-window mechanics, grant structure, reference port. |
We would not price the quarter fixed. The largest unknown is how much of this already exists, and a fixed quote against that either overcharges for small work or underprices a build.
Access, not analysis, is the constraint
Discovery produced this 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 rewrote an analysis section that had conflated today's SecretVM image with what the paper proposes. Seven 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.