Elastos traces its origins to Rong Chen's operating-system work, rather than to a plan for another exchange token. Its historical account dates that effort to 2000 and the public ELA blockchain to December 2017. The later blockchain project connected that computing ambition to identity, ownership and payment records. The distinction explains its unusually broad product vocabulary: a main chain is only one component alongside personal-cloud software, application execution and communications. The current history page presents a World Computer as a direction for integrating these pieces.

That aspiration should be evaluated through released, usable components. A long development history does not itself establish that the whole original system has been completed or adopted.

The ELA main chain records transfers, validator registration, governance and cross-chain events through predefined transaction types. It uses unspent transaction outputs rather than an Ethereum-style account database and does not host arbitrary Solidity applications. Its security design combines Bitcoin merged mining with bonded proof-of-stake participation. These are distinct checks and operating responsibilities; Bitcoin miners do not review every Elastos application or guarantee that its monetary-validation implementation is correct.

Main-chain signatures also use P-256, which differs from Bitcoin's signing curve. Treating Elastos as a Bitcoin-secured ecosystem is therefore a description of one relationship in its architecture, not an assertion that all its software inherits Bitcoin's code, operating assumptions or incident history.

Elastos Smart Chain is a geth-derived execution chain with mainnet chain ID 20. Solidity tools and Ethereum wallets can connect to it using the appropriate RPC settings, but its consensus and cross-chain integrations belong to Elastos. Native precompiles expose facilities such as P-256 signature verification and main-chain block information. Developers can use those facilities to connect contracts with staking or identity information, while ordinary EVM compatibility lowers the cost of porting an application. The same compatibility does not turn ESC into Ethereum settlement.

Nor does it make its balances identical database entries to main-chain ELA: moving between those ledgers invokes a deposit or withdrawal mechanism with its own validation and reserve obligations.

The documentation distinguishes the main chain's P-256 signing keys from the secp256k1 signing used for Ethereum-compatible sidechain transactions. MetaMask can serve the latter environment; it does not thereby acquire the ability to create valid main-chain transactions. Wallet software may derive different key types and paths from one recovery phrase, but the destination chain, address format and signing library still have to match. This is a concrete integration burden for custodians and exchanges listing ELA.

Displaying one ticker is convenient for markets; it is not a safe substitute for identifying the actual ledger involved in a withdrawal. The architecture requires explicit handling of those boundaries in both software and user interfaces.

The economics reference divides block rewards into mining, validator-and-voter, and treasury shares. The stated split is thirty-five percent, thirty-five percent and thirty percent respectively. The treasury allocation finances collective work through governance rather than becoming an automatic payment to every holder. ELA also pays main-chain transaction fees, and sidechain ELA pays execution gas. The reference describes a halving-based issuance schedule, but a monetary schedule and an application business model answer different questions.

Neither a limited issuance path nor ownership of ELA promises profitable storage, successful applications or recovery of an investment. In particular, the intended one-for-one relation between main-chain reserves and sidechain balances must be checked against incident-specific accounting, not inferred from token branding.

The BPoS guide makes a practical distinction between locking ELA and voting with it: the active pledge to a validator is what earns the relevant reward share. Pledges have recorded expiry heights and cannot simply be shortened because the holder wants liquidity. Longer commitments influence the documented weighting formula, while validator performance also matters. The guide describes purpose-specific voting units for validator selection, council elections, proposal opposition and impeachment. These units are not freely transferable investments.

This gives holders routes into governance while requiring them to understand which commitment is still preventing an exit. An advertised staking return leaves out essential information if it does not also explain the pledge period, node performance and conditions for releasing the underlying ELA.

Elastos DAO uses a twelve-member council and a staged proposal process. Ideas initially live in an off-chain governance database; a council member must sponsor a formal on-chain proposal. Council review and a subsequent community opposition period precede execution. The documentation then separates milestone reporting from withdrawal transactions that actually move treasury funds. Readers should therefore distinguish an appealing forum suggestion, an approved budget, reported progress and a completed payment.

The system offers public participation but does not give every comment the same authority as a council transaction. For builders, this creates a funding route and an accountability obligation. It also makes the quality of council scrutiny and the accessibility of proposal records important parts of practical governance.

Elastos's identity documentation separates a credential holder, an issuer and a verifier. A DID document supplies keys and service information; a signed credential records what a particular issuer claims. A verifier still has to decide whether that issuer is appropriate and check revocation rather than treating any signature as truth. The same page distinguishes the on-chain did:elastos system from Runtime's local did:key identities. It labels the bridge between those formats as planned.

That is a useful boundary for the broader vision: local application identity, chain-resolved identity and institutional credentials can complement one another without already being one completed universal identity system. The distinction also prevents an application demonstration from proving every advertised interoperability scenario.

Hive stores structured information and files in user vaults operated by a chosen provider or by the user. Its documented stack combines MongoDB records with IPFS file storage and DID-based authorization. Selecting a host and controlling application access changes the relationship between an application and its users' data. It does not mean the hosting machine cannot read unencrypted files. The security section explicitly says default storage is not end-to-end encrypted against the operator; sensitive material needs client-side encryption or an appropriate self-hosting arrangement.

Backups and provider migration also require operational work. This is a meaningful ownership model, but its usefulness depends on key management, retention, availability and the actual deployment rather than on the word decentralized alone.

The July 15 notice describes an authorization defect that allowed an ordinary main-chain transaction to spend cross-chain reserve funds. Some value then followed the normal deposit path onto ESC without the reserve backing that path was supposed to have. The team introduced consensus restrictions and froze an identified main-chain address. Its notice carefully distinguished funds being contained from funds being returned to the reserve. Around 1.585 million ELA remained frozen there, requiring a separate recovery decision.

This incident concerned the reserve mechanism, not a demonstrated compromise of every user's private key. Equally, saying keys were untouched does not establish that the bridge remained fully backed or that interruptions imposed no economic cost on users.

The August postmortem attributes the July 20 incident to integer overflow in aggregate transaction-output validation. The resulting arithmetic allowed fabricated ELA to pass checks. Operators halted the chain, returned to the last unaffected block and coordinated a patched restart. The report describes removing 145 blocks, including some legitimate transfers, rather than quietly preserving every transaction during the affected interval. It also describes exchange coordination after attacker funds reached KuCoin.

These are the project's published findings and recovery account, not an independent audit of every exchange balance. The episode demonstrates a consensus-code failure separate from the earlier reserve exploit. Merged mining did not prevent acceptance of a transaction that the monetary-validation code incorrectly considered valid.

The September 1 announcement reported ESC and EID block production and transfers with the main chain reopening. It accounted for the approximately 6.03 million ELA created on ESC in the reserve incident through burns and recovered backing. The separate frozen main-chain amount still awaited a future credit to the ESC reserve. PG could continue internal activity, but its ELA cross-chain service remained disabled pending a separate review. The notice also said updated sidechain source code had not yet been published. These details narrow the meaning of its audit and restart headline.

Service resumption was an important operational milestone, while public reproducibility, remaining reserve remediation and another team's bridge review were distinct unfinished matters.

The September 21 update identifies Runtime 0.7.0 as the foundation for an upcoming ElastOS version, with new product work moving from PC2 into Runtime. It describes controlled application permissions, wallet-mediated signing and tests of local and remote AI use. Several interfaces and the next installer remained unreleased. The same update says Halborn began reviewing the pending main-chain release, with a report expected in October. An audit in progress is not a completed assurance result, and a successful internal test is not evidence of broad consumer use.

The article also continued to identify the frozen reserve amount and disabled PG cross-chain route. Its explicit unfinished-work list is more informative than treating the whole World Computer roadmap as deployed.

The May 1 announcement offered a more tangible account of the computing vision: a dApp Centre, Elacity content-market integration, signed application packages and a rebuilt protected-content access flow. It identified a community security submission by jhond0e and described fixes before release. The content system also used Base for a USDC route, showing why ecosystem activity need not all settle on the ELA main chain. That is a product-design choice, not evidence that ELA captures all related payment volume.

The announcement included limitations around wallet integration and early Runtime support. Those qualifications matter for builders assessing an actual development target, because a demonstrated marketplace flow does not eliminate the need to verify supported accounts, permissions and deployment versions.

An April 28 announcement set June 13 as the planned end of ECO Chain support following a termination proposal. It cited very limited activity and ongoing node, maintenance and cross-chain costs, and gave users a notice period to move assets. This is evidence of an approved retirement plan and its stated rationale; this review did not independently establish the last produced ECO block. ECO should not be confused with the ESC and EID restart notices or used to claim that the whole Elastos ecosystem ended on that date.

The decision illustrates a genuine governance tradeoff: keeping every historical service running consumes resources, while retirement transfers migration work and deadline risk to the users still depending on it.

In a 2021 election interview, Sunny Feng Han described his support for Elastos through a theory of personal data becoming an asset controlled by its creator. He linked that ambition to ecosystem finance projects and argued that applications, not only base infrastructure, were necessary for recognition. He also praised changes to monetary policy and disclosure of foundation assets. These are a named early investor and council candidate's reasons for commitment, expressed during a campaign.

They do not prove that those applications delivered the predicted user growth or that data monetization produces reliable income. The interview preserves a particular cultural promise while also giving readers concrete claims against which later implementation and treasury transparency can be assessed.