Building a memory-powered financial decision assistant with Tatum, Sui Mainnet, and Walrus Memory

We have built payment systems that remember almost everything about a transaction.

The amount. The sender. The recipient. The timestamp. Whether the transaction succeeded.

But there is something important that most financial applications still forget

Every month the same charges come back: a cloud add-on nobody remembers ordering, a renewal that went up in price, a subscription that has not been used since March.

Somebody looks at each one, decides, and moves on. The decision gets made. The reason disappears.

The next time the same charge shows up, you start from zero.

A question like why was the transaction done in the first place comes up

Why did they approve a particular subscription? Why did they decline a recurring charge? Why did they decide that a payment was no longer worth making?

A transaction history can show what happened. It rarely preserves the reasoning behind it.

That question became the foundation for SpendMemory, a payment review application I built for the Tatum × Walrus Total Recall Hackathon.

The Problem: We Remember Transactions, Not Decisions

Imagine subscribing to a software service. You pay for the first month, use it for a while, and eventually decide it isn't worth renewing.

Maybe you barely used it. Maybe the price increased. Maybe you found a better alternative.

Whatever the reason, you decide not to pay again. Then, a month later, another payment proposal appears for the same merchant.

Your wallet knows how much SUI you have. Your transaction history knows what you've previously paid. But neither necessarily remembers that you already decided this subscription wasn't worth renewing.

That reasoning is gone unless you remember it yourself. Now multiply that problem across recurring subscriptions, vendor payments, services, and other financial commitments.

We have plenty of tools for tracking money, but comparatively fewer tools for preserving financial judgment. That distinction matters.

Knowing that someone declined a payment is useful. Knowing why they declined it is considerably more valuable.

I wanted to build something that could preserve both pieces of information and make them available during future reviews. Not an automatic payment executor. Not another spending dashboard.

A financial decision assistant with memory. That's how SpendMemory began.

Introducing SpendMemory

SpendMemory is a human-controlled payment review assistant built around the Sui blockchain. It combines three essential capabilities:

• Live blockchain context: Tatum retrieves current SUI balance information and can inspect existing transactions.
• Persistent decision memory: Walrus Memory stores decisions and recalls relevant history during later reviews.
• Transparent recommendations: A deterministic policy evaluates current financial information alongside historical decisions before presenting a recommendation.

The experience begins with a payment proposal. A user provides a merchant name, payment category, amount in SUI, and public Sui wallet address.

If the payment has already happened, the user can optionally provide its transaction digest for additional inspection. SpendMemory then checks the relevant blockchain data through Tatum and searches Walrus Memory for previously saved decisions associated with that wallet, merchant, and category.

It uses the results to produce one of three recommendations:

• Review manually: More consideration is needed.
• Consider approval: Relevant historical approvals and current conditions support considering the proposal.
• Decline or investigate: The available evidence suggests the payment should not proceed without further investigation.

The user always makes the final decision. They can approve or decline the proposal, explain why, and authorize saving that decision by signing a message with the wallet being reviewed. Once the memory is confirmed on Walrus Mainnet, it becomes available to influence future matching reviews.

The result is a continuous learning loop: Propose → Verify → Recall → Recommend → Decide → Sign → Remember → Recall Again

Unlike an ordinary payment dashboard, SpendMemory does not simply display financial activity. It preserves decision context and uses that context to improve subsequent reviews.

One boundary remains constant throughout the experience: SpendMemory never sends a payment.

It doesn't transfer funds, hold wallet keys, or sign financial transactions on the user's behalf. It helps people decide, but it does not spend for them.

Why Tatum and Walrus?

I needed two very different types of infrastructure. The first needed to answer questions about what was happening on the blockchain. How much SUI does the wallet currently hold? Did an existing transaction succeed? What balance changes were recorded?

The second needed to answer questions about what happened during earlier reviews. Had the user approved this merchant before? Had they previously declined it? What explanation did they save?

These are related questions, but they belong to different layers. Tatum provides the blockchain evidence. Walrus Memory provides the decision history.

SpendMemory combines them through an application-level recommendation policy. This separation was important because blockchain activity alone cannot describe the reasoning behind a financial choice, and historical reasoning alone should never override current financial conditions.

Both sources need to work together.

The application architecture

              PAYMENT PROPOSAL
                     |
           Merchant / Category
           Amount / Sui Wallet
           Optional Tx Digest
                     |
          +----------+----------+
          |                     |
          v                     v
     TATUM API             WALRUS MEMORY
   Sui Mainnet RPC          Mainnet Recall
          |                     |
     Live Balance          Previous Decisions
     Transaction Data      Wallet-Specific Matches
          |                     |
          +----------+----------+
                     |
                     v
           DETERMINISTIC POLICY
                     |
             Recommendation
                     |
                     v
               HUMAN DECISION
                     |
               Wallet Signature
                     |
                     v
             WALRUS MEMORY WRITE
                     |
             Confirmed Blob ID
                     |
                     v
              FUTURE RECALL

This is the foundation of SpendMemory's behavior.

Every component has a clear responsibility, and neither sponsor integration exists merely to satisfy a hackathon checklist.

Integrating Tatum: Bringing Real Blockchain Data Into Every Review

Tatum provides SpendMemory with access to Sui Mainnet blockchain information.

I integrated Tatum's Sui GraphQL endpoint: https://sui-mainnet.gateway.tatum.io/graphql

The application communicates with this endpoint from its backend, using the Tatum API key in the x-api-key request header. This keeps the credential out of the public frontend.

Live SUI balance verification

The first major integration is wallet balance retrieval. When someone creates a payment proposal, the backend queries Tatum for that wallet's native SUI balance. The result is returned in MIST and converted into a readable SUI amount.

This becomes one of the most important inputs to the recommendation policy.

Consider a wallet that previously approved several payments to the same merchant.

Those approvals may provide useful historical context. But imagine the wallet currently holds less SUI than the proposed payment requires.

A financial memory system should not ignore that fact.

In SpendMemory, insufficient balance triggers a decline recommendation, regardless of earlier approvals.

This is one example of how Tatum helps ground historical reasoning in present financial reality.

Optional on-chain payment inspection

I also integrated transaction lookup through Tatum.

If a user provides an existing Sui transaction digest, SpendMemory fetches its recorded effects, including execution status, checkpoint information, and SUI balance changes.

The application then evaluates whether the transaction succeeded, whether the reviewed wallet experienced an outgoing SUI balance change, and whether another address received the proposed amount. This provides supporting on-chain evidence for checking an existing payment.

The current reconciliation method has a limitation: correlated balance changes do not always prove the exact transfer relationship in complex transactions. Stronger transfer attribution remains an improvement for the next iteration. Still, this integration establishes an important distinction between a decision someone reports making and a decision accompanied by supporting blockchain transaction evidence.

Why the Tatum integration matters

Without Tatum, SpendMemory would rely primarily on user-entered information and recalled history. That wouldn't be enough for a financial review assistant.

A useful review needs to consider the current wallet state, not just what happened previously.

Tatum makes that possible without asking users to disclose private keys or authorize a payment. It gives SpendMemory the on-chain evidence layer needed to make its recommendations more grounded and understandable.

Integrating Walrus: Giving Financial Decisions a Memory

This is where the core idea becomes much more interesting. Tatum helps SpendMemory understand blockchain information.

But it doesn't explain why someone previously rejected a subscription or approved a payment. For that, the application needs memory.

I integrated Walrus Memory using the @mysten-incubation/memwal SDK. SpendMemory connects to the Walrus Memory Mainnet relayer and uses it to save, retrieve, and inspect persistent decision records.

What gets stored?

When someone records a decision, SpendMemory prepares a structured memory containing information such as:

• The merchant and spending category
• The proposed payment amount
• Whether the user approved or declined
• The reason they provided
• The proposal identifier and timestamp
• A wallet-derived identifier
• The wallet-signing status
• Relevant transaction evidence, when available

These records capture more than the result of a decision. They preserve the context that could matter later.

Writing a decision to Walrus

The hosted application submits a decision through Walrus Memory after the backend has verified the user's wallet signature. The write uses an idempotency key based on the proposal identifier to help prevent duplicate records. Walrus initially returns a write-job identifier. SpendMemory exposes that progress to the user, allowing the job to be checked until a confirmed blob ID becomes available. This is an important detail.

Submitting a write is not the same as proving that it has completed. A memory is treated as confirmed only when Walrus returns the corresponding blob ID. That confirmed identifier can then be used as evidence that the memory was persisted.

Recalling previous decisions

When a later payment proposal arrives, SpendMemory calls Walrus Memory to retrieve relevant historical records. It doesn't simply trust every returned memory. The backend filters results to ensure that they belong to the SpendMemory record format, contain valid decision information, and match the current wallet, merchant, and category. These checks keep the recommendation tied to relevant history rather than arbitrary retrieved content.

For instance, suppose a wallet previously declined a software subscription. When that same wallet reviews another proposal involving the same merchant and category, SpendMemory can retrieve the earlier decline. The recommendation engine can then use that historical decision as evidence for recommending further investigation or another decline.

This is the behavior I wanted Walrus to make possible. The memory is not merely stored. It actually participates in the next decision.

Building a Recommendation Engine That Explains Itself

An interesting part of SpendMemory is that I didn't use a large language model to decide whether someone should approve or decline a payment. The recommendation engine is deterministic. It evaluates a small set of explicit conditions, including the proposed amount, current wallet balance, configured review threshold, and matching historical approvals or declines.

The default review threshold is 25 SUI. A proposal above that threshold requires manual review unless an existing hard-stop condition already applies. If a wallet cannot cover the amount, the application recommends declining.

If matching previous declines outnumber approvals, the historical evidence can support a decline recommendation. If previous matching decisions were approvals without conflicting declines, and the wallet has sufficient funds, SpendMemory can suggest considering approval.

It also explains which conditions influenced the recommendation. This design choice matters because financial software should be understandable. Users should not have to guess why an application suggested a particular action.

And historical memory should never silently become permission to move funds. Memory informs the recommendation. It doesn't control the wallet.

Proving That the Application Actually Remembers

One of the most important questions I wanted to answer was whether Walrus Memory genuinely changed application behavior. Persisting records is useful, but it isn't the whole point of a memory-powered application. The critical test is what happens when a previously saved decision becomes relevant again.

For the initial Mainnet learning-loop test, I used a fictional software subscription called DemoCloud.

The proposal contained:

• Merchant: DemoCloud subscription
• Category: Software
• Amount: 0.02 SUI

On the initial review, the application returned a recommendation to review manually. I then recorded a decline decision and saved it through Walrus Memory.

The write completed on Mainnet and returned this confirmed blob ID: VpDjzjIwtRW1UQJ8LOrUjUp2rbfV-RaIU36yB8DNSdg

After restarting the application server, I evaluated the same scenario again. This time, SpendMemory recalled the earlier decline. The recommendation changed from Review manually to Decline or investigate.

That was the behavior I wanted to achieve. The earlier decision wasn't simply sitting in storage. It was retrieved, matched, and used to change a later review.

The original demonstration was performed before wallet-signature authorization was added to the current hosted application. It proves the earlier Mainnet persistence-and-recall loop, while the newer signed workflow extends that architecture with ownership verification.

You can explore the original result through the verified replay: https://spendmemory.vercel.app/?replay=1

Mainnet memory evidence

During development, the project also recorded 51 confirmed memories in its dedicated testing namespace. These are real Walrus Mainnet writes, but they describe explicitly fictional demonstration scenarios. They are separate from the public visitor-decision namespace and do not influence visitor recommendations.

The hosted application has also demonstrated confirmed decision writes through its production API. This distinction between real infrastructure activity and fictional demonstration content is deliberate. I wanted the evidence to show what had actually been proven, without implying that test data represented independent customers or genuine spending activity.

Introducing Wallet-Signed Decision Memory

As the application evolved, I encountered an important design problem. In an earlier implementation, decision memory was shared across visitors. If two different people reviewed the same merchant and category, one person's previous decision could influence the other's recommendation. That wasn't the behavior I wanted for a personal financial memory system.

The first improvement was wallet-specific memory matching. SpendMemory began associating each saved decision with a derived wallet key, generated using SHA-256 over the normalized wallet address. The backend then restricted recommendation history to memories associated with the wallet currently being reviewed.

But that still left another problem. Anyone can know a public wallet address. If a user could enter any address and save decisions for it, wallet-specific matching alone wouldn't establish ownership. So I introduced wallet-signature authorization.

How signed decision saving works

Anyone can still review a public Sui address. But saving a new decision now requires the wallet being reviewed to sign a message. The application uses @mysten/dapp-kit-react for wallet connection and signing, with @mysten/sui handling server-side signature verification. The wallet interaction loads on demand when signing is required, rather than forcing every visitor to connect before reading a review.

The signed message identifies the wallet address, proposal, selected decision, reason hash, and expiration time. The backend reconstructs the expected message from its signed proposal ticket and verifies the supplied signature against the reviewed wallet. This helps ensure that a different wallet cannot simply add decisions to someone else's memory history through the normal hosted API.

The signature is a personal-message signature. It does not authorize a token transfer, and signing the memory message does not require paying a transaction fee. The application also supports Sui's signature-verification mechanisms, including zkLogin handling in its backend verification path.

This was a meaningful step toward making SpendMemory's memories belong to the wallets whose decisions they represent.

Protecting the Reasons Behind Decisions

Another improvement concerned how historical reasons were returned. A financial decision can contain sensitive context. Someone might explain why they rejected a payment, canceled a service, or no longer trusted a particular merchant. Even if the wallet address is public, that explanation shouldn't automatically appear in every public review.

The latest SpendMemory implementation separates the recommendation evidence from the full written reason.

Public review: show the decision, not the note

A regular review can retrieve the number of matching past decisions and whether those decisions were approvals or declines. That information is enough for the deterministic recommendation engine to evaluate the historical pattern. But the normal evaluation response does not return the stored reason text.

Signed access: reveal the saved reasons

If the wallet owner wants to see their previously recorded explanations, they can connect the matching wallet and sign a separate view-only message. The backend verifies that signature before returning the matching reasons through the dedicated API action. The message is different from the one used to save a decision. It does not create a new memory or initiate a payment.

This introduces application-level access control over the most personal part of the decision history. There is an important technical boundary: the notes are stored as ordinary memory text rather than encrypted payloads. The signature gate restricts access through SpendMemory's API, but it is not an end-to-end confidentiality guarantee against direct access to the underlying stored data. For a production financial application, encryption and stronger storage-access controls would be important next steps.

Making the Evidence Visible: The Walrus Proof Ledger

A hackathon project should make its technical claims easy to inspect. That's why I also added a live proof ledger to the SpendMemory replay page. The ledger reads decision records from the hosted Walrus visitor namespace and shows selected public evidence. For each available record, it can display the decision outcome, category, date, confirmed blob ID, and whether the decision was saved with wallet-signature authorization. When the application has recorded supporting Tatum payment evidence, the ledger can also link to the relevant transaction on Suiscan.

To limit unnecessary exposure, the ledger deliberately omits merchant names, written reasons, and wallet-derived identifiers. This provides a clearer separation between evidence that can be shared publicly and personal decision context.

It also makes the integration easier to understand. A visitor doesn't need to rely entirely on a README claiming that Walrus writes exist. They can inspect the ledger and the identifiers associated with saved visitor decisions. The original two visitor-namespace records were created before signature authorization existed and are distinguishable from newer signed records.

Live proof ledger: https://spendmemory.vercel.app/?replay=1#ledger

For me, this is one of the more important presentation improvements. A memory-powered application should make it possible to inspect the evidence behind its core behavior.

The Technical Stack and Engineering Decisions

SpendMemory is built with a relatively focused stack.

I kept the integration code separate from the application policy. The Tatum and Walrus clients live primarily in server/integrations.js.

The recommendation rules and payment reconciliation are implemented in server/policy.js. The hosted API lives in server/hosted.js, which coordinates evaluation, signed memory writes, signed reason retrieval, the public proof ledger, duplicate protection, and write limits. Wallet message construction is isolated in server/save-message.js. The frontend communicates with the API, while the wallet-signing interface is loaded only when needed.

Testing and verification

The latest repository verification log reports 32 passing automated tests. These cover the recommendation logic and hosted API, including important signature-authorization and reason-access cases.

The project also documents production checks for Tatum queries, Walrus Mainnet writes, confirmed job IDs, and the public proof ledger. The wallet-signature implementation was tested with real cryptographic keypairs in a controlled environment, including rejection of signatures from the wrong wallet and signatures for altered decisions.

A complete, independently reproduced end-to-end save using an installed browser wallet on the latest production build remains a separate verification milestone. This is an important distinction between testing the implementation and claiming that every possible public-wallet flow has already been demonstrated.

Challenges and Lessons From Building SpendMemory

Building SpendMemory taught me several things about memory-powered applications.

Storing data is easier than making memory useful

The number of stored records matters for proving integration. But the true value of memory comes from using the correct information at the correct moment. The defining SpendMemory result was the later recommendation changing after a previous decision had been recalled.

Financial memory needs identity

A decision history is less useful if unrelated wallets can influence it. The move from shared recall to wallet-scoped matching, and eventually wallet-signed writes, helped establish a more meaningful connection between recorded decisions and their owners.

Transparency and confidentiality are different problems

A public proof ledger can show that an application is storing records, but it shouldn't reveal more personal context than necessary. At the same time, hiding reasons behind an authenticated API does not automatically encrypt the underlying memory. Both evidence transparency and genuine confidentiality require deliberate engineering.

A predictable policy can be more valuable than an opaque recommendation

For the current product, deterministic rules make it easier to understand how current wallet conditions and historical decisions interact. That also makes the behavior easier to test and less likely to silently override an important financial constraint.

Mainnet infrastructure requires operational safeguards

The application has to handle pending write jobs, duplicate submissions, malformed input, expired proposal tickets, integration failures, and public write limits. These aren't the headline features, but they matter when turning a prototype into something visitors can actually use.

What Comes Next for SpendMemory?

The current version demonstrates a specific idea: Financial decisions can be preserved as reusable context rather than disappearing after each review.

There are several directions I'd like to explore next. One is stronger privacy, particularly encryption of stored reasons and more complete control over who can retrieve decision records. Another is improved payment reconciliation, with more precise verification of complex Sui transfers. I'd also like to explore recurring-payment detection, configurable spending policies, and better controls for reviewing outdated or conflicting memories.

Longer term, the same concept could become useful for financial agents. Imagine an agent proposing a payment while remembering that the wallet owner previously rejected the same service because it was unnecessary. Instead of repeating a questionable action, the agent could surface that earlier reasoning and request a new decision. Such an agent would still need clear permission boundaries and explicit payment authorization.

The interesting possibility isn't simply an agent that remembers previous actions. It's an agent that can use the reasons behind those actions to make future recommendations more understandable. SpendMemory is an early step toward that idea.

Final Thoughts: Transactions Record What. Memory Preserves Why.

We have spent years improving how financial systems transfer, record, and verify value. But making a payment decision often involves more than a balance and a transaction. It involves judgment.

Sometimes that judgment comes from a previous mistake. Sometimes from a useful experience. Sometimes from deciding that a service, merchant, or recurring expense is no longer worthwhile. Those decisions deserve more than a forgotten note.

With Tatum, SpendMemory can examine relevant on-chain financial information. With Walrus Memory, it can preserve and recall the context behind earlier choices. With wallet signatures, it can require authorization before new decisions are written to a wallet's memory through the hosted application. And with a transparent recommendation policy, it can combine those pieces without taking payment control away from the user.

The result is a financial review experience designed around something simple but often overlooked: The next time you make a decision, the reasoning from last time should still be there.

Because knowing what you spent is useful. Remembering why you chose to spend—or not to—is better.

Explore SpendMemory

Live application: https://spendmemory.vercel.app/

GitHub and source code: https://github.com/0xNexuz/spendmemory

Mainnet learning-loop replay: https://spendmemory.vercel.app/?replay=1

Walrus proof ledger: https://spendmemory.vercel.app/?replay=1#ledger

Hackathon: Tatum × Walrus — Total Recall

Track: Consumer Finance Apps

Built by: 0xNexuz

Built with Tatum, Walrus Memory, Sui Mainnet, React, TypeScript, and Vercel.