Reading activity

Implemented

Every sync outcome is recorded, including the ones where the vault declined to trade.

#Skips carry the same weight as executions

A vault that declines to copy a trade emits an event saying so, with the reason. This is the difference between a system you can audit and one you have to trust: without recorded skips, a vault that mirrored nothing for a week would look identical to one that had nothing to mirror.

Each activity row carries:

the source's profile image, display name and handle
the token, with its symbol
what the source did — the balance delta it produced
what the vault did — mirrored, reduced, or declined with a reason
the amount
the block and time
a transaction link
whether the row is final

#Finality

Robinhood Chain is an Arbitrum Orbit chain. The sequencer gives fast soft confirmation, but an L1 reorganisation can still reorganise unfinalised L2 blocks.

Rows recent enough to be at risk are labelled unfinalised. They are shown, because hiding them would be misleading, and labelled, because presenting them as settled would be worse.

#Skip reasons

The interface glosses every reason in plain words while keeping the contract's own enum name available. A few of the common ones:

Reason	Meaning
`NoChange`	The source's balance matched the accepted snapshot. Nothing to do.
`AssetNotApproved`	The asset is not on the approved list. Recorded as visible divergence and never bought.
`BelowDustThreshold`	The proportional trade was too small to be worth its gas.
`ExposureCapReached`	Buying more would breach the position concentration cap.
`CashBufferWouldBreach`	Spending more would eat the reserve that keeps in-kind exit cheap.
`PriceStale`	The price adapter refused to stand behind a number.
`LiquidityTooLow`	The pool cannot absorb the size at an acceptable price.
`EntryImpactTooHigh`	Executing would move the price further than the ceiling allows.
`SlippageExceeded`	Execution would return materially less than quoted.

The full list is in Error reference.

#Where the data comes from

Live vault state — balances, snapshots, pause flags, NAV — is read directly from chain on every request. Activity for the last 24 hours is also read from chain, into a rolling in-memory log that back-fills once and then tails new blocks; a chain with ~100 ms blocks cannot be scanned from genesis on demand, so that window is bounded. Receipt history reaches further: it is served from the indexer where one is running, and falls back to the same 24-hour log when the database cannot be read. Every receipts response carries a coverage object naming which source answered and whether the window is degraded, so a shortened answer is never mistaken for a complete one. See Indexer.