Enhanced Solana integration now includes full SPL token support, enabling comprehensive token management and DeFi operations across the Solana ecosystem while maintaining consistent security and policy controls.
Omnibus Wallet Architecture
Implemented omnibus (pooled wallet) functionality that enables shared wallet addresses across multiple accounts with granular individual balance tracking. This architecture optimizes blockchain resource utilization through consolidated address management while maintaining complete transaction isolation and sub-address accountability for each account holder.
Multi-Tenancy Infrastructure
Deployed comprehensive multi-tenancy capabilities across the entire platform stack, including websockets, event streaming, push notifications, and approval service. This enterprise-grade architecture enables secure isolation of multiple organizations within a single deployment, reducing operational overhead while maintaining strict data segregation and tenant-specific policy enforcement.
Added native support for Canton Network and Base chain, expanding the wallet's blockchain compatibility to include enterprise-grade distributed ledger technology and Coinbase's Layer 2 solution.
Bring Your Own Identity Provider (BYOIDP)
Standardized authentication framework based on OpenID Connect (OIDC) protocol, enabling customers to integrate their existing enterprise Identity Providers for user authentication to the Institutional Vault UI. This implementation supports major providers including Microsoft Azure Entra ID, Okta, and any OIDC-compliant identity platform, allowing organizations to maintain centralized user management, enforce existing security policies, and leverage established authentication workflows without requiring migration to a proprietary identity system.
API v2 Enhancements
Extended the v2 API to support direct smart contract deployment through the Transfer API, streamlining complex contract interaction workflows. Added explicit transaction nonce and gas parameter controls to enable Replace-By-Fee (RBF) scenarios, providing institutions with precise control over transaction prioritization and fee optimization strategies during network congestion.
ClientSDK Code Generation
Introduced OpenAPI specification-based code generation for client SDKs across TypeScript, Java, Go, Python, and C#. This standardized approach ensures type-safe API integration, reduces integration complexity, and accelerates development cycles by providing native library support for all major enterprise programming languages.
MPA Horizontal Scalability
Implemented horizontal scaling capabilities for Multi-Party Authorization (MPA) nodes. This distributed architecture enhances system throughput, provides fault tolerance through node redundancy, and ensures consistent performance under high-load conditions for mission-critical operations.
AWS RDS IAM Authentication
Enhanced database security through AWS RDS IAM authentication with automatic token rotation, eliminating static credential storage and reducing credential compromise risks. This implementation maintains backward compatibility with existing deployments while providing a seamless migration path to identity-based access control for database connections.
Node Configuration:
- Added support for running MPC operations in a secure enclave. This is configured via the [Enclave] section.
- DKLS23 now supports NONE as the DeactivatedPlayersCache in addition to MEMORY and DATABASE.
Patch changes (no effect on compatibility):
- Made it possible to control for how long dynamic API keys are cached. Also changed the default from 10 to 30 seconds
- Make fewer calls to the database encryptor
Details
Secure Enclaves
We’ve added support for running MPC operations inside a secure enclave, providing stronger isolation and protection of key material.
Enclaves can be configured via the [Enclave] section by specifying the address and port of the enclave server. When enabled:
All MPC operations and key material usage are handled within the enclave, separate from the rest of the TSM.
The enclave encrypts sensitive data, ensuring that the TSM never has access to key material in clear text.
Because the enclave server is stateless, there are scenarios where key material could be exposed (e.g., by reusing a presignature or exporting keys). To mitigate this, the enclave can be restricted to allow only specific operations.
As part of this, a new option NONE has been added to the DeactivatedPlayersCache setting under [DKLS23]. When enabled, it prevents the use of precomputed data for sining, to match the setting configured within the enclave.
Note: The enclave server is distributed separately and is not bundled with the TSM.
Deactivated players
In DKLS23, it is possible to reuse certain key material data when signing and generating presignatures. This significantly improves performance by reducing computation time and protocol rounds.
However, this optimization introduces a trade-off: if a player is detected cheating during the protocol, any precomputed data associated with that key material must be discarded and never reused.
When such an event occurs, the protocol automatically falls back to a slower but fully secure mode until the key material is reshared.
To manage this, the TSM tracks which players have been deactivated due to cheating. The way this information is stored and accessed is controlled by the DeactivatedPlayersCache setting under [DKLS23].
Available Modes for DeactivatedPlayersCache
MEMORY
The TSM keeps track of deactivated players in an in-memory data structure that is persisted to disk whenever updates occur.
Fastest method.
Reloaded into memory at startup.
Not suitable for load-balanced deployments.
DATABASE
The TSM stores deactivated player information directly in the database.
Compatible with load-balanced scenarios.
Slightly slower, as it requires a database lookup for each signing and presignature generation operation.
New in This Release
NONE
The TSM does not reuse any precomputed data to speed up operations. Instead, it generates fresh data for each operation.
Completely eliminates attacks related to precomputed data.
Comes with a significant performance overhead.
The NONE option should generally only be used, if one of the players are using an enclave that has disabled the use of precomputed data.
Client Communication:
- Added new endpoints for RSA in the PKCS#11 module
- Added new endpoints for AES unwrap in the PKCS#11 module
- Management API: Added 1 minute, 5 minute, and 15 minute averages for operations to metrics
- Added Swagger (openAPI) UI for Management API at /management/docs and download at /management/openapi.yaml
Node Configuration:
- Added RSAImportKey, RSADecrypt to PKCS11
- Disable management server authentication for specific roles by specifying an empty API key
Client API:
- Added support for creation (load) of RSA keys and encryption/decryption operations in the PKCS#11 module
- Added support for Unwrapping of AES encrypted AES keys in the PKCS#11 module
Patch changes (no effect on compatibility):
- More debug logging for MPC operations, connection establishment, database use and external encryptor plugin
Details
Management API Swagger/OpenAPI UI and Download
When the management server is enabled, it now includes Swagger UI documentation, and a URL for downloading the OpenAPI yaml definitions, found under:
/management/docs
/management/openapi.yaml
respectively.
Unauthenticated access to Management API
Specifying an empty API key under the management server API keys, grants unauthenticated access with the specified permissions. Previously you would need to enter a hash of the empty string to achieve the same result.
Debug information with duration
When running the TSM with a log level of DEBUG many operations are now logged together with a duration indicating how long time the operation took. If the operations fails, then no duration is logged.
Node Communication:
- Added a new MPC TCP communication method
Node Configuration:
- Added support for dynamic API keys via the management server
- Added PacketCommunication method to the MPC TCP server, as well as corresponding
configuration options to the [Players.X] sections
- Allow getting the client IP address from the IPAddressHeader field of the log configuration
- Moved Configuration of metrics to the management server configuration. Profiling is enabled
by adding '-tags profile' when building.
- Added Management Server configuration
Client API:
- Added support for AN10922, RFC5649 and AES-CMAC to SDKv2
Client Communication:
- Added management API endpoints for dynamic API keys
- Moved Metrics and Profiling endpoints to 'management/metrics' and
'management/profiling/debug/[fgprof|pprof]' respectively
- Added Management API endpoints
- Added endpoints for AN10922, RFC5649 and AES-CMAC to SDKv2
Patch changes (no effect on compatibility):
- Upgraded Android NDK in BD_IMAGE from r22 to r28c to build for 16kB page size
Details
SDKv2 support for AN10922, RFC5649, and CMAC
These operations were available on the legacy SDKv1, and are now also supported by SDKv2.
Compared to the "client api" of SDKv1, there are a few changes to import of AN10922 and RFC5649 keys:
Import now accepts a "desiredKeyID" like other key import methods in SDKv2.
Both methods require imported keys to be envelope wrapped
A threshold parameter is accepted (though both currently only work for three MPC nodes and threshold one)
Administrative endpoints have been moved to Management Server
The endpoints for retrieving TSM information, health status, and metrics have been moved to a common Management Server. This change also adds permissions-based access control, which must be configured in the TSM node configuration file.
After the change, the endpoints can be found here:
The [Authentication] section now includes a DynamicAPIKeys option, which enables the use of dynamic API keys. This option is disabled by default.
When DynamicAPIKeys is enabled, all API key management must be done through the Management Server API. This includes creating, deleting, and listing API keys.
Create API Key
POST /management/apikey
Required permission: APIKEY
Delete API Key
DELETE /management/apikey/{apiKeyID}
Required permission: APIKEY
List API Keys
GET /management/apikey
Required permission: APIKEY
To create a new API key, send the following JSON payload in the request body:
{
"applicationId": "myapplication1",
"description": "this is application 1"
}
Enabling dynamic API keys allows changes to be made at runtime without restarting the system. When deployed across multiple MPC nodes, changes (such as adding or removing keys) may take up to 10 seconds to propagate to all nodes.
Note that these endpoints allow management of API keys related to normal TSM operations, not the API keys used for accessing the Management Server API.
PacketCommunication feature added to the MPC TCP server
A new TCP communication method (enabled by setting PacketCommunication = true under the MPCTCPServer configuration) has been added.
It switches the TCP transport from a stream‑oriented model to a packet‑framed protocol identical to the existing message‑broker format.
The new protocol has the following benefits:
Slightly lower overhead when starting MPC sessions.
Gives fine‑grained control over who dials whom: instead of the fixed “lower index connects up” rule.
Unifies the communication format, which might in the future enable deployments that mix TCP and broker‑based transports.
It is worth noting that most existing deployments using the MPCTCPServer, cannot simply enable this feature without making changes to the [Players.X] sections. Notably, the following options have been added to the players configurations:
disableMultiplexing: When PacketCommunication = true, multiplexing can be toggled per player, allowing you to save resources for rarely used peers or when a load balancer would break sticky TCP sessions.
symmetricConnection: Lets you declare that both players know each other’s address. The actual dialler is then selected dynamically from the session ID, preventing duplicate cross‑connections.
As part of our compliance requirements, any API requests made to a sanctioned address will be automatically blocked. This screening applies to all write operations made through our APIs, including but not limited to:
Sending transactions
Staking actions
Smart contract interactions
🚧
Read-only requests that do not involve written actions to the blockchain will not be affected.
We recommend that you ensure your applications do not interact with any addresses included on any sanctions lists. If you have questions or need support, please contact us.
