Integration with NEAR Chain Signatures

Cross-chain interaction traditionally requires bridges or deploying contracts on each chain. We offer an alternative—turnkey integration with NEAR Chain Signatures. One NEAR account manages assets on Ethereum, Bitcoin, Solana without additional contracts. Our experience shows a 40% reduction in time and 60% reduction in cost compared to classic bridges. We'll evaluate your project for free.

How It Works

At the core is an MPC (Multi-Party Computation) network of NEAR validators that collectively store a master key. A user requests a transaction signature for another chain; the MPC network generates a signature using threshold cryptography. The resulting signature is valid for the target chain and can be broadcast.

This means your NEAR account can control a Bitcoin address, an Ethereum address, a Solana address—without a seed phrase for each. One NEAR account = access to all assets on all chains.

NEAR Account (alice.near)
    ├── Controls ETH address: 0x1234... (secp256k1 derived key)
    ├── Controls BTC address: bc1q... (secp256k1 derived key)
    └── Controls SOL address: ABC... (ed25519 derived key)

What Is a Derivation Path and Why Is It Needed?

Each NEAR account can obtain multiple addresses on external chains via a derivation path. One account manages multiple wallets: alice.near with path 'eth-1' gives one ETH address, with path 'eth-2' another, with path 'btc-main' a BTC address. This allows structuring assets by purpose.

const ethPath = `ethereum-1`;
const btcPath = `bitcoin-main`;
const ethAddress = await deriveAddress(nearAccount, ethPath, 'secp256k1');
const btcAddress = await deriveAddress(nearAccount, btcPath, 'secp256k1');

How Chain Signatures Signs a Transaction for Another Chain?

The process consists of several steps. First, you form an unsigned transaction for the target chain (e.g., Ethereum). Then the hash of this transaction is sent to the contract v1.signer.near. The MPC network of validators generates an ECDSA or EdDSA signature using threshold cryptography. The obtained signature is compatible with the target chain—you plug it into the transaction and broadcast directly.

import { connect, KeyPair, utils } from "near-api-js";
import { CONTRACT_ID } from "./constants";

async function requestEthSignature(
  nearAccount: Account,
  ethTxPayload: string,
  derivationPath: string
): Promise<{ r: string; s: string; v: number }> {
  
  const result = await nearAccount.functionCall({
    contractId: "v1.signer.near",
    methodName: "sign",
    args: {
      payload: Array.from(Buffer.from(ethTxPayload, "hex")),
      path: derivationPath,
      key_version: 0,
    },
    gas: "300000000000000",
    attachedDeposit: utils.format.parseNearAmount("0.1"),
  });
  
  const { big_r, s, recovery_id } = result as any;
  
  return {
    r: big_r.affine_point,
    s: s.scalar,
    v: recovery_id,
  };
}

Complete Flow: NEAR → Ethereum Transaction

import { ethers } from "ethers";

async function sendEthFromNear(
  nearAccount: Account,
  recipient: string,
  amountWei: bigint,
  derivationPath: string
) {
  const ethAddress = await getEthAddressFromNear(nearAccount, derivationPath);
  const provider = new ethers.JsonRpcProvider("https://eth.llamarpc.com");
  const nonce = await provider.getTransactionCount(ethAddress);
  const feeData = await provider.getFeeData();
  
  const tx = {
    to: recipient,
    value: amountWei,
    nonce,
    chainId: 1,
    maxFeePerGas: feeData.maxFeePerGas,
    maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
    gasLimit: 21000n,
    type: 2,
  };
  
  const serialized = ethers.Transaction.from(tx).unsignedSerialized;
  const payload = ethers.getBytes(ethers.keccak256(serialized));
  
  const signature = await requestEthSignature(
    nearAccount,
    Buffer.from(payload).toString("hex"),
    derivationPath
  );
  
  const signedTx = ethers.Transaction.from({
    ...tx,
    signature: {
      r: "0x" + signature.r,
      s: "0x" + signature.s,
      v: signature.v,
    },
  });
  
  const txResponse = await provider.broadcastTransaction(signedTx.serialized);
  return txResponse.wait();
}

Bitcoin Integration

The system supports Bitcoin (secp256k1 + P2WPKH/P2TR). This is a unique capability: most other cross-chain protocols do not natively support Bitcoin. Using the NEAR Chain Signatures documentation, we implemented Bitcoin transaction signing.

import * as bitcoin from "bitcoinjs-lib";

async function sendBitcoinFromNear(
  nearAccount: Account,
  recipient: string,
  satoshis: number,
  derivationPath: string
) {
  const network = bitcoin.networks.bitcoin;
  const btcAddress = await getBtcAddressFromNear(nearAccount, derivationPath);
  
  const utxos = await fetchUTXOs(btcAddress);
  
  const psbt = new bitcoin.Psbt({ network });
  for (const utxo of utxos) {
    psbt.addInput({ hash: utxo.txid, index: utxo.vout, witnessUtxo: utxo.witnessUtxo });
  }
  psbt.addOutput({ address: recipient, value: satoshis });
  
  for (let i = 0; i < utxos.length; i++) {
    const sighash = psbt.data.inputs[i].sighashType ?? bitcoin.Transaction.SIGHASH_ALL;
    const hash = psbt.__CACHE.__TX.hashForWitnessV0(i, psbt.data.inputs[i].witnessScript!, utxos[i].value, sighash);
    
    const signature = await requestBtcSignature(
      nearAccount,
      hash.toString("hex"),
      derivationPath
    );
    
    psbt.finalizeInput(i, /* custom finalizer with MPC signature */);
  }
  
  const rawTx = psbt.extractTransaction().toHex();
  return broadcastBitcoin(rawTx);
}

Use Cases

Omnichain DeFi. A dApp on NEAR that manages positions on Ethereum AAVE, Uniswap, GMX without a bridge. The user interacts only with NEAR (cheap, fast), Chain Signatures executes actions on Ethereum.

Cross-chain liquidation bot. Monitor positions across multiple chains, automatically liquidate using Chain Signatures to sign transactions without pre-loading ETH on executor addresses.

Multi-chain portfolio management. Manage assets on Ethereum, Bitcoin, Solana from a single NEAR account.

Atomic swaps without a bridge. ETH ↔ BTC without a centralized exchange, with on-chain guarantees via HTLC + Chain Signatures.

Comparison: Chain Signatures vs. L2 Bridges

Chain Signatures is 3-5 times faster and cheaper for atomic swaps between chains.

Limitations and Maturity

This solution is a relatively new product (mainnet launched). Infrastructure maturity is lower than Axelar or LayerZero. MPC latency: signing takes 3-5 seconds. Cost: each sign request costs ~0.1 NEAR + gas.

Tech Stack

• Frontend: React + near-api-js
• NEAR smart contracts: Rust (near-sdk-rs) or TypeScript (near-sdk-js)
• Target chain interactions: ethers.js, bitcoinjs-lib, @solana/web3.js
• MPC contract: v1.signer.near (mainnet), v1.signer-prod.testnet (testnet)

Why Choose Chain Signatures for Your Project?

If your task is omnichain DeFi, multi-chain portfolio, or automation without bridges, the protocol offers advantages: a single point of control, low latency, and 3x infrastructure cost reduction. We'll evaluate your scenario in a pilot phase—contact us.

What's Included in the Integration

• Architectural design and selection of derivation paths
• Client-side TypeScript code for Ethereum, Bitcoin, Solana
• MPC contract configuration and gas budget management
• Documentation on error handling and fallback strategies
• Testing on testnet and mainnet
• Operational support during the exploitation phase

Timelines

• NEAR account + basic Chain Signatures flow: 2-3 weeks
• Ethereum integration (transactions + ERC-20): +1-2 weeks
• Bitcoin support: +2-3 weeks
• Full omnichain dApp: 2-3 months

Our team has 5 years of blockchain experience and over 10 implemented projects. Contact us for a free evaluation of your scenario—we'll help determine if the technology is right for your task.

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.