smartBCH's client repository describes an EVM and Web3 compatible sidechain for Bitcoin Cash. This means a separate execution environment and ledger, not an EVM feature that every Bitcoin Cash node executes. Its source tree includes application, staking and cross-chain components, showing that the project had to supply the surrounding machinery as well as contract execution. The distinction is essential when reading its history: a successful Bitcoin Cash transaction did not, on its own, establish that a sidechain operator would issue, exchange or redeem the corresponding balance.

The original FAQ described a familiar account-based environment for Solidity applications, supported by custom execution and database libraries. MoeingEVM aimed to run independent work concurrently, while specialized storage structures traded memory and other capabilities for faster access. These were engineering choices, not proof that every workload would achieve the largest benchmark number. The FAQ itself separated limited storage tests from full-chain performance.

Its old claim that there would be no distinct smartBCH coin must now be read historically, alongside later announcements explaining why the asset identity needed to change.

The execution design separates Tendermint's job of agreeing on blocks from the state machine's work of executing transactions. Transactions enter a standby queue, run in isolated contexts and are checked for conflicting state access before their changes are committed. A conflict can push work into a later round, and the design includes limits on how long it remains pending. This explains why parallel processing is conditional: two unrelated transfers may proceed together, while contracts competing over the same state cannot simply ignore each other's effects.

Throughput depends on the workload and scheduling behavior.

The developer guide encouraged use of existing Ethereum tools but acknowledged missing RPC features and compatibility bugs. It recommended testing applications against smartbchd rather than assuming that success on an Ethereum development simulator was sufficient. That was a practical admission of the cost of an alternative implementation. Wallets, indexers and contract backends need matching behavior at the boundaries they actually use.

Familiar bytecode and familiar addresses simplify migration, but they do not remove the need to check transaction receipts, event handling, gas behavior and unsupported interface calls.

CoinFLEX's August 23, 2021 roadmap said that its bridge had been operating for a week. Users then needed an exchange account, with an account-free interface planned for a later phase. The exchange described custody arrangements and presented its operational experience as a reason to trust the service. Those assurances are part of the historical record, not guarantees adopted here. The arrangement depended on an identifiable company while the proposed decentralized gateway was unfinished.

Removing an account-registration step later would not, by itself, remove custody or give holders direct control of the reserves.

nullama's August 2021 discussion made that dependency explicit before the crisis. The post compared the documentation's decentralized-bridge description with what users actually had to do, and pointed out that the alternative was still unfinished. Replies disagreed about whether CoinFLEX was a custodian or merely a facilitator. This is useful evidence of an early information problem: users could agree that an interface moved coins while holding very different beliefs about who controlled the backing.

The post was a request to describe the working system accurately, rather than a claim that EVM applications had no value.

In October 2021, steeevemadden asked whether CoinFLEX could jeopardize the whole ecosystem. Mark Lamb replied under mark_coinflex, acknowledging discomfort with a centralized launch arrangement and defending it as a way to avoid delaying development. His answer relied on a future SHA-Gate transition and a broader journey toward decentralization. The exchange is valuable precisely because both the risk and the justification were visible. An intended exit from a dependency is different from an enforceable deadline or a technical mechanism that prevents that dependency from failing first.

jldqt raised a related objection in February 2022: advertising a present system through expected future features could mislead new users. The author also corrected part of the post after replies supplied information about burns. That combination is worth retaining. A participant can be wrong about one accounting detail while identifying a real distinction between custody and decentralization. The thread did not establish every later allegation about CoinFLEX, but it shows that skepticism was not invented after losses.

Some users were already asking promoters to separate aspirations from deployed protections.

On July 1, 2022, smartBCH published a bailout plan stating that the CoinFLEX-operated bridge was stuck and the sidechain asset was no longer anchored one to one. The authors argued that reserve coins belonged to bridge users and proposed a collective rescue arrangement. Those statements include the project's position on ownership and legal priority; they should not be mistaken for a court ruling. The immediate operational fact was narrower and devastating enough: users no longer had a dependable ordinary exit, and the team could not give a guaranteed reopening date.

The June 2023 distribution update recorded assets received by SmartBCH Alliance Limited, including BCH, USDC and rvUSD, with part of the USDC reserved for expenses. It also described further entitlements not yet received and warned that the assets held did not match all circulating sidechain claims. This was partial recovery with continuing exposure, not restoration of complete backing. A nominal one-to-one trading price could coexist with an inability to satisfy all holders at once.

The announcement is a historical statement of the Alliance's holdings and responsibilities, not a current reserve attestation.

The archived-in-place SHA-Gate covenant documentation describes operators, monitors and rules for spending cross-chain outputs. Its design permits seven of ten operators to authorize spending, while a prolonged availability failure leads to a special recovery path. The page also notes that recognizing one monitor-driven path would require a client change. These are explicit trust and implementation assumptions. Reading the specification does not establish deployment, correct operation or replacement of CoinFLEX custody.

The name SHA-Gate circulated widely enough that later users sometimes applied it to quite different tools.

The June 2023 atomic-swap introduction made an unusually clear distinction: swapping existing BCH and SBCH does not mint or burn the supply on either chain. It exchanges assets already held by two parties. That makes it different from a canonical bridge that issues claims against reserves. The project's tools aimed to improve available exchange routes and published code for contracts, covenants, bots and a front end. Their existence did not refill missing reserves. An individual could potentially find a counterparty even while the broader backing shortfall remained unresolved.

The market-making bot design used linked hash locks and time limits, with a bot supplying assets on both networks. A taker's redemption revealed the secret needed for the other side of the exchange. The bot advertised fees and constraints, and could serve a trade only while it held enough funds. This is a different operational problem from promising that an entire outstanding supply can be redeemed. Atomicity can constrain theft within a correctly implemented exchange, but it cannot create liquidity, compel a counterparty to cooperate or guarantee that a failed attempt costs no fees.

MrFroste reported recovering roughly 100 BCH through a bot in March 2024, accepting a substantial fee and several days of waiting. The post explicitly said the author did not know the operator and warned about limited inventory. It also called the tool SHA-Gate, illustrating why user terminology needs checking against the project's own technical distinctions. This is meaningful first-person recovery evidence, not a tested recommendation for today's reader. A historical success with a particular bot does not establish current balances, current terms or universal recovery for other users.

The team reported a chain halt on July 6, 2023 and published an emergency restart patch using one validator. The announcement called it an interim measure and explained that low rewards and weakly managed infrastructure had complicated coordination among the prior validator set. This was a consensus availability incident separate from the bridge insolvency. A running chain could not repair missing reserves, and a fully funded swap route could not make transactions progress while consensus was halted.

Preserving both failures prevents the history from collapsing into a single vague story about a bad bridge.

A companion voting-scheme post explained the tradeoff that had preceded the halt. Low participation thresholds were meant to attract more validators, but unreliable machines and unresponsive operators could interrupt the system. Its proposed response was to increase economic requirements and introduce penalties. This makes the governance problem concrete: maximizing the count of registered validators is not the same as maintaining independent, responsive infrastructure. The announcement records the team's diagnosis and intended remedy.

It does not demonstrate how much independence the resulting set possessed or prove that every later availability problem was solved.

The August 2023 staking explanation scheduled a change at height 11006000. It disabled proof-of-work hash-rate elections, required collateral and used the XHedge-based participation path. It also distinguished short-term reductions in voting power from longer offline penalties and double-signing sanctions. These details make an old description of smartBCH as simply secured by Bitcoin Cash miners incomplete. Consensus rules evolved in response to an observed failure.

The announcement's amounts describe that historical upgrade, not an independently measured current validator portfolio or an assurance about staking returns.

The client changelog corroborates that the software moved to full proof of stake and added offline and double-signing controls. It separately records the later symbol and supply changes, along with fixes to execution and RPC behavior. This is valuable implementation evidence because it connects announcements to published software features. A changelog still does not reveal which version every public node is running.

The account therefore describes the documented evolution without claiming a fresh network-wide census, a live security audit or proof that all remaining service providers apply identical configuration.

The December 2023 symbol-change announcement directly acknowledged that the Alliance could not satisfy all potential withdrawals. It proposed renaming the native asset to SBCH because it was no longer economically interchangeable with main-chain BCH. This was more than cosmetic branding. A shared ticker had encouraged readers to treat two differently constrained balances as the same thing. Naming the sidechain asset separately made its remaining supply, liquidity and recovery prospects easier to discuss honestly.

A desired peg is a policy objective; it is not the same as reserves sufficient to honor every redemption.

The January 29, 2024 follow-up specified client version v0.6.0 and activation height 13627300. It described changing the native-token metadata, revising reported supply and clearing the old disabled bridge account's balance. These are software and accounting changes, not evidence that missing main-chain coins reappeared. The publication date is a confirmed historical event; the estimated February activation date should not be substituted for an independently verified block timestamp.

Readers investigating balances need the network, token representation and relevant software era, rather than relying on a wallet's old BCH label.

Development publications continued beyond the most visible rescue announcements. A March 2024 article described an enclave-based random-number service that signs the relationship between a block height and a verifiable output, avoiding reliance on only the EVM's recent block-hash window. This was a specific attempt to improve application infrastructure. Its security depends on the stated software, key and enclave assumptions; the article's broad language about trustworthy light clients should not be generalized into unconditional safety.

Continuing research does not prove that bridge losses were resolved or that applications had regained their users.

The surviving documentation itself requires care. Its introductory page still invites review of SHA-Gate feasibility and implementation, while describing the EVM interface and separate development proposals. Such a page is valuable historical and technical evidence, but cannot settle the current status of every service. This account does not claim a verified September 2026 redemption facility or complete repayment. To update that conclusion, a researcher would need contemporary operator statements, inspectable contracts or transactions and current reserve or liquidity evidence.

A reachable documentation site is not a substitute for those checks.