The route assembler that kept missing its final handoff

For this frozen window, 0x7081aa…173bbd looks less like a participant following one fixed route than a route assembler repeatedly attempting vault-backed, multi-venue cycles. Across its complete history of 71 transactions, it used 68 distinct ordered call sequences. Forty-five failed, and 43 of those failures stopped at vault::deposit_with_threshold_and_event.

The detailed latest-500 stream also contains all 71 transactions here, so the examples below are not drawn from a partial historical sample. This address was never sponsored: the sender paid gas in every transaction, and the gas owner was the same address.

Sparse rhythm, changing shape

The activity ran from 13:27:45 to 23:23:53 UTC, with a median gap of 323,845.5 milliseconds—about 5 minutes 24 seconds—and a 90th-percentile gap of 18 minutes 36 seconds. The longest idle period was about 39 minutes. Its busiest minute, 16:05 UTC, contained only two transactions.

Failures arrived in runs of up to eight. The longest uninterrupted run without an execution error was three. That combination—long pauses, repeated route construction, and short-lived runs of failure or success—is consistent with software-driven orchestration, but the address alone does not establish a bot, person, operator, or strategy.

A repertoire of attempted routes

Only 22 of the 71 transactions received a reusable whole-transaction route description, covering 19 route variants. The other 49 received prose about connected calls without a whole-transaction behavior label. Their traces frequently mention exchange-related functions, but the retained evidence does not always identify the venue function or establish the transaction’s final economic purpose.

Three transactions show the range:

• 9tGpgAoM began with a vault withdrawal, continued through a pool purchase, a reverse-direction router call, balance conversions, and a deposit. It submitted and guarded on 40.357142857 SUI, then aborted at the deposit. Because the transaction aborted, the earlier application calls were rolled back; the trace proves an attempted route, not a completed exchange.
• 4TCe8PKU completed a seven-step route involving a vault withdrawal, WAL/USDC and WAL/SUI conversions, a pool purchase, and a thresholded deposit. It submitted and guarded on 10 USDC. Its execution completed without an error, but the stored explanation still does not establish that an exchange occurred or what the sender ultimately received.
• DmpWJsmd submitted and guarded on 20 USDC, touched DEEP, WAL, and SUI, and reached an unresolved deepbookv3::swap_b2a_v2 call before failing at the vault deposit. Its boundary movement shows an inflow of 0.000330232 SUI; that is a recorded sender movement, not evidence of a payout or profit.

What actually moved

The complete-history aggregate records SUI only. In the gas accounting, the sender paid 0.188264504 SUI and received 0.000330232 SUI back, for a net gas movement of −0.187934272 SUI. In the separate holding accounting, the corresponding gross outflow was 0.187163946 SUI against the same 0.000330232 SUI inflow, for a net of −0.186833714 SUI.

Those two accounting views overlap: gas can also appear as a holding change, so they must not be added together. Route prose mentions USDC, DEEP, WAL, and other assets, but no transaction-boundary value in those assets is proven for the sender by this record. There are no prices, so the data cannot establish profit or loss.

The strongest reading is therefore narrow: during this ten-hour window, this address repeatedly attempted varied vault-funded routes, often reaching a final deposit boundary that failed. It shows persistence and route diversity, not a proven exchange result or identifiable operator.

Useful starting points are 9tGpgAoM, 4TCe8PKU, and DmpWJsmd; the recurring terminal call is 0xf0b2cc…c9d5c6::vault::deposit_with_threshold_and_event.