NEAR Chain Signatures: Cross-Chain Signing Explained
Learn how NEAR Chain Signatures enable single accounts to sign transactions on Bitcoin, Ethereum, and other blockchains using decentralized MPC nodes.
The Problem with Fragmented Blockchains
Your Bitcoin cannot natively participate in any DeFi protocol. Your Ethereum assets cannot move to a Cosmos chain without trusting a bridge. Every blockchain ecosystem operates as a separate island, and moving between them means choosing between custodial risk, wrapped assets, or managing a separate wallet and private key for each chain you use.
This fragmentation is blockchain interoperability's core unsolved problem. Hundreds of chains hold trillions of dollars in combined value, yet the mechanisms for moving that value between them all require trusting a centralized custodian, accepting the risk of a bridge exploit, or absorbing the UX friction of managing multiple wallets and private keys. The cost of getting it wrong is real: cross-chain bridges have collectively been exploited for over $2 billion in losses.
NEAR Chain Signatures is a feature of NEAR Protocol that allows a single NEAR smart contract to sign transactions on any blockchain, including Bitcoin, Ethereum, and Cosmos chains, using a decentralized network of Multi-Party Computation (MPC) nodes. This eliminates the need for cross-chain bridges and lets one NEAR account control assets across all supported networks.
Current Status: NEAR Chain Signatures is live on NEAR Protocol mainnet. Testnet is also available for development and testing. Verify the current deployment status against the NEAR Chain Signatures documentation before building.
What Is NEAR Protocol?
NEAR Protocol is a Layer-1 blockchain that uses a Proof of Stake (PoS) consensus mechanism and a sharding architecture called Nightshade to process transactions at high throughput with low fees. It is developed and supported by the NEAR Foundation, a non-profit based in Switzerland.
Nightshade is NEAR's approach to scaling. Sharding splits the blockchain into parallel processing lanes so the network can handle more transactions simultaneously than a single-chain architecture allows. The result is transaction fees that remain low even under high network load, which matters when Chain Signatures generates significant cross-chain transaction volume.
NEAR uses human-readable account names (such as alice.near) rather than the hexadecimal address strings Ethereum uses. This design choice makes NEAR accounts easier to work with and positions them as natural identity anchors across multiple blockchains. NEAR transaction fees are a fraction of Ethereum mainnet fees, and NEAR supports Rust and JavaScript for smart contract development rather than Solidity. The native NEAR token powers gas fees, staking, and governance on the network.
NEAR's multichain strategy positions NEAR Protocol as the smart contract and identity layer for all blockchains. Chain Signatures is the primary technical feature that makes this strategy possible. Aurora, NEAR's EVM-compatible execution environment built by Aurora Labs, provides a complementary component: Ethereum-compatible dApp deployment on NEAR alongside Chain Signatures for cross-chain signing.
No other major Layer-1 blockchain currently offers native cross-chain signing via a decentralized Multi-Party Computation network as a built-in protocol feature. That capability positions NEAR's architecture differently from Ethereum, Solana, and other Layer-1 platforms in the cross-chain space. For background on how another Layer-1's interoperability approach works, see What Is Polkadot: Crypto, DOT Coin, and Parachains Explained.
What Are NEAR Chain Signatures?
NEAR Chain Signatures is a feature of NEAR Protocol that allows a single NEAR smart contract to sign transactions on any blockchain, including Bitcoin, Ethereum, and Cosmos chains, using a decentralized network of Multi-Party Computation (MPC) nodes. This eliminates the need for cross-chain bridges and lets one NEAR account control assets across all supported networks.
In practice, this means you write your application logic on NEAR, and your contract gains the ability to interact with Bitcoin, Ethereum, or any supported chain as a native participant on that chain. The signed transactions those chains receive are valid in their native format, with no wrapping, bridging, or separate wallet required.
For product builders and investors, the user-facing implication is concrete. A user interacting with a dApp (decentralized application, meaning software that runs on a blockchain rather than a centralized server) built on Chain Signatures does not need to install a Bitcoin wallet, an Ethereum wallet, and a Cosmos wallet separately. One NEAR account handles everything.
The cryptographic mechanism behind this capability, Multi-Party Computation, is explained in the next section.
One Account for All Blockchains
Your users do not need a separate wallet for Bitcoin, a separate wallet for Ethereum, and another for Solana. With Chain Signatures, one NEAR account serves as the root identity across all supported blockchains.
Managing separate private keys for each blockchain is a genuine security and UX burden. Every additional key is another credential that can be lost, phished, or compromised. Chain Signatures eliminates this by having the MPC node network derive a deterministic key pair for each target chain from the user's NEAR account. The user never generates or manages those derived keys directly. The NEAR account is the only credential they need.
This is multichain account abstraction: the ability for a single identity to programmatically control accounts and assets on any blockchain without managing separate private keys per chain. Ethereum's ERC-4337 standard addresses account abstraction within a single chain, making Ethereum accounts programmable. Chain Signatures extends the concept across chains, making one NEAR account the controller for the entire supported blockchain ecosystem. Your product can offer users a single sign-in experience spanning Bitcoin, Ethereum, Solana, and beyond.
How NEAR Chain Signatures Work
NEAR Chain Signatures relies on a cryptographic method called Multi-Party Computation. This technique allows multiple parties to jointly produce a computation result without any single party seeing the others' private inputs.
Understanding Multi-Party Computation
Imagine splitting a secret number into three pieces and giving one piece to each of three separate people. None of them knows the full number. But together, the group can perform a calculation using their individual pieces and produce a correct result, without ever assembling those pieces in one place.
That is the core idea behind Multi-Party Computation (MPC): a cryptographic method that allows a group of parties to jointly compute a result from their individual inputs without any party revealing its input to the others.
In Chain Signatures, the "parties" are MPC nodes, independent computers participating in the signing network. Each MPC node holds a key share, which is a portion of the private key material for each supported blockchain. No single MPC node holds or learns the complete private key. The nodes cooperate to produce a valid cryptographic signature, and that cooperation is all that is needed to authorize a transaction on any supported chain.
Institutional custody solutions like Fireblocks use the same underlying cryptographic primitive for key protection. Chain Signatures applies it to a different problem: signing cross-chain transactions rather than protecting a custody vault. The mechanism is the same; the application is distinct.
No single node can sign alone. That is the security guarantee.
Threshold Signatures and the Security Model
The specific MPC protocol that Chain Signatures uses is called a Threshold Signature Scheme (TSS): a design that requires a minimum number of nodes, the "threshold," to cooperate before the network can produce a valid signature.
TSS is distinct from multi-signature (multisig). In multisig, each signer holds a complete private key, and multiple complete keys are required to authorize a transaction. In TSS, no signer ever holds a complete key. Each holds only a key share. The complete private key never exists in any one place. This property means an attacker who compromises one or several MPC nodes cannot reconstruct the private key unless they compromise enough nodes to meet or exceed the threshold simultaneously.
The t-of-n structure also tolerates failures. If some nodes go offline, the remaining nodes can still meet the threshold and produce signatures. Users must accept one trust assumption: that fewer than the threshold number of nodes are colluding or compromised at the same time.
The Transaction Flow: Step by Step
The Chain Signatures signing flow has five steps, from the initial contract call to the final broadcast on the target chain.
Request. Your NEAR smart contract calls the Chain Signatures MPC contract, passing the target blockchain's transaction payload and specifying the destination chain (Bitcoin, Ethereum, etc.). The smart contract does not need to hold any private key for the target chain.
Coordination. The Chain Signatures MPC contract receives the signature request and distributes it to the decentralized MPC node network.
Signing. The MPC nodes each use their key share to participate in the threshold signing process. No single node holds the complete private key. The nodes cooperate until the threshold is met and produce a valid cryptographic signature, using ECDSA (Elliptic Curve Digital Signature Algorithm) for Bitcoin and EVM-compatible chains (networks that run the Ethereum Virtual Machine, including Polygon, Arbitrum, Base, and BNB Chain), or EdDSA (Edwards-curve Digital Signature Algorithm) for Solana and other EdDSA chains.
Return. The completed signature is returned to the requesting NEAR smart contract.
Broadcast. The signed transaction can now be submitted to the target blockchain by anyone, typically a relayer or the application itself. The target chain accepts the signature as it would any valid transaction from that chain's native format.
[Diagram: Four-layer flow. Layer 1: "Your NEAR Smart Contract" sends a request arrow to Layer 2: "Chain Signatures MPC Contract (on-chain coordinator)" which distributes to Layer 3: multiple boxes labeled "MPC Node 1," "MPC Node 2," "MPC Node 3...N" which collectively produce and return a signature arrow to Layer 2, which returns the completed signature to Layer 1, which then sends a broadcast arrow to Layer 4: "Target Blockchain (Bitcoin / Ethereum / Cosmos / etc.)"]
Supported chains. Chain Signatures can authorize transactions on any blockchain that uses ECDSA or EdDSA signature schemes. The current confirmed supported chains include:
- Bitcoin (ECDSA)
- Ethereum and EVM-compatible chains (Polygon, Arbitrum, Base, BNB Chain, and others)
- Cosmos chains (ECDSA and EdDSA variants)
- Solana (EdDSA)
- TRON (ECDSA)
This list may expand as the protocol develops. Check the NEAR Chain Signatures documentation for the current confirmed chain list.
What You Can Build with NEAR Chain Signatures
Chain Signatures turns any supported blockchain into a programmable surface for your NEAR smart contract. Here are the product categories and applications it makes possible.
Bitcoin DeFi with NEAR Chain Signatures
Bitcoin holds over $1 trillion in market value, yet it has historically been excluded from Decentralized Finance (DeFi) because Bitcoin has no native smart contract capability. DeFi refers to financial services like lending, borrowing, and trading, built on blockchain smart contracts without centralized intermediaries. Chain Signatures changes Bitcoin's relationship with DeFi.
A NEAR smart contract can request a Bitcoin transaction signature from the Chain Signatures MPC network, and the resulting signed transaction can be broadcast directly to the Bitcoin mainnet. This works because Chain Signatures produces ECDSA signatures, which is the same signature scheme Bitcoin uses natively. No wrapping, no bridge, no custodian.
The applications this unlocks include:
- BTC lending and collateralization. You can build a lending protocol where users deposit native BTC (not wrapped BTC) as collateral, with all collateral management handled by NEAR smart contract logic.
- Native BTC yield protocols. Yield strategies that operate on actual Bitcoin addresses, not tokenized representations.
- BTC-denominated DEX pairs. Trading pairs that settle in native BTC on the Bitcoin mainnet.
For investors, Bitcoin DeFi represents one of the largest unaddressed markets in crypto: over a trillion dollars in BTC that currently sits outside any DeFi protocol.
Multichain Account Abstraction
Your users do not need five separate wallets to access five different blockchains. Chain Signatures derives the corresponding address on each target chain from a single NEAR account, making one NEAR login the entry point for the entire supported blockchain ecosystem.
A consumer multichain wallet built on Chain Signatures lets users authenticate once and send, receive, and interact with assets on Bitcoin, Ethereum, Solana, and any other supported chain from a single interface. A multichain dApp (an application that interacts with multiple blockchains from a single interface, without requiring users to switch networks or manage multiple wallets) becomes buildable without asking users to understand key management at all.
More Use Cases: From DAOs to Gaming
The Chain Signatures ecosystem is in its early building phase. At time of publication, the NEAR Foundation's ecosystem page at near.org lists current projects building on this infrastructure. Verify specific project integrations against NEAR's official blog and developer resources before relying on any example. Beyond Bitcoin DeFi and multichain wallets, the infrastructure enables a range of cross-chain applications.
Cross-chain DEX. You can build a decentralized exchange where users trade native assets across Bitcoin, Ethereum, and Cosmos chains without wrapping tokens or routing through a bridge. Your contract holds the signing authority; the user holds the NEAR account.
Chain-agnostic DAO treasury management. DAOs can control treasury assets across multiple chains from a single NEAR governance contract. A DAO vote on NEAR can authorize a Bitcoin transaction or an Ethereum token transfer without any bridge infrastructure in the execution path.
Cross-chain NFTs. NFT platforms can represent and transfer assets across chains. A token minted on one chain can be controlled and transferred on another through Chain Signatures authorization, without wrapping or bridging the underlying asset.
Cross-chain gaming assets. Game items stored on one blockchain can be used in games deployed on another. The player's NEAR account acts as the unified identity across gaming ecosystems, and Chain Signatures handles the cross-chain authorization.
Chain Signatures vs. the Alternatives
Chain Signatures is one of several approaches to blockchain interoperability. The differences between them reflect fundamentally different architectural choices, security models, and chain coverage assumptions.
Chain Signatures vs. Cross-Chain Bridges
Cross-chain bridges work by locking assets on the source chain and minting wrapped representations on the destination chain. The bridge contract holds the locked assets, making it a concentrated attack target.
This custodial structure is the source of bridge risk. When a bridge contract is exploited, the locked assets are accessible to the attacker. Cross-chain bridges have collectively been exploited for over $2 billion in aggregate losses, according to data tracked by the Rekt.news exploit leaderboard. The wrapped assets minted on the destination chain are not native to that chain; their value depends on the bridge's continued solvency and the security of its smart contracts.
Chain Signatures takes a mechanically different approach. Chain Signatures does not lock any assets. It produces cryptographic signatures that authorize native transactions directly on the target chain. There is no custodian holding funds, no wrapped token, and no bridge contract to exploit.
The trust model is different, not risk-free. Chain Signatures security depends on the decentralization and economic incentives of the MPC node network. A smaller or less geographically distributed node set increases risk. The threshold model distributes trust but does not eliminate it. Readers evaluating Chain Signatures for production use should review current node network statistics and security audit reports at near.org.
The comparison above applies primarily to trusted and semi-trusted bridges. Trust-minimized light-client bridges, like Cosmos IBC, operate on a distinct security model addressed in the table below.
Interoperability Comparison Table
The table below compares Chain Signatures against five interoperability approaches across the dimensions that matter most for build and investment decisions.
| Solution | Mechanism | Asset Type | Destination Chain Requirements | Supported Chain Scope | Security Model | Dest. Chain Contract Required? |
|---|---|---|---|---|---|---|
| NEAR Chain Signatures | MPC-based cryptographic signing | Native assets on target chain | None required on target chain | Any ECDSA or EdDSA chain (Bitcoin, Ethereum, Cosmos, Solana, etc.) | MPC threshold trust (t-of-n nodes) | No |
| Cross-Chain Bridge | Lock/mint (wrapped tokens) | Wrapped representations | Bridge contract on destination | Chains the bridge has deployed to | Custodial / smart contract risk | Yes (bridge contract) |
| Cosmos IBC | Light-client verification | IBC token transfers (ICS-20) | IBC module implementation required | IBC-enabled chains only | Trust-minimized (light clients) | Yes (IBC module) |
| LayerZero | Oracle + relayer message passing | Token transfers + arbitrary messages | Endpoint contracts on both chains | EVM and selected non-EVM chains | Oracle + relayer trust assumptions | Yes (both chains) |
| Polkadot XCM | Cross-Consensus Messaging | XCM-format messages and tokens | Parachain within Polkadot/Kusama ecosystem | Polkadot/Kusama parachains only | Shared relay chain security | Yes (parachain slot) |
| Wormhole | Guardian network message relay | Wrapped tokens + arbitrary messages | Core bridge contracts on supported chains | 20+ EVM and non-EVM chains | Guardian network (19 validators) | Yes |
Cosmos IBC (Inter-Blockchain Communication) is a trust-minimized protocol with strong cryptographic guarantees within its ecosystem. Its scope is limited to chains that have implemented the IBC standard. Bitcoin and most EVM chains are not natively IBC-enabled, which limits its reach to the IBC-compatible subset of blockchains.
LayerZero operates at the cross-chain message-passing layer rather than the cryptographic signing layer. It requires contract deployments on both the source and destination chains, which means it cannot natively target Bitcoin or other chains without smart contract capability.
Wormhole uses a guardian network of 19 validators to validate and relay messages between supported chains. It operates at the message layer with its own trust assumptions, and it experienced a $320M exploit in 2022. For a detailed look at Polkadot's parachain architecture and how XCM (Cross-Consensus Messaging) works within the Polkadot ecosystem, see the linked explainer. XCM is a powerful intra-ecosystem standard; Chain Signatures is designed for ecosystem-agnostic cross-chain operations.
Note: Verify all competitor protocol descriptions against official documentation at time of reading. Protocol capabilities evolve.
For Investors: Chain Signatures and NEAR Token Demand
For Investors
Every Chain Signatures transaction is processed on NEAR Protocol, consuming NEAR tokens for gas fees. If Chain Signatures adoption grows, NEAR transaction volume increases proportionally, creating increased demand for the NEAR token through the gas fee mechanism.
Chain Signatures is the only major Layer-1 feature that enables native cross-chain signing via a decentralized MPC network without requiring infrastructure on the target chain. No other major L1 currently offers this as a built-in protocol capability. That technical distinction is the basis for the competitive moat argument.
The honest caveat: the ecosystem is early-stage, and adoption is not guaranteed. The value of the technical differentiation depends entirely on developer and user adoption, which remains to be proven at scale.
This content discusses token utility mechanics for informational purposes only and does not constitute investment advice. The value of cryptocurrency assets can decrease as well as increase. Consult a qualified financial advisor before making investment decisions.
Getting Started with NEAR Chain Signatures
Chain Signatures is available on NEAR Protocol mainnet and testnet. Your NEAR smart contract is the entry point. You deploy your application logic on NEAR, call the Chain Signatures MPC contract, and Chain Signatures handles the cross-chain signing layer.
Two points about deployment architecture matter here. First, the signing request must originate from a NEAR smart contract. Yes, you need a contract on NEAR, because Chain Signatures is a NEAR Protocol feature and the request flow begins there. Second, you do not need to deploy any contract or infrastructure on the target chain. That distinction separates Chain Signatures from alternatives that require destination chain contract deployments. Your cross-chain logic lives entirely on NEAR.
NEAR supports Rust (near-sdk-rs) and JavaScript/TypeScript (near-sdk-js) for smart contract development. Chain Signatures can be invoked from either SDK. The architectural advantage for developers is real: you write one contract on NEAR rather than deploying separate contracts on every chain you want to target.
Here is a numbered starting path to go from zero to a working cross-chain signing integration:
Read the concept documentation. Start with the NEAR Chain Signatures documentation to understand the MPC contract API, the signature request format, and the supported chain parameters.
Review the quickstart tutorial. The Chain Signatures quickstart provides a working example of a NEAR smart contract invoking Chain Signatures for a target chain. See how the request payload is structured and what the returned signature looks like.
Set up your NEAR development environment. Install
near-cli, the command-line interface for deploying and calling NEAR smart contracts. Review the NEAR smart contract developer guide for environment setup and contract structure.Deploy a test contract on NEAR testnet. Invoke the Chain Signatures contract with a sample payload for your target chain. Testnet lets you test the full five-step signing flow without mainnet transaction costs. Verify current testnet capabilities against near.org before testing, as the supported chain list and API may evolve.
Join the NEAR developer community. The NEAR developer Discord provides community support, code reviews, and answers to questions about Chain Signatures integration patterns. Early-stage integrations benefit from direct access to other builders who have worked through similar problems.
Ready to build? Start with the NEAR Chain Signatures documentation at docs.near.org and the NEAR smart contract developer guide.
Technical specifications, deployment status, and supported chain information are current as of publication. NEAR Protocol is an active development project. Verify current capabilities at docs.near.org before building.
Frequently Asked Questions
What Is NEAR Chain Signatures?
NEAR Chain Signatures lets any NEAR smart contract produce valid transaction signatures for other blockchains (Bitcoin, Ethereum, Cosmos, and others) through a decentralized network of Multi-Party Computation nodes. Users get one account that works across all supported chains. No bridge is required, and no separate wallets are needed for each blockchain.
How Do NEAR Chain Signatures Work?
Your NEAR smart contract sends a signature request to the Chain Signatures MPC contract. A decentralized node network then cooperates to produce a valid cryptographic signature using a Threshold Signature Scheme. No single node holds or ever sees the complete private key. The completed signature returns to your contract and can be broadcast to the target blockchain.
What Blockchains Does NEAR Chain Signatures Support?
Chain Signatures supports any blockchain using ECDSA (Elliptic Curve Digital Signature Algorithm) or EdDSA (Edwards-curve Digital Signature Algorithm) signature schemes. Confirmed supported chains include Bitcoin, Ethereum and EVM-compatible networks, Cosmos chains, Solana, and TRON. Check docs.near.org for the current confirmed list, as support may expand over time.
Is NEAR Chain Signatures the Same as a Cross-Chain Bridge?
No. Cross-chain bridges lock assets on one chain and mint wrapped representations on another, creating custodial risk concentrated in the bridge contract. Chain Signatures produces cryptographic signatures that authorize native transactions directly on the target chain. No assets are locked, no wrapped tokens are created, and there is no single custodian holding funds.
Is NEAR Chain Signatures Secure?
Chain Signatures is secure as long as fewer than the threshold number of MPC nodes are compromised or colluding. The system distributes trust across a node network rather than concentrating it in a single smart contract. Security scales with the size and distribution of the node network. Readers evaluating Chain Signatures for production use should review current network statistics and security audits at near.org.
What Is Multi-Party Computation (MPC)?
Multi-Party Computation (MPC) is a cryptographic method that lets a group of parties jointly compute a result without any participant revealing their individual input to the others. In Chain Signatures, MPC nodes each hold a key share (a portion of the private key material) and cooperate to produce a valid signature. No single node knows or holds the complete private key at any point.
Do I Need a Separate Wallet for Each Blockchain?
No. Chain Signatures uses your NEAR account as the root identity and derives a corresponding address on each target chain. You manage one set of credentials, and your product users do the same. Developers building on Chain Signatures can offer a single sign-in experience that covers Bitcoin, Ethereum, Solana, and every other supported chain without asking users to manage separate keys.
Can a NEAR Smart Contract Sign a Bitcoin Transaction?
Yes. Chain Signatures produces ECDSA signatures, the same signature scheme Bitcoin uses. Your NEAR smart contract can request a Bitcoin transaction signature from the Chain Signatures MPC network, and the resulting signed transaction can be broadcast directly to the Bitcoin mainnet without any bridge, wrapped asset, or Bitcoin-side contract deployment.
What Can You Build with NEAR Chain Signatures?
You can build Bitcoin DeFi protocols using native BTC, cross-chain DEXes that trade assets across multiple networks without wrapping, multichain wallets where users manage all chains from one account, DAO treasuries that control assets on multiple chains, cross-chain NFT platforms, and cross-chain gaming asset systems. Chain Signatures makes any ECDSA or EdDSA blockchain a programmable surface for your NEAR smart contract.
How Does Chain Signatures Affect NEAR Token Demand?
Every Chain Signatures transaction is processed on NEAR Protocol, consuming NEAR tokens for gas fees. If Chain Signatures adoption grows, NEAR transaction volume increases proportionally, increasing demand for the NEAR token through the gas fee mechanism. This is not investment advice. Consult a qualified financial advisor before making investment decisions.
Conclusion
NEAR Chain Signatures makes it technically possible for a single account to authorize transactions on Bitcoin, Ethereum, and any other ECDSA or EdDSA chain without bridges, wrapped assets, or multi-wallet management. The mechanism is grounded: MPC nodes hold key shares, a Threshold Signature Scheme coordinates signing without any node seeing the complete key, and the resulting signatures are valid on the target chains natively.
Whether that capability becomes foundational infrastructure for the next generation of cross-chain applications depends on adoption. And adoption starts with builders.
Key Takeaways
- A single NEAR smart contract can sign transactions on any supported blockchain through a decentralized MPC node network. No bridge required.
- Unlike bridges, Chain Signatures does not lock assets or create wrapped tokens. It authorizes native transactions directly on the target chain.
- Security relies on the MPC threshold model: an attacker must compromise enough nodes to meet the threshold, not just one.
- Supported chains span Bitcoin, Ethereum and EVM networks, Cosmos, Solana, TRON, and others using ECDSA or EdDSA signatures.
- Chain Signatures is live on NEAR mainnet. Developers can start with the NEAR Chain Signatures documentation.
Developers: Start building with the NEAR Chain Signatures documentation at docs.near.org.
Investors: Explore the NEAR ecosystem and current network statistics at near.org.
Product builders: See what teams are building at the NEAR Foundation's ecosystem page at near.org.