# Chain Signatures for Developers By [Jaswinder Singh](https://paragraph.com/@jaswinder-singh) · 2024-09-18 --- **Hola, fellow developers!** It’s been a few weeks since **Chain Signatures** went live on the [NEAR Protocol](https://near.org) mainnet, and I’m sure many of you have already been experimenting with the examples and building cool things. I’ve been super excited about this tech, testing it since the testnet launch. But recently, I’ve really started to grasp just how game-changing Chain Signatures are. I kind of knew it all along but didn’t truly appreciate it until I tried to put it into words. That’s why I’m sharing this with all of you. Hopefully, it clicks for you too. ### First Impressions At first glance, Chain Signatures seemed straightforward: there’s a signer smart contract with a `sign()` function that, when called with a path and payload, generates signatures via the MPC (Multi-Party Computation) network. My initial thought? "This is cool! I can now control Ethereum, Bitcoin, or whatever, and manage multiple accounts from my single NEAR account by tracking the unique paths I use for different chains." That was already impressive. But then I was told, **"your smart contract can do this too."** Honestly, I didn’t pay much attention to that at first. I figured, "Yeah, okay, accounts can sign stuff. Cool." But then it hit me, this feature isn’t just about accounts. The **real power** is what happens when **smart contracts** start doing the signing. That’s where the magic is. ### Why is this huge? Smart contracts being able to sign transactions directly from within their code is a huge deal, especially for cross-chain functionality. This isn’t a minor improvement—it’s a whole new paradigm. Let’s break down some key concepts first. On NEAR, when you have an account (say, Alice.near), you sign transactions using your private key. This key is stored off-chain, usually in your wallet. You sign off-chain, send the transaction to the blockchain, and the state gets updated accordingly. Simple, right? Even if you have a smart contract deployed on Alice.near, the process stays the same: you still use off-chain keys to sign transactions, and your smart contract **does not** have access to those private keys. It cannot sign transactions itself. In Ethereum, it’s even more rigid. You have either Externally Owned Accounts (EOAs) or smart contract addresses. EOAs control smart contracts, but contracts themselves can’t have private keys, whether on-chain or off-chain. ### Enter Chain Signatures This is where **Chain Signatures** change the game. With Chain Signatures, you have a **signer contract** on-chain that lets smart contracts request signatures for any payload they need. Here’s how it works: when your contract calls the `sign` function, the MPC network intercepts the request and, based on the parameters (account, path, payload), generates a signature. The signature is sent back to the signer contract, which returns it to your smart contract—all without exposing any private keys. For regular NEAR accounts as we talked in the beginning, this opens up some cool possibilities: 1. You can control an infinite number of addresses on any chain. 2. You can own assets across all these chains—Bitcoin, Ethereum, Avalanche—all controlled by a single NEAR account. But here’s where things get **really** interesting, when **smart contracts** gain access to this ability. We’re talking about contracts signing things **on-chain**, directly from within their code. That’s what Chain Signatures is all about. I often call them “on-chain signatures” to make it clearer when I explain to friends. ### An Example: USDC Bridge from NEAR to Ethereum Let’s walk through an example to really understand this. You create a DEX contract on NEAR, let’s call it **dex.near**. Now, we’re going to fund this contract with USDC from Ethereum. Yes, **Ethereum USDC** sent to a NEAR smart contract. Here’s how it works: The contract, **dex.near**, controls an Ethereum address through a specific path (say, `usdc_treasury`). This means the NEAR contract now controls assets on Ethereum. As the DEX owner, you can manage when and how USDC gets transferred out of this Ethereum address. Now, let’s say Bob (bob.near) wants to convert his NEAR USDC to Ethereum USDC. Bob sends 1,000 USDC to **dex.near** and passes along his Ethereum address, where he wants the USDC sent. Here’s what happens: 1. **dex.near** verifies the transfer of 1,000 USDC on NEAR. 2. Once confirmed, **dex.near** creates an Ethereum transaction to transfer 1,000 USDC from its treasury to Bob’s Ethereum address. 3. The smart contract then calls the Signer contract and gets this Ethereum transaction signed using the MPC network. 4. Finally, the signed transaction is relayed to Ethereum, and Bob’s Ethereum address receives the USDC. Boom. Just like that, a **smart contract on NEAR** has controlled and transferred assets on **Ethereum**. No bridge, no waiting for centralised services, no high fees, no fear of transaction being dropped in the middle, easy to trace process. Let me say that again: a NEAR smart contract, controlling an Ethereum treasury, signed the transaction on-chain, **without any access to private keys**. Huge. And it’s not just limited to Ethereum. You could use this same approach for other chains, like Bitcoin and beyond. ### What’s Next? NEAR’s Chain Signatures unlock endless possibilities. We’re talking bridges, cross-chain swaps, automated treasury management, and more—all handled by immutable smart contracts. This changes the game for anyone building in the multi-chain world. * * * ### TL;DR * Chain Signatures allow smart contracts to sign transactions directly from within the code. * This enables cross-chain control, like managing assets on Ethereum or Bitcoin from NEAR. * It opens the door to building advanced DeFi tools, cross-chain bridges, and automated treasuries—all controlled by code. Chain Signatures are the start of something **big**. Ready to build? --- *Originally published on [Jaswinder Singh](https://paragraph.com/@jaswinder-singh/chain-signatures-for-developers)*