In May someone took about $150,000 out of an on-chain agent's wallet. No stolen key. No contract bug. Grok was wired to a Bankr wallet on Base. Someone prompt-injected Grok with a reply on X, payload hidden in Morse. Then the part people skip: Bankr read Grok's output and signed the transfer on it. One agent trusted another's output. That was the whole exploit.

2.

SlowMist mapped the kill chain and called it permission chain abuse. Privilege escalation, injection, on-chain execution. Read it. The post-mortem isn't my point. The point is this isn't rare.

StakeBench ran trading agents across a range of setups. Direct injections worked more than 79% of the time. Indirect ones, buried in data the agent reads, 42 to 68%. No reliable defense in anything they tried. Grok wasn't a careless outlier. It's close to the default for an agent that reads untrusted input and can move money.

3.

These agents get audited. The audits weren't wrong. They checked the contract and the contract held. No Solidity moved that money.

Two things did. An inbound NFT widened what the agent's wallet was allowed to do, so the capability was live before a word was sent. Then the signing agent took another agent's output as a trusted instruction. Neither is a line you can point at in a file. Both are about how the pieces behave once they're wired together.

That's the gap. An audit asks if the code is correct. It doesn't ask which states the agent can be pushed into once the wallet, the tools, the untrusted input, and the other agents it listens to are all live at once. The second question is the one that costs money.

4.

We don't call these vulnerabilities. Without a working proof against a specific deployment they're reachable failure paths. Candidates. What makes a candidate worth acting on is classification, of a state, not a finding. Can the agent be pushed into it (Reachable). Could a design choice have kept it out of reach (Avoidable). Once it's reached, can it be undone (Unrecoverable). The read comes from several models reasoning independently, because one model alone misses whole classes it wasn't told to look for.

Grok drain:

• Reachable. Yes, permissionless. The path ran through a public reply anyone could post.

• Avoidable. Partly. Letting an inbound NFT change wallet permissions is a choice. So is letting one agent sign on another's say-so with no check. Bankr had blocked Grok's replies in an earlier build and dropped the block in a rewrite.

• Unrecoverable. Here the easy reading is wrong. On-chain it was final. Funds settled and moved. Most of the value came back, but only because the community deanonymized the attacker and negotiated. That's an off-chain, social recovery. You can't design around it and you can't count on it. Technically the loss was irreversible.

Quieter case, from StakeBench. An agent finishes your task while steering it, nudging toward a token or leaking a credential on the way.

• Reachable. Yes, and the base rates aren't small.

• Avoidable. Harder. The pattern is built to leave no trace. You can't avoid what you have no check for.

• Unrecoverable. Mixed. A steered trade you might unwind. A leaked key you won't.

Two states, same catalog, nothing alike. One loud and final. One quiet, usually reversible per event, and still running. A list of findings doesn't separate them. R/A/U does. That ordering is where you look first.

5.

The public cases aren't the whole list. The behavior-layer paths that keep showing up across on-chain agents come down to a handful:

• Direct injection. Sent straight to the agent.

• Indirect injection. Hidden in data the agent reads.

• Capability escalation via an on-chain artifact. An inbound token or NFT widens what the wallet can do.

• Memory or context poisoning. Bad data planted now to bend a decision later.

• Stealthy goal-steering. The agent working for you and someone else at once.

• Inter-agent trust. One agent taking another's output as authorization.

• Tool-channel poisoning. The path coming in through a connected tool or MCP server.

Touch any of these and the matching path is worth checking for reachability.

6.

The trick changes every week. The structure doesn't. Read input you don't control and you can be injected. Hold funds and a wrong call becomes a loss. The agent listens to other agents, so it inherits whatever compromised them. And it runs unattended, which gives an attacker room between the steps. Most useful agents have all of this. Same thing that makes them useful.

The goal-directed ones are most exposed. You hand them an objective and let them run. Rebalance this. Chase yield there. They read the most untrusted data and a human checks the least. That's the profile every case above hit.

So the question about your agent isn't whether its contract passed an audit. It's which of these paths it can reach, and which of those are irreversible.

7.

This is methodology work, in the open. Cases are public, reasoning is public.

There's a wave of automated agent-security tooling landing right now. Scanners that promise a fast, scalable verdict. This isn't that. If you run an on-chain agent and want a read on which of these paths it can reach, and which would be unrecoverable if it did, I'll do a worked R/A/U read on your actual setup, for a small number of agents, no charge. By hand, not by scanner. No yes/no safety stamp. Verification, not coordination.

founder@getreacher.xyz, or @getreacher

CC BY-SA 4.0

Target Class: Olas DeFAI Trader Agents (Modius Architecture Baseline)

Validator: [ERC-8004 Agent ID to be assigned — agent0.xyz registration pending]

Methodology: Epistemic Evolution Engine v1.0 — reachability-first invariant hunting with R/A/U classification, minimal counterexample extraction, and UNRECOVERABLE-flag escalation

Report Date: May 2026

Scope: Strategy logic, wallet delegation boundary, protocol integration reachability, recovery paths

Status: Public baseline validation — generic architecture analysis applicable to Modius, Omenstrat, and similarly-structured DeFAI portfolio agents deployed via Olas Pearl. The Optimus class is referenced as architectural baseline; on May 5, 2026 Pearl announced Optimus moving into maintenance mode (see Section 1.1).

Executive Score Matrix

Critical findings: 3 (SYS-01, SYS-03, SYS-05) UNRECOVERABLE paths identified: 2 (SYS-03 full depeg propagation, SYS-05 whitelist expansion) Mitigations proposed: 17

Section 1 — Scope & Methodology

1.1 What this report validates

This report analyzes the decision architecture and reachability surface of Olas DeFAI trader-class agents — not the underlying smart contract code of the DeFi protocols they interact with (Aave, Balancer, Sturdy, Uniswap, etc.), which are separately audited by those protocols’ own security providers.

The question answered here is narrower and, for an autonomous agent operator, more immediately consequential: given the agent’s strategy logic and delegation permissions, what are the minimal adversarial or environmental conditions under which user capital under management is impaired?

Note on platform state at time of publication. On May 5, 2026, Pearl announced that Optimus, Polystrat, and Agents-dot-fun were moving into maintenance mode, while Modius and Omenstrat remain fully operational with continued staking incentives.[^pearl-update] The reasoning Pearl gave for the Polystrat decision is directly relevant to the methodology applied here: Polymarket shipped a wallet-architecture update that Pearl could not absorb without “a fundamental rewrite of both Pearl and Polystrat’s core codebase and related off-chain indexing.” This is precisely the class of dynamic this report studies — the agent’s reachable state set depends on the composition of its own logic with external systems whose contracts the agent does not control. The architectural analysis below is therefore framed as applying to the trader class (of which Modius is the active baseline), not to any specific deployment whose continued availability is a Pearl-side product decision.

[^pearl-update]: Pearl (2026). A short update on Pearl and its agents. Twitter thread published May 5, 2026, 20:10 UTC. The conclusion of the thread states: “Pearl is about owning your AI agent. An agent you own should be able to control its destiny. An externally imposed platform presents a challenge to this vision.” This framing aligns closely with the present report’s distinction between coordination contracts (which Pearl provides) and verification contracts (which the methodology of this report addresses); see Section 6.2.

1.2 Methodology: Epistemic Evolution Engine (EE)

The Epistemic Evolution Engine is the methodological framework applied to produce this report. The framework is described here at the level of its principles and outputs; full operational details (specific scoring heuristics, generation procedures for hypothesis enumeration, internal validation pipeline) are part of the validator’s proprietary implementation and are not the subject of this publication.

The framework is built on five principles:

• Reachability classification (R/A/U): Every hypothesis about agent failure is classified into one of three categories.

  • R — Reachable: an adversarial or environmental path exists that triggers the condition under plausible assumptions

  • A — Assumption-bounded: the condition is reachable only under assumptions that are themselves testable but presently unverified

  • U — Unreachable: the architecture provably blocks this path

• Minimal counterexample requirement: Each R-classified hypothesis is accompanied by the smallest adversarial sequence demonstrating reachability, with concrete economic parameters. This converts abstract risk claims into falsifiable concrete predictions.

• UNRECOVERABLE flagging: Hypotheses where realization permanently impairs user capital are escalated above hypotheses with available recovery paths. The framework treats reversible losses categorically differently from irreversible ones.

• AdversarialCritic discipline: Each hypothesis is subjected to the strongest counter-argument before being accepted, with the counter-argument explicitly documented in the hypothesis card. Hypotheses that survive the strongest counter-argument carry epistemic weight; hypotheses that do not are downgraded or discarded.

• Citation discipline: No claim is made without tracing to either (a) published public documentation of the target system, (b) observable on-chain behavior, or (c) explicit assumption labeled as such. Untraceable claims are rejected.

The framework is designed to operate as observer-class evidence in the sense of Romanchuk and Bondar (2026) — the classification concerns which states the agent can arrive at given its execution surface, not which states the agent’s internal logic claims it can or cannot reach. Whether the classification achieves non-circularity in any specific instance depends on whether each classification is grounded in explicit truth-makers and epistemically relevant transitions, rather than re-stated internal claims. Externality of the classifier is necessary but not sufficient for non-circularity; the methodology must demonstrate, case by case, that the classification draws on new observations, externally validated inference rules, or explicit epistemic typing that prevents generated propositions from being treated as observations.

Section 6 (Related Work) develops the theoretical positioning of this framework in greater depth.

1.3 What this report does not claim

This is a decision-architecture validation, not a line-by-line code audit. Hypotheses labeled as Assumption-bounded (A) require direct code access to resolve to R or U. A paid engagement converts A-class hypotheses to definitive R/U classification and produces an updated score.

The methodology and its specific position within the emerging stack of primitives extending ERC-8004 are described in Section 6 (Related Work).

Section 2 — System Decomposition

L1 — Delegation Boundary

The user-to-agent delegation surface, operationalized through Safe smart accounts with module permissions restricting agent capability to a whitelisted set of contracts (typically Aave pools, Balancer vaults, Sturdy silos, Uniswap routers) and token approvals.

Critical properties to validate:

• Module permission scope at time of delegation

• Upgrade path of whitelisted contract set (static vs. dynamic)

• Token approval policy (unlimited vs. per-transaction)

• Emergency revocation path (user-side)

L2 — Strategy Selection Logic

The decision loop that ranks available yield opportunities and produces allocation targets. Based on public Olas/Valory materials, this is primarily driven by off-chain APY data feeds (CoinGecko and protocol-native APIs) combined with on-chain TVL and utilization reads.

Critical properties to validate:

• Data source redundancy and cross-validation

• Ranking function sensitivity to outliers

• Tick frequency and minimum reallocation thresholds

• Fallback behavior under feed staleness or unavailability

L3 — Execution Layer

Transaction construction and submission — swap routing, slippage configuration, gas policy, retry semantics on failed txs.

Critical properties to validate:

• Slippage bounds (static vs. dynamic with position size)

• Multi-hop route validation

• MEV exposure profile on large reallocations

• Retry logic on revert vs. partial fill

L4 — Recovery & Exit

Paths by which the user regains full control, and by which the agent gracefully handles upstream failures (protocol upgrades, frozen pools, agent process death).

Critical properties to validate:

• User-initiated exit latency

• Agent behavior when a whitelisted contract is paused or upgraded

• OLAS token economic dependency in agent staking/rewards

• Process-level liveness guarantees

Section 3 — Hypothesis Cards

SYS-01 — Oracle-Induced Misallocation Cascade

Class: R (Reachable) Severity if realized: HIGH UNRECOVERABLE flag: CONDITIONAL Layer: L2 (Strategy Selection)

Premise

Agent selects allocation targets using off-chain APY feeds (CoinGecko primary) combined with on-chain TVL/utilization reads. Decision loop estimated at 1–6 hour cadence per public Modius documentation.

Hypothesis

Targeted manipulation of the APY signal source — via flash-loan-funded pool distortion timed to the feed snapshot, CoinGecko-side stale data, or RPC congestion causing delayed reads — can trigger the agent to concentrate delegated capital into a pool that is (a) illiquid at exit scale, (b) economically compromised, or (c) subject to an imminent parameter change.

Reachability Trace

1. Attacker observes agent’s decision cadence (inferable from public tx history of Safe).

2. At time T − Δ, attacker deposits and borrows in target pool X via flash loan, inflating reported APY for the feed snapshot interval.

3. Agent’s scheduled pull at time T reads inflated APY.

4. Ranking logic selects pool X as top allocation target. Assumption: ranking is monotonic in APY without a sufficient TVL-depth or momentum penalty.

5. Agent submits allocation tx with default slippage tolerance. Assumption: slippage is not dynamically scaled to allocation size.

6. Execution lands during or immediately after attacker unwind, causing entry at distorted share price.

7. Loss materializes on next mark-to-market or exit.

Minimal Counterexample

AdversarialCritic Pushback

“Agent likely has inter-tick sanity checks.”

Response: Public Olas/Valory documentation and community walkthroughs do not describe inter-tick validation (multi-source APY consistency, TVL-depth gating, momentum smoothing). The hypothesis remains Reachable pending direct code read.

“Slippage protection blocks catastrophic entries.”

Response: DEX-level slippage protection is local to the swap transaction. It does not prevent entry into a manipulated pool at the manipulated clearing price — loss realizes on exit, not entry. This objection misidentifies the attack vector.

UNRECOVERABLE Assessment

• Partially recoverable if: agent’s next tick re-allocates out of the compromised pool before attacker completes exit, AND withdrawal path remains whitelisted.

• Unrecoverable if: pool experiences actual exploit during holding period, OR attacker pattern repeats across multiple ticks, compounding slippage drain.

Recommended Mitigations

1. Multi-source APY cross-validation gate. Reject ranking decisions when variance across 3 sources exceeds configured threshold (suggested: 15%).

2. TVL-depth penalty. Suppress APY ranking when intended position size exceeds 2% of target pool TVL.

3. Momentum smoothing. Require 3–6 tick corroboration of APY signal before large reallocations.

4. Hard position cap. Enforce per-pool ceiling as fraction of target TVL at allocation time.

Confidence

Medium-High on Reachability. Medium on Severity without direct code access. Resolvable to High with paid engagement.

SYS-02 — Protocol Parameter Drift Without Agent Awareness

Class: A → R (Assumption-bounded, likely Reachable) Severity if realized: MEDIUM-HIGH UNRECOVERABLE flag: NO Layer: L2, L4

Premise

Integrated protocols (Aave, Balancer, Sturdy) periodically adjust risk parameters — LTV ratios, liquidation thresholds, interest rate curves, fee tiers, reserve factors. These changes are announced through governance channels but do not emit agent-consumable signals in all cases.

Hypothesis

The agent continues executing its strategy against stale assumptions about protocol parameters, leading to positions that were rational under old parameters but are now dominated, underwater, or unsafe under new ones.

Reachability Trace

1. Protocol X governance executes parameter change at block B (e.g., Aave reduces supply cap on asset A, or Sturdy increases risk premium on silo S).

2. Agent’s strategy selection logic continues scoring pool under pre-change economics because either (a) CoinGecko APY reflects new state with lag, or (b) agent does not monitor protocol governance events directly.

3. Allocations made between block B and the next feed refresh are mis-priced relative to new risk profile.

4. If parameter change is a tightening (e.g., LTV reduction), existing leveraged positions may be approaching forced exit without agent awareness.

Minimal Counterexample

Sturdy Finance silo parameter changes have historically occurred on 7–14 day governance cycles. An agent with 4-hour tick cadence may execute 42–84 decisions under stale parameters during the drift window, with compound error.

AdversarialCritic Pushback

“CoinGecko APY reflects realized yield, so drift corrects itself quickly.”

Response: Realized APY lags parameter changes. For risk parameters (LTV, liquidation buffers), there is no APY-reflection at all — these manifest only when stress arrives. The hypothesis concerns the latter class.

UNRECOVERABLE Assessment

Recoverable in most instances — agent can exit once signal updates. Not flagged UNRECOVERABLE unless combined with SYS-03 (depeg during drift).

Recommended Mitigations

1. Governance event subscription. Direct monitoring of Aave/Balancer/Sturdy governance contracts for parameter change events with immediate strategy re-evaluation trigger.

2. Parameter staleness clock. Explicit TTL on cached protocol parameters; force refresh on expiry.

3. Conservative defaults during drift windows. Reduce position sizing during periods of known governance activity.

Confidence

Medium on Reachability pending confirmation of the agent’s governance-event subscription capability.

SYS-03 — Stablecoin Depeg Propagation Through Rotation Logic

Class: R (Reachable) Severity if realized: CRITICAL UNRECOVERABLE flag: YES (under specific conditions) Layer: L2, L3

Premise

Yield-rotation agents monitor the top stablecoins by TVL and rotate between platforms such as Compound, Yearn, Curve, and Aave, exchanging between stables (e.g., DAI for USDC) when risk management conditions are met. This pattern is publicly documented for Olas-class DeFAI agents.

Hypothesis

During a stablecoin depeg event, the agent’s rotation logic can amplify user losses rather than dampen them: the agent may (a) detect the depeg through APY divergence and rotate into the depegging asset at temporarily inflated yields, or (b) rotate out at the worst moment (maximum slippage, minimum liquidity), or (c) get stuck mid-rotation with capital split across two impaired positions.

Reachability Trace

Scenario A — rotating INTO the depegging asset:

1. Stablecoin S begins losing peg; pools offering S-denominated yield spike APY to compensate holders.

2. Agent’s ranking logic, seeing elevated APY, flags S-pool as top target.

3. Assumption: depeg signal is not part of agent’s risk gate.

4. Agent rotates capital from stable S’ into S at close-to-peg prices, just before further peg deterioration.

5. Loss materializes as S continues to depeg.

Scenario B — stuck mid-rotation:

1. Agent initiates exit from pool in asset S on detection of deteriorating conditions.

2. Exit tx lands during liquidity crunch; fill rate is partial, or slippage bound is breached and tx reverts.

3. Agent retries under worsening conditions, or agent’s retry policy triggers a different pool entry while exit is still pending.

4. Capital ends up split across a depegging position and a target position, with neither fully owned.

Minimal Counterexample

• Capital under management: $1,000,000 in DAI

• Depeg event: USDC briefly drops to $0.92 (historical precedent: March 2023)

• Agent detects USDC pool APY spike (artifact of stress, not reward)

• Agent rotates $600,000 DAI → USDC at effective price $0.94

• USDC re-pegs to $1.00 after 72 hours — but agent has already rotated out at $0.96 on fear signal

• Net round-trip loss: ~4% = $24,000 on rotated portion, plus gas and slippage

AdversarialCritic Pushback

“Agent would have an explicit depeg gate.”

Response: Public documentation does not describe a depeg gate in the Modius/Optimus strategy class (the architectural baseline this report analyzes). A depeg gate requires continuous multi-source price validation for each monitored stable, which is non-trivial. Assumption-bounded as absent until proven present.

“User-set strategy constraints would prevent stable-to-stable rotation during depeg.”

Response: User-set constraints typically exclude specific protocols (e.g., “don’t use X”), not dynamic conditions. The risk surface remains.

UNRECOVERABLE Assessment

UNRECOVERABLE if:

• Depeg fails to reverse (permanent loss scenario)

• Agent’s retry pattern compounds the entry during peg deterioration

• Exit liquidity evaporates entirely during the window

Partially recoverable in standard depeg-and-recover events, but losses from bad timing persist.

Recommended Mitigations

1. Depeg gate. Real-time multi-source price validation for each monitored stable; suspend all rotations involving a stable when price deviates more than configured threshold (suggested: 0.5%).

2. Circuit breaker on cross-stable swaps. Time-based cooldown on rotation between stables during elevated volatility windows.

3. Single-in-flight constraint. Ensure no new rotation begins while a previous rotation’s exit has not fully settled.

4. Per-asset capital ceiling. Hard cap on percentage of portfolio in any single stablecoin, independent of APY.

Confidence

High on Reachability. The depeg scenario has historical precedent (USDC March 2023, UST May 2022) and the described amplification patterns are consistent with publicly documented rotation-agent behavior.

SYS-04 — MEV Sandwich Exposure on Reallocation Transactions

Class: R (Reachable) Severity if realized: LOW-MEDIUM UNRECOVERABLE flag: NO Layer: L3 (Execution)

Premise

Reallocation transactions for portfolios above $100k frequently exceed the threshold at which MEV sandwich attacks become economically viable on public mempool DEX swaps.

Hypothesis

Large reallocation swaps submitted through public mempools without private-order-flow protection are sandwich-attacked, extracting 0.5–3% value per large swap.

Reachability Trace

1. Agent submits swap of size $S on Uniswap v3 pool with depth D.

2. Tx enters public mempool on Base/Optimism.

3. MEV searcher observes pending tx, front-runs with buy, back-runs with sell.

4. Agent’s swap fills at worse price than quoted.

5. Effective loss per swap: ~0.5–3% of swap volume depending on pool depth.

Minimal Counterexample

• Agent rebalances $200k across 3 swaps per tick

• 4 ticks per day = 12 swaps/day = 4,380 swaps/year

• If even 30% of swaps are sandwich-vulnerable at 1% avg extraction: ~$26,000/year drag on $200k book = 13% annualized fee

AdversarialCritic Pushback

“L2 chains have weaker MEV; this is overstated for Base/Optimism.”

Response: Base and Optimism MEV is lower than L1 but not zero. Private order flow (Flashbots Protect equivalent) or CoW-style batch settlement meaningfully reduces this regardless of chain.

UNRECOVERABLE Assessment

Not applicable — MEV losses are a continuous tax, not a catastrophic event.

Recommended Mitigations

1. Private order flow routing for swaps above configured threshold (suggested: $25k).

2. CoW Protocol or UniswapX integration for competitive execution.

3. Time-randomization of reallocation submissions to reduce predictability.

4. Split large swaps across multiple blocks when latency budget permits.

Confidence

High. This is standard DEX execution hygiene; absence of these protections is a quantifiable ongoing drag.

SYS-05 — Safe Module Permission Creep via Whitelist Expansion

Class: R (Reachable) Severity if realized: HIGH UNRECOVERABLE flag: YES (if exploited before user revocation) Layer: L1 (Delegation Boundary)

Premise

Modern Olas/Pearl agent architecture uses Safe smart accounts with module-based permissions. The agent is granted ability to call specific whitelisted contracts. Expansion of this whitelist — to support new protocols or new strategies — is typically a permissioned action, but the permissioning model and default upgrade path require scrutiny.

Hypothesis

Whitelist expansion, if executable without explicit user per-change approval, creates a path by which a compromised agent-side key or a malicious strategy update can route user capital to attacker-controlled contracts.

Reachability Trace

1. Agent’s strategy backend is updated (cloud-deployed scenario) OR agent-side signing key is compromised.

2. Updated strategy adds new “yield opportunity” pointing to attacker-controlled contract.

3. Assumption: whitelist expansion does not require explicit user signature.

4. Agent allocates capital to malicious contract via legitimate Safe module call.

5. Attacker drains.

6. Recovery is impossible after capital leaves Safe.

Minimal Counterexample

If agent runs cloud-side (non-Pearl, operator-managed), a single compromised deployment key can drain full TVL of all managed agents of that operator. For an operator managing 20 agents at $500k avg TVL, blast radius is $10M.

For Pearl-local agents, blast radius is per-instance, but the attack surface shifts to the Pearl update mechanism.

AdversarialCritic Pushback

“Safe modules require user-signed setup; agent cannot expand whitelist unilaterally.”

Response: Initial setup is user-signed. The question is whether subsequent whitelist additions — a common feature request for evolving strategies — are user-signed per-change or enabled via a broader initial delegation. If the latter, the hypothesis holds. Assumption-bounded until confirmed via code read.

“Olas Pearl is audited.”

Response: Pearl’s core codebase audit does not cover the entire trust chain: operator-managed cloud deployments, third-party strategy plugins, and the update/release path of the agent binary itself are out-of-scope for a standard Safe-module audit. The attack surface extends beyond the audited code.

UNRECOVERABLE Assessment

UNRECOVERABLE by construction — once capital leaves the Safe via a legitimate module call, on-chain recovery requires attacker cooperation or legal action.

Recommended Mitigations

1. Per-expansion user signature. Require explicit user signature for every whitelist addition after initial setup.

2. Time-lock on whitelist changes. Minimum 24–48 hour delay between whitelist expansion request and effect, with notification.

3. Max-addition-per-period cap. Rate-limit whitelist expansion to prevent bulk additions.

4. Destination reputation gate. New whitelist entries must pass a reputation threshold (e.g., contract age, audit status, TVL history).

5. Operator-level transparency. For cloud-deployed operator-managed agents, publish operational security practices (key management, deployment process, multi-sig for releases).

Confidence

Medium-High on Reachability. Severity and exact vector depend on deployment mode (Pearl-local vs. operator-cloud) and whitelist-expansion policy.

SYS-06 — OLAS Token Economic Dependency in Agent Operation

Class: A (Assumption-bounded) Severity if realized: MEDIUM UNRECOVERABLE flag: NO Layer: L4 (Recovery / Liveness)

Premise

Olas agents participate in a staking and rewards economy denominated in OLAS token. Agent operators earn OLAS for “Proof of Active Agent.” The agent’s own operational costs (gas, compute, optional fees) and the operator’s incentive structure are partially tied to OLAS token price.

Hypothesis

A severe decline in OLAS token price creates an economic scenario where:

• Operator incentive to maintain agent liveness weakens (rewards no longer cover operational costs).

• Agent operations may be suspended, deprecated, or reduced in quality.

• User capital remains in-protocol but without active management.

Reachability Trace

1. OLAS token price declines below threshold where staking rewards < operational costs.

2. Operators discontinue cloud deployments; Pearl-local users unaffected unless Pearl itself stops supporting the service.

3. Users whose agents were operator-managed now have capital in positions but no active rebalancing — exposure to SYS-02 (parameter drift) and SYS-03 (depeg) amplifies.

Minimal Counterexample

Historical precedent: many DeFi-token-incentivized services experience operator exodus during token drawdowns of 80%+ from peak. OLAS is not exempt from this pattern.

AdversarialCritic Pushback

“Users self-custody in Pearl; operator exit doesn’t affect Pearl-local agents.”

Response: Accurate for Pearl-local. But cloud-deployed operator-managed agents (used by non-technical users via SaaS-like wrapping) do have this exposure. The hypothesis applies selectively.

UNRECOVERABLE Assessment

Not UNRECOVERABLE — user retains Safe self-custody and can manually exit or migrate. But loss through inaction during the gap is possible.

Recommended Mitigations

1. Operational cost subsidy reserve. Protocol-level reserve to sustain agent operations during token downturns.

2. Graceful-shutdown protocol. Mandated exit-to-stable-positions behavior when operator cannot sustain service.

3. User notification SLA. Contractual requirement for N-day advance notification of service discontinuation.

Confidence

Medium. This is a known class of issue for token-incentivized service economies; the specific impact on Olas depends on operator diversity and reserve structure.

SYS-07 — Data Feed Staleness and DoS Behavior

Class: R (Reachable) Severity if realized: MEDIUM UNRECOVERABLE flag: NO Layer: L2 (Strategy Selection)

Premise

CoinGecko and protocol-native APIs are subject to rate limiting, outages, and DoS. An agent that depends on these feeds must have a defined behavior for feed unavailability.

Hypothesis

Under feed staleness or DoS, the agent either (a) continues executing against stale data, (b) halts entirely leaving positions unmonitored, or (c) falls back to a less reliable source. All three failure modes are exploitable or degrading.

Reachability Trace

1. CoinGecko API hits rate limit or experiences partial outage.

2. Assumption: agent’s fallback behavior is undefined or defaults to last-known-good data for a configurable TTL.

3. During outage, market conditions shift (e.g., real depeg starts, protocol parameter change lands).

4. Agent’s decisions during this window are made on stale data.

Minimal Counterexample

CoinGecko free-tier rate limits are well-documented. For an agent polling every 4 hours, a 30-minute outage is a significant fraction of the tick. If stale data is used during a depeg initiation, SYS-03 fires under compounded risk.

AdversarialCritic Pushback

“Multi-source fallback resolves this.”

Response: Multi-source fallback is a mitigation, not a given. The hypothesis classifies the agent’s current behavior (A-bounded), not the ideal behavior.

UNRECOVERABLE Assessment

Not UNRECOVERABLE standalone; amplifies other hypotheses.

Recommended Mitigations

1. Multi-source feed redundancy. Minimum 2 independent data sources with automatic failover.

2. Explicit staleness TTL. Reject decisions when all sources are stale beyond configured threshold.

3. Halt-and-hold fallback. When feeds are unavailable beyond staleness threshold, freeze allocations at current state rather than execute on stale data.

4. Heartbeat monitoring. User-visible indicator of feed health.

Confidence

Medium-High on Reachability.

SYS-08 — Inter-Agent Liquidity Collision in Thin Pools

Class: R (Reachable) Severity if realized: LOW-MEDIUM (individual) / MEDIUM-HIGH (systemic) UNRECOVERABLE flag: NO Layer: L2, L3

Premise

When multiple independent agent instances share similar strategy logic and similar data inputs, their decisions are correlated. On thin-liquidity pools, simultaneous or near-simultaneous entries/exits can cause self-inflicted slippage.

Hypothesis

As Olas DeFAI trader population grows, correlated decisions across instances can saturate target pool liquidity, causing each instance to execute at materially worse prices than a stand-alone instance would have.

Reachability Trace

1. N agents share strategy logic; all read same APY signal at similar times.

2. All N identify the same top target pool.

3. First agent to execute gets expected price; subsequent agents push through declining liquidity.

4. Last agent to execute may face slippage large enough to trigger its own slippage-bound revert.

Minimal Counterexample

If 50 Olas DeFAI instances manage $100k average ($5M aggregate) and all rotate into the same pool over a 30-minute window on a $20M TVL pool, the last-mover cost approaches 1–2% of entry due to cumulative price impact.

AdversarialCritic Pushback

“Olas framework randomizes tick timing across instances.”

Response: If true, this partially mitigates. Not confirmed in public documentation; assumption-bounded.

UNRECOVERABLE Assessment

Not UNRECOVERABLE.

Recommended Mitigations

1. Tick jitter. Randomize tick timing across instances to reduce correlation.

2. Pool-depth-aware sizing. Each instance checks recent volume/price-impact signals before committing to a target size.

3. Coordinator awareness (optional). An opt-in coordination layer where instances broadcast intent and stagger execution.

Confidence

Medium. Severity grows with agent population and is currently low because agent count is modest.

Section 4 — Aggregate Risk Profile

4.1 Severity heatmap

4.2 Capital-scale thresholds

Based on the cumulative risk profile, this report suggests the following ship-conditional scale bounds:

• Below $100k TVL per instance: Current architecture is acceptable for experimental use. MEV drag and minor execution inefficiencies dominate.

• $100k–$1M TVL per instance: P0 mitigations (SYS-01, SYS-03, SYS-05) should be implemented before scaling.

• Above $1M TVL per instance: All P0 and P1 mitigations required. Operator-level transparency (SYS-05, SYS-06) becomes a disclosure obligation.

4.3 Comparison to baseline

This architecture scores notably above memecoin-launch bot agents (which typically score 25–40/100 on equivalent analysis) and notably below institutional custody-grade vault systems (85–95/100). The 64/100 aggregate positions Olas DeFAI agents as a retail-viable with caveats class of autonomous capital manager.

Section 5 — Recommendations Summary

5.1 Immediate (pre-deployment for any new instance above $100k TVL)

1. Implement SYS-03 depeg gate (price validation, circuit breaker, per-asset cap)

2. Implement SYS-01 multi-source APY gate and TVL-depth penalty

3. Document SYS-05 whitelist expansion policy; require explicit user signature per-expansion

4. Enable private order flow routing for swaps above $25k (SYS-04)

5.2 Near-term (within 30 days for scaling services)

1. Governance event subscription for protocol parameter changes (SYS-02)

2. Multi-source feed redundancy with explicit staleness TTL (SYS-07)

3. Operational cost reserve and graceful-shutdown protocol (SYS-06)

5.3 Medium-term (for ecosystem-scale resilience)

1. Tick jitter and pool-depth-aware sizing (SYS-08)

2. Formal on-chain attestation of deployed strategy hash for auditability

3. User-visible risk dashboard exposing current exposure to each documented hypothesis

Section 6 — Related Work: Theoretical Foundation and Adjacent Primitives

The methodology applied in Sections 1–5 builds on prior theoretical work and positions itself within an emerging stack of complementary primitives extending ERC-8004. This section makes both the theoretical lineage and the structural positioning explicit, so that the report’s contribution can be evaluated against work it builds on (theoretical) and work it operates alongside (architectural).

6.1 Romanchuk & Bondar (2026a) — Semantic Laundering in AI Agent Architectures[^1]

The foundational paper formalizes a failure mode the authors term semantic laundering: the structural mechanism by which an agent’s internal validation processes produce outputs that appear to constitute verification while in fact only re-encoding the agent’s own claims. The paper proves a Theorem of Inevitable Self-Licensing demonstrating that any verification process operating within the same epistemic boundary as the generating system necessarily produces self-licensing artifacts rather than independent warrant.

Two implications matter for the present work:

1. External validation is structurally required, but externality alone does not solve the problem. The theorem rules out the possibility that an agent — or a coordinator agent within the same orchestration — can produce non-self-licensing verification of its own outputs through tool-boundary or format-level means alone. The theorem is conditional on specific architectural assumptions identified in the source paper: generator and tool outputs treated as the same proposition type, tool results admitted as observations without epistemic typing, and LLM-generated propositions influencing epistemic status assignment. An external validator addresses these conditions only insofar as the validation step introduces epistemically relevant grounding: new observations, externally validated inference rules, or explicit epistemic typing that prevents generated propositions from being treated as observations. Externality is necessary but not sufficient.

2. Format-based validation reproduces the failure mode. Confirming that an output passes a schema, a test suite, or a checklist does not exit the self-licensing boundary if the schema, suite, or checklist were generated within the same system. Romanchuk’s subsequent applied case study[^2] makes this concrete in the context of orchestrator agents.

The R/A/U state classification used throughout this report is designed to operate as observer-class evidence in Romanchuk-Bondar’s terminology: it classifies which states an agent can actually arrive at given its execution surface, not which states the agent’s internal logic claims it can or cannot reach. Whether any specific R/A/U classification achieves non-circularity is not established merely by the classifier’s externality; it must be demonstrated case by case that the classification is grounded in explicit truth-makers and epistemically relevant transitions, with internally generated propositions explicitly typed to prevent their elevation to observation-like warrant. The methodology’s discipline points (minimal counterexample requirement, AdversarialCritic, citation discipline) are the operational means by which this grounding is attempted for each hypothesis card.

6.2 Romanchuk & Bondar (2026b) — Responsibility Vacuum[^3]

The second paper provides an organizational diagnosis of what happens when decision-generation throughput exceeds bounded human verification capacity in scaled agent systems. The authors distinguish between coordination contracts (format-level agreements among components that the system works) and verification contracts (independent external checks that some external observer would also classify the system as working). The paper defines responsibility vacuum not as the mere presence of verification gaps, but as the condition where a decision has occurred and no entity has both authority over the decision and capacity to understand it. Verification gaps may contribute to responsibility vacuum, but the authority-capacity structure is what defines it.

The paper is primarily diagnostic. It does not specify ERC-8004-style attestations, signed finding cards, or a technical registry mechanism as the solution; these are proposed in the present report as one applied response to the organizational condition the paper describes. The signed finding cards (SYS-01 through SYS-08) and on-chain Validation Registry posting are the author’s applied design choices, not constructs established by the cited work.

The throughput-vs-verification distinction also informs the report’s scoring methodology. The Executive Score Matrix weighs verification gaps separately from coordination gaps, since (per Romanchuk-Bondar) only the former indicate placement in the responsibility vacuum regime.

6.3 Romanchuk & Bondar (2026c) — AI Space Physics: Constitutive Boundary Semantics[^8]

The third paper extends the Romanchuk-Bondar program from failure-mode formalization toward a constitutive semantics for agent institutions that accumulate state and modify their future authority surface over time. The paper introduces a minimal state model with typed boundary channels, horizon-limited reach semantics, and a membrane-witness discipline, governed by a core law family (P-1, P-1a, P-1b, P-1c) that imposes witness completeness, non-bypass mediation, atomic adjudication-to-effect transitions, and replayable reconstruction.

This paper is conceptually adjacent to the present methodology in two specific ways, with important boundary qualifications:

1. Horizon-limited reach as conceptual predecessor. In AI Space Physics, Reach_H(s; A_adm) is a horizon-relative set of externally effective channel traces under an explicit admissibility profile, strategy class, policy-update semantics, and channel alphabet — not a binary label meaning “this failure path is reachable.” The Reachable class in the R/A/U classification used here can be read as an applied classifier inspired by that semantics, but it is a domain-specific simplification rather than the same construct. Where AI Space Physics defines reach with full formal apparatus, the present methodology produces a binary classification grounded in concrete adversarial sequences for a specific concrete domain (DeFAI agents under ERC-8004).

2. Membrane witness as discipline target, not achieved property. In AI Space Physics, a membrane witness is bound to a boundary-relevant transition through membrane adjudication, following the Decide → Anchor → Effect discipline with non-bypass mediation, atomic adjudication-to-effect coupling, and replayable reconstruction. A finding card in Section 3 of this report is evidence about a reachability claim, but it is not a membrane witness in the technical sense of the paper unless it is integrated into the transition semantics of the institution being governed — which is a stronger architectural requirement than post-hoc analytical reporting can satisfy on its own. Similarly, on-chain attestation via ERC-8004 can support witness integrity through durable publication, but it does not automatically instantiate the full witness discipline (completeness, binding to adjudication and action instance, non-bypassability, atomic anchoring with the external effect, replayability under declared policy/context assumptions). The witness requirements in the source paper are stronger than what durable publication alone provides.

The R/A/U classification used here is a domain-specific applied classifier informed by the boundary-crossing semantics developed in AI Space Physics, not a direct instantiation of those semantics. On-chain attestation in the present methodology supports witness integrity at the publication layer; it does not claim to satisfy the full membrane-witness discipline of the source paper.

6.4 Romanchuk (2026d) — IETF Draft on Normative Admissibility[^4]

A parallel IETF draft formalizes a four-modality framework for agent speech acts (ASSERTIVE / CONDITIONAL / REFUSAL / DESCRIPTIVE) with a license-derivation table grounded in axioms governing GroundSet scopes. The R/A/U classification operates on agent states rather than agent statements, and is therefore complementary rather than competing with the IETF framework. The boundary between the two frameworks is important: admissibility is not truth, and admissibility is not reachability. The draft evaluates whether a speech act is admissible given its modality and grounding; it does not verify semantic truth, domain validity, or state reachability. A future report will examine whether the two frameworks can be composed, but this remains explicitly tentative: a sequence of admissible ASSERTIVE statements may satisfy participation rules for agent speech acts, but that alone does not establish that a state is reachable. Reachability would still require independent state-level truth-makers and transition evidence.

6.5 Bondar (2026) — IETF Draft on Warrant Certificate Authorities[^9]

In a separately authored IETF draft, Roman Bondar (one of the co-authors of the Romanchuk-Bondar papers cited above) develops the Warrant Certificate Authority (WCA) framework: an end-to-end cryptographic attestation infrastructure that certifies data sources, not data content. WCA targets the AI-agent tool-call chain specifically: when an agent invokes external tools and consumes their outputs as input to subsequent reasoning, the question of what was the actual provenance of each datum entering the chain is structurally distinct from the question of whether the data is correct. WCA establishes the former without claiming to address the latter.

Three structural elements of WCA matter for the present report:

1. Channel-to-content trust conflation. WCA §2 identifies a failure mode where trust in a data source (the channel) is implicitly transferred to trust in the data content itself. The R/A/U classification used here operates analogously at the state level: classifying which states an agent can reach is structurally distinct from classifying whether each individual transition was executed correctly, and conflating the two reproduces a state-level analog of channel-to-content conflation.

2. Reference monitor properties: complete mediation, tamperproofness, verifiability (WCA §9.1, framed in the draft as Non-Interference properties NI-1, NI-2, NI-3). These three properties together describe what the present report calls observer-class evidence: an external classification authority must mediate every reach claim (complete mediation), cannot itself be modified by the agent (tamperproofness), and must produce attestations that downstream consumers can independently verify (verifiability). On-chain attestation via ERC-8004 contributes to these properties at the publication layer — durable, externally accessible, cryptographically signed — but does not automatically instantiate the full reference-monitor discipline of the WCA draft. The stronger requirements (complete mediation of every reach claim, atomic binding of attestation to adjudication and action instance, non-bypassability, replayability under declared policy context) are architectural goals that the methodology aims toward, not properties that publication alone confers.

3. Provenance vs. content as a layered trust pattern. WCA establishes that data provenance and data content correctness are independent layers of trust that compose without subsuming each other. The present methodology takes a structurally analogous position at the state-reachability layer: which-states-can-be-reached is distinct from whether-each-transition-was-executed-correctly, and a complete trust stack requires evidence addressing both. The analogy is structural, not an identity claim — WCA addresses data provenance through cryptographic attestation of sources, while the present methodology addresses state reachability through analytical classification of reachable failure paths.

WCA and the present methodology are conceptually adjacent primitives operating on different objects (data sources vs. agent states), drawing on structurally similar reference-monitor logic. They are complementary rather than identical; neither implements the other.

6.6 Adjacent Primitive: Privacy Layer (ACTA)

In May 2026 the Privacy Stewards of Ethereum (PSE) published ACTA — Anonymous Credentials for Trustless Agents[^5], a draft proposing a privacy primitive that sits above ERC-8004 without modifying it. ACTA addresses a specific gap in the base standard: ERC-8004’s NewFeedback event emits client address, agent identifier, and feedback value in plaintext, producing a permanent public interaction graph. For deployments where the interaction graph itself is sensitive (DeFi execution strategies, regulated jurisdictional data, cross-protocol vendor relationships), this transparency is an attack surface rather than a feature.

ACTA’s response is a composable architecture of credential anchoring, predicate verification, nullifier registry, and a ZK reputation accumulator that anchors blinded Merkle roots back into ERC-8004’s existing Reputation Registry. Agents prove claims — audit score thresholds, jurisdictional compliance, model provenance — without disclosing the underlying values.

ACTA and the present report are complementary primitives extending the same base standard along different axes:

• ACTA operates on the Reputation Registry and identity disclosure, addressing what gets revealed about an agent’s interaction history.

• The present methodology operates on the Validation Registry, addressing what can be known about an agent’s reachable state set independent of its own claims.

The two layers compose without conflict. An agent operating in a privacy-sensitive deployment can publish ACTA-mediated proofs that its credentials satisfy a verifier’s policy, while separately publishing methodology-mediated attestations that its reachable state set has been classified by an external validation engine. Neither layer subsumes the other; both are necessary for a complete trust stack on autonomous on-chain agents. The acknowledgments in the ACTA draft — which include co-authors of ERC-8004 — indicate that the base-standard authors are actively reviewing extensions of this kind, suggesting the primitive-layer pattern is the intended direction for ecosystem development rather than an idiosyncratic positioning.

6.7 Adjacent Primitive: Code-Level Security Analysis

A growing body of work applies AI to the static and dynamic analysis of smart contract code, including recent efforts to scan Ethereum execution and consensus client implementations against their formal specifications.[^6] The Sherlock AI platform, engaged by the Ethereum Foundation Protocol Security Team in early 2026 through a paid audit contest of Ethereum execution and consensus clients ahead of the Fusaka mainnet transition, is one such effort; its public performance update of May 2026 reports cumulative analysis across hundreds of thousands of lines of code, with deliverables organized at the repository level: scans for potential vulnerabilities, verification of exact code paths and triggers, and grouping of duplicate findings into per-repository issue lists.[^7]

This work is valuable and necessary; it occupies an adjacent rather than overlapping position to the present report. The distinction matters and is worth stating precisely.

Code-level security analysis asks whether a given contract or client implementation behaves as its specification or developer intent describes — does the code do what it says. The unit of analysis is the repository; the deliverable is an issue list against that repository.

Epistemic state validation as defined here asks a different question: given an agent that operates by composing tool calls into the broader environment, which states in that environment can the agent actually reach, regardless of whether each individual contract or model call behaves correctly in isolation. The unit of analysis is the agent’s execution surface as a whole; the deliverable is a classification of states (R/A/U) anchored as an external attestation.

Concretely, in the Olas DeFAI case examined in Sections 1–5: every contract a DeFAI agent interacts with may pass a code audit, every client implementation may match its EIP specification, and the agent’s own reasoning model may produce locally coherent outputs — and the agent may still reach an unintended state in production because the composition of correctly-behaving components opens reachability paths the individual audits did not consider. This is exactly the dynamic SYS-01 (oracle-induced misallocation) and SYS-03 (depeg propagation) describe: each integrated protocol works as specified, yet the composed agent reaches loss states no individual code audit would catch.

The two layers are complementary. A complete trust stack for autonomous on-chain agents requires both code correctness (the contracts and clients work as specified) and state reachability bounds (the agent operating over those contracts cannot reach states outside its warranted surface). The present methodology addresses the second; existing AI-driven code analysis efforts address the first.

6.8 The Emerging Primitive Stack on ERC-8004

Read together, ACTA, the WCA framework, the Sherlock-class code analysis efforts, and the methodology presented in this report describe an emerging architecture in which ERC-8004 functions as a base standard with multiple non-modifying extensions, each addressing a distinct trust property:

Each layer is independently useful, and each is composable with the others through the registries ERC-8004 already provides. The present report contributes the fifth row of this table.

6.9 Positioning Statement

This report does not claim to have discovered the failure modes Romanchuk and Bondar formalize across their five publications cited above. The theoretical work predates this report by approximately three to four months and stands on its own terms. The contribution offered here is narrower and applied:

• Operational methodology (the Epistemic Evolution Engine) for executing R/A/U classification on a specific agent class.

• Domain instantiation in DeFAI vault architectures under ERC-8004, with Olas Modius/Optimus as the case study (Sections 2–4).

• Distribution mechanism for the resulting attestations via on-chain Validation Registry posting and x402-signed delivery.

In the terminology developed across the Romanchuk-Bondar publications, the present report is an exercise in operationalized applied response: drawing on a body of theoretical work that develops a linguistic and architectural apparatus for locating where warrant is lost, transformed, or falsely upgraded inside agent systems (semantic laundering); diagnoses the organizational condition in which decisions occur without aligned authority and verification capacity (responsibility vacuum); formalizes constitutive semantics for agent boundary crossings (AI Space Physics); specifies admissibility constraints for agent speech acts (normative admissibility framework); and establishes reference-monitor properties for data provenance (WCA). The present report builds one specific applied instance — at the state-reachability layer of ERC-8004, in the DeFAI agent domain — without implying that the theoretical authors have reviewed, endorsed, affiliated themselves with, or proposed this implementation. The conceptual debt is acknowledged through citation. The applied architecture, the choice of finding-card format, the R/A/U binary classification, and the on-chain attestation distribution mechanism are the present author’s design decisions, not constructs established by the cited work. The engineering implication drawn from the source theory is not that an external validator “solves warrant,” but rather: do not hide warrant failure inside tool boundaries; type epistemic roles explicitly; isolate validation claims; make them traceable, inspectable, and contestable. The methodology and report should be evaluated on whether they meet that engineering implication, not on whether they instantiate the source theory’s full formal apparatus.

Parallel applied work extending the same R/A/U classification framework to industrial R&D hypothesis validation — particularly in domains where AI-derived discoveries face pre-publication scrutiny — is forthcoming under the Hypothex domain.

Appendix A — Methodology Note: The Epistemic Evolution Engine

This appendix expands on the framework principles introduced in Section 1.2. The intent is to convey what the methodology requires of any analysis applying it, not how the validator’s pipeline implements those requirements internally. The framework is applicable to any agent class with a definable execution surface; the particular implementation that produced this report is the validator’s proprietary tooling.

The framework treats validation as a falsifiable scientific process rather than a checklist exercise. Each hypothesis is a testable claim about system behavior under adversarial or stressed conditions. The framework distinguishes itself from pattern-match-based automated auditors by explicitly modeling reachability — the question is not “does this pattern appear in the code” but “does an adversarial path exist that triggers the claimed failure, and what is its minimal form.”

Three discipline points are non-negotiable for any analysis to qualify as EE-compliant:

• No fabrication. Claims without traceable citations (to documentation, observable on-chain behavior, or explicitly labeled assumption) are rejected. The framework treats any unsourced claim as inadmissible until grounded.

• Unrecoverability is primary. Severity is modulated by recovery path availability. Losses that cannot be undone are treated categorically differently from losses that can be reversed by subsequent action. UNRECOVERABLE-flagged paths drive priority above all other considerations.

• Minimal counterexamples are mandatory. A hypothesis without a concrete adversarial sequence and economic parameters is not accepted as Reachable. Abstract risk language is downgraded to Assumption-bounded until concretized.

These three discipline points constitute the public face of the framework. Operational details — how hypothesis candidates are enumerated, how AdversarialCritic counterarguments are generated, how minimal counterexamples are extracted, what scoring heuristics convert qualitative analysis into numerical scores — are implementation choices made by the validator and may differ across implementations of the same framework. What is portable across implementations are the three discipline points above and the R/A/U classification structure they enforce.

Appendix B — Glossary

• R/A/U: Reachable / Assumption-bounded / Unreachable — classification of attack paths.

• UNRECOVERABLE: A path whose realization permanently impairs capital, with no on-chain recovery action available to the affected party.

• DeFAI: DeFi × AI — autonomous agents managing on-chain capital.

• Pearl: Olas’s desktop-native application for running AI agents locally with self-custody.

• Safe module: A smart contract extension that grants specific execution permissions to non-owner addresses under defined constraints.

Appendix C — Scope Limitations & Paid Engagement Scope

This report is a public baseline validation produced without direct code access to Olas/Valory production systems. Hypotheses labeled Assumption-bounded (A) cannot be resolved to definitive R/U without either:

• (a) direct engagement with the operator team and access to current production code, or

• (b) extended on-chain forensic analysis of deployed instances with known addresses.

A paid validation engagement includes:

• Resolution of all A-class hypotheses to R or U with direct evidence

• Additional hypothesis cards specific to the engaged operator’s strategy configuration

• ERC-8004 Validation Registry entry with signed attestation

• 30-day re-validation on material strategy changes

On framework vs implementation. The Epistemic Evolution Engine described in Appendix A is the public methodological framework. Any analyst who applies the three discipline points (no fabrication, unrecoverability primacy, mandatory minimal counterexamples) under the R/A/U classification structure is operating in the EE tradition. The validator’s specific implementation — including hypothesis generation tooling, AdversarialCritic configuration, scoring heuristics, and continuous-monitoring pipelines — is proprietary and is offered as a service rather than a published artifact. This separation follows the convention in research-driven consulting: the framework is open and citable; the implementation is the engagement.

Contact: investportfel@gmail.com | Twitter: @getreacher | ERC-8004 agent ID: [to be assigned]

References

[^1]: Romanchuk, O. & Bondar, R. (2026). Semantic Laundering in AI Agent Architectures: Why Tool Boundaries Do Not Confer Epistemic Warrant. arXiv:2601.08333. Published January 13, 2026.

[^2]: Romanchuk, O. (2026). Your AI Agent Says “Tests Passed.” Did They? Medium, January 19, 2026. Available at medium.com/@romoleg.

[^3]: Romanchuk, O. & Bondar, R. (2026). The Responsibility Vacuum: Organizational Failure in Scaled Agent Systems. arXiv:2601.15059. Published January 21, 2026.

[^4]: Romanchuk, O. (2026). Normative Admissibility Framework for Agent Speech Acts. IETF Internet-Draft draft-romanchuk-normative-admissibility-00, January 6, 2026.

[^5]: zulu0echo et al. (2026). Anonymous Credentials for Trustless Agents (ACTA) — A Privacy Layer for the On-Chain Agent Economy. Ethereum Research forum, May 5, 2026. Available at ethresear.ch/t/anonymous-credentials-for-trustless-agents-acta/24797. The acknowledgments cite review feedback from Davide Crapis, Marco De Rossi, and others associated with the ERC-8004 base standard.

[^6]: For a survey of related code-analysis efforts, see the Privacy and Scaling Explorations (PSE) and Ethereum Foundation grant rounds covering security tooling for execution and consensus clients.

[^7]: Sherlock (2026). Sherlock AI Performance Update, May 2026. The Ethereum Foundation Protocol Security Team engaged Sherlock through a 28-day, $2 million audit contest ahead of the Fusaka mainnet transition; the cited Performance Update describes the system as scanning for potential vulnerabilities, verifying exact code paths and triggers, and operating at the repository level — confirming the categorical distinction between code-level analysis (the cited work) and state-level reachability analysis (the methodology of the present report).

[^8]: Romanchuk, O. & Bondar, R. (2026). AI Space Physics: Constitutive Boundary Semantics for Open AI Institutions. arXiv:2603.03119. Published March 3, 2026.

[^9]: Bondar, R. (2026). Warrant Certificate Authorities (WCA): Auditable Data Provenance for AI-Agent Tool-Call Chains. IETF Internet-Draft draft-bondar-wca-00, March 2026. Status: Informational, expires September 2, 2026.

Disclosure: Shared Surname

The author of this report is Oleksandr Bondar. One of the authors of the foundational theoretical work cited above is Roman Bondar, co-author with Oleg Romanchuk on the 2026 papers (arXiv:2601.08333 and arXiv:2601.15059).

We share the same surname. We are not related, have not previously met, have not collaborated, and the present author had no knowledge of Roman Bondar’s work prior to encountering the published papers in 2026. The convergence in surname is coincidental — Bondar is a common surname in the region of origin (cognate of “cooper” / barrel-maker, similar in commonness to “Smith” or “Miller” in English-speaking contexts).

The author’s GitHub handle is OleksandrBondarr (with a doubled r). This is a username artifact: the handle OleksandrBondar was already taken at the time of registration, so the doubled r was added as the simplest available variant. The doubled spelling appears nowhere in the author’s legal identity, ENS records, domain registration, or any other context. It is purely a GitHub username convention and should not be interpreted as an attempt to assert difference from Roman Bondar — there is no such difference to assert.

All theoretical claims attributed to Romanchuk and Bondar in this report — semantic laundering, the Theorem of Inevitable Self-Licensing, the responsibility vacuum, coordination-vs-verification contracts, the four-modality speech-act framework — belong to them. The present author’s contribution is narrower: the R/A/U classification structure, the Epistemic Evolution Engine methodology framework, and the SYS-01..SYS-08 findings applied here to autonomous DeFAI trader agents.

This disclosure is published proactively. Outreach to both Oleg Romanchuk (olromanchuk@gmail.com) and Roman Bondar (bondar.roman@gmail.com) — co-authors of the foundational papers cited above, and (in Roman Bondar’s case) sole author of the WCA Internet-Draft cited in Section 6.5 — was sent on 9 May 2026, before the present report’s public release on 14 May 2026. The intent of these communications is to disclose, not to imply collaboration: citations to Romanchuk-Bondar work in this report are bibliographic only and do not imply endorsement, review, approval, certification, affiliation, or collaboration by either author. Neither Oleg Romanchuk nor Roman Bondar has reviewed, validated, or endorsed Reacher as a methodology, the present report, or any associated validation service. Their published works are cited as theoretical foundation under standard academic citation practice.

This report is provided under Creative Commons BY-SA 4.0. It represents the analytical opinion of the validator at time of writing based on publicly available information. It is not financial advice and does not constitute a warranty of security. Operators and users should independently verify all findings.