# 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.