Skip to main content
Chain signatures enable NEAR accounts, including smart contracts, to sign and execute transactions across many blockchain protocols. This unlocks the next level of blockchain interoperability by giving ownership of diverse assets, cross-chain accounts, and data to every single NEAR account. chain-signatures Diagram of a chain signature in NEAR
While you can sign transactions for any network using Eddsa or Ecdsa keys, each chain signs transactions differently.Our example implementation shows you how to sign transactions for: Bitcoin, Solana, Cosmos, XRP, Aptos, Sui and EVM networks (Ethereum, Base, BNB Chain, Avalanche, Polygon, Arbitrum, and more).

​
Benefits

Integration with Chain Signatures brings many benefits to Web3 developers:
  • Single Account, Multi-Chain Operations: Developers can manage interactions with external blockchains from one NEAR account, without needing multiple wallets or addresses.
  • Reduced Overhead in Cross-Chain Development: Developers can write smart contracts on NEAR that directly sign for cross-chain transactions.
  • Secure Transaction Signing: Using Multi-Party Computation (MPC), no single entity controls the signing key.
Keep in mind that Chain Signatures is a “one way” solution to sign and execute outbound transactions happening on other blockchains. If you’re looking to access states on external blockchains, you should check out Omnibridge.

​
How It Works

Controlling accounts and their assets on other blockchain platforms is made possible thanks to the interaction between three elements:
  1. Derivation Paths - A deterministic way to derive foreign addresses from one NEAR account
  2. Multichain Smart Contract - Receives requests to sign a transaction for other blockchains
  3. Multiparty Computation Service - Third-party service providing signatures to the contract
Chain Signatures Chain signatures flow

​
Derivation Paths: One Account, Multiple Chains

Chain Signatures link NEAR accounts to addresses in other blockchain using Additive Key Derivation (a simple mechanism for deriving many subkeys from a single master key). These keys are generated using derivation paths (or paths for short). A derivation path is simply a string (e.g. ethereum-1, ethereum-2, etc) that in conjunction with the NEAR account derives a unique address on the target blockchain. For example, we can derive multiple Ethereum addresses from example.near by using different paths:
  1. example.near + ethereum-1 = 0x1b48b83a308ea4beb845db088180dc3389f8aa3b
  2. example.near + ethereum-2 = 0x99c5d3025dc736541f2d97c3ef3c90de4d221315
  3. example.near + ... = 0x...
It is important to note that this allows us to discover the public address of the foreign account that we can control. To actually control the foreign account, we need to request signatures from the MPC service.
In practice, the external address is deterministically derived using the NEAR address (example.near), the path (ethereum-1) and the MPC service’s public key
Avoid ambiguous signatures across chainsA signature is only bound to a specific network if the signed payload itself encodes that network. When it doesn’t, the same signed transaction can be valid on more than one chain, allowing it to be replayed on a chain you did not intend to interact with. Two common cases:
  • EVM networks: transactions that follow EIP-155 include the chainId in the signed data and are safe. Legacy (pre-EIP-155) transactions omit it and can be replayed across any EVM chain (Ethereum, Polygon, BNB Chain, Arbitrum, …).
  • Bitcoin-like networks: chains that share Bitcoin’s transaction format (Litecoin, Dogecoin, Bitcoin Cash, …) may accept the same signed payload unless the chain adds replay protection (e.g. Bitcoin Cash’s SIGHASH_FORKID).
Rather than tracking which chains are affected, the robust rule is to use a distinct derivation path per chain (for example ethereum-1 and polygon-1 instead of reusing one path). Different paths derive different keys, so a signature for one chain cannot authorize a transaction on another.

​
Multichain Smart Contract

A deployed smart contract (v1.signer) is used to request signatures for transactions on other blockchains. This contract has a sign method that takes these three parameters:
  1. The payload (transaction or transaction hash) to be signed for the target blockchain.
  2. The path that identifies the account to be used to sign the transaction.
  3. The domain_id: an integer that picks the key and signature scheme, only the two signing domains are currently supported: 0 for Secp256k1 or 1 for Ed25519.
For example, a user could request a signature to send 0.1 ETH to 0x060f1... (transaction) using the ethereum-1 account (path) with 0 (Secp256k1) as domain ID. After a request is made, the sign method will yield execution waiting while the MPC signing service signs the transaction. Once the signature is ready, the contract resumes computation and returns it to the user. This signature is a valid signed transaction that can be readily sent to the target blockchain to be executed. For the user, the process is made completely on chain, since they only need to make a call to a smart contract and wait for the response.
The sign method currently supports both Secp256k1 and Ed25519 signature schemes which enables signing transactions for the vast majority of the well-known blockchains including Bitcoin, Ethereum, Solana, BNB chain, Ton, or Stellar.

​
Multi-Party Computation Service

The essence of Multi-Party Computation (MPC) is to enable independent parties to perform shared computations on private information without revealing secrets to each other. In practice, this system can be used with blockchain platforms to safely sign a transaction on behalf of a user without ever having to expose a private key. NEAR’s MPC service is comprised of several independent nodes, none of which can sign by itself, but instead create signature-shares that are aggregated through multiple rounds to jointly sign a transaction. The participant set and the signing threshold are public in the v1.signer contract, and they change only through its vote_new_parameters method, when enough current participants vote for it (see The MPC network today). This service continuously listens for signature requests (i.e. users calling the sign method on the v1.signer smart contract) and when a call is detected the MPC service:
  1. Asks its nodes to jointly derive a signature for the payload using the account identified by the path
  2. Once complete, call the v1.signer contract to store the resulting Signature
A Custom MPC Service Generally, MPC signing services work by sharing a master key, which needs to be re-created each time a node joins or leaves.NEAR’s MPC service allows for nodes to safely join and leave, without needing to re-derive a master key.
Want to learn more about the mathematics that enable MPC? Check this awesome article.

​
The MPC network today

Read the live mainnet participant set and threshold from the contract:
mpc.nearone.org shows the live operators and a security overview. The audit reports are in near/mpc/audits, and the operator guide covers running a node.