Fort Canning upgrades the Enjin Relaychain runtime to v1.8.0 on Monday, November 9, 2026, and the Enjin Matrixchain runtime to v1.4.1 one week later, on Monday, November 16, 2026. This entry lists the changes on each chain and the actions each audience needs to take. For an overview, read the Fort Canning announcement. Both upgrades are subject to their governance referenda passing.

Upgrade Schedule

The Relaychain upgrade is fixed to its block by the referendum. The Matrixchain upgrade takes effect when the authorized code is applied after its referendum passes, so its block is a target. Times are estimates based on current block times.

Changes

Relaychain

Governance parameters

Fort Canning tunes the governance parameters set at launch so that deposits and support requirements better match their purpose: fair and decentralized governance, with referenda decided by a meaningful share of ENJ holders. The same values apply on both chains, and the Matrixchain adopts them for its new OpenGov tracks.

• Submission deposit rises from 0.025 ENJ to 1,000 ENJ on every track. It is refunded when a referendum passes or is cancelled, and forfeited when it is rejected or times out.
• Decision deposits rise on 18 of 19 tracks. Root and Fellowship Admin move to 2,500,000 ENJ, the other admin tracks to 1,000,000 ENJ, and the treasury tracks to a stepped share of their spend caps: 2,500 / 5,000 / 12,500 / 37,500 / 250,000 ENJ from Small Tipper to Big Spender. Decision deposits are refunded in every outcome except a kill.
• Support floors are introduced on every track. A referendum now needs a minimum share of total ENJ voting in support to pass: 0.5% on Root and the admin tracks, 0.005% to 0.125% on the treasury tracks, 0.1% for Referendum Killer, 0.05% for Referendum Canceller. Whitelisted Caller drops from 1% to 0.25%.
• Support is measured against total issuance (about 2.02 billion ENJ) instead of active issuance (about 1.45 billion). ENJ held on the Matrixchain now counts in the denominator.
• Tipper caps rise to 2,500 ENJ (Small Tipper) and 10,000 ENJ (Big Tipper). Other spend caps are unchanged.
• Concurrent referenda per treasury track are cut to 20 / 10 / 10 / 10 / 10 from 200 / 100 / 50 / 50 / 50.
• Unchanged: all periods, curve shapes, approval thresholds, origins, vote locking and treasury settings.

The new values apply to referenda already in progress at enactment.

Validator accountability

• Dispute slashing. Validators who lose a parachain dispute are slashed, as on Polkadot and Kusama: 100% of stake for backing a candidate found invalid, 2% for approving one, shared with nominators, deferred 27 eras and cancellable by governance. The losing validator is also disabled for the rest of the era. Honest, up-to-date validators are unaffected.
• GRANDPA authority limit rises from 32 to 100, matching BABE, ahead of the expansion of the active set to 35 validators.

Staking and nomination pools

• Rewards are paid per exposure page. nominationPools.payoutRewards takes a new page argument and is called once per page per era per validator. The payout offchain worker examines a bounded number of pages per run and shares the work across the validator set.
• Stake exchange. The stakeExchange_queryAccountOffers RPC is served again after being unregistered since v1.4.0, and a paginated queryAccountOffersPaged is added.

Marketplace and multi-tokens

The marketplace upgrade, token lending, ephemeral tokens, mint rate limits and attribute freezing described under Matrixchain below also land on the Relaychain on November 9, where the marketplace and multi-tokens pallets back sENJ and the Degens collection. Relaychain-specific changes:

• Auction bids in ENJ are held in escrow in a marketplace account from the moment they are placed, instead of on the bidder's account. Bids placed before the upgrade stay on hold and settle as before.
• Abandoned settlements can be resolved permissionlessly with resolve_abandoned_listing, releasing the listed asset to the seller and the bid to the bidder when a sale can no longer complete.
• Large fungible listings no longer fail with Overflow.
• Lending on the Relaychain is limited to tokens minted after the upgrade, so existing Degens cannot be lent. Nomination pool tokens and sENJ cannot be lent at all.

Fuel tanks

• The creation deposit stays with the tank's creator through any change of owner and is refunded to them at destruction. A new depositor field records this (storage version 4).
• Sponsored calls that fail are now included on chain as DispatchFailed, and the tank pays their fee.
• Stricter rule enforcement. Tank owners should test their rule sets on Enjin Canary, which already runs the new runtime.
• The rule_set_id argument of fuelTanks.dispatch is now optional.

Infrastructure and SDK

• Polkadot SDK stable2606 on both the runtime and the client. Block length for mandatory and operational extrinsics rises to 10 MiB (user extrinsics keep 3.75 MiB) so a large parachain code upgrade fits in one inherent. The unused Coretime assignment provider pallet is removed.
• XCM. Reserve transfers are filtered (reserveTransferAssets, limitedReserveTransferAssets and reserve variants of transferAssetsUsingTypeAndThen now fail with Filtered). Teleport is unaffected and remains the way ENJ moves between the two chains. Governance can send XCM to the Matrixchain again (the delivery fee is waived for Root). xcmPallet fees change after re-benchmarking.
• XCM dry-run and fee APIs let wallets simulate a cross-chain call and quote its cost before sending.
• Deposits. Preimage storage now costs 1 ENJ base plus 0.001 ENJ per byte (from 0.000025 ENJ per byte), and on-chain attributes 0.001 ENJ per byte.
• Storage housekeeping. Multisig, disputes and crowdloan storage versions are brought up to their in-code versions.
• Metadata published with each release (V15 SCALE and JSON) together with the RFC-78 metadata hash, so integrators can regenerate types before enactment.

Matrixchain

Community governance (OpenGov)

The Matrixchain adopts the same OpenGov framework the Relaychain adopted with Kallang. Referenda, Conviction Voting, Origins, Whitelist and the Enjin Fellowship replace the Democracy, Council and Technical Committee pallets.

• Anyone can propose. Any account can submit a referendum on one of fifteen tracks, each with its own deposit, approval curve and enactment period.
• Conviction voting. Holders vote with ENJ and can multiply their vote weight by locking for longer, with a seven-day vote lock.
• Fellowship whitelisting. Members of the Enjin Fellowship can whitelist time-sensitive proposals for fast-tracking, mirroring the Relaychain.
• Clean transition. Pending Democracy proposals are cancelled, their deposits refunded, and existing Democracy vote locks released at the upgrade.

Deposits and thresholds match the tuned Relaychain values: 1,000 ENJ to submit a referendum, 2,500,000 ENJ decision deposit on Root and Fellowship Admin, 1,000,000 ENJ on the other admin tracks, treasury tracks from 2,500 to 250,000 ENJ, and the same support floors. Support is measured against total issuance. All deposits are refundable as on the Relaychain. Preimage storage costs 0.001 ENJ per byte.

Marketplace listings and offers

Marketplace listings and offers are upgraded to be more streamlined and efficient. A seller can list a token and, when an existing offer already meets the asking price, complete the sale in the same transaction.

• Existing listings, offers and bids are carried over as they are. Auctions keep their high bid; partly sold listings keep their sold amount.
• Counter-offers work through listings and offers. A seller answers an offer by listing the token at their own price, and a buyer answers a listing with an offer at theirs. The separate counter-offer calls are removed, and open counter-offers are refunded at the upgrade (see Downtime).
• Expired listings and ended auctions are settled on-chain every block, replacing the offchain worker introduced in Sentosa. Settlement no longer depends on a collator running the worker.
• Royalties below the existential deposit go to the treasury instead of failing the sale.
• Offers can be partly accepted, and listings that can no longer be completed can be cancelled by anyone. A listing is also cancelled automatically when someone tries to buy it or bid on it and its token has been lent, has expired, has been burned or can no longer be listed. An auction with bids is only cancelled if its token has expired or no longer exists, so a bid stays binding on the seller.
• Auction bids in ENJ are held in escrow from the moment they are placed. Bids placed before the upgrade stay on hold and settle as before.
• Bids cost more to place. placeBid fees rise because each bid now moves funds into escrow.

Token lending

Owners can lend a non-fungible token to another account for a fixed term. The borrower holds and can use the token until the loan expires, at which point the chain returns it automatically. The borrower cannot list, burn or transfer the token elsewhere, and the lender cannot recall it early but can extend the term. The lender covers the borrower's token account deposit. Whoever mints a token decides whether it can be lent. Tokens that exist before the upgrade start out non-lendable, and their collection owner can enable lending with mutateToken. It is built for rentals, trials and in-game loans, not as a financial product: there is no collateral and no interest.

Ephemeral tokens

A non-fungible token can be minted with an expiry block up to one year ahead. When that block is reached the token becomes non-transferable and is destroyed automatically, releasing its deposits and any marketplace hold. Ephemeral tokens suit event passes, time-limited access, seasonal badges and rentals where the item should simply disappear when it is done. When an ephemeral token expires, any marketplace listing of it is cancelled.

Multi-token improvements

• Mint rate limits: collection owners can cap how many units may be minted per period, at collection or token level. Tightening a limit applies immediately; loosening or removing one takes effect after a 72-hour delay and can be cancelled, giving the owner and the community time to react if a minting key is compromised.
• Attribute freezing: individual collection, token and token group attributes can be frozen permanently. Once frozen, an attribute can never be changed or removed.
• Attribute deposits change from 0.000025 ENJ to 0.001 ENJ per byte. Deposits remain refundable when attributes are removed.
• Collection transfers move the whole deposit. Accepting or claiming a collection moves all of the collection's held deposit to the new owner, or fails and changes nothing.
• Deposit records. One-off migrations bring token, collection and attribute deposit records in line with the amounts actually held. Most changes are to records only. A small number of collection owners see their held deposit adjusted, and each change emits a TokenUpdated or CollectionUpdated event.

Fuel tanks

The fuel tank changes listed under Relaychain apply to the Matrixchain as well: the creation deposit stays with the creator, failed sponsored calls are included rather than dropped, and rules are enforced more strictly. Rule sets that referred to the retired custom utility pallet are repointed automatically, except permitted-call rules, which tank owners need to reset.

Infrastructure and SDK

• Polkadot SDK stable2606, matching the Relaychain.
• Proof-size reclaim: the Matrixchain measures the proof size each transaction actually uses and returns the unused budget to the block. This is the change that requires the client upgrade.
• XCM: the dry-run and fee APIs are added, so wallets can simulate a cross-chain call and quote its cost before sending.
• Standard utility pallet: the Matrixchain's custom batch pallet is removed in favour of the standard Utility pallet, already present. Use utility.batch and utility.forceBatch.
• Metadata available in advance: Enjin Canary runs the new runtime, so integrators can regenerate types against the Canary Matrixchain before Mainnet enactment.

Housekeeping

• Removed the Hyperbridge pallets from Canary. They were never enabled on Mainnet.
• Removed the completed state-trie migration pallet and the obsolete MultiTokens.UpgradeBlockNumber storage item.
• Runtime weights regenerated on reference hardware for the Matrixchain, so fees change (see Wallets, SDKs and integrators).

Security

Both runtimes include security improvements and various bug fixes. The full list will be added to this entry once both upgrades are live on Mainnet.

Notices

Node operators

• Matrixchain nodes still on v1.3.x stop following the chain at the upgrade. The new client works on the current runtime, so you can upgrade now. [VERIFY with Jay: collator test, Matrixchain 1031 under Relaychain 1080]
• Relaychain validators on v1.7.0 cannot generate usable session keys under the new runtime. Other v1.7.0 nodes keep following the chain but do not serve the stake-exchange RPC methods.
• Validators and collators: add an ofcw key. Insert an sr25519 key with author_insertKey under key type ofcw and register it with session.setKeys. Without it, the node still produces blocks but does not sign for the pool payout worker (Relaychain) or the fuel tank worker (Matrixchain).
• Validators and collators: rotate keys with author_rotateKeysWithOwner from now on, not author_rotateKeys. Existing keys keep working.
• Validators: dispute slashing applies from November 9. A correctly operating validator is unaffected.

Guides: Upgrading a Relaychain node and Upgrading a Matrixchain node. Docker images: enjin/relaychain:v1.8.0 and enjin/matrixchain:v1.4.1. Building from source needs Rust 1.93 and the wasm32v1-none target. [CONFIRM with Brad: link to the public source repository.]

Nominators and pool members

No action. Pool payouts continue automatically, now per exposure page.

Wallets, SDKs and integrators

Both chains change their transaction version (Relaychain 18 to 19, Matrixchain 12 to 14), and transactions signed with the old version are rejected after enactment. Clients that read the runtime version and metadata from the node each time they sign, such as Polkadot-JS, pick this up automatically, as they do for every runtime upgrade. Offline signers and SDKs that hard-code versions or ship generated types must update before enactment. Several calls also change shape without changing index, so regenerate types from the new metadata.

• Relaychain: nominationPools.payoutRewards gains a page argument; fuelTanks.dispatch takes an optional rule set and dispatchAndTouch is removed; marketplace fillListing and finalizeAuction drop royalty_beneficiary_count; multiTokens.setAttribute gains frozen. The signed-extension set and order are unchanged.
• Matrixchain: multiTokens.mint, setAttribute, freeze, thaw and collatorStaking.joinCandidates change; minting an ephemeral token more than a year ahead fails with EphemeralExpirationTooFar; matrixUtility.batch becomes utility.batch. A StorageWeightReclaim signed extension is added. It adds no bytes, so transactions encode exactly as before, but Polkadot-JS logs a benign "Unknown signed extensions StorageWeightReclaim" warning until types are regenerated.
• Fees change on both chains: re-quote with payment_queryInfo rather than reusing cached figures.

Exchanges and custodians

Both upgrades change the runtime spec version and transaction version. After each upgrade, transactions signed with the old versions are rejected, including transactions signed in advance and transactions still in the pool at the upgrade. Fees change on both chains: use payment_queryInfo instead of fixed fee values. User balances, deposit addresses and the address format are not affected.

Relaychain, Monday, November 9, 2026

• Upgrade at block #18,059,100, approx. 16:00 UTC. The block number is authoritative.
• Spec version 1070 to 1080, transaction version 18 to 19. The encoding of a balance transfer and the signed extensions (set and order) are unchanged.
• For a few blocks after the upgrade block, the chain includes no user transactions while storage migrates. Block production continues.
• Pause ENJ deposits and withdrawals from block #18,059,000 (approx. 15:50 UTC). Resume after block #18,059,200 (approx. 16:10 UTC), once your node reports spec version 1080 (state_getRuntimeVersion) at a finalized block and a test withdrawal signed with transaction version 19 has been finalized.
• If you use the metadata hash check (CheckMetadataHash), recompute the hash from the new metadata.
• Node client v1.8.0 is recommended. A v1.7.0 node keeps following the chain.

Matrixchain, Monday, November 16, 2026 (if you run Matrixchain nodes or support the Matrixchain)

• Upgrade at approx. block #12,331,000, approx. 16:00 UTC. The exact block is set when the authorized upgrade is applied.
• Spec version 1031 to 1041, transaction version 12 to 14. The StorageWeightReclaim signed extension is added. It adds no bytes, so the transaction encoding and signing payload are unchanged, but tools that compare the extension list against metadata need the new metadata. The encoding of a balance transfer is unchanged.
• Node client v1.4.0 or later is required before the upgrade. Nodes on v1.3.x stop following the chain, and deposits are not detected. v1.4.1 is recommended and runs on the current runtime.
• Pause deposits and withdrawals from 15:30 UTC. Resume once your node reports spec version 1041 at a finalized block and a test transaction signed with transaction version 14 has been finalized.

Before each upgrade

1. If your signing setup hard-codes the spec or transaction version, or bundles metadata (for example an offline or air-gapped signer), prepare an update to the new versions and metadata. Libraries that read both from the node at signing time, such as Polkadot-JS, need no change.
2. Test on Enjin Canary, which already runs both new runtimes: https://rpc.relay.canary.enjin.io (Relaychain, spec 1080, transaction version 19) and https://rpc.matrix.canary.enjin.io (Matrixchain, spec 1041, transaction version 14).
3. For withdrawals in flight at the upgrade, check on chain whether each one was included before you re-sign it, so that nothing is sent twice. Re-sign rejected ones with the new versions and resubmit them.

Enjin Platform developers

No action needed. The new features can be tested on Enjin Canary now.

Enjin Wallet and NFT.io users

The Matrixchain marketplace will be unavailable for up to 30 minutes from the Matrixchain enactment block on November 16. Transfers, minting and all other features continue to work. Settle any open counter-offers before the Matrixchain upgrade. Update to the latest Enjin Wallet version for full support of the new features.

Downtime

Both chains keep producing blocks throughout.

• Relaychain, November 9: user transactions pause for a few blocks while storage migrates. The Relaychain marketplace (sENJ and Degens) is not paused.
• Matrixchain, November 16: user transactions pause for a few blocks. The marketplace then stays paused for up to 30 minutes while listings migrate, and marketplace calls fail with CallFiltered until it reopens. Listings, offers and bids carry over. Everything else works normally.
• Counter-offers: open counter-offers are removed at the Matrixchain upgrade and refunded in full. Settle any you want honoured before November 16.

Governance

Relaychain. Referendum submitted October 12. If it passes, the upgrade is enacted automatically at block #18,059,100. Proposal: GP-2026-10-12-01.

Matrixchain. Referendum from November 10 to 13. If it passes, the upgrade is applied on November 16. From then on, Matrixchain upgrades go through OpenGov. Proposal: GP-2026-11-10-01.

Both proposals list the exact calls, preimage hashes and runtime code hashes so anyone can check the on-chain referenda against them. Vote on the Relaychain referendum at gov.enjin.cloud.

Versioning

• Relaychain runtime: v1.8.0 (spec 1080, transaction version 19). Client: v1.8.0 (v1.7.0 follows the chain but cannot rotate keys).
• Matrixchain runtime: v1.4.1 (spec 1041, transaction version 14). Client: v1.4.1 (v1.4.0 minimum; collators must run v1.4.1).

Links

• Fort Canning announcement
• Relaychain governance proposal GP-2026-10-12-01
• Matrixchain governance proposal GP-2026-11-10-01
• Upgrading a Relaychain node and Upgrading a Matrixchain node