At 13:05 UTC, Sui processed 1,438 eligible transactions at a median gap of 0 ms and a 90th-percentile gap of 213 ms. The memorable event was not a system-wide failure: just 27 transactions failed, or 1.88% of the minute, versus 8.36% across the frozen corpus.
The outlier was a single sender-boundary movement. At 13:05:28.694, address 0x672860…a90318d3 opened a liquidity position, with the boundary showing −516,208.483374365 SUI and −77,232.706561 USDC. Twenty-two seconds later, the same address closed a position in digest 4gVz3xjK; the boundary showed +516,208.842383664 SUI and +77,232.70656 USDC. That SUI movement was about 126.6 times the corpus’s per-asset 99th-percentile holding movement for this measure.
The two narratives describe a coherent-looking lifecycle. The opening transaction prepared funding, opened a position, added liquidity through a fixed-amount gateway, and transferred the resulting position object. The closing transaction attempted reward collection, then invoked close_position, which removed remaining liquidity and sent resulting balances to a supplied recipient. The evidence does not establish who controlled the transferred position, nor does it prove an exchange, yield, or profit. It establishes opposing boundary movements for the same address in two nearby transactions.
The minute’s repetitive backbone
For semantic percentages, the denominator is 1,422 rows after excluding 16 transactions that did not reach a usable whole-transaction explanation; chronology and totals use all 1,438 eligible rows. Of those 1,422 rows, 324 asserted cancel-order, 316 asserted place-limit-orders, and 225 asserted update-price—865 transactions, or 60.8%, concentrated in order-book and pricing activity.
The largest exact reusable patterns were owner-proof cancellations, with 315 of 1,422 rows, and owner-proof limit-order placement, with 253. One sender, 0xcde6db…6c0e04, supplied 427 of the 1,438 transactions. That concentration and the zero-millisecond median gap are consistent with highly automated or batch-like execution, but the records do not establish whether the address represents a bot, a person, or an organisation.
The activity was also sponsored 339 times. A separate gas owner therefore paid for roughly 23.6% of the minute’s transactions; sender and gas owner should not be treated as the same identity in those rows.
What actually failed
The dominant failure boundary was pyth::check_price_is_fresh: 12 of 27 failures stopped there. Another seven stopped at validation::check_min_amount. Digest 59Hd7aok shows the sequence clearly: verification, preparation of price information, an attempted price update, and then a Move abort at check_price_is_fresh with code 3. Its state records the attempted composition, not a completed price update.
That transaction called two revisions whose earliest stored uses in this corpus fall here, 0x8e4743…a718a1 and 0xfc9b05…4ace73. Fourteen exact revisions have minima in the minute, but observation began only at 13:01:48.968 UTC. The count does not establish that those revisions were deployed at 13:05, and their presence does not show that they caused the failures. In 59Hd7aok, application changes were rolled back after the abort while 0.000706932 SUI was still charged as gas. This matches Sui’s documented all-or-nothing transaction semantics for Move aborts ([Sui technical paper](https://docs.sui.io/paper/sui.pdf)).
So the best-supported reading is narrower than “the market broke”: a dense order-management stream continued while a small, repeated cluster of price-freshness and minimum-amount checks rejected attempts. The minute’s largest movement came from a rapid open-and-close liquidity sequence, not from evidence of a proven trade or profit.
For a closer look, start with DGExtYp8 and 4gVz3xjK, the paired liquidity transactions from 0x672860…a90318d3; then compare 59Hd7aok with revisions 0x8e4743…a718a1 and 0xfc9b05…4ace73, first stored here but not proven newly deployed.