NEAR MPC Is Expanding From Signatures to Cross-Chain Verification

Having authority to sign a transaction on another blockchain is not the same as knowing what happened after submission. A cross-chain application may control the destination account yet still need dependable information that the transaction finalized, executed successfully, and produced the expected result before taking its next step.

NEAR Chain Signatures addresses the first half of that problem through distributed key control. NEAR accounts and contracts can control accounts on external chains using MPC-generated signatures without reconstructing a complete private key in one place. The distinction is operationally important: signing determines whether the MPC network can authorize an action; foreign-chain verification determines whether configured nodes can inspect provider-supplied chain data and sign a specified observation about it. (docs.near.org)

Sui support was included in the official MPC 3.14.0 release, published on August 5, 2026, through two complementary pieces: a Sui contract interface and a node-side inspector. That date marks more than code landing in the repository. It establishes that the implementation was packaged into a tagged release, while saying nothing by itself about which deployed MPC networks or operators have configured the capability. (github.com)

The released request is intentionally compact. It identifies a Sui transaction by digest, asks for checkpointed finality, and selects an event by index. This gives the NEAR-side application a precise question to ask—effectively, “did this transaction reach the required status and contain this particular event?”—without asking a NEAR contract to understand Sui’s provider APIs, Move event representation, or serialization rules. (raw.githubusercontent.com)

Configured MPC nodes answer that question by querying gRPC-capable Sui full-node providers. The released inspector fetches the transaction over Sui gRPC, confirms that the returned transaction digest matches the requested digest, requires the response to contain a checkpoint field, requires successful execution, and then extracts the event at the requested index. Each participating node performs that provider-backed inspection, derives the deterministic observation, and cooperates in producing a signature over the result that a NEAR contract can verify. (github.com)

A concrete flow makes the separation from transaction signing clearer. Suppose an application authorizes a Sui transaction expected to emit an event recording that a particular operation completed; after the transaction is submitted, the next NEAR-side action should remain blocked until that result is established. MPC nodes can inspect the transaction and attest that it was checkpointed, succeeded, and contained the selected event, after which the NEAR contract checks the resulting signature before proceeding. The first MPC operation grants authority; the second supplies a signed account of the outcome.

What gets signed is designed for agreement across independently operated nodes. The event observation includes deterministic fields such as the package ID, transaction module, sender, canonicalized type information, and the event’s Binary Canonical Serialization bytes. Using the underlying BCS payload avoids making consensus among MPC nodes depend on provider-rendered parsed JSON, whose formatting or representation can vary even when providers are describing the same event. Canonicalization is therefore not cosmetic: it defines the stable material that nodes must agree on before signing. (github.com)

Sui also required a dedicated transport path rather than reuse of the shared JSON-RPC machinery available to some other inspectors. The released implementation talks to Sui gRPC services and handles provider credentials through gRPC metadata, including the semantics needed to attach authentication to the request itself. That is different from treating credentials as ordinary URL components or HTTP query substitutions, and it makes provider integration part of the chain-specific inspector rather than a generic endpoint swap.

This specialization matches Sui’s object-centric architecture, where onchain state is organized around uniquely identified objects with versions and transaction-linked metadata. But the scope of the released inspector is narrower than Sui’s overall state model: it checks the status of a specified transaction and extracts a specified event. Its significance is not broad object-state inspection, but the demonstration that a useful verification path must still understand Sui’s native transaction identifiers, checkpoint finality signal, Move event fields, BCS encoding, canonical type representation, and gRPC access. (docs.sui.io)

That makes Sui a strong example of heterogeneous-chain engineering. An EVM-style adapter can reason in terms of familiar transaction receipts and logs, but Sui cannot simply be mapped into that shape without discarding the semantics the inspector needs to produce a stable observation. The integration has to follow the destination chain’s own interfaces and data model. As more foreign chains are added, the reusable layer is the MPC coordination and signed-observation workflow; transaction lookup, finality, transport, extraction, and serialization remain deliberately chain-aware.

The trust boundary is equally specific. For this inspector, the presence of a checkpoint field is the implemented finality condition, but the MPC nodes do not verify Sui checkpoint signatures, run a Sui light client, participate in Sui consensus, or replace Sui validators. They independently query their configured providers and compare the deterministic results extracted from those responses. The MPC signature therefore establishes agreement among participating nodes about a defined provider-supplied observation, not an independent cryptographic proof of Sui state.

That boundary also explains why deployment claims require separate evidence. Repository implementation, inclusion in the 3.14.0 release, tagged localnet examples, operator configuration, and availability on a deployed MPC network are distinct milestones. Localnet documentation shows how the released software can issue a Sui verification request, but neither that example nor the release artifact establishes activation on v1.signer, NEAR mainnet enablement, or provider coverage across current MPC participants; those remain unconfirmed without a separate official deployment source. (github.com)

The broader MPC-node security model includes confidential virtual machines and Intel TDX attestation, which are intended to isolate node execution and provide evidence about the software stack operators run. That architecture strengthens the environment in which distributed signing and inspection occur, but it does not alter where foreign-chain observations originate: the Sui inspector still evaluates responses from configured full-node providers using its released chain-specific checks. (github.com)

As of August 22, 2026, MPC 3.14.1 is the latest published release. Released on August 19, it did not introduce Sui support; its changes focused on contract migration, extending stored attestation expirations, and release plumbing. Keeping that patch separate from the August 5 Sui milestone avoids collapsing software history into deployment status: the architectural shift began in 3.14.0, toward cross-chain infrastructure that combines distributed control with increasingly chain-specific awareness of the context surrounding external activity. (github.com)