Seismic: shielded EVM, disclosed risks and unanswered tokenomics

Project Research Dossier — Seismic Research snapshot, 2 November 2026. Research and writing by rammanbl4. Source limitations are stated below; no independent audit or project endorsement is claimed.

Research question Can shielded EVM execution help financial applications keep customer information private without abandoning familiar development tools? Seismic is a candidate for technical due diligence, not a token purchase recommendation.

What is being built The documentation describes an EVM chain using a modified Solidity compiler, TEE-secured execution and flagged private storage. Shielded types route reads and writes to CLOAD/CSTORE; encrypted transaction type 0x4A protects calldata in the described execution path.[1] The inference is that existing Solidity skills can remain useful, while applications must still be designed to avoid disclosure through public state or interfaces. This is an architecture description, not an independent security finding.

The public site positions Seismic as infrastructure for stablecoin financial services. It names Seismic Systems Inc. and says licensed partners provide many services; it expressly distinguishes the company from a bank or money-services business.[2] These are self-reported statements. Availability, legal responsibility and partner controls must be verified separately. Product-service claims should not be treated as guarantees from the blockchain itself.

Evidence of execution and team The public SeismicSystems GitHub organization exposes execution-client, consensus, enclave, compiler and virtual-machine repositories. Its overview lists recent updates, including 30 October 2026 for several core repositories.[3] This supports the existence of public development work. Repository dates and stars do not establish code quality, audit coverage, deployment correctness or commercial adoption. The organization page does not publicly list individual members. Investor a16z names Lyron Co Ting Keh as founder and states it led an investment.[6] This is attributable investor testimony, not an independent background check or evidence that every contributor is identified.

Current stage and quest eligibility The node FAQ calls the chain pre-mainnet, describes a test network and says no mainnet outage history exists because mainnet has not launched.[4] An official 13 May X post announces a live testnet.[5] Neither statement proves that a token has not launched or that no public token sale occurred. The visible profile posts inspected on 2 November did not establish a current token sale, but that limited view is not an exhaustive historical check. On 2 November, an X Latest search from:SeismicSys token returned an older application-design post, not a native-token launch. A combined token/TGE/sale search returned no latest matches. Together with the site/docs review, this is a dated negative screen: no public native-token sale or active TGE identified in the inspected official sources. Search incompleteness remains a limitation, not proof that no event ever occurred. This bounded source check is the basis for selecting the project; it is not a certification of an exhaustive sale history.

Tokenomics and dilution No verified native-token allocation table, maximum supply, circulating supply, valuation, emissions schedule, vesting cliff or unlock calendar has been established in the sources reviewed. FDV and market capitalization therefore cannot be calculated responsibly. A testnet gas unit is not evidence of a tradeable token or entitlement. No allocation or reward is assumed. For a future disclosed supply schedule, record both new transferable supply and its percentage of existing circulation: new unlock / circulation immediately before unlock. An illustrative 20 units unlocked against 100 previously circulating is 20% additional float, not 20% of an unknown maximum supply. This is arithmetic guidance only, not a Seismic forecast. Unlocking enables transfer; it does not demonstrate a sale.

Risks and decision conditions Hardware/attestation: the FAQ describes Intel TDX and matching node software.[4] Review vulnerability handling, key management and recovery assumptions; do not equate TEE privacy with zero trust. Application privacy: the official Footguns page documents a concrete hazard: a function with shielded parameters can still be called through a regular transaction, exposing its inputs. It also describes gas/branching side channels and public getters that disclose unshielded data.[7] Review encrypted-call enforcement, signed-read access controls and side-channel-aware application design; do not assume a shielded variable makes an application private. Key custody and operations: the enclave README describes a RAM-only network-root-key custodian and separate attestation service.[8] This is a published control boundary, not proof of resilient key recovery or audited isolation. Supported deployment environments and uniform software versions can constrain operator independence. Execution and governance: compare reviewed code versions with deployed releases and identify who controls changes. No security-audit conclusion is claimed here. Economic and legal: token value capture, incentives and supply remain unknown. Financial-service delivery can depend on external providers and jurisdictional controls. Neither funding publicity nor testnet activity establishes durable demand. Research conclusion: the public technical material supports further study, but the missing supply and allocation data do not support a defensible token valuation. No expected return, allocation or token entitlement is claimed. Evidence that would change this conclusion includes dated official launch/sale records, supply and vesting disclosures, an audit tied to a release, and verifiable control/upgrade documentation.

Disclosure Prepared for the Republic educational quest, which offers 75 VP upon approval; no approval or award is claimed. No purchases or financial transactions were performed during this research. On 2 November 2026, the author confirmed no investment, equity stake or remuneration from Seismic. The educational quest's potential 75 VP reward is separate from Seismic remuneration.

Primary source ledger (read 2 November 2026) [1] https://docs.seismic.systems/overview/how-seismic-works — architecture and privacy model; project documentation, not independent assurance. [2] https://www.seismic.systems/ — product positioning and company/partner disclaimer. [3] https://github.com/SeismicSystems — public repositories and dated overview updates; code was not executed or audited. [4] https://docs.seismic.systems/reference/node-operator-faq — TEE requirements and pre-mainnet statements; may lag announcements. [5] https://x.com/SeismicSys/status/2054566547255898360 — official testnet announcement; personally read in Chrome profile, auto-translated UI. [6] https://a16zcrypto.com/posts/article/investing-in-seismic - investor announcement 6 March 2025; interested-party founder/investment attribution. [7] https://docs.seismic.systems/seismic-solidity/footguns - published privacy hazards and mitigations, not proof of a tested exploit. [8] https://github.com/SeismicSystems/enclave - documented custodian/attestation architecture; no code execution or audit performed. Additional: https://docs.seismic.systems/ — tooling overview; https://docs.seismic.systems/llms.txt — navigation index, not proof of absent token plans.

Education QA appendix - actual work and limitations Research and the slide/rubric notes below were prepared by rammanbl4. The short QA proposal was shared at 05:25 Moscow and the full working research PDF at 11:28 on 2 November. At 20:26, nzubemush replied: "You pretty much covered it all. Not sure I need to add anything". This is the actual feedback received after sharing. It is not evidence that nzubemush inspected every quiz question, co-wrote this article, or independently verified each source. No such claim is made.

Quiz reviewability finding: after completed education, the briefing review returned to the objective; the current Briefing & Concept Check section displays Complete and static instructions without exposing quiz stems/options. We could assess this review path, but could not perform a question-by-question quiz QA. Please treat that part as an explicit limitation, not completed question-level review. A read-only question/option review after passing would enable the requested end-to-end QA without resetting progress.

The Objective Report exposes PDF and Research Article, but no separate Full Feedback field. The feedback is therefore included transparently in this appendix. Slide-level observations refer to the briefing personally read on 28 October; report workflow and limits were checked again on 2 November. The report picker says 8MB, while objective prose says 10MB; synchronize the published limit.

Priority fixes

1. Publication destination conflicts. The objective says to write the research article in the Objective Report, which is published to the Research archive after approval. Slide 7 instead requires Discord Headquarters Research Forum text plus a screenshot. Synchronize the slide and submission checklist with the current report workflow; state whether Discord is optional or required.
2. Reward conflicts. The objective displays 75 VP; slide 7 says 50 VP after approval. Show one current reward and explain any separate solo/team components.
3. Eligibility differs. The objective requires no public raise and no active ICO/TGE. Slide 7 additionally excludes projects already committed to a competitor launchpad. Put the complete current eligibility rule in both places and specify acceptable evidence when a project has not disclosed a launch plan.

Slide-level notes Slide 1, Beyond the Hype: add a concrete claim-to-source example. Separate avoiding unsupported claims from predicting future returns; research does not guarantee an outcome. Slide 2, Research in Practice: the verifiable-link contrast is useful. Add source date, version and a distinction between a project's assertion and independently verifiable implementation evidence. Permit an explicit unknown when disclosure is unavailable. Slide 3, The Legion Standard: distinguish reputation/access information from evidence about project quality. Link the current score documentation and date the description. Reduce density by moving score components into a separate panel. Slide 4, Tokenomics 101: correct the definition of total supply: it is not necessarily the maximum number that can ever exist. Distinguish current total, circulating and maximum supply, including an uncapped maximum. State which supply basis FDV uses. Define the denominator and time window of the 30–40% early-unlock heuristic. Clarify that unlocking permits transfer but does not prove a sale. Slide 5, Good vs. Bad Tokenomics: keep the illustrative label, but avoid treating a 12-month cliff or FDV/market-cap ratio as a universal quality verdict. Add a worked numerical unlock example with assumptions, circulating-supply change and alternative sale-pressure scenarios. Slide 6, Vetting the Vanguard: distinguish self-reported founder profiles from corroborated work. An audit must identify scope, date, code version, unresolved findings and deployed-contract match. Explain how to evaluate private repositories or anonymous contributors without inventing evidence. Slide 7, Understanding Sale Dynamics & Next Steps: fix publication, reward and eligibility conflicts above. Add non-financial contribution examples such as documentation corrections and reproducible bug reports. Separate required coursework from optional staking/LP/product use; completing this research should not imply a financial transaction.

Proposed dossier rubric improvements

• Require a dated eligibility check and source ledger: claim, primary-source URL, version/date, evidence and remaining uncertainty.
• Show supply definitions, allocations, next unlock dates, emission assumptions and a simple dilution calculation; mark undisclosed values as unknown.
• Distinguish deployed code, audited code and announced plans.
• Include contrary evidence, technical/execution/governance risks, limitations and genuine author disclosures.
• Grade evidence quality and reasoning, not optimism or a bullish rating.
• List required upload fields, limits, publication destination and reward consistently.