Skip to main content

Polymesh Chain Changelog - v8.0 to v8.1.3

This is the entry point for the Polymesh v8.0 → v8.1.3 runtime changelog. spec_version moves from 8_000_020 to 8_001_030, and transaction_version stays at 8.

The release is dominated by one theme: making Polymesh assets usable from EVM code without giving up compliance. v8.1 exposed fungible assets as ERC-20 tokens; v8.1.1 completes that surface with ERC-3643 and ERC-7943 coverage, adds an ERC-721 precompile for NFT collections, and adds a general-purpose runtime precompile for the calls that are not scoped to an asset. Supporting that work, the chain gains holder-level asset freezing, NFT approvals, and first-class support for ETH wallets in the Relayer and MultiSig pallets.

Baseline

The "v8.0" side of this comparison is chain v8.0.2 (spec_version 8_000_020), the last v8.0.x patch release. If you are still on v8.0.0 or v8.0.1, see the note on patch releases below.

v8.1.0, v8.1.1 and v8.1.2 were Testnet and Develop releases. Mainnet's first v8.1.x runtime is v8.1.3, so it upgrades from v8.0.x in a single step and this changelog is written as one v8.0.2 → v8.1.3 upgrade. If you operate against Testnet or Develop, read the delta for the release you already run instead — it is what you need, and the rest of this section will be familiar:

Who this is for​

  • Smart contract developers, EVM tooling and wallet integrators — three precompiles are now available. Start with Fungible Asset Precompile, NFT Precompile, and Polymesh Runtime Precompile, then the Precompiles reference for how to use them.
  • Asset issuers and their agents — Asset Freezing is new capability you can use immediately: freeze an individual holder, or part of a holder's balance, rather than the whole asset. NFT issuers should also read NFT Approvals.
  • Exchanges, custodians, indexers — this release changes the pallet API, unlike v8.1. New extrinsics, events, errors, constants and storage items exist, and three storage migrations run at the upgrade. See Full Pallet API Reference, and note the new Asset and Nft events your indexer will start seeing.
  • Wallet and SDK integrators — ETH Wallets covers EVM-keyed accounts as subsidy beneficiaries and MultiSig signers, and the restriction of transaction tipping to Governance Committee members.
  • Node and infrastructure operators — Other Runtime Changes for the storage migrations, the Grandpa warp-sync fix, and the refreshed weights.
  • Compliance and settlement integrators — v8.1.3 tightens validation of compliance requirements, settlement affirmations and same-identity direct transfers. See What changed in v8.1.3; every change there is also listed in the Full Pallet API Reference.
  • Anyone already running v8.1.2 or v8.1.1 on Testnet, Develop or a private network — What changed in v8.1.3 and What changed in v8.1.2 are the short lists of what each release corrects on top of the one before.

Key themes​

Precompiles​

v8.0 added pallet-revive, giving Polymesh a dual-VM contract engine. v8.1 and v8.1.1 use it to expose native chain functionality to contracts through three precompiles:

PrecompileAddressInterfaceCovers
Fungible Asset0x<assetId>00080000ERC-20, partial ERC-3643 and ERC-7943Every fungible asset
Non-Fungible Asset0x<assetId>00090000ERC-721, ERC-721Metadata, ERC-165, partial ERC-7943Every NFT collection
Polymesh Runtime0x…0000ffff0000IPolymeshRuntimeAsset creation, ticker registration, DID onboarding, agent authorization

Every asset and every collection is exposed automatically — there is no deployment step, no registry, and no issuer opt-in. Calls route through the same pallet code an extrinsic would, so identity, compliance, transfer restrictions and agent permissions are enforced exactly as before. A call that would break a Polymesh rule reverts rather than silently succeeding.

The practical consequence for a contract developer is that a Polymesh asset behaves like a standard token until a rule says otherwise. Both asset precompiles deviate from their standards in ways mainstream tooling does not expect, and each precompile page documents those deviations in full. Read them before porting an existing integration.

ERC-3643 and ERC-7943 methods​

The fungible-asset precompile gains much of the permissioned-token surface that ERC-3643 (T-REX) and ERC-7943 (uRWA) define: pause/unpause, setName/setSymbol, isAgent, setAddressFrozen, freezePartialTokens/unfreezePartialTokens, setFrozenTokens/getFrozenTokens, and canSend/canReceive. This lets tooling written for regulated-asset standards work against Polymesh assets with less Polymesh-specific code. Neither standard is implemented in full — the fungible-asset reference records what is implemented and where it deviates.

forcedTransfer now delivers to a named recipient rather than to the caller, on both the fungible and NFT precompiles. See Fungible Asset Precompile.

Holder-level asset freezing​

Before this release, freezing was all-or-nothing: an agent could freeze an entire asset, stopping every transfer. v8.1.1 adds freezing scoped to a single holder — either an account key or a portfolio — and to part of a holder's balance.

This is the Substrate-side feature with the widest reach: it adds five extrinsics to pallet-asset, new storage in pallet-asset and pallet-portfolio, new transfer-time errors, and new events. Anything that pre-checks whether a transfer will succeed needs to account for it. See Asset Freezing.

NFT approvals​

NFTs gain the approval model fungible assets already had: a per-token spender (Nft::approve) and a collection-wide operator (Nft::set_approval_for_all), which together back ERC-721's approve/setApprovalForAll. Settlement::transfer_funds now accepts non-fungible funds in spender mode, consuming an approval. See NFT Approvals.

EVM key support​

An EVM-keyed account can now be subsidised by the Relayer pallet — including the storage deposit pre-charged for an EVM transaction — and can act as a MultiSig signer. ETH wallets accepting authorizations do not pay the transaction fee, matching Substrate keys. Separately, transaction tipping is now restricted to Governance Committee members. See ETH Wallets.

Correctness fixes in v8.1.2​

v8.1.2 adds no new capability. It closes gaps in the features above and tightens three permission checks:

  • Freeze enforcement now reaches the pre-flight reports. In v8.1.1 a transfer report could come back clean for a transfer the chain would then reject because the sender was frozen. Both the fungible and NFT reports now evaluate the holder freeze and the frozen balance, so the report and the transfer agree.
  • Freezing now covers every route out of a portfolio. Portfolio-to-portfolio moves check the frozen balance, not just a whole-portfolio freeze; launching an STO and funding a capital distribution now check the freeze too; and an NFT held in a frozen portfolio can no longer be locked into an instruction.
  • Sto::invest no longer assumes its settlement completed. When the offering asset — or the raising asset, for an investment funded on chain — had mandatory mediators, invest debited the fundraiser's tiers even though the instruction was still pending affirmation.
  • Three permission checks tightened: secondary keys need portfolio permission to quit custody, MultiSig::create_multisig validates the permissions it is given, and Except extrinsic permissions are now refused wherever they are still accepted.

See What changed in v8.1.2 for the detail.

Validation and weight fixes in v8.1.3​

v8.1.3 is also mostly fixes. It adds two events and otherwise tightens validation and weighing:

  • NFT controller transfers emit dedicated events. Nft::ControllerTransfer and Nft::ControllerTransferTo follow NFTHoldingsUpdated, so an indexer can tell the two calls apart even when they are reached through the NFT precompile, a batch or a MultiSig.
  • Compliance requirements are validated more strictly. IsAnyOf and IsNoneOf conditions must name at least one claim, and trusted issuers are capped at 8 per list, with at most 16 claim types each.
  • Settlement closes three gaps. An affirmation must name a holder or carry a receipt. Executing an instruction cancels any execution still queued for it. A same-identity transfer_funds checks that the destination portfolio exists and that a secondary key may use it.
  • Freezing requires a holder that exists, tokenURI reverts for an NFT that does not exist, issue_nft enforces the metadata value length limit, and nested relay_tx calls are refused.
  • Weights. MultiSig::approve includes the cost of decoding the proposal, PIP voting reads the proposer from new dedicated storage instead of decoding the whole proposal, and the precompile pre-check methods are weighed accurately.

See What changed in v8.1.3 for the detail.

Migration checklist​

Unlike v8.1, this release changes the pallet API. Work through the list below:

  1. Re-generate metadata-derived code. New extrinsics, events, errors, constants and storage items exist across pallet-asset, pallet-compliance-manager, pallet-nft, pallet-pips, pallet-portfolio, pallet-relayer, pallet-settlement and pallet-sto. transaction_version is unchanged at 8, so existing signing code is unaffected, but decoding and type generation should be refreshed against v8.1.3 metadata. See Full Pallet API Reference.
  2. Update transfer pre-checks for holder freezing. A transfer can now fail because the sender or their portfolio is frozen for that asset, or because the amount exceeds their unfrozen balance — with errors that did not exist in v8.0. The pre-flight reports account for both as of v8.1.2, so a clean report is again a reliable signal. See Asset Freezing.
  3. Handle the new events if you index chain state: Asset::FrozenBalanceSet, Asset::SetAccountFreeze, Asset::ControllerTransferTo, Nft::NFTApproval, Nft::NFTApprovalForAll, Nft::NFTApprovalSpent, Nft::ControllerTransfer, Nft::ControllerTransferTo.
  4. Settlement::AllowancesNotSupportedForNFTs is renamed, not removed — it is now DeprecatedAllowancesNotSupportedForNFTs and keeps its index, so decoders keyed on the index still resolve. NFT spender transfers now fail with Nft::InsufficientNFTApproval instead. Update any error-name matching.
  5. Three storage migrations run at the upgrade: two backfill NFT counts, and one copies each PIP's proposer into new storage. No action is required, but node operators should expect the upgrade block to do proportionally more work on chains with many NFTs or PIPs. See Other Runtime Changes.
  6. If you use NFTApi, note it is now at version 4 with two added methods. Version 3 clients continue to work.
  7. If your secondary keys call into the EVM, permission checks now evaluate the extrinsic actually being dispatched rather than the pallet-revive call carrying it. A secondary key that could previously make a precompile call may now need permission for the underlying extrinsic. See Other Runtime Changes.
  8. If you submit tips, only Governance Committee members can now do so. DID Registrars have lost that ability. See ETH Wallets.
  9. If you build EVM contracts or tooling, read the precompile pages and the Precompiles reference before writing code.
  10. If you create external agent groups or secondary keys programmatically, stop emitting Except extrinsic permissions. They are refused at both the pallet and the extrinsic level — build the equivalent These set instead. See What changed in v8.1.2.
  11. If you run an STO, handle the new Sto::InstructionNotSettled error. An offering asset with mandatory mediators makes every Sto::invest fail with it, and a raising asset with mandatory mediators does the same for every investment funded on chain, because the investment instruction cannot settle within the call. See What changed in v8.1.2.
  12. Re-estimate fees. Weights were re-benchmarked across pallet-asset, pallet-compliance-manager, pallet-multisig, pallet-nft, pallet-pips, pallet-portfolio, pallet-relayer, pallet-settlement and pallet-sto. Nft::redeem_nft, MultiSig::create_multisig and MultiSig::approve also changed how their weight is derived, as did canTransfer, canSend and canReceive on both asset precompiles. See Other Runtime Changes.
  13. If you build compliance rules programmatically, do not send an empty IsAnyOf or IsNoneOf condition, and keep to 8 trusted issuers per list and 16 claim types per issuer. See What changed in v8.1.3.
  14. If you affirm settlement instructions, handle Settlement::EmptyAffirmation. add_and_affirm_instruction with no holders now fails, so use add_instruction instead. See What changed in v8.1.3.
  15. If you use transfer_funds between portfolios of one identity, the destination portfolio must exist, and a secondary key needs permission for it. See What changed in v8.1.3.
  16. If you relay transactions, relay_tx cannot be nested by any route, including batches and MultiSig proposals. See What changed in v8.1.3.

A note on the v8.0.x patch releases​

The v7.4 → v8.0 changelog documents the v8 runtime as deployed, which is spec_version 8_000_010 (v8.0.1) and later — not the initial v8.0.0 tag. Two patch releases followed v8.0.0:

  • v8.0.1 (8_000_010) — removed the legacy Contracts/PolymeshContracts (Wasm/ink!) pallets, moved to Substrate stable2603-4, plus runtime fixes (secondary-key permission check in transfer_funds, blocking transfers of frozen assets, a same-DID check in unverified_transfer_asset, an automatic-payout fix) and corrected benchmark weights. All of this is already reflected in the v7.4 → v8.0 changelog.
  • v8.0.2 (8_000_020) — CI and Docker packaging changes only; no runtime logic change.

This changelog picks up from v8.0.2.