You want an AI agent to execute trades on your behalf -- picking venues, routes, and parameters autonomously. But you need guarantees that the agent can't drain your wallet, pick a malicious venue, or cause unbounded losses.
Traditional approaches require whitelisting every program, instruction format, and parameter. This is brittle, high-maintenance, and breaks whenever a new DEX or aggregator launches.
Date: 2026-03-02 Status: Design Goal: Evaluate agent quality across real user flows -- catch regressions when code changes, measure improvements when new tools/skills are added.
A benchmark system that runs real user scenarios through the real agent loop with real LLM calls, then evaluates the resulting trajectory using two layers:
Research compiled February 2026
All withdrawals from RYUSD on Arbitrum (0x392B1E6905bb8449d26af701Cdea6Ff47bF6e5A8) are being routed to the withdrawal queue because totalAssetsWithdrawable reports only $3.97 USDC out of $29,303 total assets (0.014% liquid). The ~$27,300 in Aave V3 aToken positions are not counted as withdrawable due to two compounding configuration issues in the Aave V3 aToken Adaptor.
| Metric | Value |
|---|
An analysis of how IronClaw's skills system and Docker sandbox work together to prevent prompt injection from manipulating the top-level agent.
The strongest defense. When an installed (untrusted) skill activates, the dispatcher in src/agent/dispatcher.rs:178-194 calls attenuate_tools() which physically removes dangerous tools from the LLM's context. The model only sees 8 read-only tools:
memory_search, memory_read, memory_tree, time, echo, json, skill_list, skill_search
Design notes and working code sketch for integrating priority auctions, competitive builder marketplaces, and sender-controlled transaction privacy into Mosaik-based consensus architectures (Commonware Simplex, CometBFT).
Code: zmanian/commonware-mempool (compiles and runs)
Mosaik provides typed Producer<T> / Consumer<T> streams with tag-based discovery and subscribe_if predicate re-evaluation. Combined with Commonware Simplex BFT, this gives us a dual-stack architecture where consensus traffic runs on Commonware's authenticated P2P and transaction dissemination runs on Mosaik streams.
Exploring whether Mosaik -- Flashbots' self-organizing p2p runtime -- could serve as the foundation for a high-performance mempool (in the style of Commonware or CometBFT) that collapses transaction dissemination, order matching, and block production into a single pipeline.
In CometBFT and most blockchain architectures, the pipeline is segmented:
Tx submission -> Mempool gossip (opaque bytes) -> Block proposer selects txs
Analysis of Mosaik (v0.2.1) -- a Rust runtime for self-organizing, leaderless distributed systems built on iroh (QUIC-based p2p networking) -- and how its primitives map onto intent-based orderflow systems like NEAR Intents.
Nodes deployed on plain VMs self-organize into a functioning topology using just a secret key, a gossip seed, and role tags. No orchestration needed. Four subsystems:
NEAR Intents (formerly Defuse Protocol) coordinates intent-based settlement across 18+ chains. The current architecture relies on a centralized Solver Relay (solver-relay-v2.chaindefuser.com) as the sole coordination point between users and solvers. This is a single point of failure, a censorship vector, and a trust assumption on the relay operator.