A First Look at Chain Signatures: Cross-Chain Without Bridges
As 2023 witnessed the Cambrian explosion of L2s and modular blockchains, it simultaneously observed the pushback against Web3’s increasing complexity and fragmentation. Reflected in the buzzwords of abstraction and aggregation, we saw the ongoing discourse about account abstraction on Ethereum, Polygon’s AggLayer, and the chain abstraction narrative spearheaded by NEAR or Agoric, to name a few. Though all different in detail, the underlying idea is the same: Web3 is vowing to become simpler, unified, and more usable.
In the recent chain abstraction thesis, Illia Polosukhin, NEAR Protocol co-founder and NEAR Foundation CEO, hinted at the idea of “account aggregation:”
From a user perspective, this should be a single account where they interact with apps on different chains, and assets either get bridged or swapped automatically. I call this “account aggregation” […].
Account aggregation is the ability to sign transactions on any given chain from a single (NEAR) account, through a single interface, in a single transaction. In it lies the idea of chain abstraction: instead of having to separately manage accounts for multiple chains, often requiring a different wallet interface (e.g. Metmask for EVM, Keplr for Comos chains, Phantom for Solana), and going through several hurdles to send assets from one chain to another, the entire experience is boiled down to a single layer and a single transaction for the end user.
The technology enabling this is Chain Signatures, a novel threshold signature protocol utilizing an MPC (multi-party computation) signer network on NEAR. With Chain Signatures live on testnet, let us look at the technology and its potential for cross-chain development.
Challenges in Cross-Chain Interoperability
Recent peaks in bridge volumes testify to the growing demand for cross-chain transactions.
However, cross-chain bridging is not without its challenges. First and foremost, bridges have been proven time and again to be vulnerable to hacks. Bridges inherently have a large attack surface.
Secondly, bridges today lack comprehensive chain support. Many bridges or messaging protocols lack support for non-EVM chains, not to mention non-smart contract chains like Bitcoin, Doge, or Ripple. While bridges can cover a lot of space, they are limited from achieving 100% interoperability.
Finally, bridge UX is inconsistent and cumbersome. Not only is every bridge designed differently — which means a learning curve for each one — but each bridge operates at a different speed. An additional UX hurdle comes when you try to bridge, only to learn that you need to acquire another token separately to pay for gas, for which you normally need to use a centralized exchange. A further challenge is that bridged assets are often a “wrapped” version of an asset, which is different from its native version on the origination chain, and may not even be the version the user needs for their intended action. After bridging, the user may end up with an unsupported token or a token with low liquidity.
Solving Cross-Chain Challenges with Programmable MPCs
Fortunately, there is a new design pattern for cross-chain messaging that can alleviate the challenges of bridging. Enter programmable MPCs.
MPC, or multi-party computation, is a privacy-preserving coordination protocol in cryptography where multiple parties can perform a computation together without revealing the data to each other. Many of us are familiar with the concept from MPC wallets such as the Coinbase Wallet or Fireblocks, where the private key of the user’s wallet is shared among multiple parties to eliminate a single point of failure. In this approach, the user retains a key, while centralized parties retain the other keys.
Programmable MPCs allow developers to tap into this and also decentralize key sharing. Core advantages include:
- Comprehensive coverage: programmable MPCs can support any chain including non-smart contract chains such as Bitcoin, Doge, or Ripple
- Instant support: as long as the MPC provider supports the elliptic curve for the chain in question, chain support is instantaneous and does not require separate integration efforts (as is the case for bridges)
e.g. ECDSA-based chains: EVM, Bitcoin, many Cosmos chains, etc; EdDSA-based chains: NEAR, Solana, Cardano
- Standardized DevX and UX: For devs, it’s just a simple API to utilize. For users, it means the same transaction speed across all chains in cross-chain swaps and even no gas token required, depending on the implementation (see Multichain Gas Relayer below). This marks the true potential for chain abstraction, where users do not have to know which chain they are on.
Chain Signatures: NEAR’s Approach to Programmable MPCs
Today, there are mainly two approaches to programmable MPCs. One is deposit-based and the other account-based. Deposit-based MPC networks maintain deposit addresses to create a canonical bridged asset. This is the case of Dfinity $ETH or Zetachain $BTC; Thorchain, where users deposit to a specific address to enact swaps with another user; or Axelar, where, as a generalized bridge protocol, it maintains the deposit address for the user without the user having direct access to it.
The efforts of NEAR and Lit Protocol fall under the category of account-based programmable MPCs. On NEAR, such an account-based approach to programmable MPCs is called Chain Signatures: threshold signatures controlled by NEAR accounts and smart contracts and signed by MPC nodes on the NEAR network.
At a high level, the mechanism of Chain Signatures is as follows:
- An account on NEAR, which can also be a smart contract, requests validators (i.e. MPC nodes) to sign an arbitrary payload (e.g. a transaction on Bitcoin or Optimism)
- Validators sign the payload via MPC and relay it to the destination chain
- This entire process is abstracted away for the user: as a user, you are simply signing a transaction on a NEAR account and getting the amount on the destination chain (e.g. Bitcoin, Optimism, etc).
One of the biggest advantages of the NEAR account model is that it allows end users to hold any number of sub-accounts under a single top-level account. This means that with Chain Signatures, users can control 10s of 1000s of accounts across different chains from a single NEAR account. This is what we mean by “account aggregation.”
For devs, Chain Signatures is a simple API that looks something like this:
- Function call to sign payload
- Key derivation path: because a single NEAR account can have an almost infinite number of accounts it can sign for on any given chain, this designates which account is being signed for
- Key type: designates the elliptic curve of the chain in use (at launch, Chain Signatures will first support ECDSA, then later, EdDSA).
In the following example, Proximity Labs’ Matt Lockyer demonstrates Chain Signatures by sending $ETH between two accounts on the Ethereum Sepolia network using a single NEAR account, on a single interface, and in a single transaction.
Here, the Ethereum address (from which your $ETH will be sent) is generated from a path variable, akin to an HD path on a Ledger account. This address is an offset of your NEAR account that is uniquely generated for this purpose.
When you sign the transaction, the MPC contract generates a signature for this particular Ethereum transaction without revealing the private key to any party.
The example above is open-source for anyone who wants to check it out.
Multichain Gas Relayer
An additional protocol that can help maximize the potential of account aggregation is the multichain gas relayer, which realizes gas abstraction.
Let us visualize this flow with an actual implementation of chain signatures by Sweat Wallet to enable users to send $BNB from NEAR to BNB Smart Chain from the Sweat Wallet (a NEAR account).
- The user initiates a signature from the Sweat Wallet (= NEAR account) to send 0.02 $BNB on NEAR to an address on BNB Smart Chain.
- The MPC nodes sign the payload and send it to the relayer network.
- The gas relayer picks up the transaction; the user pays for gas in $SWEAT on the NEAR network.
- The gas relayer takes the payment and funds the destination address on BNB with the appropriate gas tokens (in this case, $BNB). The relayer network then routes the signed transaction. All of this happens in the same block (2–3 seconds).
- The user has successfully sent 0.02 $BNB to their BNB address from their NEAR account.
When used in combination with Chain Signatures, the multichain gas relayer prevents apps and users from having to deal with multiple gas tokens on multiple chains. Behind the scenes, the gas relayer handles the gas payment on the respective chains — the user only needs to use one token for gas.
Check out the demo by Sweat Wallet. The transaction hash is here.
Use Cases
The examples above illustrate Chain Signatures use cases in which a single NEAR account signs a cross-chain transaction. A whole new design space for cross-chain dApps emerges when we consider that a NEAR account is natively a smart contract.
Here are a few:
- DeFi on Non-Smart Contract Chains: Chain Signatures can enable DeFi on non-smart contract chains such as Bitcoin, Doge, or Ripple, which thus far only supports transfers on the network. NEAR smart contracts can act as escrow contracts and manage who controls what. On top of this primitive, you can build swaps or lending protocols, for instance, that support any asset on any chain, including assets in unique states (e.g. staked, in liquidity pools). Imagine swapping your staked $TIA for an NFT on Solana or using it as collateral to borrow $ETH on Optimism.
- Multichain account abstraction (with support for gas relayer): Because NEAR accounts are natively smart contracts, there is a lot of flexibility out of the box: any NEAR account can have any number of keys, rotate keys for security, and have multi-signer patterns. Additionally, with the Multichain Gas Relayer, you can even abstract the complexity of multiple gas tokens for different chains. With Chain Signatures, one can essentially “NEAR-ify” any account on any chain by extension, thereby bringing about account abstraction on a multichain scale, from Ethereum to Solana to Bitcoin.
- Bridgeless Cross-chain DeFi: As seen in the overview above, one of the most powerful things about Chain Signatures is that they eliminate the need for bridging and instead power cross-chain transactions via an MPC signature protocol. We can imagine net new DeFi products such as,
- Native cross-chain swaps (e.g. swap $XRP on Ripple for an NFT on Solana)
- Cross-chain lending orderbook (e.g. use X on Optimism as collateral to borrow Y on Arbitrum)
- Restake any asset on any chain; even handle the reward or slashing conditions from NEAR
- Trustless Bitcoin Ordinals Marketplace
Additionally, smart contract-based Chain Signatures would open up the possibility of privacy-focused apps as well as trustless multichain deployments.
Case Study: Bitcoin Ordinals Marketplace
Let us take one of the use cases and understand how it would work: a trustless Bitcoin Ordinals marketplace. Currently, one implementation of this idea is underway by the EastBlue team.
In this scenario, we are dealing with a trade between a seller whose asset (Ordinal) is on Bitcoin and a buyer whose asset ($USDC) is on NEAR; but this can be generalized to any asset on any chain.
- The marketplace contract exists on NEAR.
- The seller generates a deposit account on Bitcoin via the marketplace contract.
- Only the marketplace contract can request the MPC signers to sign a transaction on behalf of this Bitcoin account.
- Within the smart contract state, the seller is recognized as the owner of this Bitcoin account and only they are allowed to deposit and withdraw the Ordinal out of that account.
- The seller deposits the Ordinal to the Bitcoin account and creates a listing for 10 $USDC.
- To protect the buyer, the contract disallows the seller from withdrawing the Ordinal if there is an open order to their listing. No changes on the Bitcoin network will affect the account, only the marketplace contract and allow withdrawals.
- The buyer deposits $USDC to the marketplace contract.
- The buyer accepts the 10 $USDC listing.
- The sale is executed. In other words, the marketplace contract has verified that two users have agreed to swap their accounts and atomically executes the swap in a single block (2–3 seconds).
- The seller now has control over the 10 $USDC deposited by the buyer and withdraws the funds. In turn, the buyer is now the owner of the Bitcoin account holding the Ordinal and can withdraw.
Conclusion
Chain Signatures is currently on testnet and awaiting mainnet release before the end of Q1. In combination with the flexible NEAR account model and the Multichain Gas Relayer, Chain Signatures have great potential to bring cross-chain interoperability to the next level. Furthermore, Chain Signatures have the potential to drive chain abstraction, where the complexity and fragmentation of today’s Web3 are abstracted away with a single user layer that can interact with any asset on any chain.
If you are a developer, now is the perfect time to get acquainted with the concept and explore this technology for your cross-chain dApp. If you are building, do not hesitate to reach out to us via hello@proximity.dev or on the Chain Abstraction Dev Chat. We are more than happy to provide technical assistance, strategic advice on product and business development, as well as GTM support.
The content of this article is based on Kendall Cole’s keynote at ETH Denver and recreated by Rim Berjack. Find the full talk here.
Chain Signatures Resources
Find all the resources below and more in this Chain Signatures Linktree.
- Chain Abstraction Thesis
- Account Aggregation Deep Dive
- Chain Signatures Overview: Cross-Chain without Bridges (Video)
- Chain Signatures Docs
- NEAR Account Model Docs
- Chain Signatures API
- Generate MPC Private Keys for NEAR
- Github Discussions
- Sample Request and Response
- Multichain Gas Relayer
- (Example) Send ETH on Ethereum from a NEAR account: Demo video; Open-source component
- (Example) Sign a transaction on BNB from a NEAR wallet: Demo video; Transaction hash
- Official Chain Abstraction Dev Chat
Further Reading
Disclosures: Proximity Labs holds $NEAR and other tokens or investments that may be associated with protocols or projects mentioned in this article. The authors of this article have not purchased or sold any token for which the authors had material non-public information while researching or drafting this report. The statements and content in this article should not be misconstrued as a recommendation to purchase or sell any token, or to use any protocol. This article also contains forward-looking statements about third-party projects that the authors have no control over and, as such, actual future developments may be substantially different from the expectations described in the forward-looking statements for a number of reasons, including those that are not under the control of the authors. The content of this article reflects the opinions of its authors and is presented for informational purposes only. This is not and should not be construed to be investment advice.
