Investigating Mina <> NEAR Intents #1589
Description
Twitter posts:
- https://x.com/dwillems42/status/1985314606655393985
- https://x.com/dwillems42/status/1984183067830108237?t=PMzKEhv4rrpN2cEydsVl8Q&s=19
Introduction
NEAR Intents are based on Chain Signatures.
NEAR Intents is a multichain transaction protocol where users specify what they want and let third parties compete to provide the best solution. This works for everything from token swaps to pizza delivery, creating a universal marketplace across crypto and traditional services.
NEAR intents explorer with metrics like trading volumes per instruments: https://explorer.near-intents.org/. It gives a good overview on the actual volume and the service traction.
The volume can also be found on Dune: https://dune.com/near/near-intents.
The company developing NEAR Intents is Defuse Labs.
Defuse Labs develops NEAR Intents to enable seamless cross-chain interactions in an automated world — connecting AI, services, and financial applications.
How Mina could benefit from integrating NEAR Intents
Integrating the Mina Protocol into this kind of intent-framework could bring several tangible advantages:
- Seamless cross-chain access: Mina could expose its native assets or smart-contract capabilities to the intent-network.
- Broader liquidity & usage: By being part of a system where solvers competently route across chains, Mina might tap into ecosystem liquidity and usage flows it might not otherwise reach - helping its assets or services become more interoperable.
- Improved UX for Mina-centric flows: For users of Mina apps, using an “intent” model means less friction (wallet/bridge complexity, chain-choice decisions). Integrating intent support could enhance user experience and lower barriers to entry.
Potential issues
Mina does not support natively ECDSA over secp256k1 or ED25519. The signature algorithm is based on Schnorr signatures over the Pasta curves (see the specification with different implementations). In particular, it does use a specific instance of Poseidon for the challenge.
Resources
- https://www.near.org/blog/unpacking-near-intents-a-deep-dive
- Chain Signatures
- MPC node implementation.
- Omni bridge
- NEAR Intents repository: seems to be the active codebase.
Notes on the NEAR Intents documentation
Some links seem to be outdated on https://docs.near.org/chain-abstraction/chain-signatures/implementation#2-creating-the-transaction.
- The Omnibridge library seems to be located at https://github.com/Near-One/omni-bridge.
- The MPC codebase is located at https://github.com/near/mpc, and contains the MPC contract located here.
Requirements for chain signatures
- The Mina chain must support ECDSA with ed25519 or secp256k1. By "supporting", we mean that the chain must be able to verify signatures.
- Ad cross-chain signatures require to generate a new address from a seed (see https://docs.near.org/chain-abstraction/chain-signatures/implementation#1-deriving-the-foreign-address), we must have an implementation to generate addresses, like Implement BIP39 proof-systems#3363
- It must be possible to verify Mina transactions in a NEAR contract. For that, the contract must implementation the Poseidon instance used by Mina and should implement the verification algorithm of the specific instance of the Schnorr signature scheme used by Mina payments.
Appendix: Zcash integration with NEAR Intents
Disclaimer: can be wrong - will be updated over time if necessary.
Overview
This appendix examines how Zcash successfully integrates with NEAR Intents despite using the Pasta curves (Pallas/Vesta) for its shielded protocol, and why Mina Protocol faces different technical challenges despite using the same curve family.
Note (20251103): it seems that the NEAR team is working on adding shielded address support, see here, here, here.
Zcash architecture: dual-address system
Zcash employs a dual-address architecture that enables seamless integration with NEAR Intents:
- Transparent addresses (T-addresses)
- Signature algorithm: ECDSA
- Curve: secp256k1
- Properties: Public, fully traceable transactions
- NEAR chain signatures support: native support (secp256k1 and ECDSA are fully supported)
- Shielded addresses (Z-addresses)
-
Signature algorithm:
- Sapling: RedJubjub (RedDSA on Jubjub curve)
- Orchard: RedPallas (RedDSA on Pallas curve)
-
Curves:
- Sapling: Jubjub
- Orchard: Pallas
-
Properties: private
-
NEAR chain signatures support: not natively supported
How Zcash integration actually works
It seems that it works as follow:
┌─────────────────────────────────────────────────────────────┐
│ User's Shielded ZEC (Orchard Pool) │
│ Using: RedPallas signatures on Pallas curve │
└──────────────────────┬──────────────────────────────────────┘
│
│ Step 1: Unshield to T-address
▼
┌─────────────────────────────────────────────────────────────┐
│ Temporary Transparent Address (T-address) │
│ Using: ECDSA signatures on secp256k1 │
│ ✅ Compatible with NEAR Chain Signatures │
└──────────────────────┬──────────────────────────────────────┘
│
│ Step 2: NEAR Intents processes swap
│ (All signatures use secp256k1)
▼
┌─────────────────────────────────────────────────────────────┐
│ NEAR Intents Smart Contract (intents.near) │
│ Verifies: ECDSA/secp256k1 signatures ✅ │
│ Action: Cross-chain atomic swap │
└──────────────────────┬──────────────────────────────────────┘
│
│ Step 3: Swap completion
▼
┌─────────────────────────────────────────────────────────────┐
│ Return to Temporary T-address │
│ Using: ECDSA signatures on secp256k1 │
└──────────────────────┬──────────────────────────────────────┘
│
│ Step 4: Re-shield to user's wallet
▼
┌─────────────────────────────────────────────────────────────┐
│ User's Shielded ZEC (Orchard Pool) │
│ Privacy restored through shielded transaction │
└─────────────────────────────────────────────────────────────┘
Metadata
Metadata
Assignees
Labels
Type
Projects
Status