NEAR Intents as a Dev Primitive: Routing, Signing, and Execution Without UX Friction

Intents make it super easy to turn “what the user wants” into cross-chain settlements in just seconds. They do this using standardized routing, flexible signing, and atomic execution on NEAR--without putting the burden of managing chains, gas, or wallets on users. In this post, we’ll break down the latest key components (like solvers, signatures, and bridges) into tangible patterns you can implement right away. (docs.near.org)

Why Intents, Why Now

• NEAR’s “AI-native transaction layer” simplifies the multi-chain experience into just one signed outcome: Express → Solve → Settle. Basically, users or agents sign a single payload, a solver network takes care of finding the best execution, and then NEAR wraps everything up by finalizing and co-signing all the necessary transactions across chains. You can dive into the details here.
• What really makes the user experience shine is performance: since May 13, 2025, NEAR has delivered blocks in about ~600 ms with a finality time of roughly ~1.2 seconds. This speed is super important, especially when an intent branches out into various on- and off-chain steps. Check out more on this here.
• With Chain Signatures, a NEAR account (or even a smart contract) can now sign transactions on Bitcoin, Ethereum, Cosmos, and XRP--and since April 2025, it also covers EdDSA chains like Solana and TON. This means transactions can breeze through without getting stuck at chain borders. For more information, take a look here.

The takeaway for product leaders is simple: you just need to send “swap X→Y” or “pay invoice Z,” and the protocol takes care of all the heavy lifting like routes, signatures, and atomicity. Forget about those pesky chain selectors, gas prompts, and bridge UIs. Check it out here: (docs.near.org)

---

The Three Primitives: Route, Sign, Execute

1) Route with a solver bus (quote → publish → status)

NEAR Intents offers a Message Bus that:

• sends out user requests to all connected solvers,
• collects quotes for as long as 3000 ms,
• checks AML compliance in the distribution channels,
• and monitors settlement status from start to finish. (docs.near-intents.org)

Key Endpoints and Fields

• quote (JSON-RPC): Here you can find defuse_asset_identifier_in/out, exact_amount_in or exact_amount_out, and min_deadline_ms (which basically sets your offer's time-to-live). Once you get your quote, the quote_hash is what ties everything together for the execution. Check out more details here.
• publish_intent: This is where you attach your quote_hashes along with signed_data using NEP-413, ERC-191, or raw_ed25519. In return, you'll get an intent_hash. For a deeper dive, visit the documentation here.
• get_status: You can track the status as it moves through various stages: it could be PENDING, then shift to TX_BROADCASTED, and finally settle as SETTLED. If it’s not valid, it’ll show as NOT_FOUND_OR_NOT_VALID. Learn more about this process here.

For seamless turnkey distribution, 1Click offers REST and SDKs (in TS, Go, and Rust) that come with deposit addresses, lifecycle statuses, and an optional JWT to help minimize fees. It's super handy if you want to integrate “Swap in one click” without having to dive into the raw solver bus. Check it out here: (docs.near-intents.org)

Compliance is a key part of the process: all 1Click quote requests go through a screening process (think TRM, Binance AML, and AMLBot/PureFi). Any high-risk transactions are blocked before they can be executed. Check out more details here.

2) Sign once (wallets you already support)

Intents make it super easy to standardize off-chain signatures, so you can keep your current authentication process running smoothly:

• For NEAR wallets, we use NEP-413 (it involves a base58-prefixed key/signature and a base64 nonce). You can check it out here.
• If you’re working with EVM wallets, you’ll want to go with ERC-191 (it employs secp256k1, and you can recover the public key from the signature). More details can be found here.
• For Solana-style wallets (like Phantom), we use raw Ed25519. Get the scoop here.

Verifier Encoding Rules (What Your Backend Needs to Check)

• Curves: Make sure to support Ed25519 (32/64 bytes), Secp256k1 (for uncompressed 64-byte pubkeys and 65-byte r||s||v), and P256 (uncompressed). Just a heads up: steer clear of DER encoded keys and compressed ECDSA keys. Check out the full details here.

FastAuth, along with passkeys (which is backed by NEAR’s MPC and has that handy email recovery feature), makes it super easy to bring non-crypto users on board while still allowing you to generate NEP-413 signatures. This setup is perfect for a smooth user experience since you don't have to deal with seed phrases. NEAR is also working on making FastAuth even more decentralized with a new multi-team roadmap (check out the FastAuth 2.0 RFP), and it's already powering over 800,000 users in real-world applications. You can read more about it here.

3) Execute atomically on NEAR

All the real action happens in the Verifier contract through the execute_intents(intents[]) function. You can combine several intents--like swapping and then withdrawing--and NEAR takes care of them all at once from the escrowed balances. Just a heads up: NEAR operates asynchronously, so calls that get kicked off during execution might finish in a different order. But don’t worry, the contract keeps everything in the right sequence for the intents you provided. (docs.near-intents.org)

Common Intent Types You'll Use First:

• token_diff: “I’ll give -X to receive +Y.” This is the backbone of swaps and multi-leg nets.
• transfer: Just moving balances around between Intents accounts (think fees and referrals).
• ft_withdraw: Withdraw to an external chain address (the bridge takes care of the egress for you).
• add_public_key / remove_public_key: Manage the signers who are allowed for an Intents account. (docs.near-intents.org)

---

Settlement and Bridges: What Actually Moves the Coins

Intents uses locked funds in NEAR for atomic settlement. It then takes advantage of bridges to transfer assets between the origin and destination chains:

• Omni Bridge (primary): This one’s a hybrid design that uses Chain Signatures along with light clients or Wormhole, depending on which chain you're on. Right now, it works with Ethereum, Bitcoin, Solana, Base, BNB, and Arbitrum. You'll find that settling from NEAR to other chains takes about 30 seconds on average (thanks to those MPC signatures). Just a heads-up, the inbound finality can differ by chain--like Ethereum's is around 960 seconds, Base is about 1026 seconds, and Arbitrum clocks in at roughly 1066 seconds. Check out more details in the docs.
• PoA Bridge: This is an alternative option that works with JSON-RPC. It helps you keep tabs on supported tokens, deposit addresses, and the status of your deposits and withdrawals. It's especially handy for any assets that haven’t made it onto Omni yet. You can dive into the specifics in the docs.

Chain Signatures are like the secret sauce: they create a decentralized MPC network that's backed by NEAR/EigenLayer restakers. This setup co-signs transactions targeted at different chains so that a NEAR contract can kick off smooth operations on Bitcoin, EVM, Solana, and TON. And guess what? With EdDSA support coming on April 30, 2025, we’ll be able to natively sign for Solana, TON, Stellar, Sui, and Aptos. Check it out here: (pages.near.org).

---

Practical Build Patterns (copy‑paste friendly)

Pattern A: Best‑price cross‑chain swap in one user action

1. Get a quote using the solver bus (or 1Click). Make sure to set the min_deadline_ms so that the solvers can give you a more competitive price.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "quote",
  "params": [{
    "defuse_asset_identifier_in": "nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near", // USDC (Arbitrum) mirrored on NEAR
    "defuse_asset_identifier_out": "nep141:sol-<token-id>.omft.near", // SOL-mirrored token on NEAR
    "exact_amount_in": "100000000", // 100 USDC (6 decimals)
    "min_deadline_ms": 30000
  }]
}

The UI gets a bunch of quotes (with details like quote_hash, amount_out, and expiration_time). It should display the best price along with the estimated time of arrival (ETA) and a breakdown of the fees. Check out the details here: docs.near-intents.org.

1. The user signs a single NEP‑413 payload along with the token_diff (and maybe a referral transfer if they feel like it). Then, they publish it using quote_hashes:

{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "publish_intent",
  "params": [{
    "quote_hashes": ["<best-quote-hash>"],
    "signed_data": {
      "standard": "nep413",
      "payload": {
        "recipient": "intents.near",
        "nonce": "base64-unique",
        "message": "{\"signer_id\":\"alice.near\",\"deadline\":\"2025-12-01T12:00:00Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:arb-...usdc.omft.near\":\"-100000000\",\"nep141:sol-...omft.near\":\"<minOut>\"}}]}"
      },
      "public_key": "ed25519:...",
      "signature": "ed25519:..."
    }
  }]
}

1. Withdraw to your destination chain (you can do this inline or through a second intent if you prefer):

{
  "intent": "ft_withdraw",
  "token": "sol-...omft.near",
  "receiver_id": "F84x...h7Y (Solana address)",
  "amount": "<received-amount>"
}

Keep an eye on the status until it says SETTLED. Once available, show the NEAR transaction hash and the link to the transaction on the destination chain. Check it out here: (docs.near-intents.org)

Why this Wins:

• It’s all about simplicity! With just one signature, you don't have to deal with annoying gas popups, and atomic settlement on NEAR keeps things running smoothly. Fast finality means you can breeze through many routes in just seconds. Check it out here: (pages.near.org).
• Thanks to Chain Signatures, the protocol takes care of co-signing and submitting the Solana leg for you--no need to switch wallets! You can find more details here: (pages.near.org).

Pattern B: OTC stablecoin P2P netting (zero price impact)

Two parties post offsetting token_diff intents and carry out the execution at the same time:

[
  {
    "standard": "nep413",
    "payload": {
      "message": "{\"signer_id\":\"maker.near\",\"deadline\":\"2025-12-01T12:00:00Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"-1000000000\",\"nep141:usdt.near\":\"1000000000\"}}]}",
      "nonce": "...",
      "recipient": "intents.near"
    },
    "public_key": "ed25519:...",
    "signature": "ed25519:..."
  },
  {
    "standard": "nep413",
    "payload": {
      "message": "{\"signer_id\":\"taker.near\",\"deadline\":\"2025-12-01T12:00:00Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"1000000000\",\"nep141:usdt.near\":\"-1000000000\"}}]}",
      "nonce": "...",
      "recipient": "intents.near"
    },
    "public_key": "ed25519:...",
    "signature": "ed25519:..."
  }
]

The Verifier settles balances in a single transaction, so neither party has to worry about counterparty or fill risk. Check out more details here.

Pattern C: One‑click checkout via 1Click API (no wallet UX)

For those who prefer a Web2-style checkout or custodial flows, just go with 1Click:

1. Hit us up for a quote and the deposit address (using JWT means you skip that extra fee):

POST https://1click.chaindefuser.com/v0/quote
Content-Type: application/json
Authorization: Bearer <JWT>

{
  "dry": false,
  "swapType": "EXACT_INPUT",
  "slippageTolerance": 100,             // 1%
  "originAsset": "btc:<chain-id>...",   // user pays in BTC
  "destinationAsset": "nep141:usdc.near",
  "amount": "100000",                   // sats or smallest unit
  "depositType": "ORIGIN_CHAIN",
  "recipientType": "DESTINATION_CHAIN",
  "recipient": "0x...",                 // or chain address
  "refundType": "ORIGIN_CHAIN",
  "refundTo": "bc1q...",
  "deadline": "2025-12-01T12:45:00Z"
}

1. First, display the deposit address along with the estimated time of arrival (ETA). If you want, you can send a POST request to /v0/deposit/submit with the transaction hash. Then, keep checking the status by polling /v0/status until you get a result of either SUCCESS or REFUNDED. For more details, check out the documentation: docs.near-intents.org.

---

Signing Deep‑Dive: Keys, Curves, and Account Abstraction

• Intent accounts pinpoint users by their NEAR AccountId, either named or implicit. You can hook up multiple public keys (with full control) through on-chain transactions or intents. Just make sure to keep this mapping updated; if a wallet swaps keys, don’t forget to rotate them too. (docs.near-intents.org)
• Stick to the Verifier’s raw encoding: use uncompressed ECDSA public keys and stick to concatenated signatures (let's skip DER here). A lot of libraries default to using compressed/DER, so be sure to configure yours explicitly. (docs.near-intents.org)
• Check out multi-payload signatures! They allow the same app to work with NEP-413, ERC-191, and raw Ed25519 without needing to write separate code paths for each wallet type. Pretty handy, right? (docs.near-intents.org)
• If you're looking for a simple way to authenticate on your backend (like controlling access to price-impacting flows), there are NEP-413 verification libraries out there. Just keep in mind that you’ll need Full Access Keys to stay aligned with the spec guidance. (socket.dev)

Passkeys and FastAuth are making life a whole lot easier for newbies and AI agents. With passwordless, recoverable accounts, you can sign NEP‑413 without giving up control of your assets. Plus, the ecosystem is working hard to decentralize infrastructure through open RFPs. Check it out here: (pages.near.org)

---

Execution Deep‑Dive: Atomicity, Bridges, and Time

• Atomicity: When execute_intents runs, it processes your list in the order you set and finalizes balances all within the same NEAR transaction. Just a heads up, though: any async calls that pop up might get resolved out of order, so it's a good idea to design your off-chain orchestrations to be idempotent. You can read more about it here.
• Fees: The protocol hits you with a tiny fee of 0.0001% (that’s just 1 pip) on every transfer or swap. If you choose to use the interface at near-intents.org, there’s an extra 0.2% fee. On the flip side, 1Click has a lower 0.1% fee, but only if you don’t use an API key (it’s zero if you have a JWT). You can even add your own app fee through appFees. More details can be found here.
• Bridge times: When you're planning your user experience, keep in mind there's some asymmetry here. Transferring from NEAR to other chains is pretty quick--around 30 seconds, thanks to MPC. However, bringing assets in can vary based on how quickly the source chain finalizes (check out the current timings for more info). It’s a smart idea to show users reliable estimated times and refresh quotes if they're getting close to a deadline. Dive deeper here.
• Message format: The Omni Bridge relies on Borsh-encoded payloads. These are signed by the MPC and then verified on the destination chains using native signature precompiles, making it a cleaner solution compared to the sometimes clunky optimistic challenge periods. For more insights, click here.

---

Emerging Best Practices (what’s working in production)

Routing

• Get several quotes by using min_deadline_ms to find a balance between price and certainty. If any quotes are close to expiring, just reject them and automatically ask for new ones. (docs.near-intents.org)
• Maintain a steady WebSocket connection to the solver bus. If you get disconnected, ease back on retries, and make sure to link it back to the quote_id. (docs.near-intents.org)

Signing

• When it comes to signing, we recommend using NEP‑413 for NEAR wallets, ERC‑191 for EVM, and raw_ed25519 for Solana. It’s key to standardize everything to the Verifier’s raw formats and to steer clear of compressed keys or DER signatures. You can find more details here.
• Managing your Intents account keys is crucial. Start with the add_public_key action the first time you connect. Remember to rotate keys whenever wallets are rotated and make sure to get rid of any outdated keys to keep your attack surface smaller. More info on this can be found here.

Execution

• Get your intents together: bundle up token_diff, ft_withdraw, and transfer (that’s for app/referral fees) into one smooth package--just one signature and one settlement. Check out the details here: docs.near-intents.org.
• Make sure to show the status changes in the UI, like PENDING, TX_BROADCASTED, and SETTLED. If things take too long, let it time out nicely and give users an easy one-tap retry option. More info can be found here: docs.near-intents.org.

Bridging

• Go for Omni whenever you can; if it's not an option for certain assets, then switch to PoA. Check out supported_tokens before showing any choices. (docs.near.org)
• Just a heads-up for users about CEX deposit addresses; some exchanges might not credit bridge deposits on a per-user basis--so it's best to start with small test amounts. (docs.near-intents.org)

Compliance & Risk

• You can either use 1Click’s built-in screening or set things up yourself with the same vendors like TRM or AMLBot/PureFi if you’re managing your own distribution. Check it out here.
• Keep an eye on official audits and bug bounties; make sure to route any disclosures through the program that’s already been published. More details can be found here.

Performance & UX

• Take advantage of NEAR's quick 1.2-second finality to simplify those multi-step processes into a super smooth experience. You can show a "Done" status once it’s SETTLED, and if the external transaction hash is still MIA, just add a little badge that says “receiving chain pending.” Check out more about it here: (pages.near.org).

---

What’s New and What’s Next

• On April 30, 2025, EdDSA was added to Chain Signatures, bringing native signing for Solana/TON and a few other improvements. This change really helps eliminate a common last-mile hiccup for multichain intents. Check it out here: (pages.near.org)
• The team has been busy optimizing the throughput and latency of Chain Signatures throughout 2025. The latest roadmap updates hint at some big improvements aimed at boosting solver volume and supporting even more chains. You can read more about it here: (pages.near.org)
• Omni Bridge is making a shift from a hybrid model to full Chain Signatures verification. The plan is to gradually cut down on dependencies related to Wormhole. Details can be found here: (docs.near.org)

---

Implementation Checklist (enterprise‑ready)

• Business Logic
  • Set up which origin and destination assets are allowed, along with their minimum and maximum sizes. Make sure to check these against supported tokens in real-time. (docs.near-intents.org)
  • Don’t forget to outline your fee structure: this includes protocol fees, distribution fees, and app fees through appFees. (docs.near-intents.org)
• Integration
  • If you need speed, go for the 1Click option; if not, you can integrate quote, publish, and status directly. (docs.near-intents.org)
  • Make sure to align wallet signatures with NEP‑413, ERC‑191, or raw_ed25519. It’s a good idea to unit test those curve and encoding rules too. (docs.near-intents.org)
• Security & Compliance
  • Register and rotate your Intents keys regularly; keep an eye on AML responses and block any deposits coming from flagged sources. (docs.near-intents.org)
  • Stay updated on the bug bounty and audit discussions; pin the bridge versions and chainlists for extra safety. (docs.near-intents.org)
• Observability
  • Link up quote_hash, intent_hash, NEAR transaction hash, and destination transaction; create a “Details” drawer where all these IDs are easily accessible. (docs.near-intents.org)

---

How 7Block Labs Can Help

We've rolled out intent-driven flows from start to finish--from quoting to multi-curve signing and atomic settlement--spanning across different wallets and chains. Here’s what you can typically expect:

• 2-3 weeks: We’ll dive into discovery, set up the asset policy, integrate KYC/AML, and run the 1Click pilot in staging.
• 3-6 weeks: Next up, we’ll work on direct solver bus integration, roll out custom fee logic, explore OTC P2P patterns, and develop observability dashboards.
• Ongoing: We’re continuously working on bridge expansions (Omni/PoA), getting Chain Signatures onboarded for new chains, and automating key rotation.

If you want your users to experience “route, sign, execute” as if it’s just one seamless click, we’re here to make it production-ready.

---

Appendix: Reference Snippets

Supported Signature Object (NEP-413):

The Supported Signature Object, defined in NEP-413, is all about making signatures more dynamic and flexible for users. Here’s a quick breakdown of what it covers:

Overview

This proposal introduces a way to support multiple signature algorithms and formats in a single object. The goal is to enhance how we handle signatures, ensuring compatibility and easier integration with various platforms.

Key Features

• Multiple Signature Formats: You can have different signature types bundled together, so it’s easier to work with diverse ecosystems.
• Extensibility: Future enhancements can be added without breaking existing functionality. This means you can keep evolving without a complete overhaul.
• Improved Security: By supporting various algorithms, the proposal aims to bolster security measures, allowing for more robust verification processes.

Benefits

• Interoperability: Developers can create solutions that work seamlessly across different systems and platforms.
• User Control: Users get to choose their preferred signature methods, catering to their specific needs and preferences.
• Simplified Development: Developers save time and effort by using a unified interface to handle multiple signature formats.

Conclusion

The Supported Signature Object (NEP-413) is a step forward in making signature handling more versatile and user-friendly. By embracing a range of algorithms and formats, we’re paving the way for better security and smoother integrations across different platforms.

{
  "standard": "nep413",
  "payload": {
    "message": "{\"signer_id\":\"alice.near\",\"deadline\":\"2025-12-01T12:00:00Z\",\"intents\":[{\"intent\":\"transfer\",\"receiver_id\":\"merchant.near\",\"tokens\":{\"nep141:usdc.near\":\"100000000\"}}]}",
    "nonce": "base64...",
    "recipient": "intents.near"
  },
  "public_key": "ed25519:...",
  "signature": "ed25519:..."
}

EVM Wallet (ERC‑191) Variant:

The EVM wallet is built on the ERC‑191 standard, which brings some exciting features to the table. Here’s a quick breakdown:

• Compatibility: This wallet works seamlessly with all ERC-20 tokens, making it super easy to manage your assets.
• User-Friendly Interface: Navigating through the wallet is a breeze, even for those who might be new to the crypto scene.
• Security Features: Your assets are protected with state-of-the-art security protocols, ensuring that your funds stay safe and sound.
• Customizable: You can tailor the wallet to suit your needs, whether it’s organizing tokens or adjusting settings.

If you're looking to dive into the world of crypto with an efficient and reliable tool, the EVM wallet (ERC‑191) variant might just be the perfect fit!

{
  "standard": "erc191",
  "payload": "{\"signer_id\":\"0xCcAa...\",\"verifying_contract\":\"intents.near\",\"deadline\":\"2025-12-01T12:00:00Z\",\"nonce\":\"base64...\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"-100000000\",\"nep141:usdt.near\":\"99800000\"}}]}",
  "signature": "secp256k1:base58..."
}

Both verify according to the same Verifier rules, which means you'll want to keep those public keys uncompressed and the signatures in a non-DER format. For more details, check out the documentation here.

---

When you treat NEAR Intents like a key building block--using the solver bus or 1Click for routing, signing with the wallets you already have, and executing everything seamlessly on NEAR--you really cut down on the user experience bumps that hold back multi-chain products from growing. Thanks to the protocol's latest improvements in speed, signature coverage, and bridge capabilities, you can get started right away. Check it out here: (pages.near.org)