Secret Network combines the Cosmos SDK, Rust-based CosmWasm contracts, encryption and Intel SGX trusted execution environments. Its native SCRT coin pays fees, supports proof-of-stake security and participates in governance. Native transfers are public. The privacy feature belongs to how Secret Contracts process protected messages and state, rather than to a promise that everything bearing the Secret name is anonymous. The documentation's introductory application and developer counts are historical promotional figures; they are not used here as a September 2026 census.

The original graypaper argues for applications that can use sensitive information without putting every input on a public ledger. It distinguishes encrypted contract messages from visible fields such as the sender, chain context and sent funds. That is a narrower and more useful proposition than invisibility. A user can want a private balance or confidential computation while still leaving public transaction metadata. The paper's old throughput, supply and governance parameters should not be carried forward as current measurements simply because the design explanation remains available.

The SEC's February 19, 2020 order concerns Enigma MPC's 2017 ENG offering. It records an approximately $45 million sale, registration violations and a settlement accepted without admission or denial of the findings apart from jurisdiction. This is a specific historical legal record about ENG and its issuer. It does not automatically classify every later SCRT transaction, promise an available refund today, or erase the distinction between an earlier token sale and the independent network that subsequently developed.

Enigma's later annual filing says it stopped developing its earlier protocol and joined development of the Secret Network community after concluding ENG would no longer function as intended in its planned decentralized system. The filing describes a February 2020 genesis organized by the community. Reading that account alongside the legal order helps explain why names, companies and tokens are easily confused. The company's description is evidence of its own decisions and role, not proof that it owned the resulting chain or every subsequent community organization.

On September 15, 2020, contributor jlwaugh announced that the mainnet upgrade enabling Secret Contracts had completed. The post addressed participants as Secret Agents and framed programmable confidentiality as a public infrastructure opportunity. That launch is a dated deployment milestone, distinct from the earlier chain genesis. Claims in the announcement about being first are promotional comparisons; the enduring technical event is that the chain acquired encrypted general-purpose contract execution.

Later security disclosures are part of evaluating that capability, rather than reasons to omit its development history.

The October 23, 2020 secretSCRT announcement explains the difference between native SCRT and a wrapped SNIP-20 representation. Users deposit native coins into a contract and receive a private token representation with contract-defined transfers, allowances and redemption. The distinction matters whenever a proposal treats native balances, staking and contract-held positions differently. Wrapping is not the creation of a second independent monetary base, and privacy does not remove the need to understand the wrapper's code, access controls and ability to honor redemption.

Viewing keys solve a particular query problem: an ordinary public query does not prove that its sender owns the address whose private data it requests. The contract stores a viewing credential associated with that address. Anyone holding the appropriate key and address can read the permitted information without possessing the spending key. This makes selective disclosure possible, but it also makes a viewing key sensitive. Sharing one for accounting or application access is a real permission decision, even though it need not authorize moving the underlying funds.

Query permits use signed messages identifying the relevant tokens and permissions instead of requiring a new on-chain viewing-key transaction. A contract verifies the signature before answering the query. This can reduce setup friction and unnecessary transactions, but the scope of the signed permission still matters. A request to reveal transaction history is different from a request to reveal a balance. The interface should expose that distinction clearly; a wallet signature is not harmless merely because the application describes it as logging in.

The SGX.Fail researchers demonstrated that vulnerable hardware could expose Secret's consensus seed, the basis for decrypting protected information. They obtained mainnet and testnet seeds, published proof of compromise and said they destroyed the mainnet key material. Their account distinguishes confidentiality failure from ordinary consensus integrity: exposing private state need not rewrite balances, although assets relying on secret authentication material can face additional risks.

The disclosure is concrete evidence against treating hardware isolation as an unconditional guarantee or dismissing all hardware attacks as merely theoretical.

Secret Labs' January 2026 roadmap describes further lessons from wiretap.fail and tee.fail, followed by tighter control of machine admission. It presents governance-approved machines and hardware restrictions as a response to a changing threat model. Those controls introduce a participation tradeoff alongside the privacy objective. The page now carries a notice that Secret Labs is no longer involved with the network. Its technical history remains relevant, but unfinished work in that roadmap is not a promise from the current community stewards or proof that a feature shipped.

The March 30, 2026 v1.24.1 release blocks specified end-of-life hardware, enables Cron, supports adding multiple machines through governance and removes the MRSIGNER requirement. That last change makes older repository descriptions of mandatory developer-signed enclave code incomplete. A release record establishes what the published software changes; it does not independently establish the exact activation time of every operator. Keeping those two claims separate is especially important when emergency hardware policy, node admission and contract functionality change in the same package.

The June 10 v1.25.0 release adds machine-ID replacement, updates emergency validator information and introduces a beta non-SGX node that must pair with an SGX node. The pairing requirement is decisive: it is not evidence that confidential execution became independent of trusted hardware or that fully autonomous non-SGX validators were deployed. Software can make public infrastructure easier to operate while still relying on a smaller specialized execution component. Describing the architecture requires following that dependency rather than counting a new binary as a new security model.

Common Prefix's technical postmortem traces the June 10, 2026 exploit to modified Secret-side ICS-20 logic that no longer enforced the necessary source-channel and denomination checks. An attacker used a controlled chain to create unbacked representations, then redeemed through the legitimate Axelar connection. Valid IBC proofs established that messages came from a chain; they did not establish legitimate backing for the claimed asset. The report estimates $4.67 million affected and distinguishes these bridged assets from native SCRT and unrelated Axelar escrows.

Alex Zaidelson's June 19 incident thread likewise identifies the Secret-side bridge contract and reports that the connection was paused. It contains arguments about responsibility and monitoring that should be treated as the author's position, rather than a settled judgment against every organization mentioned. The useful practical distinction is between network confidentiality, consensus and bridge accounting. A privacy-oriented chain can still host a contract with flawed asset-origin checks.

Users need the exact wrapper and channel identity before assuming one incident affects, or spares, every token with a similar ticker.

The July 7 post titled SCRT is moving to Arbitrum explicitly made the move conditional on governance approval. It also said Labs would stop supporting the Cosmos L1 regardless of that vote, while operators could continue the existing chain. Proposed snapshot rules distinguished native and ordinarily staked SCRT from some contract positions. Those were proposed eligibility rules, not standing instructions for users to unwrap or move funds. Later community-continuance records supersede any reading of this headline as proof that the original network had already migrated.

Lisa Loud's July 28 draft proposed a different path: keep the existing L1 and include contract-held positions while funding new stewardship, infrastructure and remediation through revised economics. It explicitly identified itself as a discussion draft rather than an on-chain proposal. This was a conflict over who should be carried forward and how maintenance should be financed, as well as over technology. The possibility of changing organizations without abandoning the chain became central to the community's claim that continuity could preserve relationships a hurried migration would exclude.

The August 5 continuation proposal illustrated a mint of roughly 1.079 billion SCRT, leaving existing holders with about a quarter of the expanded supply while retaining their absolute balances. It allocated funds for development, infrastructure and remediation, with vesting and staking arrangements that could give allocations voting power before all principal unlocked. These are the proposal's figures and design choices, not a live supply reading.

Its explicit admission of dilution and concentration risk is essential to understanding why supporters and opponents could both favor survival yet disagree sharply about its financing.

The August upgrade coordination thread shows that the path to execution was not instantaneous. An initial schedule was delayed, followed by an August 12 announcement of an on-chain proposal and target height for v1.26.0-community-continuance. Such notices document coordination and intended activation rather than independently proving execution at the estimated hour. They also show why historical guides should preserve the status of each record: testnet success, a submitted vote, a projected block and a completed mint are different events with different evidentiary strength.

In September 21 replies, Foundation representatives confirmed that the mint had occurred. Lisa Loud said there had been no core-development distributions, described validator announcements and limited infrastructure or exchange-support spending, and reiterated reporting commitments. On September 29, crypto_mentions still asked when remediation would be distributed. This establishes a post-mint continuation discussion, not a completed reimbursement program.

The replies are management representations rather than audited accounts; wallet-level reconciliation and published payment records would be needed to substantiate every category and beneficiary.

Secret's governance documentation describes bonded SCRT voting, with delegators inheriting their validator's choice unless they vote themselves. The available options include approval, rejection, veto and abstention. That mechanism explains why passive staking can carry political consequences, particularly when large allocations alter the distribution of bonded tokens. It does not make every forum poll binding or ensure that a funded organization delivers its commitments.

Parameter changes, software execution and subsequent organizational spending still require separate records, even when they originate in the same governance debate.

Jiricepelka's August 24 fee discussion argues that existing minimum tiers produce too little revenue and weak resistance to spam. The post proposes higher tiers while acknowledging possible harm to application demand and IBC relayer economics. Its dollar estimates are the author's contemporary calculations, not permanent prices. By September 9 the author was still discussing a signaling proposal. The record therefore supports a debate about resource costs and sustainability, not a claim that the proposed increases had already become the network's mandatory fee schedule.

The project's Secret Finance explanation makes the original application case concrete: encrypted inputs can support lending checks and financial contracts without exposing every underlying detail. That is a reason builders may value the technology even when the network's financing is disputed. It does not make a private lending position solvent or a bridge reserve fully backed. Confidentiality governs who can inspect information; credit risk, collateral design, administrator powers and the accuracy of the input remain separate questions for each financial application.

The February 11 SecretVM announcement introduces AMD SEV-SNP alongside Intel TDX for hosted confidential virtual machines. It describes a different workload and trust boundary from SGX-based on-chain Secret Contracts. Consequently, a product's new processor support must not be interpreted as a completed replacement of L1 execution hardware. The announcement's benchmarks are the team's internal comparisons on specified machines, not universal performance guarantees.

Its later historical banner also warns readers not to assume the organization named in the original launch still maintains the network itself.

The early network history records a community trying to make private computation useful across tokens, applications and other chains. That wider ambition helps explain why supporters see more here than a private payment coin, but it does not validate every later product under the same brand. The most informative assessment follows deployed contracts, maintained clients, explicit operator responsibilities and the status of recovery obligations. Historical bridges and application lists show what was attempted; they should not be read as a current inventory of safe or supported services.