Wanchain's official introduction dates the project's founding to 2017 and describes a network connecting otherwise separate blockchains. Its premise is that useful applications should be able to move assets and information across differing execution environments. That vision does not require every user to abandon their original chain. The documentation's product-support table is correspondingly specific: a network supported for an asset bridge is not automatically supported for every messaging, swap or accelerated-transfer product.

Connectivity is a collection of implemented routes, not one universal switch.

The December 11, 2018 Wanchain 3.0 announcement connected Bitcoin, Ethereum and selected Ethereum tokens through the then-current architecture. It also records a January 2018 native-platform launch and Ethereum interoperability earlier that year. Founder Jack Lu presented interoperability as a foundational component of a future digital-asset economy. The announcement's early routing example used proxy assets on Wanchain. That history should not be mistaken for a requirement that every modern route still passes through the native chain in the same way.

The Wanchain Layer 1 provides an Ethereum-like execution environment with Galaxy proof-of-stake consensus. The technical introduction describes distributed secret sharing and threshold signatures as part of the randomness and block-production design. Running a native validator is therefore a different role from operating a bridge signer. The shared brand and native asset connect those roles economically, but they do not make their responsibilities interchangeable. A problem in a destination-chain bridge contract is not automatically a failure of Wanchain's own block-production protocol.

The network reference identifies mainnet with chain ID 888 and WAN as its currency, while the test network uses chain ID 999. Those exact identifiers are more reliable than recognizing a logo or ticker when distinguishing environments. They also explain why a market listing for WAN is not a directory of all chains supported by the bridge. The canonical Wanchain account concerns this native network and its associated infrastructure, not the claim that it owns or supplies consensus to every connected ecosystem.

The Galaxy parameter guide distinguishes Random Number Proposers from Epoch Leaders, which package and validate transactions. Staking power combines the committed WAN amount with a time multiplier. Delegation increases a validator's support without making every delegator a machine operator. The guide also documents different withdrawal delays for operators and delegators. These are protocol participation rules, not an instant-access savings product.

Its table retains explicit launch-era Foundation reservations, so that historical entry cannot establish the current number of independently controlled validators.

Current maintenance is visible in the separate go-wanchain-release repository. Version 3.0.4, published July 2, 2026, identifies a peer-to-peer fix and distributes platform-specific binaries. Earlier setup guides still point to older client paths and versions. A maintained release demonstrates that software was published, but it does not prove every public node installed it or independently establish current validator diversity. This is a practical reason to read operational references by date instead of assuming a tutorial's presence makes every embedded instruction current.

The current bridge-node description specifies 25 nodes, rotated and reelected monthly, with a 17-of-25 signing threshold. Secure multiparty computation and secret sharing allow the group to authorize cross-chain actions. This model distributes signing power; it is not equivalent to the destination chain independently verifying the complete consensus history of every source chain. Permissionless candidacy also does not establish that the active operators have unrelated owners.

The relevant questions include actual operator independence, software behavior and the contracts interpreting the signed authorization.

The bridge-node fact sheet distinguishes minimum operator collateral from the higher requirement for accepting delegation. It also describes a monthly exit cycle: an unstaking request before month-end is returned on the tenth of the following month. That differs from the native validator withdrawal schedule. Someone choosing between the two staking roles therefore needs to compare operational exposure and access to capital, not just displayed rewards. A familiar WAN balance supports both systems, but the contracts and timing governing that balance are different.

The November 10, 2020 Wanchain 5.0 announcement explicitly described moving from a more restricted earlier arrangement toward community-operated Storeman nodes. It connected collateral, delegation and bridge capacity, while presenting a future cross-chain financial ecosystem as the ambition. The old release's group sizes and collateral examples belong to that period. They should not override the current 25-node specification. Historical progress toward more open participation is meaningful without treating the contemporary marketing phrase about perfect security as a proven property.

The security-mechanism documentation discusses the risk of an adversary controlling enough nodes in one signing group and describes randomness intended to make grouping less predictable or biased. This is an explicit adversarial assumption, not simply a claim that decentralization makes collusion impossible. Economic collateral and cryptographic signing address particular failure modes. They do not, by themselves, validate the interpretation of every signed field inside a separate chain's contract.

That boundary became especially important when evaluating the later Cardano integration incident.

Wanchain's July 28, 2026 postmortem reports that an attacker withdrew about 515 million NIGHT from its Cardano bridge contract on July 20. It attributes the exploit to ambiguous serialization of adjacent numeric fields: a valid signature for a small withdrawal could authorize a differently interpreted amount. The publisher says its MPC network and private keys were not compromised. It describes recovery efforts and a fix still undergoing work, not a completed recovery total. This incident supersedes older claims that the bridge had never been exploited.

The maintainer report also says two external audits had not found the flaw. Its account distinguishes the vulnerable Cardano code from other integrations, but that distinction is a claim about this particular attack surface, not a universal certification. Neither a promised fix date nor the continued presence of a route in general documentation demonstrates that remediation, reimbursement and independent review all finished.

The main website distinguishes ordinary token bridges from native-to-native asset routes. A lock-and-mint transfer holds an original asset and creates a representation elsewhere, with burning and release on the return path. These are linked balances with a redemption dependency, rather than two unrelated native assets. NFT transfers similarly preserve identifiers and attributes while representing the original on another chain. The route's mechanism matters more than the broad label cross-chain because it determines what backs the destination asset and how an exit is authorized.

For supported USDC transfers, the CCTP integration uses burning, Circle's signed attestation and minting on the destination chain. The documentation says WanBridge selects this route when available and otherwise uses its standard mechanism. This changes the trust boundary: the issuer's attestation is part of the transfer rather than a lockbox backing a newly wrapped coin. A shared interface can therefore expose economically similar transfers that have materially different contracts and dependencies. The supported-chain table should be checked for the selected route and protocol version.

XPort combines the bridge-node group with gateway contracts that send and receive arbitrary data. The gateway is the contact point for application developers, while off-chain relayers move the message between networks. Its stated alignment with an interoperability specification concerns interface design; it does not make an application's interpretation of a received message automatically correct. Applications still decide what the message authorizes, which sender is trusted and how failures are handled. A successful delivery and a safe business operation are separate outcomes.

XFlows is described as a native-to-native swap interface that selects among route types. QUiX adds intent-based execution through independent solvers and currently documents ETH, USDC and USDT support. The advertised short completion time describes product behavior under suitable conditions, not a universal finality bound for all networks. Solver execution is also distinct from the native chain's staking consensus. A user should be able to identify the received asset and route rather than assuming every transfer under the Wanchain name uses an identical process.

The fee guide separates a network fee covering on-chain costs from a service fee related to transferred value. It gives common limits and percentages but explicitly defers to the live bridge quote when the documentation and interface disagree. That qualification matters because costs can differ across destinations and asset types. A low percentage alone can also hide the importance of a minimum fee for a small transfer. An economic comparison needs the complete quoted cost and the actual amount expected on the destination chain.

Convert n' Burn connects bridge activity with WAN by converting collected fees and allocating the resulting value across the ecosystem. Its stated goals combine operating-cost recovery with incentives for participants. The name can be misleading if read literally: the distribution reference includes operations, treasury, native validators, bridge nodes and xWAN rewards as well as a burn address. It does not say all fees are destroyed. Nor does collecting fees in several assets mean each fee-paying bridge user must personally acquire WAN first.

WAN is the native coin used for transactions and infrastructure staking, with a documented maximum supply of 210 million. It is also the reference asset for fee conversion and governance. These roles provide specific ways network activity can interact with the coin, but none guarantees a market price. Holding unstaked WAN differs from operating a node, delegating to one or depositing into an application. Each activity can have its own source of rewards, costs and conditions for recovering the underlying balance.

The xWAN documentation calls it an escrowed WAN derivative. Conversion into xWAN is one-to-one, but immediate redemption returns only a fraction of the corresponding WAN; the documented full ratio requires a 90-day vesting choice. That asymmetric exit is central to understanding incentives advertised in xWAN. A reward denominated in the derivative is not immediately equivalent to the same amount of freely transferable WAN. The page's old in-development label for staking also needs to be read alongside subsequent product announcements rather than treated as the latest release status.

XStake combines native-validator and bridge-node delegation in a web interface. Its documentation explains that the former supports the Layer 1 and the latter supports cross-chain operations. Daily reward presentation does not erase those different roles or their withdrawal rules. An interface that offers both can simplify access while still requiring users to understand which contract holds their delegation. The important distinction is what work the stake supports and what conditions apply, not merely that both options display the WAN symbol.

The April 10, 2026 announcement added reverse xWAN staking, described as depositing supported BTC, ETH or stablecoin assets to earn xWAN. It contrasts that direction with staking xWAN for a share of bridge-fee rewards. The publisher's historical APR examples are variable observations, not promised returns. Its economic story depends on actual fee generation and allocation. The same article's then-current security superlatives cannot be retained as September facts after the later bridge incident; product mechanics and promotional assurances need different treatment.

The January 9, 2025 Proposal 0 framed a community treasury funded from bridge fees and invited discussion of pledges, voting and funding. Its language was explicitly provisional. The August revision described changes responding to feedback, including limits on request size and a participation-history requirement. Together these records show an evolving design rather than a constitution fixed at launch. They also identify a tension within the stated goal of inclusion: financial commitment may discourage spam while making participation more demanding for smaller or less active users.

The September 21, 2026 governance FAQ describes treasury and non-treasury proposals, WAN commitments and adjustable thresholds. It explicitly retains team review before proposals become visible and says administrative or governance processes can change parameters. It also warns that voluntarily burned commitments are not returned when a proposal fails. These details qualify the broad promise of community control. The system is not simply a costless opinion poll, and permission to submit a proposal does not mean every submission automatically reaches a binding vote.

Kurisu's September 15, 2026 proposal sought to raise the burn allocation from ten to twenty percent by reducing the treasury share. Its projected net deflation assumes the contemporary bridge-fee flow continues; it is not a guarantee independent of activity. The proposal also argues existing treasury reserves provide sufficient runway, which is an economic judgment open to disagreement. The structural tradeoff is clear even without accepting the projection: less revenue retained for discretionary ecosystem work and more converted WAN permanently removed.

On September 30, the Reddit account Alternative_Type6050 reported that the first proposal had passed and that the new allocation would start in October. This is a dated community report of the result. The governance interface did not expose a readable vote receipt in this review, and October implementation is still future relative to the review date. The article therefore does not certify an executed change or already-established deflation. Completed allocations and subsequent supply records are the evidence needed to evaluate the claim in practice.