Users can release Impenetrable Vault transactions that are stuck on the blockchain without needing Galaxy Customer support intervention or the transaction releaser tool. This helps reduce delays and operational overhead when a pending transaction is not mined and blocks subsequent transactions from the same nonce sequence.

The Replace by Fee flow is available for EVM based chains only. It supports native transfers, ERC-20 tokens, and smart contract interactions for transfers and contract calls. Both EIP-1559 and legacy gas models are supported.

On the Impenetrable Vault Transactions page, users select the new Release stuck transactions button. The system checks and lists any stuck transactions for the account and asset, and then calculates suggested replacement fees to free the transactions. The user selects the transactions to free up, edits the suggested fee, and sends the replacement transactions to the blockchain.

If a lower transaction has sufficient fees but is held up by another transaction, the Sufficient Fees sign appears at the end of the transaction row. The Sufficient Fees sign indicates that the fees set for the transaction are sufficient once the blocked transaction is processed on the blockchain.      

The flow includes built-in safeguards to prevent invalid or unsafe fee values. Replacement transactions must remain within the configured maximum fee cap, and comply with Coin Management and Policy Engine rules.

The Impenetrable Vault transaction process is upgraded to display an appropriate warning message listing potential issues the user might encounter when starting a transaction. The message lists any policy or settings issues that prevent the user from completing a transaction. Once the issues are resolved the message does not appear. 

For each type of transaction - staking, transaction, tokenization (smart contracts) or Proxy Vault - a specific list of prevention issues tells the user what changes must be made to allow the transaction to succeed. These issues range from lack of balance for the currency to unauthorized policy issues. 

While the user can still continue with the transaction, they will not be able to complete the process.

A new Backup and Restore feature in the Preferences page enhances the present backup system for the Active Backup Vault. 

When a user ends a session that includes changes to the system settings, an updated version of the system settings and preferences is created and sent to the Active Backup Vault. 

Once the latest file is successfully received and verified on the Active Backup the previous file is deleted.

To clarify and improve logging during the Impenetrable Vault or uMPC upgrade, the Audit entry now specifies the machine, action and an action description. Each log lists a start and completion status, either successful or unsuccessful, ie. Upgrade Started → Upgrade Success / Upgrade Failed.

These new logs allow the administrator to follow the upgrade process and identify which point has led to a failure during the upgrade process.  

The Admin can now create new Admin users and Policies on the connected Backup Vault. However, these management settings are overwritten in the event that the Backup Vault is restored using the file sent from the Primary Vault. 

Before this restore occurs the user receives a warning that these local settings will be lost during the restore process.

This feature allows an organisation to maintain access and control of the Backup Vault after an administrator listed in the Primary Vault is unable to perform actions in the event they are no longer a part of the organisation or are incapacitated. Instead, other administrators are able to perform important backup or vault restore actions.

As changing the status of a connected Backup Vault, to the Primary or disconnected Backup, erases any Restore setting files, the Backup Vault checks the Primary Vault for a more up to date restore file than the one it is presently running. 

If the Backup Vault has more up to date settings than the Primary Vault, the Backup Vault asks the Admin to install this file before changing the Vault status. This ensures that newer settings are not lost during this process.

In the User Roles, set up the new Functional Permission Allow proving ownership signing gives permission to the user to create a proof of Address ownership QR code. The QR code contains a signed JSON script including information for a specific account, coin and deposit address. The script is signed with the owner’s private key to provide the proof of ownership. 

This QR code is sent with a Galaxy Infrastructure provided Python code to any third party organisation, like an auditor. The Python code, which can be run on any computer, reads the QR code and verifies the signature included in the QR code is correct for the relevant Address.

The Impenetrable Vault now supports Smart contracts function calls that only returns data and do not perform transactions on the blockchain. The data is returned in the format returned by the smart contract and not as a binary. 

The Impenetrable Vault Notepad feature can now produce a QR version of any information written or copied into it. The feature is disabled when the information becomes too large to be included in a QR code. 

The Typer Helper availability is now available to assist entering EVM, ERC20 and TRC20 contract details. This improves the speed and accuracy of entering the contract details that the Typer is designed to assist with.  

Tempo is an EVM-like network that supports tokens and contracts but does not have a native gas token. The system now supports such EVMs using the new deviation type “Phantom Balance”.

A new table format displays Smart Contract addresses in the UI, matching the Load Contract format, making contract information easier to view and access.

This version also includes the following new preloaded contract functions:



When creating a transaction policy, you can now open a pop-up from the User Group list to view the users associated with each group. This makes it easier to select a User Group or combine a User Group with individual users.

The Canton coin features on Galaxy’s Custody Infrastructure are expanded on the Impenetrable Vault, Desktop app and SDK / API.  

The API and Desktop app allow the creation of Send and Receive Canton coins and token (CIP-56) transactions. Transactions appear in the Transaction page once sent to the network.

On the Impenetrable Vault, the Canton network is listed in the Coin Management page in the new Canton tab. The Impenetrable Vault can create Canton Topology transactions to create a namespace, delegate or undelegate request. The Topology transaction process also allows the user to choose the PartyToParticipant and VettedPackages specifications.   

Canton native coin transactions are also available that include saving a contact with a Canton coin address.

The Impenetrable Vault and Desktop app require two new transaction policies to be set:

If only making topology transactions, only the topology policy is needed.

Canton Topology is also added to the API.

For more information on the Canton network, 

https://docs.canton.network/overview/understand/what-is-canton

The disaster recovery solution provides backup and recovery capabilities for both the Impenetrable Vault and MPC environments. 

For the Impenetrable Vault a backup version of all actions and settings the Vault has performed, is saved to a CD Rom. This serves as a second form of backup for the Vault and can be used to restore the Vault if the original Vault becomes unavailable.

The CD can be transferred to another Impenetrable Vault and used to restore the second Vault.   

For MPC environments, disaster recovery uses multi-region cloud replication. Multiple region backup allows the MCS to be restored to a secondary region if the primary region becomes unavailable. 

Disaster recovery is not a zero-downtime process. Depending on the incident, the recovery process can cover a full site loss, a temporary outage (that could last hours or days), an MPC-only failure, or an Impenetrable Vault-only failure. 

Activating the disaster recovery environment requires operational recovery steps, which can include activating the secondary infrastructure, updating DNS, physically accessing the Impenetrable Vault, and restoring its backup.

The MCS can be restored to a new location with the support of our DevOps teams. 

To simplify the contact management process, a user now adds multiple coins or tokens with one name and address. This means that one address can be assigned to several different coins (EVMs, ERC-20s, TRC-20s and CC Canton tokens). For example, when adding a new contact on the ETH blockchain, the admin is offered the option to add any of the existing EVM’s or ERC20’s to this contact instead of creating a new contact for each of these coins.

The list of available coins or tokens that can be added to the new contact is limited to those within the same related currencies, i.e. for an ETH contact only Ethereum based coins and tokens can be chosen but TRC20s are not available. 

The Desktop app then provides the user the options to

In the Impenetrable vault the policy maintenance is performed manually, without any system prompts. 

This new feature is available across platforms on the Impenetrable Vault, Desktop and Mobile apps.

When the system is upgraded to this version the feature automatically reviews the contact list and combines all contacts with the same address. 

On the first login after the system upgrade, the system displays a list of migration results, showing which contacts are merged, and any conflicts that occurred during the process. An example of a conflict would be a contact listed in different Address groups with different policy settings that produce conflicts when combined. 

These conflicts must be resolved after the upgrade, before continuing with the system so that the user does not continue with unresolved conflicts. 

To improve client experience and usability all of the Transaction Policy types are separated so that the user can easily assign the appropriate type.

The changes are as follows: 

This feature is backward compatible for existing ‘Transfer’ policies that are automatically updated to the new ‘General Transfer’ type without causing any conflicts. The Staking and  Raw signing policies remain unchanged.

However, the old sub types, Deploy, Signature and Tokenization, which now become main types cause a breaking change in the SDK and must be updated.

In addition, the Any option is now available in the ‘From’ option as well as the ‘To’, and  applies only to the list of names on the page being displayed, and does not include names on other pages.

Smart contracts can be uploaded to the Custody Infrastructure Desktop app using a new interface for managing Smart Contracts. The details of a new Smart Contract, such as the name, description, and function names are defined in the contract’s machine readable definition file, for example ABI (for EVM) or IDL (for Solana) .  

This allows new contracts to be added or to update an existing contract with the latest version when their interfaces change. 

When uploading a new contract, the system presents a read-only preview of the contract’s functions and their inputs for the user’s approval. Functions that cannot be parsed are identified separately. 

When updating a contract, a new version of the definition file is used to replace the existing contract.

Once updated, the system produces two lists: 1. New or changed functions 

2. Functions removed by this new version.

Creating, updating, or removing a definition is completed through an administrative approval session. 

The feature initially supports Solana Anchor IDL, Ethereum Solidity ABI, and Stellar Soroban specification files. 

The Vault Sync screen shows the differences between the actual asset values for coins on the blockchain against the values registered in the Impenetrable Vault. The dashboard helps users identify cases where the balance differences and price deviations between the Vault data does not match the current blockchain state. 

Over time the registered amount and price of a coin in the IV becomes out of sync with the real amount and price for the coin on the blockchain. The discrepancy can occur in one of two ways: 

1. by receiving a transaction that is not registered on the IV using the Sync button, 

2. the coin network price changes over time and drifts from the price quoted in the IV, which can affect role and policy limits.

The dashboard marks each currency in the IV as Synced or Not Synced with the blockchain balance, shows the percentage deviation between the coin’s Vault Price and Network Price, and alerts users when the Network Price falls below the minimum price configured in the Vault. 

The Desktop app lists the unsynched transactions that are not registered on the IV. These transactions can then be added to the IV, as well as updating the coin price with the accurate market price.



After an approver cancels a transaction the user name is listed in the transaction history to improve transparency and internal follow up and auditing.

The MPC SDK/ API includes new endpoints to allow the deployment of a new smart contract for the Tron chain. Until now TRON deployment was performed only on an EVM network, now it is also possible to deploy on the TRON network. 

Capabilities include:

The Dry Run feature is now a default for ETH and EVM coins. Therefore, if your EVM node doesn’t support the dry run feature the deploy function dry-run argument must be set to false.



The GalaxyCustody mobile app now supports the Canton network coin, allowing the user to send, receive, accept and approve transactions. A transaction can also be withdrawn using the app. 

All of the Canton transactions appear in the History tab of the Activities screen.

The Transaction details screen displays both the simulation data and the risk assessment in the new Risk & balance impact tab.

The Associate multiple coins or tokens to the same contact feature is also available on the GalaxyCustody mobile app. This allows a user to add a new contact and associate the contact with multiple coins or view the contact.

Improvements are also made for the Contacts screen, with improvements to the scrolling speed and display of contacts. The Contacts screen is a Refresh button that can be used at any time to update the contacts information. A new Refresh indicator also appears above the Refresh button to show that new information was received about contacts above or below the section presently on display. 

Finally a new scroller icon appears as the user scrolls up or down indicating the new information being uploaded.