A correction does not inherit the old approval

mengxiujie — Tue, 13 Oct 2026 04:15:50 +0000

Building version-bound, revocable context authorization for AI agents on Monad

AI memory is becoming portable.

Agents can inherit previous conversations. Personal assistants can carry context across sessions. Multi-agent systems can hand information from one model to another. User-owned context layers promise that people will no longer need to start from zero every time they switch applications.

That is real progress.

But portability leaves a harder question unanswered:

May this recipient obtain this approved version of the context through a new handoff now?

Those are not the same thing.

A copy can survive after the facts have changed.

A recipient can still possess information after the owner has narrowed the intended scope.

And an approval that was valid yesterday can remain technically usable even after the person who gave it has corrected, replaced, or withdrawn what they meant.

This is the problem we explored while building Shanhai Continuity on Monad.

Our starting principle is simple:

A correction does not inherit the old approval.

That small rule has surprisingly large consequences for how AI continuity should be designed.

Portable does not mean still authorized

Consider an intentionally ordinary example.

A user prepares an event brief.

The approved version says:

The announcement will happen on Friday.

The user authorizes another agent to use that brief.

Later, the event moves to Saturday.

The information changes.

What happens to the old approval?

A document system might simply overwrite Friday with Saturday.

A conventional permission system might still see:

the same owner,
the same recipient,
the same resource,
and an existing grant.

But something important has changed.

The user approved one particular version of the context. They did not necessarily approve:

whatever that context may become later.

So this:

Friday v1
APPROVED

↓ content changes

Saturday v2
STILL APPROVED

is not the behavior we want.

Instead:

Friday v1
APPROVED

↓ a new context version is explicitly created

Friday v1
VERSION_STALE

Saturday v2
NOT YET AUTHORIZED

Only after a fresh authorization should version 2 become usable.

This is the central idea behind Shanhai Continuity.

From memory portability to continuity authorization

Memory portability asks:

How can context move between AI systems?

Shanhai asks a different question:

Under what current authority may another recipient obtain this context through the next handoff?

That distinction matters.

User control is not only the ability to export or move information.

It also includes the ability to determine:

which recipient may use it;
which portion may be used;
which version was actually approved;
and whether that authorization still exists.

We call this layer:

Continuity Authorization

The primitive is conceptually small:

Owner
Recipient
Scope
Context Version
Authorization State

The context payload remains encrypted and off-chain. Grant metadata is public: wallet addresses, versions, scope hashes, expiry and commitments can still reveal relationships or timing. This prototype does not claim metadata privacy.

The authorization layer tracks the minimum state necessary to determine whether a particular handoff is still valid.

Conceptually:

Authorization {
  owner
  recipient
  scope
  version
  status
  commitment
}

The important part is not the data structure.

It is what the grant means.

It does not mean:

Agent B is allowed to know me.

It means something narrower:

Agent B may receive this approved scope and context version through the checked handoff path while the grant is valid. This does not control reuse of plaintext already delivered.

That gives the primitive four properties.

Authorized

A recipient must have an explicit grant.

Scoped

Permission for one portion of context does not imply permission for everything else.

Version-bound

Authorization remains attached to the version that was actually approved.

Revocable

The owner can revoke the grant for subsequent requests through the checked handoff path. Revocation cannot recall plaintext already delivered.

The second and third properties are especially important for AI systems.

The version is part of the permission

Traditional access control often asks:

Does principal B have permission to access resource X?

For AI continuity, that question is incomplete.

Human context evolves.

A user may:

correct a date,
change a priority,
withdraw a plan,
reduce a scope,
replace an instruction,
or simply decide that something previously supplied should no longer guide future work.

So the relevant question becomes:

May recipient B still obtain scope S of version V through this handoff?

The version is not metadata around the permission.

It is part of the permission.

This is why VERSION_STALE matters.

It is not merely an implementation error code.

It represents a distinction that ordinary persistent memory systems can easily blur:

information may still exist while the authorization attached to that particular version is no longer current.

What Shanhai does — and does not — decide

There is an important boundary here.

Shanhai does not attempt to autonomously decide whether a human change is “semantically important enough” to invalidate an authorization.

That would introduce another difficult problem:

Who decides what change in a person's life counts as material?

The current prototype does not answer that.

Instead, version creation is explicit.

When the user or application creates a new context version, authorization remains bound to the version that was actually approved.

In other words, the system proves:

new version ≠ inherited approval

It does not claim to automatically infer when human meaning has changed.

That distinction is deliberate.

Friday becomes Saturday

Our hackathon prototype uses fixed fictional material so that the authorization behavior can be tested without using real personal data.

The scenario is deliberately simple.

Version 1 is approved

The owner approves a Friday announcement for a recipient.

The permitted scope excludes a private planning note and an unapproved suggestion.

The recipient requests the authorized context.

The request succeeds.

version: v1
status: ACTIVE
decision: ALLOW

The approved encrypted envelope proceeds through the protected delivery path.

The context is corrected

The event moves from Friday to Saturday.

A new context version is explicitly created.

The recipient then attempts to rely on the old authorization.

The result is:

VERSION_STALE

But the status code itself is not the important result.

What matters is what does not happen next.

In the recorded run, the stale request produced:

no new envelope fetch,
no new decryption,
no context assembly,
no downstream gateway call.

That is the actual authorization boundary.

A UI that displays a red DENIED badge while the application continues processing the protected context would not prove very much.

For authorization to be meaningful:

the denial has to change execution.

Version 2 receives its own approval

The Saturday version does not automatically inherit the Friday approval.

The owner explicitly authorizes it.

Only then does the recipient continue.

version: v2
status: ACTIVE
decision: ALLOW

This is the rule in executable form:

A correction does not inherit the old approval.

Authorization is revoked

Finally, the owner revokes the recipient's authorization.

A subsequent request returns:

REVOKED

Again, the protected downstream work does not proceed.

The recipient still exists.

The context still exists.

But the protocol's permission to continue supplying that context does not.

Revocation is necessary. Correction is subtler.

Revocation is easy to understand.

A user says:

I no longer want this recipient to have access.

The more interesting case is correction.

The user may still trust the same recipient.

They may still want the same task completed.

They may still want continuity.

What they no longer want is for the recipient to act on an obsolete version of reality.

That creates a distinct condition:

recipient is still valid
scope is still relevant
a previous authorization existed

but

requested version is stale

The correct answer is neither:

ALLOW

nor:

RECIPIENT BANNED

It is:

VERSION_STALE

Version-bound permissions, scoped grants, expiration and revocation are established access-control patterns. This prototype combines them with encrypted context delivery and a recipient-side check before decryption. We claim an implemented and tested composition for this AI context handoff scenario.

Authorization must happen before disclosure

Another implementation principle became important during the prototype.

A recipient should not:

fetch protected context
↓
decrypt it
↓
assemble it
↓
then ask whether access was allowed

By that point the authorization boundary has already failed.

The protected path should instead look like:

verify
↓
ALLOW
↓
fetch
↓
decrypt
↓
assemble

while:

verify
↓
VERSION_STALE / REVOKED
↓
STOP

Our current prototype checks authorization before releasing the encrypted envelope, and the independent recipient process checks the authorization state again before decrypting and assembling the context.

The design rule is simple:

Verify first. Disclose second.

What would falsify the boundary?

The reference path checks authorization at two separate decision points.

If the sender's read returns VERSION_STALE or REVOKED, that request must stop before a new envelope fetch or release. If the recipient's own read returns either denial, it must stop before decryption, context assembly and the controlled gateway call.

A failed boundary would be a component observing a denial and still performing the downstream operation it is supposed to gate.

The two reads are snapshots. If the sender observes ACTIVE and authorization changes before the recipient checks, ciphertext may already have arrived. The recipient can then refuse decryption. State can also change after the last read; the prototype does not make authorization checking and delivery atomic.

In the two recorded denial requests, the sender observed denial before release, and project instrumentation recorded zero new downstream work. Those records support the tested paths. Chain receipts do not independently prove the off-chain counters.

This is the property our recorded scenario was designed to test.

Why Monad?

The obvious engineering question is:

Why not put this in PostgreSQL?

Sometimes, you should.

If one application is the only trust domain, an application database may be entirely sufficient.

Shanhai is not claiming that every AI permission needs a blockchain.

The problem changes when context crosses independently controlled applications.

Imagine:

a user,
a context provider,
Agent A,
and Agent B

all needing a shared answer to:

Is this authorization still valid?

If the final authorization record belongs exclusively to Agent B's platform, then the party requesting access also controls the state that determines whether it is allowed access.

That weakens the meaning of user-owned continuity.

Our principle is:

The party requesting access should not be the final authority on whether access is allowed.

Shanhai therefore uses Monad when the authorization state needs to cross that trust boundary.

The private context itself remains encrypted and off-chain.

Monad provides a common authorization state and durable transaction evidence that independent parties can verify.

So the architecture separates two things:

private human context
│
│ encrypted
▼
OFF-CHAIN

and:

authorization state
│
▼
MONAD

The precise claim is therefore not:

blockchain is always better than a database.

It is:

when independent applications need a shared answer to whether a cross-application authorization is still valid, that state should not belong exclusively to the application requesting access.

That is the role Monad plays in this prototype.

Or more compactly:

Private content. Publicly verifiable authorization state.

Why not let every application build its own authorization layer?

They can.

For a closed application, that may be the right design.

The interoperability problem begins when a supposedly user-owned context layer crosses product boundaries.

If every AI application independently keeps a private record saying:

I am still authorized to use this user's context,

then the user's portable context has escaped one silo only to encounter another at the authorization layer.

A shared primitive becomes useful when applications need a common answer to:

owner
recipient
scope
version
current authorization status

without treating the requester itself as the sole authority.

This is also why the integration point can remain small.

Before inherited context is decrypted or assembled, the integration should check the requested grant. The following is conceptual pseudocode, not a shipped SDK API:

verify(
  owner,
  recipient,
  scope,
  version
)

The source-level reference entry is createSprintRuntime, with a local example. It is not a published stable SDK.

The authorization result determines whether the checked path continues.

Conceptually:

Context request
      │
      ▼
Continuity Authorization
      │
 ┌────┼────┐
 ▼    ▼    ▼
ALLOW STALE REVOKED
 │      │      │
 ▼      └──┬───┘
disclose   ▼
          STOP

The goal is not to build another giant AI platform.

It is to make this permission boundary composable.

What the current prototype actually proves

Precision matters here.

During the Monad Metropolis build period, we executed a fixed fictional scenario against Monad Testnet.

The recorded run includes five confirmed state transactions and covers the authorization lifecycle demonstrated above:

v1 authorized → ALLOW
context corrected → old grant becomes VERSION_STALE
v2 authorized → ALLOW
authorization revoked
subsequent request → REVOKED

The public deployment is a read-only evidence verifier.

It can re-check the recorded transaction receipts against Monad Testnet.

It does not initiate a fresh wallet-signing ceremony from the browser, and it is not presented as a production authorization network.

The evidence has two sources:

Five Monad Testnet receipts establish successful authorization-state transactions and their recorded block alignment.
Project instrumentation in the original exports records where the tested handoff requests stopped, including zero new downstream work in the two sender-denied requests.

The public verifier checks the exported hashes and can re-read the transaction receipts. Hash matching preserves the records; it does not independently certify the off-chain instrumentation.

It does not demonstrate:

production-grade security;
a completed security audit;
real-user adoption;
large-scale developer adoption;
model quality;
production identity separation;
or long-term operational resilience.

The scenario uses fictional material.

The final announcement output uses a fixed template rather than a live AI model.

The owner-side and request-signing operations in this run used the same test wallet.

The recipient execution path ran in a separate local process.

Therefore this experiment does not establish independent human identities or production key separation.

The property under test is narrower:

authorization-state enforcement across the protected handoff path.

That is what the evidence should be used to evaluate.

Revocation cannot make a recipient forget

Another boundary deserves to be explicit.

Once plaintext has legitimately been delivered to another system, a later blockchain transaction cannot guarantee that every existing copy disappears.

Shanhai does not claim otherwise.

Revocation means:

future disclosure through the protected authorization path is no longer permitted.

It does not mean:

remotely erase every byte previously received.

This distinction matters because “revocable AI memory” can easily become an overclaim.

The property we are building is a permission boundary, not remote mind erasure or DRM.

That narrower property is still valuable.

The existence of information and the continuing authorization to supply or process it are not the same thing.

Authorization, not legal consent

We also deliberately use the term authorization rather than claiming to implement legal or regulatory consent.

Human consent can involve requirements around:

notice,
comprehension,
voluntariness,
capacity,
purpose limitation,
jurisdiction,
and withdrawal semantics.

This prototype does not attempt to encode all of those requirements.

What it implements is narrower:

a technical authorization state tied to a particular recipient, scope and context version.

That boundary lets us reason precisely about what the system currently does without claiming more than the prototype supports.

Where this primitive could fit

The most relevant adopters are not necessarily general consumers.

They are developers building systems where context crosses recipients and where user intent can change over time.

Examples include:

personal AI assistants;
multi-agent systems;
user-owned AI memory layers;
enterprise agent workflows;
and sensitive-domain AI systems where freshness and scope matter.

The integration point is concrete:

before inherited context is decrypted or assembled, verify whether this recipient is still authorized for this scope and this version.

This also answers an important product question.

Why would another developer use a shared authorization primitive instead of building the same logic internally?

Our adoption hypothesis is that some independently controlled tools will value a common, independently readable grant record enough to accept its signing, network and integration costs.

A shared database service or signed-grant design may be sufficient for other workflows. Monad supplies the shared state in this implementation; the prototype does not establish a Monad-specific performance advantage or prove that target developers will choose it.

External application integration and sustained use remain to be tested.

From owning memory to owning continuity

The broader design question is larger than this prototype.

Much of the discussion around user-owned AI focuses on possession:

Can I export my memory?

That is necessary.

But possession alone does not answer:

Who can continue using it?
Which part?
Which version?
Under what current authorization?
What happens when I change my mind?

This suggests a distinction:

Owning the context is not the same as owning its permission lifecycle.

A truly user-owned context layer should eventually support both.

Portability determines where information can go.

Authorization determines whether it may still go there.

A small rule with a large consequence

Shanhai Continuity can ultimately be reduced to one principle:

A correction does not inherit the old approval.

From that follows:

explicit versioning,
fresh authorization after version change,
stale-version rejection,
scope-bound access,
revocation,
and fail-closed disclosure.

The mental model changes from:

The AI knows this about me.

to:

The next recipient may receive this approved scope and version through the checked handoff path.

That is a smaller claim.

It is also a much more controllable one.

Evidence

The current prototype and recorded run can be inspected directly.

Source repository

Shanhai Continuity Protocol — GitHub

The repository contains the hackathon implementation and the disclosure of the pre-existing Shanhai product context.

Live evidence verifier

Shanhai Continuity — Monad Testnet Evidence Verifier

No login or wallet is required.

The page presents the recorded authorization outcomes and can re-check the five recorded transaction receipts against Monad Testnet.

Technical demo

Shanhai Continuity — Technical Demo

The 69-second technical demo shows a post-run walkthrough of the read-only verifier, including archived evidence and a fresh receipt check. It does not record the original wallet-signing run or a new recipient handoff.

Project pitch

Shanhai Continuity — Pitch

Recorded test sequence

approve context v1
deliver authorized v1
create corrected context v2
reject use of stale authorization
separately authorize v2
deliver authorized v2
revoke authorization
reject subsequent access

Five authorization-state transactions from this recorded run are exposed through the public evidence verifier and can be re-checked against Monad Testnet.

Build-window disclosure

The broader Shanhai product direction predates this hackathon.

The work described in this article concerns the Shanhai Continuity authorization prototype built during the Monad Metropolis hackathon period.

That hackathon-period work includes the protocol implementation, Monad authorization integration, independent recipient execution path, browser workbench, executed fictional test scenario, and public evidence-verification surface.

The intention of this disclosure is simple:

the argument in this article should stand on the work actually built and tested for this submission, not on the existence of the broader pre-existing Shanhai project.

What comes next

The next questions are no longer primarily about adding more protocol features.

They are about whether the primitive survives contact with other developers.

Among them:

Can an independent developer reproduce the authorization flow quickly?
What is the smallest usable integration API?
Which application events should explicitly create a new context version?
How should shared scopes be represented across different AI products?
How should recipients be identified across ecosystems?
Where should authorization checks sit inside existing agent frameworks?
How should delegated or derived context inherit — or fail to inherit — authorization?
How much friction will users tolerate when re-authorizing materially changed context?

Those questions need evidence, not speculation.

The current prototype is meant to make them testable.

Conclusion

AI memory is becoming portable.

That is useful.

User-owned context is better.

But neither concept alone answers what happens after the information changes.

A system still needs to know:

May this recipient obtain this approved version of the context through the next handoff?

Our answer is that AI continuity should be:

authorized, scoped, version-bound, and revocable by the human.

Private context can remain off-chain.

Authorization state can remain independently verifiable.

A stale or revoked grant can stop downstream disclosure rather than merely changing a label in a database.

And when a person explicitly changes the context being shared, yesterday's approval should not silently follow.

Because:

A correction does not inherit the old approval.

The version is not metadata around the permission. It is part of the permission.

And ultimately, the goal is not to make AI forget continuity.

It is to make continuity answerable to the person it describes.

Users should control which approved context reaches the next recipient.

Shanhai Continuity

The permission layer for human-owned AI continuity.

Built on Monad Testnet for the Monad Metropolis Hackathon.

DEV Community: mengxiujie

A correction does not inherit the old approval

Portable does not mean still authorized

From memory portability to continuity authorization

Continuity Authorization

Authorized

Scoped

Version-bound

Revocable

The version is part of the permission

What Shanhai does — and does not — decide

Friday becomes Saturday

Version 1 is approved

The context is corrected

Version 2 receives its own approval

Authorization is revoked

Revocation is necessary. Correction is subtler.

Authorization must happen before disclosure

What would falsify the boundary?

Why Monad?

Why not let every application build its own authorization layer?

What the current prototype actually proves

Revocation cannot make a recipient forget

Authorization, not legal consent

Where this primitive could fit

From owning memory to owning continuity

A small rule with a large consequence

Evidence

Source repository

Live evidence verifier

Technical demo

Project pitch

Recorded test sequence

Build-window disclosure

What comes next

Conclusion