Security, TSS Executions and Programmability

The CoreSDK, along with its APIs and intuitive CLI tools, provides a comprehensive developer interface to interact with Tria's infrastructure. This CoreSDK supports a range of client-side functionalities, including securing sessions via secure enclaves, encrypted data transportation, and transaction object and binary translation/creation. This section will explore the CoreSDK's isolated security, threshold signature scheme (TSS), network architecture, permissioning, programmability and overall security.

CoreSDK

CoreSDK establishes a distinct separation between dApp environments and user authentication layers to ensure integrity at each interaction point. The Authentication interface operates independently from the wallet interface and SDK integration, securing the authentication process from any unauthorized access or interference by the application's frontend. Post-authentication tokens are stored securely within the iFrame, tightly coupled to the session and cryptographically configured to prevent use beyond that context.

Tria's SDK leverages hardware-based Trusted Execution Environments (TEEs) and secure enclaves on supported devices to manage sessions securely. In these environments, rotating private key pairs and access tokens are isolated, ensuring that transaction-related access tokens used in the TSS network remain confined within the TEE's memory. This containment mitigates risks from malware or unauthorized access by processes on an applicaton environment. Additionally, CoreSDK employs ephemeral key management within the enclave: dynamically generated, short-lived keys are purged immediately upon task completion, significantly reducing the time-sensitive key material remains in memory. This approach minimizes the attack surface and provides a robust defense against potential threats targeting sensitive data.

Threshold Signature Schemes, TSS/MPC and Secure Encrypted Virtualization (SEV)

Tria decentralizes public key cryptography through the use of Lit Protocol’s threshold signature schemes (TSS). By distributing cryptographic processes across a network of nodes, Tria securely manages persistent cryptographic keys for signing, encryption, and computation in a decentralized, trust-minimized manner.

Both multi-party computation (MPC) and threshold signature schemes (TSS) originate from the concepts of public key cryptography and extend their benefits to multi-party and decentralized environments, where the security and privacy of the private key material, data, and computation are critically important. These methods expand upon “traditional” public key infrastructure (PKI), removing the dependence on centralized key custodians, who exist as a single point of failure. This greatly reduces the attack vector for key compromise by distributing ownership among multiple parties, undermining the ability of a single entity to cause widespread harm. In order for an attacker to gain control, they would need to successfully gain control of more than the threshold of participating parties. In Unchained, this threshold is set to two-thirds, meaning participation from two-thirds of nodes is required for signing and encryption.

Nodes perform asynchronous distributed key generation (ADKG) to create new private key pairs where no one party ever holds the entire key. Each node retains a distinct key share, used independently to execute signing and decryption operations. These operations are performed in parallel across nodes, with results aggregated to produce a composite signature or decryption outcome, maintaining the confidentiality of the private key throughout the process. By distributing key material across multiple nodes, the network sustains operational resilience even when some nodes are offline or compromised.

In addition to the security provided by the decentralized nature of TSS, this construct leverages AMD’s Secure Encrypted Virtualization (SEV), providing advanced hardware-level protection and an additional layer of security. SEV ensures that node operators never have access to any key shares directly, nor the computation processed inside of each node. This robust hardware-level isolation complements the decentralization of cryptographic operations and mitigates the risk of access to sensitive information.

In the context of user-facing operations — such as when key shares are provisioned for signing and decryption — nodes communicate via independent, encrypted channels. This means that shares are only ever exposed client-side at the exact moment of recombination. We strongly believe that the marriage of threshold signature schemes (TSS), and SEV provides end users with the most robustly secure and versatile non-custodial KMS solution currently available on the market today.

Threshold Signature Schemes (TSS) in comparison with Custodian, Self-custody, and Multi-party computation (MPC)

Self-custody and third-party custodians simplify the user experience by handling private key management on behalf of users. However, this centralizes risk; a breach of the custodian could expose user assets. Self-custody, while removing this single point of failure, requires a higher degree of technical proficiency and personal responsibility, such as securing seed phrases.

Multi-Party Computation (MPC) within cryptographic contexts operates by partitioning private keys across multiple nodes or validators, ensuring that each node only has access to a shard of the key, known as a share. This distribution leverages mathematical constructs from Secret Sharing Schemes, where a function over these shares can be computed securely, allowing for operations like signing transactions without any single entity ever possessing the complete key. MPC thus facilitates a decentralized approach to key management, reducing the risk vectors associated with centralized key storage. However, in MPC networks keys are reconstructed on (client or server) as they are generated for the first time, and every subsequent times to sign transactions.

In Threshold Signature Scheme (TSS), each participant only computes a partial signature on their portion of the data. These partial signatures are then aggregated through cryptographic means into a valid signature under the public key, without ever needing to reconstruct the private key. This method employs advanced polynomial interpolation for signature aggregation, ensuring that the private key remains perpetually in a disassembled state. The security paradigm here shifts from preventing key reconstruction to ensuring that signatures can be produced securely across distributed systems, leveraging the trust model of having no single point of failure or key exposure.

Proactive Secret Sharing in the TSS network keeps the same overall private key, but change the private key shares, such that private key shares after the PSS operation are incompatible with shares from before the operation. We use PSS for adding and removing nodes from the network during an epoch transition, such that private key shares from the previous epoch are incompatible with private key shares in the next epoch.

Access Control, Permissioning and Automating States

Validators running TSS nodes read and write states to Unchained L2 to facilitate granular permissioning, access control and automations of signatures to always give users a 1-click experience. This construct also enables immutable and trustless executions conditions tied to specific wallets, chain, dApp-specific actions and automated-permissions like signing a series of complex intent-based transaction.

Validator-operated TSS nodes read and write states to Unchained L2, enabling precise permissioning, access control, and automated signature workflows that deliver a seamless, one-click execution experience for end users. This architecture supports immutable and trustless execution conditions anchored to specific PKPs or children wallets, chain contexts, dApp-defined actions, and automated permissions. Through this construct, complex, intent-based transaction sequences can be programmatically authorized and executed. By embedding granular control over transaction permissions and intent routing directly within the L2, Tria facilitates trustless chain abstraction flows like multi-stage approvals, delegated signing, and condition-based automations that adhere to predefined execution rules.

---

Ephemeral Computation on Trusted Execution Environments (ECTEE) for Enterprises

Tria introduces a robust CLI-based interface within Trusted Execution Environments (ECTEE), designed for heightened security in enterprise-grade deployments and bespoke integrations where a public client interface is not utilized. ECTEE harnesses the capabilities of cloud-based TEEs—such as AWS Nitro, Intel SGX, and AMD SEV—to dynamically create isolated enclaves for real-time, on-demand cryptographic computations. These TEEs dynamically provision enclaves for each task, ensuring secure isolation from the main operating system and preserving the confidentiality and integrity of code and data. Within these enclaves, ECTEE generates short-lived cryptographic keys and client-less PKP vaults that are destroyed post-computation, minimizing the attack surface by limiting key lifespan in memory. ECTEE supports both self-managed and multi-party computation (MPC) KMS configurations extending Tria's inherent functionalities.