intents docs migration

docs/2.build/1.chain-abstraction/what-is.md

@@ -41,15 +41,15 @@ With chain abstraction, both you and your users just focus on the core experienc
 
 NEAR's chain abstraction framework consists of three core technologies that work together to create seamless cross-chain experiences:
 
-1. [**Intent / Solver Layer**](#intent--solver-layer): A decentralized system where users express desired outcomes (like "swap Token A for Token B at the best price") without specifying technical details. A network of solvers then competes to fulfill these intents optimally, handling complex cross-chain operations behind the scenes.
+1. [**NEAR Intents**](#NEAR-Intents): A decentralized system where users express desired outcomes (like "swap Token A for Token B at the best price") without specifying technical details. A network of solvers then competes to fulfill these intents optimally, handling complex cross-chain operations behind the scenes.
 
 2. [**Chain Signatures**](#chain-signatures): Enables NEAR accounts, including smart contracts, to sign and execute transactions on other blockchains (like Bitcoin or Ethereum), allowing cross-chain interactions.
 
 3. [**OmniBridge**](#omnibridge): A trustless multi-chain asset bridge that combines Chain Signatures for cross-chain transaction execution with a verification layer allowing NEAR smart contracts to confirm transactions on foreign chains. This creates a fully trustless system where NEAR can both initiate and verify cross-chain operations.
 
-### Intent / Solver Layer
+### NEAR Intents
 
-The Intent / Solver Layer (aka [NEAR Intents](https://pages.near.org/blog/introducing-near-intents/)) is a new type of transaction that allows information, requests, assets, and actions to be exchanged between users, services, and AI agents.
+The [NEAR Intents](../../chain-abstraction/intents/overview.md) is a new type of transaction that allows information, requests, assets, and actions to be exchanged between users, services, and AI agents.
 
 This represents a paradigm shift in how users and AI agents interact with blockchain networks. Instead of directly executing complex transactions across multiple chains, users simply declare what they want to achieve, and the network determines how to make it happen.
 

docs/chain-abstraction/intents/faq.md

@@ -0,0 +1,47 @@
+---
+description: Frequently Asked Questions
+---
+
+# FAQs
+
+### Is there a testnet deployment?
+
+There's no `testnet` deployment and no plans for it. We recommend testing on NEAR `mainnet` with using separate dev/test NEAR accounts.
+
+### Is there support for native NEAR deposits?
+
+Only  `ft_transfer_call` can be used to deposit NEP-141 tokens from Near to `intents.near`:
+
+
+```
+<TOKEN_ACCOUNT_ID>::ft_transfer_call({
+  "receiver_id": "intents.near",
+  "amount": "1234",
+  "msg": "{\"receiver_id\": \"<ACCOUNT_ID>\"}"
+})
+```
+
+Here is an example [receipt](https://nearblocks.io/txns/EwmeXzZJStA6e5JB49vgxNYJDemqeYCFGvPH7zapP1Fw#execution#4tyaF4MnMcNQVqrg3kXzsH9277ErDeCXS9g3c2keV38G) for that.\
+Parameter `msg` can also be empty, so that funds will be deposited to `sender_id` (i.e. caller of `ft_transfer_call`). Here is an example of such [transaction](https://nearblocks.io/txns/HoWpAR8dF5azsUVaQWrBW5VsRve5X4dwr9GGiHWj3R1P#execution).
+
+### `tx_hash` in the `recent_deposit` response for all SOL deposits is empty
+
+This information is not available for Solana because the mechanism of deposit tracking works a bit differently there.
+
+### Is there a reason why my UTXOs aren't being swept on the BTC ? I sent 5,000 sats
+
+This is a very small amount that is considered to be "dust" and there is a special business logic to process such small amount.
+
+### How does the deposit process work?
+
+The deposit process begins once the transfer transaction on the foreign network has been completed.  When the balance of the user's unique deposit address has become positive our indexer generates a deposit event and assigns it a `PENDING` status.
+
+The next step is collecting the current tokens in storage. The result of this process will be either a `COMPLETED` or `FAILED` status. Deposits with a `FAILED` status are currently handled manually and eventually updated to the `COMPLETED` status.
+
+On EVM networks, deposits can bypass the `PENDING` status due to faster processing and transfer completion times.
+
+The data structure for the `PENDING` and `FAILED` statuses is identical to that of the `COMPLETED` status.
+
+Regarding BTC deposits: If you want to make a deposit to an account that hasn’t yet been connected to the application - this is possible but requires extreme caution. You can request a deposit address by calling the bridge API (`deposit_address`) and specifying the `account_id` parameter. The `account_id` can be a NEAR account, an EVM address, or a SOL address to which you have access.
+
+It is recommended starting with a small amount for experimentation. After the deposit is completed, you can connect wallet and check the tokens.

docs/chain-abstraction/intents/intents-bridge.md

@@ -0,0 +1,66 @@
+---
+id: intents-bridge
+title: Intents Bridge
+sidebar_label: Intents Bridge
+---
+
+
+NEAR Intents utilizes multichain bridges for cross-chain settlement. Currently the following bridges are supported:
+
+1. [Omni Bridge](#omni-bridge)
+2. [PoA Bridge](#poa-bridge)
+
+---
+
+## Omni Bridge
+
+<!-- TODO: incoming omnibridge docs that will be added after this PR is merged. Once those are merged update this section. -->
+
+The Omni Bridge is the primary bridge solution supporting multiple networks and deposit options. 
+
+### Supported Networks
+
+- Bitcoin
+- Ethereum
+- Arbitrum
+- Base
+- Solana
+- TON
+
+### Features
+- Support for `ft_transfer_call()` with `msg` field (active deposit)
+- Passive deposit functionality through:
+  - NEAR-side smart contract owning deposit addresses
+  - Protocol for bridging type correspondence (`ft_transfer` or `ft_transfer_call`)
+  - Parameter-based derivation paths for deposit addresses
+
+### Deposits & Withdrawals
+
+The Omni Bridge handles deposits and withdrawals between other chains and NEAR FTs. For assets not yet supported by Omni Bridge, the [PoA Bridge](#poa-bridge) serves as an alternative.
+
+#### Why Deposits are Required
+Users need to deposit funds into NEAR Intents accounts to trade, which differs from traditional AMMs. This design choice is based on:
+
+1. The necessity of bridging external crypto to NEAR
+2. Single-transaction atomic settlement benefits
+3. Centralized risk comparable to existing NEP-141 tokens
+
+Future migration to a fully sharded architecture will occur once sharded FT standards are developed.
+
+---
+
+## PoA Bridge
+
+The Proof of Authority (PoA) Bridge provides an alternative solution for transferring assets between blockchain networks and NEAR Intents.
+
+![bridge diagram](/docs/assets/intents/poa-bridge-user-docs.jpg)
+
+### Usage Guide
+
+The PoA Bridge API provides a JSON-RPC interface for managing deposits and withdrawals between supported networks and NEAR Intents. See the [official documentation](https://docs.near-intents.org/near-intents/poa-bridge) for more details.
+
+1. **Check Asset Support**: Verify your token is supported
+2. **Get Deposit Address**: Request a deposit address and transfer tokens
+3. **Monitor Deposits**: Track recent deposits via API
+4. **Manage Withdrawals**: Initiate and monitor withdrawals through contract or frontend
+

docs/chain-abstraction/intents/overview.md

@@ -0,0 +1,156 @@
+---
+id: overview
+title: Intents
+sidebar_label: Overview
+---
+
+In NEAR, an `intent` is a high level declaration of what a user wants to achieve. Think of it as telling the blockchain "what" you want to do, not "how" to do it. For example, instead of manually:
+- Finding the best DEX for a token swap
+- Calculating optimal routes
+- Executing multiple transactions
+
+You simply express: "I want to swap Token A for Token B at the best price."
+
+[NEAR Intents](https://near.org/blog/introducing-near-intents/) is a revolutionary transaction framework that simplifies blockchain interactions for:
+- Users
+- Services
+- AI agents
+
+The key innovation is that users & developers no longer need to handle complex cross-chain transactions themselves. Instead, they declare their desired outcome, and a specialized network of solvers (including both AI agents and traditional market participants) competes to execute that intent in the most optimal way possible.
+
+:::info
+The NEAR intents protocol and the documentation are under active development.
+
+The protocol has been renamed from _Defuse_ to **NEAR Intents**.
+Any mentions of _Defuse_ in the source code and documentation are to be replaced.
+:::
+
+## How It Works
+
+1. [**Intent Creation**:](#intent-creation) A user or AI agent expresses a desired outcome _(ex: Swap Token A for Token B)_ and broadcasts the intent to a Solver Network of their choice.
+
+2. [**Solvers Compete**:](#solvers) A off-chain decentralized network of solvers compete to fulfill the request in the most optimal way. When the solver network finds the best solution, it presents it as a quote to the originating user/agent for approval.
+
+4. [**Intent Execution**:](#intent-execution) If the quote from the Solver Network is accepted, the intent begins execution. This is done by the solver performing a contract call (`execute_intents`) to the Intents smart contract on NEAR ([`intents.near`](https://nearblocks.io/address/intents.near)) and passing the intent details. This contract then fullfills the request and (if needed) uses a [cross-chain bridge](/concepts/intents/intents-bridge) to broadcast the intent to the destination chain. The NEAR Intent smart contract also verifies state changes and ensures the intent is settled correctly, reporting the outcome to the originating user/agent.
+
+Here is a sequence diagram of the intent flow:
+
+```mermaid
+sequenceDiagram
+    participant User/Agent
+    participant Solver Network
+    participant NEAR Blockchain
+    participant Destination Chain
+
+    User/Agent->>Solver Network: Broadcasts intent
+    note right of Solver Network: Solvers compete to <br> find the best solution
+    Solver Network-->>Solver Network: 
+    Solver Network-->>User/Agent: Return quote from a solver
+    User/Agent->>Solver Network: User accepts quote and <br> solver executes intent
+    Solver Network->>NEAR Blockchain: Solver calls NEAR <br> Intent smart contract
+    note over NEAR Blockchain, Destination Chain: Bridge facilitates <br> cross chain communication
+    NEAR Blockchain-->>Destination Chain: Transaction(s) broadcasted <br> to destination chain
+
+
+    Destination Chain->>NEAR Blockchain: Transaction(s) completes
+    note over NEAR Blockchain: NEAR smart contract <br> verifies and settles intent
+    NEAR Blockchain->>User/Agent: 
+    note right of User/Agent: Intent Fulfilled! ✅
+```
+
+---
+
+## Intent Creation
+
+Users and AI agents can create various types of intents to interact with assets across different chains. Each intent represents a specific desired outcome while abstracting away the complexity of execution.
+
+The main intent types supported by the `intents.near` contract are:
+
+1. **Swap Intent**: Exchange one token for another at the best available rate
+2. **Transfer Intent**: Move tokens between addresses or chains
+3. **FT Withdraw Intent**: Withdraw fungible tokens from the protocol
+4. **NFT Withdraw Intent**: Withdraw non-fungible tokens from the protocol
+5. **MT Withdraw Intent**: Withdraw multiple tokens in a single transaction
+6. **Native Withdraw Intent**: Withdraw native blockchain tokens (e.g., NEAR)
+
+Each intent follows a standard structure that includes:
+- The NEAR account ID of the initatior
+- Type of intent they want to execute
+- Source assets and amounts
+- Desired outcome parameters
+- Unique identifiers for tracking and authentication
+- Optional constraints (e.g., minimum output amount, deadline)
+
+Here is an example of a native NEAR swap intent structure ready to be broadcasted to a Solver Network:
+
+```js
+{
+  intent_type: "atomic_near", // Type of intent - in this case for atomic swaps on NEAR
+  intent_creation_hash: "Hx7b2270616...", // Unique hash of the intent for authenticity
+  intent_id: "intent_1234567890", // Unique identifier for this specific intent
+  intent_initiator: "alice.near", // The NEAR account ID of the user initiating the swap
+  defuse_asset_identifier_in: "near:wrap.near",  // inpute token (what you are swapping)
+  defuse_asset_identifier_out: "near:usdc.near", // output token (what you want to receive)
+  amount_in: "1000000000000000000000000",  // Numbber of $NEAR in yoctoNEAR (1 NEAR = 10^24 yoctoNEAR)
+  amount_out_desired: "1000000"            // Number of desired USDC (6 decimals)
+}
+```
+
+<!-- TODO: add example of a cross-chain swap intent & and where to get the asset identifiers -->
+
+---
+
+## Solvers
+
+NEAR Intents uses decentralized networks of solvers to fulfill intents. Each solver network is an off-chain message bus that facilitates:
+
+1. Communication between users and solvers
+2. Exchange of `permits` (signed state changes) between participants
+3. Competition between solvers to provide the best quote possible for the intent originator
+
+When an intent is broadcast, the solver network communicates with multiple solvers simultaneously. Each solver analyzes the intent and proposes their solution, including execution path and pricing. The solver network then aggregates these responses and selects the most optimal solution before presenting a final quote to the intent originator.
+
+<!-- TODO: add diagram of the solver network -->
+
+Solver networks are typically specific to a single distribution channel (like a DeFi application) and may contain authorized/trusted solvers for that channel. These solvers:
+
+- Monitor for new intent broadcasts
+- Calculate optimal execution paths
+- Compete to provide the best quotes
+- Execute approved intents through the NEAR smart contract
+- Handle cross-chain coordination when needed
+
+The decentralized nature of solver networks ensures:
+
+- Competitive pricing through solver competition
+- Redundancy and reliability
+- Specialized solvers for different types of intents
+
+:::tip
+See [Create a Solver](/concepts/intents/solvers) for more details on how these solvers work.
+:::
+---
+
+## Intent Execution
+
+When a user accepts a quote from the Solver Network, the intent begins execution. This is done by the solver performing a contract call (`execute_intents`) to the Intents smart contract on NEAR ([`intents.near`](https://nearblocks.io/address/intents.near)) and passing the intent details. 
+
+The NEAR Intents contract fullfills the request and (if needed) uses multi-chain bridge to settle an intent cross-chain. The Intent smart contract also verifies state changes and ensures the intent is settled correctly, reporting the outcome to the originating user/agent.
+
+<!-- TODO: add link to smart contract docs -->
+
+---
+
+## Examples
+
+Here are examples of NEAR Intents in action. Please note that this protocol is still under development and source code is available for learning purposes.
+
+- [Defuse Frontend](https://github.com/defuse-protocol/defuse-frontend): `near-intents.org` fronted sourcecode
+- [Defuse SDK](https://github.com/defuse-protocol/defuse-sdk): Typescript SDK powering `near-intents.org` [WIP]  
+- [AMM Solver](https://github.com/defuse-protocol/near-intents-amm-solver): Sample solver with AMM functionality
+- [Python Client](https://github.com/referencedev/test-intent): A Python example of interacting with the Solver Bus
+- [NEAR Intents AI Agent Example](https://github.com/near-examples/near-intents-agent-example): A Python example of an AI agent that uses NEAR Intents
+
+:::warning
+Currently there is no `testnet` deployment.
+:::