White Paper: Adaptive Trust - A Multi-Agent Orchestration Layer for Resilient NEAR Intents

# White Paper: Adaptive Trust
## A Multi-Agent Orchestration Layer for Resilient NEAR Intents

**Date:** 2026-02-08  
**Author:** Team Daehe (EDITH, Hermes, Daedalus)  
**Status:** Final Submission Candidate  

---

### Abstract
As blockchain interaction shifts toward Chain Abstraction via NEAR Intents, the complexity of multi-chain execution creates a transparency gap. When intents fail or stall, users lack actionable insights. We propose **Adaptive Trust**, a three-tier agentic architecture that monitors, diagnoses, and autonomously recovers NEAR Intents, transforming the "Black Box" of intent execution into a resilient "Glass Box."

---

### 1. The Challenge: Opacity in Intent-Centric Systems
NEAR Intents simplify user experience by focusing on outcomes rather than transactions. However, the reliance on third-party Solvers introduces risks:
*   **Execution Stalls:** Intents may hang without clear feedback.
*   **Cryptic Failures:** Standard error codes (e.g., gas limits, slippage) are unintelligible to non-technical users.
*   **Brittle Recovery:** Current systems often default to simple refunds, losing time and market opportunity.

---

### 2. The Adaptive Trust Architecture
We implement a specialized multi-agent system designed to wrap the NEAR Intent protocol.

#### 2.1. Layer 1: Strategic Interpretation (EDITH)
Edith translates high-level user desires into precise intent parameters and provides natural language transparency.
*   **Function:** Intent translation & Human-Centric Reporting.
*   **Action:** If an intent is delayed, Edith explains *why* in plain language (e.g., "Market volatility has temporarily increased slippage beyond your safe threshold").

#### 2.2. Layer 2: Real-Time Telemetry (HERMES)
Hermes functions as a high-frequency monitoring pulse, tracking solver commitments and on-chain state transitions.
*   **Function:** Liveness Monitoring & Heartbeat.
*   **Mechanism:** Watches for `intent_id` status changes. If no progress is detected within the defined SLA, Hermes triggers an immediate diagnostic interrupt.

#### 2.3. Layer 3: Technical Diagnostics & Recovery (DAEDALUS)
Daedalus provides the engineering depth to handle failures by analyzing `TokenDiff` logs and solver performance.
*   **Function:** Deep Analysis & Path Re-Routing.
*   **Technical Implementation:** 
    *   **Failure Analysis:** Parses NEAR VM trace data to identify if a failure was due to liquidity (Inventory) or connectivity (RPC).
    *   **DIR (Dynamic Intent Recovery):** Calculates alternative `TokenDiff` paths. If the original solver fails, Daedalus prepares a pre-validated alternative intent for the user to approve with a single click.

---

### 3. Technical Implementation Example: The "Pivot"
When a user intent for a multi-chain swap (e.g., ETH to NEAR via solver) stalls:

1.  **HERMES** detects the `SolverTimeout` event.
2.  **DAEDALUS** identifies that the specific liquidity pool on Ref Finance is imbalanced.
3.  **DAEDALUS** generates a new `TokenDiff` using an alternative route (e.g., via Orderly Network).
4.  **EDITH** presents the situation: *"Your initial route is congested. We've found a new path that completes your swap with only a 0.05% difference in output. Proposing recovery..."*

---

### 4. Conclusion: Completing the Promise of Chain Abstraction
Adaptive Trust ensures that as we abstract away the chain, we do not abstract away the user's confidence. By combining real-time monitoring (Hermes), technical resilience (Daedalus), and strategic communication (Edith), we provide the final piece of the NEAR Intents puzzle: **Resilience through Transparency.**

---
**Team Daehe**  
*Building the Meta-Cognitive Layer for the Open Web.*

Hi RockStar,

Thanks for sharing this. I however don’t quite understand the purpose of sharing this on the NEAR governance forum. I suggest you join the NEAR Chain Abstraction WG on Telegram: Telegram: View @chain_abstraction

Hi Rockstar thanks for sharing here.
Is there any way we can have documentation on any peculiar development from devs in this forums mister @fiatisabubble .

I think it is a good to have well-documented ideas, instead of searching it on Telegram groups. So we may revisit some ideas that may or may not work in the future.

Of course there must be a certain moderation on it.

I had a similar discussion on tg about tinkering with ideas to leverage the current technology of NEAR on Telegram. If it’s possible, we could have such forums here.

The focus on plain-language status reporting caught my attention. I work in Community and Growth at Gem Wallet, where NEAR Intents is used for supported cross-chain routes.

From a wallet-support perspective, when an intent is delayed, users often cannot tell whether the issue involves the deposit, selected route, solver, or destination network.

Are you considering a standardized set of user-facing states that integrating wallets could consume—for example: deposit detected, solver assigned, execution in progress, destination confirmed, refund initiated, or action required?

A consistent status model and API could help wallet teams explain problems accurately without exposing users to the underlying protocol complexity.