A Sui naturalist that gets graded by the chain: building RIMBA for Tatum Walrus

RIMBA is a naturalist agent that guesses what big Sui wallets will do next, gets graded by the chain minutes later, and remembers the result in Walrus Memory. This post is about how it keeps score, and what the score says so far.

Repo: https://github.com/edycutjong/rimba · Live reef: https://rimba.edycu.dev · Demo video: https://youtu.be/7qJOvaxraEQ (recorded 7–8 Nov on development data, before Walrus Memory went live)

Data mode, up front. This write-up is for the Walrus × Tatum Total Recall hackathon. The headline scorecard counts only rounds streamed through Tatum's Sui gRPC gateway and recalled from Walrus Memory. Tatum went live on 7 Nov 15:39 UTC and Walrus Memory on 8 Nov 03:12:53 UTC. Earlier rows (Sui's public fullnode, or a local memory stand-in) are labelled development data and never counted. Figures below are frozen at the 10 Nov re-freeze, 12:37:50 UTC; the logger keeps running.

The problem

A watcher sees a large wallet move for the fifth time today and has to guess, again, whether it moves again. Nobody scores those guesses, so nobody learns whose read to trust. On Sui a "what happens next" question can be answered in minutes from the chain itself, which makes it a good place to build an agent whose memory is graded.

What it does

For every large transfer on the mainnet checkpoint stream, RIMBA writes a sighting. Plain code, with no LLM in the call path, turns it into a species sentence: size bucket, round or odd amount, number of recipients, time of day, new or repeat counterparty, the wallet's recent pace, how often it was seen before, and the coin.

The naturalist then recalls similar field notes from Walrus Memory, calls "this wallet moves again within 15 minutes: yes or no" with a probability, and records which notes it cited. The same stream resolves the call. The outcome is written back to Walrus as a new note, so the next similar sighting can get a different answer.

How it uses Tatum and Walrus

• Tatum Sui gRPC. SubscriptionService/SubscribeCheckpoints is both the source of sightings and the resolver; LedgerService/GetCheckpoint and GetTransaction back the pnpm verify command that re-derives outcomes from the chain. The .proto files are vendored from MystenLabs/sui-apis, and the endpoint is a one-line switch, so I built and tested the whole decode path against the public fullnode first.
• Walrus Memory. recall is widened to log near-misses, but only notes within the cut-off (0.35 for Walrus) vote, otherwise the agent abstains; scoringWeights is set so newer notes win; rememberBulk writes outcomes. Live since 8 Nov: 479 outcome notes stored on Walrus by the freeze. Recall failures tripped RIMBA's circuit breaker 8 times (3 failures → 60 s without memory). Memories are immutable, so a changed habit is a newer superseding note rather than an edit.

How it scores itself

Every round freezes three predictions at the same instant: the memory call, the global base rate, and that address's own frequency table. The score is a Brier score, the mean of (p − outcome)²; always guessing 0.5 scores 0.25, and lower is better.

The core of the call is small. Each cited note votes with a weight that falls with its semantic distance, the vote is shrunk toward the base rate, and the agent abstains if the total evidence is thin:

const w = 1 - r.distance / o.maxDistance; // in (0, 1] wy += w * note.yes; wn += w * note.n; // ... if (wn < (o.minEvidence ?? 0)) return { p: base, call: 'abstain', abstainReason: 'too-little-evidence' }; const p = clamp((wy + k * base) / (wn + k)); 

Abstain thresholds live in config/rimba.json. The local stand-in's were set on development rows. The Walrus cut-off (0.35) was set before any live recall ran and has not been recalibrated; any change will be stated in the README.

The scorecard (Tatum stream × Walrus Memory)

Question: does the sender move again within 15 minutes? Re-freeze, 10 Nov 2026 19:37:50 WIB, 4,157 resolved headline rounds:

On wallets it has never seen, memory beats the base rate by half (50.9 % skill). On wallets it has seen before, the plain per-address frequency table beats memory, and across all rounds the two are close. The development rows, for comparison only (public fullnode, local stand-in): never-seen N = 1,130, 0.1085 against 0.1693; all 2,408, 0.1421 against 0.2370.

Two holes in the run, both disclosed in the README: 5 h 18 min on 7–8 Nov when the free Tatum credits ran out, and about 34 h on 9–10 Nov when the machine running the logger lost network. No rounds exist in those windows.

How to check it yourself

pnpm install pnpm test # 118 tests pnpm score # Brier tables pnpm verify # invariants I1-I3, then re-derive a sample of outcomes from the chain 

At this freeze the invariants hold on 8,053 logged calls (every cited note was written and submitted before the call that cites it: 139,859 of 139,859), and 50 of 50 sampled sightings and 50 of 50 sampled outcomes re-derive from the chain through the Tatum gateway.

Limitations

• Dev rows are never the headline, and the headline is one run of a few days with two outages. Read the N next to every number.
• "Moves again within 15 minutes" is partly a habit question, so the frequency table is hard to beat on known wallets.
• Gateway latency is unmeasured; the Tatum credit burn (about 30K/h on the full stream) is measured, and a burst of GetTransaction calls drew HTTP 429.
• Not every outcome becomes a note: writes have a 400-note-a-day budget (config/rimba.json), so the writer prioritises novel species and supersedes.

Code, live reef and demo video: https://github.com/edycutjong/rimba · https://rimba.edycu.dev · https://youtu.be/7qJOvaxraEQ