The new public chain Final announced on September 15th that its first major version, Shannon, was already running on the development network. The project positions itself as an “adaptive blockchain network” and showcases a structure composed of a main chain and a transaction chain, with plans to provide core facilities such as derivatives, spot trading, and stablecoins at the protocol layer. What needs to be clarified at this point is the status: what has been launched is Devnet, not the mature mainnet for everyone. The official website states that Shannon will be opened to the public “in the near future,” and currently, the page still provides an application access link; functions such as wallets, bridges, and documentation are also marked as upcoming.
"The development network is up and running" can prove that the project has begun, but it does not prove that the economic model is valid.
The purpose of the development network is to allow teams and early developers to verify consensus, transaction execution, node operation and maintenance, and interface design in an environment that does not involve real assets. It is closer to a real system than a white paper, as the code needs to continuously generate blocks, process transactions, and expose potential faults; however, it still has a significant difference from the mainnet. The scale of participants, motives for attacks, asset value, and traffic pressure are all different, so the performance of the development network cannot directly represent the security and performance of the mainnet once it goes live.
Final states that Shannon is composed of two interconnected chains, with the goal of adapting to different loads. The project draws an analogy to the elastic scaling of cloud computing, hoping that the network can adjust its performance and resources according to the usage scenarios. This approach addresses a long-standing issue faced by public blockchains: reserving too many resources for peak times reduces efficiency, while designing for average loads leads to congestion during periods of high demand for popular applications. However, it remains unclear which protocol mechanisms are used to achieve "adaptability," as well as the speed of adjustment and the boundaries of security. Complete technical documentation, code, and public test descriptions are still needed to clarify these aspects.
The project also lists Final Trade as its primary core facility, describing it as a high-performance decentralized exchange for derivatives and spot trading. The preview page claims to offer up to 50x leverage, zero Gas fees, low order execution costs, and market-making rebates. However, these are product specifications and statements from the project team, not yet verified by the market in terms of actual trading capabilities. Leveraged trading involves complex processes such as order matching, oracles, settlement, and risk management. Any delay or abnormal price movement in any of these areas can quickly amplify losses.
Integrating transaction facilities “built-in” into the network may allow the blockchain to directly generate revenues such as transaction fees, rather than relying solely on general computing fees. Final states that its economic system will be supported by revenues generated from derivatives, spot transactions, and stablecoin facilities. This design attempts to address the issue of value capture for new public blockchains: if applications earn revenue while the underlying infrastructure only charges a small fee, how can tokens and validators obtain sustained returns? Built-in facilities can streamline the value chain, but they also expose the protocol to greater business risks.
Built-in exchanges also bring about issues of neutrality. General-purpose public chains usually allow multiple applications to compete, with the protocol providing only execution and settlement services. If official facilities have inherent advantages in terms of performance, fees, or order processing, it is necessary to clarify in the rules and code whether third-party trading applications can still compete fairly. Final also emphasizes "trustworthy neutrality" and community-driven development; how these two goals are compatible with built-in core facilities will be a question that must be answered before the mainnet goes live.
The performance figures displayed on the official website should not be regarded as an independent benchmark at present. The number of blocks, the number of transactions, and the maximum TPS require a clear understanding of the testing environment, node distribution, transaction complexity, and duration; single peak values are not comparable. Truly meaningful evaluations include sustained throughput under multiple verification nodes, network fluctuations, and complex contracts, as well as failure recovery and state synchronization times. "High performance" without a clear methodological basis is more akin to a statement of intent or a roadmap.
From Shannon to the mainnet, the market should focus on code, permissions, and risk control.
The first check is the degree of openness of the development network. Who can run nodes, who can submit transactions, how validators can join, and who decides on network upgrades all affect whether the testing is close to a public environment. If the early network consisted of a small number of controlled nodes, it is suitable for functional verification, but it does not prove the decentralization or resistance to censorship capabilities. The project claims to have no institutional stakeholders, yet it still needs to be verified through token distribution, financing disclosure, and governance structure.
The second point is transaction security. Derivatives platforms must disclose margin requirements, liquidation priorities, insurance or risk funds, price sources, and procedures for dealing with extreme market conditions. A leverage ratio of 50 times means that even small price fluctuations could trigger liquidation, and low latency cannot replace sound risk management. If stablecoins also become part of the protocol economy, it is also necessary to clarify the procedures for collateralization, redemption, issuance rights, and handling in cases of decoupling from the underlying asset.
The third point is bridges and wallets. New chains often experience losses at points outside of consensus, especially with cross-chain bridges, private key management, and front-end signatures. The Final website currently indicates that wallets and bridges are about to be launched, suggesting that the ecosystem's entry points are not yet fully established. Before the mainnet is opened, the audit scope should not only cover the core chain but also include bridge contracts, upgrade keys, oracles, and the official front-end.
The fourth point is developer experience. Documentation, SDK, test tokens, block browsers, and error diagnostics determine whether external teams can truly build applications. The official website currently has a browser entry point, but the technical documentation still indicates that it will be launched soon. If a public chain only has official trading facilities and lacks third-party developers, it is difficult to verify its so-called universal adaptability, and it is also easy to equate the network's value with the trading volume of a single product.
The fifth point is the clear threshold from the development network to the main network. The team should announce the testing phases, known issues, audit results, and conditions for going live, rather than just providing vague dates. Phased openings, incentive test networks, main network test versions, and fully permissionless main networks represent different risks, and the media and users should not confuse them. Even once the main network goes live, early-stage assets should only bear risks that are commensurate with the experimental phase.
Shannon has enabled Final to move from a conceptual stage to an observable engineering phase, which is a substantial advancement; however, for now, what can be confirmed is only that the limited development environment is operational and the design direction of the project has been announced. Whether an adaptive architecture, built-in revenue models, and high-performance transactions can all be achieved simultaneously will still need to be verified through open-source code, decentralized nodes, stress testing, and real-market validation. The most valuable focus for new public chains is not to prematurely believe in a new concept, but to carefully check what it actually delivers at each stage of its launch.
