Enjin activates Fort Canning on Relaychain as Matrixchain vote opens

Enjin activated its Fort Canning runtime on the network’s Relaychain on November 9, while opening a separate governance process on November 10 for a broader Matrixchain upgrade scheduled one week later.

Enjin’s updated protocol changelog says Relaychain runtime version 1.8.0 took effect at block 18,059,101 at 17:10 UTC on November 9. The project’s governance repository shows that the preceding block applied the runtime authorized by referendum 16, moving the network from specification version 1070 to 1080 and transaction version 18 to 19.

The completed activation matters immediately to validators, exchanges and software that signs Enjin transactions. The pending Matrixchain vote is potentially more visible to users because that chain hosts Enjin’s gaming tokens, collections and marketplace functions. It remains a proposal, however, rather than an activated feature release.

Relaychain rules changed at activation

Fort Canning raised governance deposits, introduced minimum support requirements across referendum tracks and changed the denominator used to measure support. According to Enjin’s changelog, the submission deposit rose from 0.025 ENJ to 1,000 ENJ, while decision deposits increased on 18 of 19 tracks. Support is now measured against total ENJ issuance rather than only active issuance, bringing tokens held on the Matrixchain into the calculation.

The runtime also introduced dispute penalties for Relaychain validators. Enjin’s governance proposal specifies a loss of 100% of stake for backing a parachain candidate ultimately found invalid and 2% for approving one, with penalties deferred for 27 eras and subject to governance cancellation. Those parameters define protocol consequences; they are not evidence that any validator has incurred a penalty.

Other changes include paginated nomination-pool reward processing, restored stake-exchange queries, marketplace settlement fixes and an update to the stable2606 release of the Polkadot software development kit.

Enjin says block production continued during the activation, although user transactions paused for several blocks while storage migrated. The project has not published an independent post-upgrade performance report, transaction-volume comparison or measurement of how many operators completed the required client update.

Old transaction versions are no longer accepted

The transaction-version change is the principal operational limitation for service providers. Enjin’s technical notice says transactions signed with version 18 are rejected after the Relaychain activation. Software that reads current runtime metadata from a node should adjust automatically, but offline signers and integrations that hard-code versions or generated types require an update.

The project required Relaychain operators to install client version 1.8.1 before activation. That client included upstream security fixes, but Enjin has not disclosed evidence of exploitation affecting its network. The runtime activation and client security release are distinct: the network now runs runtime 1.8.0, while nodes require client 1.8.1.

Matrixchain remains behind a vote

The companion proposal published in Enjin’s governance repository opens voting from November 10 through November 13. If approved, Enjin targets approximately Matrixchain block 12,331,000 on November 16 for runtime version 1.4.1. The block and time remain targets rather than completed facts.

That proposal would replace Matrixchain’s existing governance bodies with a 15-track OpenGov system. It would also add fixed-term token lending, tokens that can expire as much as one year after minting, permanent attribute freezing and mint-rate limits. Loosening or removing a mint limit would take effect after a 72-hour delay, according to the proposal.

The Matrixchain upgrade would move its transaction version from 12 to 14 and require node client version 1.4.1 or later. Enjin warns that older nodes would stop following the chain. The marketplace is expected to pause for as long as 30 minutes while listings migrate, even though the chain is intended to keep producing blocks.

None of those Matrixchain changes is active merely because the proposal was published. The next verifiable milestones are the vote result, application of the authorized runtime and post-activation evidence that nodes, transaction signing and marketplace migration operated as planned.