DEV Community: U W A I S E

SubSense: A Subscription Manager That Remembers Why You Kept It

U W A I S E — Tue, 10 Nov 2026 12:04:32 +0000

A design tool used twice a month can look like wasted money.

Unless those two sessions are when you deliver work to a client.

That is the gap I wanted to explore with SubSense: subscription trackers can tell you what you pay, but a useful renewal decision also needs to remember why you kept paying.

I'm building SubSense around a simple idea:

Remember the reason behind a decision, then reconsider it when the facts change.

The project is being prepared for the Tatum × Walrus Total Recall hackathon, with Consumer Finance Apps as its intended track. This post covers the working local experience, the integration design, and the live checks still outstanding.

Start with clarity, not another setup screen

Actual application UI with synthetic demonstration records-not live billing accounts or Mainnet evidence.

The first useful screen is a dashboard, not a request for provider API keys.

After signed wallet login, users can add subscriptions, review recurring costs, set a monthly budget, and see what is renewing. Online memory and AI are optional.

Some details matter more than they initially seem:

An annual plan is spread across 12 months when comparing commitments, but its upcoming bill shows the full charge.
A trial includes its future price, so “free today” does not hide next month's commitment.
A cheaper-plan or cancellation decision creates a follow-up. It does not pretend the provider has changed your account.
Budget scenarios are previews until the user explicitly records a change.

SubSense does not connect to a bank, cancel subscriptions, or send payments. It helps users decide; it does not act as if the decision has already happened.

What “learning” means here

I wanted the core learning loop to be inspectable, rather than asking a model to invent a financial recommendation.

In SubSense, learning means structured decision feedback. It is not model training or fine-tuning.

Here is the example used in the browser review:

Step	Information	Result
Before feedback	A $15/month design tool is rarely used and marked optional	Try a cheaper plan
User decision	Keep + Essential, with “Required for monthly client handoffs. Low usage does not mean low value.”	Save the decision and its reason
Next recommendation	The relevant saved decision is available	Keep, with the remembered context
New price	The same plan rises from $15 to $17-more than 10%	Request a fresh review

The feedback does not silently rewrite the service's importance or billing status. It changes the recommendation, not the underlying facts.

Synthetic records in the real Renewals screen. The recommendation change was verified locally; this screenshot does not demonstrate remote recall.

The recommendation engine uses the latest applicable decision within a 180-day relevance window. It ignores unrelated and future-dated records, and a price increase above 10% can reopen the question. Services explicitly marked essential remain protected.

That last point is important: memory should inform a decision, not freeze it forever.

A small stack with clear boundaries

The application uses React, TypeScript, Vite, and Express, with one server process and one port.

React + TypeScript
  ├─ Wallet-scoped workspace → browser storage
  ├─ Provider vault → browser-side encryption
  └─ Same-origin API requests
       Express → verified wallet session
         ├─ Tatum → read-only Sui data
         ├─ Walrus Memory → explicit decision save / recall
         └─ OpenRouter → optional, consented AI assistance

Subscription calculations and recommendations remain deterministic. USD amounts use integer cents; native-SUI amounts use integer MIST. A USD budget is not mixed with a SUI balance as though they were interchangeable.

The preview environment has no durable runtime database. Browser-local state makes the tracking experience work within that constraint, but it also creates an obligation: recovery must be explicit and understandable.

A wallet is identity-not an automatic vault unlock

Connecting a wallet is only the first step. The backend verifies a one-time personal-message signature before creating a session. Signing in costs no gas and does not authorize spending.

The workspace and provider credentials have different storage boundaries:

Data	Where it lives	Important limitation
Subscriptions and local decisions	Wallet-scoped browser storage	Unencrypted; not synchronized across devices
Saved provider credentials	Encrypted browser vault	Requires the original wallet identity and separate password
Unlocked provider credentials	Backend's temporary in-memory session	Available to the app server while unlocked
Selected online decisions	Walrus Memory integration	Explicit upload; not a complete workspace backup

The vault uses browser Web Crypto: PBKDF2-SHA-256 with 600,000 iterations, a fresh salt, and AES-256-GCM with a fresh IV. Authenticated additional data binds the ciphertext to the normalized wallet identity and Mainnet.

The password stays in the browser. Unlocking sends the decrypted provider keys to the app's backend; it is not a claim that the backend can never access them.

Signing out or locking removes backend credentials without deleting the saved workspace or ciphertext. Reconnecting the same wallet restores its local context, but the provider vault still needs its password.

Two exports are therefore necessary when moving devices:

Workspace backup: subscriptions, decisions, and the original profile ID.
Encrypted-vault backup: provider credentials, still protected by its password.

Wallet scoping is not a defence against someone or a malicious script with access to the browser. There is no vault-password recovery, and clearing storage without backups can lose local data.

Why the Walrus integration stores decisions

The useful memory is not just “this service costs $15.”

It is the combination of the service, price, decision, value assessment, timestamp, and reason. That gives future recommendations context they can actually use.

SubSense's Walrus Memory integration stores validated decision records in a profile-specific namespace:

subsense-<workspace-profile-id>

This means preserving the profile ID matters. Creating a new workspace is not the same as reopening the previous profile's memories.

The implemented upload path uses a profile-and-decision idempotency key. A simplified excerpt of the SDK call looks like this:

client.remember(JSON.stringify(decision), namespace, {
  idempotencyKey: `${namespace}:${decision.id}`,
  dedupe: true,
});

Uploads require confirmation. An accepted job is shown as pending, not as a successful Mainnet memory. The application records completed storage only when the job reports done and returns a blob ID for the matching namespace.

Recall is also explicit. Returned text is validated as decision data—not treated as instructions-and valid records merge by decision ID rather than duplicating history. Recall is bounded to 50 relevant results, so it is not an account-wide export or full recovery system.

There is also a privacy boundary worth stating plainly: the relayer processes decision plaintext before encrypted storage. “Encrypted storage” does not mean nobody involved in the upload can see the content. Private client details and secrets do not belong in public demonstration memories.

What Tatum contributes

Tatum's role is the read-only Sui data layer, separate from the subscription recommendation engine.

The Mainnet adapter is implemented for native-SUI balance reads and verification of existing transactions through Tatum's Sui GraphQL endpoint.

A transaction check is deliberately strict: the digest must match, execution must succeed, balance-change data must be complete, and the recipient's net increase must satisfy the requested amount. The check also validates the UTC payment date and an optional sender.

That is transfer evidence, not proof that a subscription vendor recognized a payment. It does not execute a transfer, and it does not make SubSense an autonomous payment agent.

AI helps explain-it does not take control

Optional OpenRouter assistance can answer questions, explain selected subscriptions, plan renewals, or search selected context semantically.

It does not replace the deterministic recommendation rules or edit subscriptions on its own.

Each request requires explicit sharing consent. The app sends the question and selected, validated context rather than the entire workspace. Wallet identifiers, credentials, payment evidence, and remote receipts are excluded from that context.

Routing is limited to allowlisted free models with zero price caps and no paid fallback. Strict privacy routing is the default. Some free-model endpoints may not satisfy it; the app does not silently weaken the policy to make a request succeed.

Free availability, quota, and provider policies can change. Those are real limitations, not details to hide behind an “AI-powered” label.

The wallet-switch bug that made recovery better

One of the most useful review cases was switching wallets A → B → A while requests were in flight.

Comparing only the current wallet address is not enough. An old request from A can finish after the user returns to A, making stale data look current.

The API client now captures a wallet generation alongside the expected address and rejects the result if either changed:

// Capture these before sending the request.
const expected = walletAddress;
const generation = walletGeneration;

// Check again before applying its response.
if (expected !== walletAddress || generation !== walletGeneration) {
  throw new Error('Wallet changed during the request. No result was applied.');
}

Wallet-scoped workspace keys were also aligned with the same address normalization used by login and the vault. Short, padded, and mixed-case representations should identify the same workspace-not accidentally create different ones.

In the browser fixture, wallet B showed neither A's subscriptions nor its vault prompt. Returning to A restored its original profile and reason with the vault still locked. A wrong password preserved the ciphertext; the correct password unlocked it without rewriting it.

What is verified-and what is not yet

The latest local verification passed 90 automated tests, TypeScript checking, a production build, and an isolated production HTTP smoke test. All eight screens were checked at 390, 768, and 1440 CSS pixels in both themes: 48 geometry checks with no document horizontal overflow.

Those tests use generated unfunded wallets, local servers, and mocked provider responses. They verify application behaviour, not real Mainnet integration success.

At the time of writing, the live evidence still outstanding includes:

Signed login using the intended real wallet extension.
An authenticated Tatum Mainnet read.
A real completed Walrus write and recall after reconnecting.
The hackathon's required 10+ completed Mainnet memories.
Real-key AI inference and the hosted demo.

Two Vite/esbuild dependency audit findings also remain-one moderate and one high. Public demos should serve built assets rather than expose the development server, but that is not a substitute for fixing the dependencies or conducting a security review.

I want the evidence boundary to be visible: a passing mock test and a genuine completed Mainnet memory are different things.

What I learned

The biggest lesson was that a memory feature is only useful when it changes a visible product decision.

“We stored some text” is not the same as “the next renewal recommendation understood why this tool mattered.”

The second lesson was that remembering and recovering are different problems. Local workspace storage, an encrypted credential vault, and remote decision memory each need their own lifecycle and recovery story.

SubSense began from a friend's SpendGuard scaffold. That foundation deserves attribution; the work described here focuses on SubSense's decision-feedback experience, wallet-specific recovery, provider boundaries, and verification. The visual direction was inspired by Goodface's Emerald24 case study, without including its artwork or branding.

The goal is not a finance app that makes more decisions for you. It is one that helps your next decision begin with the context you already worked out.

What would you want a subscription manager to remember: usage, budget trade-offs, work dependencies-or something else?

Building Keeva: Client-Side Encryption and Persistent Vault State with Tatum and Walrus Memory

U W A I S E — Tue, 10 Nov 2026 11:46:07 +0000

A technical walkthrough of a credential vault built for the Total Recall - Tatum × Walrus Memory Hackathon.

Remembering a user is not the same as securely restoring their private data.

For a credential vault, persistence raises several difficult questions: Where does encryption happen? What authorizes access? How does the application identify the correct vault after a wallet reconnects? What happens when a password changes, two devices edit the same record, or a storage request succeeds but its response never arrives?

I built Keeva to explore these questions during the Total Recall - Tatum × Walrus Memory Hackathon, held from 20 October to 10 November 2026.

Keeva stores passwords, API keys, and private notes as client-encrypted records. It combines a Sui Mainnet wallet for authorization, Walrus Memory for persistent storage, and Tatum for blockchain reads and transaction checks.

The central architectural choice is straightforward:

Storage receives ciphertext. The browser reconstructs the usable vault after explicit authorization.

This article explains that implementation, how persistent memory changes the application’s state over time, and the boundaries that remain.

1. Separating identity, encryption, storage, and blockchain reads

Keeva does not treat “connected wallet” as a single permission that unlocks everything.

Instead, the application separates several responsibilities:

Component	Responsibility
Sui wallet	Supplies the connected account and personal-message signatures for authorization and supported key-derivation flows.
Browser cryptography	Derives vault keys, encrypts records, authenticates ciphertext, and decrypts authorized data.
Walrus Memory SDK	Authenticates delegated storage requests and persists or retrieves encrypted envelopes.
Tatum integration	Checks Sui Mainnet identity, reads network telemetry, and supplies transaction/checkpoint evidence.
Vault projection	Reconstructs current credentials from validated immutable revisions.
Local browser storage	Retains encrypted gateway profiles, ciphertext caches, pending encrypted operations, and continuity checkpoints.

This separation matters because identifying a wallet does not automatically provide the correct storage configuration or authorize decryption.

A user can connect the correct wallet while selecting the wrong memory account or namespace. Conversely, a valid storage delegate does not mean the application should expose credential plaintext without the vault’s unlock material.

Keeva checks these concerns separately.

2. Encrypting before data reaches Walrus Memory

Keeva uses the browser’s Web Crypto API for its application-level encryption.

The current implementation uses:

AES-256-GCM for authenticated encryption.
A fresh, randomly generated 96-bit IV for each encryption operation.
A 128-bit authentication tag.
PBKDF2-SHA256 with a minimum of 600,000 iterations.
A random 32-byte salt for key derivation.
Non-extractable Web Crypto keys.

AES-GCM authenticates the encrypted content and its associated context. A damaged ciphertext, incorrect key, or mismatched context causes decryption to fail rather than producing data that the application accepts.

The core operation is:

const iv = crypto.getRandomValues(new Uint8Array(12));

const encrypted = await crypto.subtle.encrypt(
  {
    name: 'AES-GCM',
    iv,
    additionalData: utf8.encode(context),
    tagLength: 128,
  },
  key,
  utf8.encode(JSON.stringify(record)),
);

The context is important. Keeva binds encrypted records to identifiers such as the memory account, namespace, vault, credential, and revision.

A ciphertext should not become a valid record merely because someone places it in another storage location.

Protecting the whole credential

Encrypting only a password would still expose useful information about the user: service names, usernames, notes, categories, and rotation dates.

Keeva therefore encrypts the secret field and then encrypts the complete credential record—including its metadata, revision relationship, and audit event—in an outer envelope.

This layering is not a claim that “encrypting twice” independently doubles security. Its purpose is to give the secret and complete record explicit authenticated contexts. Security still depends on correct cryptographic use, key protection, and trusted application delivery.

Walrus Memory receives the serialized encrypted envelope, not the plaintext credential body.

The SDK’s own SEAL and storage processing is an additional layer, separate from Keeva’s browser-side encryption.

3. Two distinct unlock boundaries

One practical challenge was allowing a returning user to recover their configuration without confusing that operation with unlocking their passwords.

Keeva separates:

Unlocking the saved gateway configuration.
Unlocking the encrypted vault.

The gateway configuration includes the Tatum endpoint and API key, Walrus Memory account and delegate settings, and original namespace.

Restoring these settings makes the application capable of contacting the correct services. It does not itself expose the vault’s credentials.

Wallet-protected gateway profiles

Each wallet can have its own encrypted configuration stored on the current device.

For supported wallets, Keeva derives the configuration-encryption key from a verified deterministic Ed25519 personal-message signature, using PBKDF2.

The derivation message includes:

The application origin.
Sui Mainnet identity.
The wallet address.
The profile format and KDF parameters.
A random per-save salt.

The signature and derived encryption key are not persisted with the encrypted profile.

The signature is sensitive: it participates in deriving the key that protects saved API and delegate credentials. It should never be published or included in logs, screenshots, or demonstration recordings.

Vault unlock methods

The vault itself supports two modes:

Passphrase-derived encryption, accompanied by a fresh wallet authorization signature.
Wallet-derived encryption, using a vault-specific deterministic Ed25519 personal-message signature.

The vault header records the selected method. Reopening the vault requires that original method; Keeva does not silently switch between them.

Wallets without the required deterministic signature scheme can use passphrase protection instead.

4. Recovering the correct vault after a wallet reconnects

The recovery problem is not simply “download everything again.” The application first needs to recover the correct relationship between:

wallet → memory account → namespace → vault header → encrypted revisions

Keeva’s returning-user flow is:

Connect the owning Sui Mainnet wallet.
Explicitly unlock that wallet’s saved gateway profile.
Restore its original account, namespace, and gateway credentials.
Inspect existing storage.
Authorize the vault unlock.
Authenticate and reconstruct the encrypted inventory.

Once valid configuration and a Mainnet wallet are available, inspection runs automatically. This inspection is read-only: it does not initialize a vault, create memory records, or prompt for a wallet signature.

The header is checked against the configured account, namespace, and connected wallet. Conflicting headers or mismatched identities stop the operation.

Switching between wallets

Consider a browser that has saved profiles for wallets A and B.

After A’s vault has been unlocked, switching to B must not leave A’s credentials visible while B’s configuration loads.

Keeva invalidates the previous session and clears active gateway secrets when the wallet changes. B must restore its own configuration and unlock its own vault. Switching back to A restores A’s profile rather than reusing B’s most recently selected namespace.

This behavior was exercised in a controlled browser review: A’s inventory returned, B exposed only its own inventory, and switching back restored A without additional mock writes.

A wallet is not a complete backup

Saved gateway profiles are specific to a browser profile and application origin.

For example, localhost, 127.0.0.1, different ports, and a hosted domain have separate browser storage.

On a fresh device, the user still needs the original gateway configuration and vault unlock material. Keeva does not claim that a public wallet address alone can discover and decrypt every previously created vault.

5. Using Walrus Memory without plaintext semantic search

Walrus Memory supports memory retrieval, but a credential vault has a different requirement from a conversational assistant.

An assistant may retrieve a few semantically relevant memories. A vault must discover the records required to reconstruct its complete available history. Omitting a revision can change which password appears current.

Keeva therefore does not use a capped similarity result as its inventory.

Paginated inventory discovery

The storage service first calls listMemories() and follows pagination.

It checks for:

Inventory resynchronization requirements.
Valid blob identifiers.
Advancing cursors.
Records within the configured root or revision namespaces.

An index inconsistency fails synchronization rather than being presented as an empty vault.

Immutable revision namespaces

The root namespace contains the vault header. Each immutable record uses a distinct namespace beneath it:

<root>.r.<record-uuid>

Keeva retrieves an indexed record within its namespace using a constant discovery phrase, then matches the result to the exact expected blob ID.

User-entered search terms are not sent to Walrus Memory. Credential metadata is decrypted and searched locally in the browser.

This deliberately trades server-side semantic understanding for keeping credential content private.

It does not hide all metadata. Account identifiers, namespaces, ciphertext sizes, timing, and access patterns remain observable. Ciphertext and the constant discovery phrase may still pass through the Memory service’s processing pipeline.

6. What Tatum contributes

Tatum’s role is blockchain access and evidence-not credential encryption.

Keeva supports configured Sui Mainnet GraphQL and JSON-RPC interfaces. The endpoint and interface must match what the provider actually supports.

In GraphQL mode, network telemetry includes:

query KeevaNetwork {
  chainIdentifier
  checkpoint {
    sequenceNumber
    networkTotalTransactions
    epoch {
      epochId
      referenceGasPrice
    }
  }
}

Keeva validates the returned chain identity against Sui Mainnet’s 35834a8a identifier. A wallet advertising Mainnet support is not sufficient if the configured blockchain endpoint points elsewhere.

Returned fields are schema-validated. GraphQL errors, partial results, incompatible data, and non-advancing pagination are not accepted as successful readings.

A read-only backend boundary

Browser requests reach Tatum through Keeva’s same-origin:

POST /api/tatum

The Node backend forwards the selected endpoint, API interface, key, and permitted blockchain request.

The backend restricts supported operations, bounds request and response sizes, rejects redirects, and applies an upstream deadline. It also handles limited rate-limit retries.

The application does not send master keys or plaintext credentials through this route. However, the backend necessarily receives the Tatum API key for forwarding, so it remains part of the gateway trust boundary.

Transaction verification and its limits

Keeva can inspect an existing transaction by:

Retrieving its transaction bytes and signatures.
Recomputing its digest locally.
Verifying sender and sponsor signatures using the Sui SDK.
Checking the expected wallet relationship.
Requesting membership in the reported checkpoint.

These checks have different strengths.

Digest and signature verification are local cryptographic checks. Checkpoint membership, execution status, and event contents remain provider-attested. Keeva does not independently verify a validator-certificate proof.

Accordingly, the application records a checked transaction as transaction.checked; it does not turn that result into a claim that an unspecified sharing or recovery contract executed successfully.

7. Reconstructing state from immutable history

Password rotation creates a new revision instead of overwriting the previous stored record.

Each credential revision carries:

A stable credential ID.
A unique revision ID.
Its parent revision ID.
Creation and update timestamps.
An authenticated audit event.

After decrypting records, Keeva validates revision ancestry.

Missing ancestors and cycles are rejected. If two devices create different descendants of the same revision, the application exposes the concurrent heads as a conflict.

It does not silently decide that the record with the newest timestamp must be correct.

The current implementation detects such conflicts and blocks unsafe overwrites. Automated conflict reconciliation is not yet implemented.

Handling an uncertain write

A storage request can succeed even when its response is lost.

Retrying with freshly generated ciphertext and a new identifier could create an unintended extra revision or incur another paid operation.

Before dispatching a write, Keeva retains the encrypted request and its idempotency identifier locally. An explicit retry reuses that original operation.

This is a client-side idempotent retry strategy, not an unconditional guarantee of exactly-once storage under every network or service failure.

Reconnecting or unlocking does not automatically replay paid writes.

Browser Web Locks also serialize writes across same-origin tabs. This reduces local races but does not create a global lock across devices.

8. How memory changes Keeva over time

The hackathon asks how a product learns over time. For Keeva, the accurate answer is persistent, evolving security state-not machine learning.

Keeva does not train on passwords or claim to be an autonomous security agent.

Instead, stored history changes the state reconstructed in later sessions.

An illustrative workflow is:

A user stores a credential.
A local audit identifies password reuse or a rotation concern.
The user deliberately replaces the password.
Keeva stores a new encrypted revision and its audit event.
The user locks the vault and returns later.
Keeva reconstructs the updated credential and recomputes the audit from current state.

The application remembers the change rather than reverting to the original record. Earlier revisions remain part of the authenticated history, subject to storage availability and retention.

The Mainnet account associated with my wallet already contains more than 10 memories. Those records are separate from synthetic fixtures used in automated and controlled browser testing.

A memory-record count should also not be confused with a count of unique current credentials: headers, revisions, and audit records can contribute to stored history.

The useful demonstration is therefore not only that records exist. It is that existing history changes what the user sees after returning.

9. Keeping security analysis local

Keeva’s ordinary password checks run in the browser. They include password resistance estimates, reuse detection, and rotation analysis.

Password generation uses Web Crypto randomness with rejection sampling rather than predictable pseudorandom values.

The application also offers an explicit, optional Pwned Passwords check.

For that lookup, Keeva hashes the password locally and sends only the first five hexadecimal characters of its SHA-1 hash. Matching against the remaining hash suffix happens locally. SHA-1 is used for this lookup protocol, not for vault encryption or key derivation.

The provider still sees the hash prefix, IP address, and request timing. This is not a zero-disclosure operation.

A failed lookup leaves the result unknown. A password not found in the dataset is not automatically safe, and a match does not prove that the particular account was breached.

These checks support a user’s decision to rotate credentials; they do not make that decision autonomously.

10. Session safety includes asynchronous work

Clearing a screen is not enough to lock an application if an earlier asynchronous operation can later restore its decrypted state.

Keeva tracks session generations around wallet changes, configuration changes, locking, and pending operations. Results from an invalidated generation cannot reopen the workspace.

The service also checks whether its session remains active after important asynchronous boundaries.

One regression specifically covers locking while write-health preflight is pending: when the response arrives, the closed session must not start the storage write.

This cannot revoke a request that the network has already accepted. It prevents stale work from proceeding where the application still controls dispatch.

The vault locks on inactivity, page hiding, page exit, wallet changes, and configuration changes.

Web Crypto keys are non-extractable, and temporary byte buffers are overwritten where practical. Nevertheless, JavaScript strings and browser memory cannot be reliably zeroized. Client-side encryption does not protect against a compromised browser, wallet extension, or application delivery.

11. Testing, deployment, and remaining boundaries

The release review passed:

180 automated tests across 12 files.
TypeScript checking.
Web application and browser-companion production builds.
Three live Tatum integration checks.
A dependency audit reporting no known vulnerabilities at review time.

Recovery tests use real Web Crypto and Sui signatures with controlled transport responses. They cover wallet separation, recovery without the ciphertext cache, rotated credentials, incomplete history, interrupted sessions, and uncertain-write retries.

The controlled browser test verified A → B → A recovery without additional mock writes.

These results do not constitute an independent security audit. Automated Walrus integration checks in that review were skipped because the runner lacked the required account/delegate identifiers. They must not be represented as independent verification of the existing Mainnet account.

Deployment

Keeva requires more than static hosting. Its Node server supplies the web application and the required Tatum and Walrus gateway routes.

Shared deployments should use HTTPS and must not compile operator secrets into browser assets. Vite’s VITE_* variables are public build inputs; API and delegate credentials should be entered through the protected runtime settings instead.

The browser companion does not maintain another plaintext vault. It provides a local generator and opens the wallet-compatible web workspace, which retains the same authorization boundaries.

Recovery limitations

Index restoration depends on what the relayer can discover. A response reporting no truncation is not proof that every historical record was found.

Device continuity checkpoints can detect some previously observed records disappearing, but a fresh device has no independent checkpoint. Stronger completeness guarantees would require an independently authenticated manifest or consensus-backed vault head.

Encrypted export is implemented. Automated backup import is not.

Rotation also does not erase earlier ciphertext, and Keeva makes no perpetual-retention or guaranteed-deletion promise.

Conclusion

Building Keeva for the Total Recall - Tatum × Walrus Memory Hackathon highlighted that persistence is only one part of a reliable private workflow.

The harder work is restoring the correct configuration, authenticating records, preserving revision relationships, rejecting stale asynchronous results, and distinguishing cryptographic verification from provider claims.

Walrus Memory supplies persistent encrypted records. Tatum supplies Sui Mainnet reads and transaction evidence. Keeva’s browser-side implementation connects those services into a user-authorized credential workflow.

The result is a hackathon-stage implementation-not an audited production password manager or an autonomous AI agent. Its memory is useful because authenticated history survives sessions and changes the state reconstructed when the user returns.