NEAR announced on October 23, 2026 that Chain Signatures operations now run inside trusted execution environments, using Intel TDX. For someone approving a cross-chain payment, the practical distinction is between evidence about the signing environment and evidence about the payment itself. An attested environment cannot turn the wrong recipient into the right one.
What changed in the signing environment
The NEAR announcement reports a signing threshold of 11 out of 17 operators. Treat that as the reported configuration at the announcement date, rather than a permanent network parameter. The milestone concerns how those operators perform their work; a wallet holder does not need to move coins just to acknowledge the announcement.
Intel describes TDX as hardware-isolated virtual machines with memory protection and remote attestation. That makes the hardware and its verification system part of the assumptions being evaluated. A reassuring badge should therefore lead to an explanation of what was checked, rather than an instruction to skip the payment preview.
A valid signature still needs the right instruction
The Chain Signatures documentation distinguishes outbound signing from reading another chain’s state. It also explains that network binding depends on the signed payload, not merely the name given to a derivation path. A screen labelled with a familiar chain is insufficient evidence of what the application will actually request.
The MPC design document describes approved software-image hashes and contract verification of attestation. These controls address the approved execution environment. They should be evaluated separately from application permissions, the transaction preview and evidence of delivery. Do not infer that a design document independently proves the live configuration of every operator.
| Question before approval | Evidence to request | What it does not establish |
|---|---|---|
| Who may request this operation? | The application’s permission and approval rules | That the recipient is correct |
| What is being signed? | Decoded network, asset, recipient and amount | That the transaction has been sent |
| Which environment produced the result? | An explanation of attestation and approved software | That the application’s business rule is sensible |
| Did the destination accept it? | The destination transaction and its status | That an exchange credited its internal balance |
An ordinary recipient mistake survives good infrastructure
Consider a hypothetical application preparing a supplier payment. The operator selects the correct asset and amount but pastes a previous supplier’s address. If the application accepts that instruction, proving that approved software processed it would not prove the address belongs to the intended supplier. The useful intervention is a recipient check before approval, not a stronger claim about the server after approval.
For the same reason, keep an expected-payment record outside the final confirmation screen: the intended chain, asset, recipient and reason for sending. Compare the decoded operation against that record. If the application cannot explain a mismatch, stop before signing. This is a review method, not a claim that a particular live application has a defect.
- Identify the application and the permission that lets it request signatures on your behalf.
- Compare the decoded transaction with your intended recipient, network, asset and amount; investigate unfamiliar contract actions.
- Ask what the attestation result covers and where the approved software information can be checked.
- After sending, retain the destination-chain transaction reference separately from the signing request.
- When a service receives the transfer, check its own deposit status before treating the entire operation as complete.
What the announcement does not require you to assume
The release discusses further post-quantum research rather than announcing production-ready post-quantum threshold signing. Do not use TEE and quantum resistance as interchangeable descriptions. Likewise, this infrastructure announcement does not confirm that every wallet, asset or receiving platform supports your intended route.
Before a separate exchange, consult supported coins and networks, review how an order works, and then use the simple-swap form for the actual order details. These checks do not establish that KOT.CASH uses Chain Signatures. The useful next step is to understand the operation you are approving, not to infer a service integration from a network announcement.
FAQ
What does the NEAR Chain Signatures TEE update change?
The October 23 announcement concerns the operators’ execution environment. Review the transaction you approve separately; an environment attestation is not a recipient check.
Where can I inspect the NEAR MPC design on GitHub?
The linked near/mpc repository contains the TEE design description. Reading that document does not independently establish the current configuration of every live operator.
What is a trusted execution environment, and what is it not?
It is an isolated execution environment with a defined protection and verification model. It does not decide whether the recipient and amount match your intention.