If you run support for a Sui app, you've answered the same ticket a hundred times. "My transaction failed and I don't know why." You open the explorer, find the abort code, look up what code 5 in big_vector means, and write back: your order was already filled before the cancel landed, only the gas was charged.
The next day someone else on the team gets the same ticket and looks it up again.
I built Ticketwise for the Total Recall hackathon to stop that loop. It's a support inbox that reads the failed transaction from the chain, explains it in plain words, and answers from what your team has already taught it. The teaching lives in Walrus Memory on Sui mainnet.
Live app: https://ticketwise-gamma.vercel.app
Demo video: https://youtu.be/ju1XZ-x7j0I
Code: https://github.com/kinnuworks/ticketwise
What happens when a ticket comes in
- Read the chain. The user's message usually has a transaction digest or a wallet address in it. Ticketwise pulls the transaction from Sui mainnet through Tatum's Sui gateway: status, abort code, module, function.
-
Name the error. Abort codes are just numbers on chain. I mapped 276 of them for DeepBook v3, Bluefin Spot and Cetus CLMM to the constant names in each contract's source, pinned to a commit with a link to the line. So code 5 in DeepBook's
big_vectorbecomesENotFound. -
Check memory. Every failure gets a stable key, like
deepbook::big_vector#5. Ticketwise recalls corrections for that key from Walrus Memory. If a teammate taught it before, the answer comes from them: what it means, what to tell the user, which queue owns it, with their name and the date. - Say so when it doesn't know. If nobody has taught it the error, it says "Nobody has taught me what this error means for your users yet." It doesn't guess.
Then you correct it once. The correction is written to Walrus Memory, and the next ticket with that error gets your answer.
There's also an escalation rule you can teach: "if the same wallet fails 3 or more times in a day, page on-call." It's stored in Walrus Memory like a correction and checked against the wallet's real failures, read through Tatum.
Does memory actually change anything?
I wanted a number, not a demo that only works on the example I picked. So I replayed real data.
I collected 661 failed transactions raised inside DeepBook, Cetus and Bluefin over 13 days (Oct 29 to Nov 10), all read through Tatum. I split them by time. From the first 435, Ticketwise was taught one correction per distinct error, using the meaning from the contract's source. Then it triaged the last 226 twice, once with memory off and once on.
- Memory off: 0 of 226 answered with anything the team taught. It can explain the abort code, and that's it.
- Memory on: 226 of 226 answered from a correction, all with the right meaning.
That 226 of 226 isn't luck. Every error in the later part had already shown up in the earlier part. That's the whole point. Support queues repeat. Thirteen days of real failures produced only 10 distinct errors, and all of them appeared in the earlier part. An error that only shows up later would stay unanswered until someone teaches it, and the scorecard page says so.
To check that the 226 wasn't baked in, I also played the same 661 failures forward one day at a time against an empty Walrus Memory namespace. Each day's tickets could only be answered from corrections taught on earlier days. Day one answered nothing, and the team taught the nine errors it had seen. From day two every ticket was answered, except on November 4, when a new error turned up and 67 of 71 were answered. In total, 595 of 661 tickets were answered from memory, with 10 corrections.
Why Walrus Memory and not a table in my database
A table would work for one server. But I wanted the team's knowledge to not belong to the server.
- You can check it. Every correction is a blob on Walrus mainnet. The Proof page lists them with Walruscan links.
- It comes back. The relayer keeps a search index over the memories. I added a check that deletes that index for a test namespace, shows recall coming back empty, then restores it from Walrus and recalls again. On the live deployment it restored 1 of 1 memories in 4.5 seconds.
- It's shared. Any app or tool on the same Walrus Memory account can read the same corrections.
The cost is write time. A remember takes about 20 seconds before it can be recalled, because the memory is encrypted, stored and registered on chain. The app tells you that while it saves, instead of pretending it's instant. Recall during triage takes about 3 seconds.
Keeping a public demo honest
The demo is open to anyone, and Walrus writes come out of a shared quota. So visitors write only to their own sandbox namespace, and the team namespace needs a passcode. Saves are rate limited per visitor, per IP and globally, and the durability check is teammates only. A judge can still do the full loop in the sandbox: triage, correct, triage again.
What's next
Ticketwise is also a read-only MCP server, so a coding assistant can triage a ticket or look up what support taught about an error, from the same Walrus Memory:
claude mcp add --transport http ticketwise https://ticketwise-gamma.vercel.app/api/mcp
Next: more apps' error maps, and intake from email and Discord instead of a paste box.
Ticketwise was built for the Total Recall hackathon (Tatum x Walrus Memory), Track 2: Smart Agents for Real Life.
Top comments (0)