Memory Lineage

Inspiration

Problem. After an outage, an AI agent can restart from a backup that opens normally but is behind the history its team treats as current. The operator can see that the files loaded; a reviewer still needs to know whether that snapshot is an authorized point to continue from. We started with this recovery question, not with the idea of putting private memory on a blockchain.

What it does

Solution. MemoryLineage checks a restored snapshot before an agent resumes. It compares the snapshot's fingerprint and previous step with the recorded history and approval evidence. It says whether the snapshot is current, an older known checkpoint, different from the recorded history, or unsupported by enough evidence, and explains why before anyone continues.

The demo follows The Silent Rollback: Backup 1 is restored after the synthetic history has reached state 3. A new step tries to continue from the old state, and local execution of the Solidity registry rejects it with BAD_PREVIOUS_STATE. The Inspector asks the visitor to predict the outcome, then reveals the evidence and reason. A separate Rust verifier can replay the bundle without relying on the website.

This is a local synthetic prototype, not a connection to a production agent or a live-chain run of this history. Offline replay checks that the bundle is internally consistent; it does not prove which live chain produced it.

Innovation. Our focus is snapshot-level recovery: whether a backup is an authorized continuation before an agent resumes. MemoryLineage does not trace the origin or derivation of individual entries, detect memory poisoning, or claim general novelty for memory lineage. Its contribution is bringing a recovery-time decision, authority context, and portable evidence replay together in one prototype workflow.

How we built it

We built the protocol logic, CLI, and independent evidence verifier in Rust. The browser Inspector uses Dioxus and WebAssembly. A Solidity registry defines the sequence, predecessor, and authorization rules. In the demo, Rust/revm runs the checked-in Solidity bytecode against a deterministic fixture derived from synthetic SQLite snapshots. Raw memory stays off-chain; the portable evidence contains commitments and proof metadata. We build on existing standards and do not claim to have invented ERC-8350, EIP-712, or ERC-1271.

Challenges we ran into

We had to make the contract, Rust tools, browser, and CLI agree on the same sequence and approval rules. Another challenge was explaining the boundary of a successful replay: a bundle can be consistent without proving which chain produced it, and a commitment cannot tell us whether the memory is true or safe. The Inspector spells this out instead of hiding it behind one green check.

Accomplishments that we're proud of

Impact (intended, not measured). The person restoring a backup, the person approving it, and an auditor can inspect the same recovery decision before a snapshot reaches the reference loader. In the prototype, the stale snapshot is held before that loader. We have not measured incident reduction, user impact, or production outcomes.

• Built a complete local recovery-preflight walkthrough around a concrete stale-snapshot incident.
• Replayed the Silent Rollback against the checked-in Solidity behavior through Rust/revm, with the stale predecessor rejected as BAD_PREVIOUS_STATE.
• Added an independent Rust verifier and CLI for portable evidence, so review does not depend only on the website.
• Kept raw fixture values out of the registry and portable evidence while making commitments, proof metadata, and decision receipts inspectable.
• Published the v1.0.2 source snapshot and a ten-page pitch PDF under the repository's MIT license.

What we learned

We learned to say exactly what a successful replay means. It shows that the supplied evidence fits together; it does not establish that the evidence came from the canonical contract. We also saw that privacy and recovery have to be planned together: raw memory can stay off-chain, but reviewers still need retained bundles or event logs to reconstruct the history.

What's next for MemoryLineage

Future scope. We want to authenticate the registry and chain behind the evidence, rebuild history from retained events or bundles, and integrate the gate with one real agent runtime. We also need uncoached developers to try the flow and measure whether they understand and complete it. Historical ERC-1271 replay, privacy and secret recovery for real memory, formal security review, and measured user impact remain future work.

Built With

• cli
• cryptography
• dioxus
• eip-712
• ethereum
• revm
• rust
• solidity
• sqlite
• webassembly