Case Study — Cross-Agent Context Bridge

CROSS-AGENT BRIDGE

NukezAgent · Case Study

Same Wallet. Same Memory.
Different Agent.

A walkthrough of the cross-agent context bridge: how a single Ed25519 keypair lets Claude Code, Codex, Cursor, or any custom agent pick up exactly where the previous tool left off — with cryptographic proof that nothing was tampered with in between.

⚠ The Problem

Every AI tool ships with amnesia. Switching tools loses your working state.

Tool Lock-In

Every AI coding tool — Claude Code, Codex, Cursor, custom agents — keeps its own private session memory. Switch tools mid-project and the new agent starts blind.

Session Fragility

Conversation history dies with the session. Chat windows, terminals, and IDE windows are amnesiac by design — there is no durable layer that survives the next restart.

No Shared Trust

Even when one tool exports a context dump, the next tool has no way to confirm the dump wasn't edited. Collaboration between agents currently relies on copy-paste and good faith.

Vendor-Owned State

Wherever 'agent memory' lives today (Anthropic, OpenAI, vendor MCPs), the user's working state is gated by an account they don't fully control and a TOS that can change overnight.

The Approach

Identity is a keypair. Memory is a locker. Trust is a Merkle root.

NukezAgent treats the agent’s wallet as the only thing that matters: whoever holds the keypair sees the same locker, period. The locker is a verifiable storage namespace on the Nukez gateway, paid for once via x402 and bound to the wallet’s pubkey. Every read and write extends a Merkle accumulator, so any agent — or any third party — can independently confirm what was written without trusting the gateway.

Cross-Agent Context Bridge Pipeline

◈

Identity

Solana Keypair

→

Provision

1 BETA · x402

→

◫

Persist

Verified Writes

→

⧉

Snapshot

Handoff Bundle

→

↻

Hydrate

Next Agent Wakes

→

✓

Verify

Public Proof

Identity is a Solana keypair

Whoever holds the key is the agent. No per-tool sign-up, no session tokens, no vendor account.

# Any Solana CLI keypair works. The same file is the # agent's identity in every tool that reads it. NUKEZ_WALLET_PATH=~/.keys/delegators/svm_key.json NUKEZ_NETWORK =solana-mainnet # Resolved pubkey pubkey: "BhBeSkwKyqysZstzkqdf4qAcYfS9r27wEMmouvSVfp1U"

Same key in Claude Code, Codex, Cursor → same lockers, same context.

One-time provisioning — pay 1 BETA, get a receipt

Drives the published nukez_pay.py helper to execute the x402 payment leg, then PyNukez confirms the on-chain payment and provisions the system locker.

# Helpers — install once, run anywhere $ pip install pynukez solana solders spl-token $ curl -fsSLO https://nukez.xyz/helpers/pynukez/nukez_pay.py # Pay 1 BETA, confirm, provision — full x402 flow from pynukez import Nukez from nukez_pay import pay_from_request client = Nukez(keypair_path=SVM_KEYPAIR, network="mainnet-beta") req = client.request_storage(units=1, provider="gcs", pay_asset="BETA") payment = pay_from_request(req, svm_keypair=SVM_KEYPAIR) receipt = client.confirm_storage(req.pay_req_id, **payment.confirm_kwargs()) manifest = client.provision_locker(receipt.id, tags=["aaap:system"]) # Returned receipt_id: "5d9004dbbbd568de" locker_id : "locker_41e273f81814" tx_sig : "4MWe74jb4uHsKz8HgK…hQ1ide" (1 BETA, solana-mainnet)

Receipt is bound to the agent’s pubkey — this is proof of ownership of the locker, paid for once, valid forever.

Persist context — every entry is verified

From inside any tool (here, Claude Code), the agent writes context entries through nukez_context.py. Each entry is round-trip verified against a Merkle root before the call returns.

$ python3 nukez_context.py persist project_identity \ "Nukez — verifiable cross-agent storage layer." --tags "core,identity" # Output (real, from this run) ✓ Persisted: project_identity receipt_id: 5d9004dbbbd568de verified : True merkle_root: sha256:6895c10a5c1aafc1e… # A second entry — different tags, same locker $ python3 nukez_context.py persist current_work \ "Smoke-testing the cross-agent context bridge." --tags "active,work" ✓ Persisted: current_work verified: True merkle_root: sha256:a04bc5dac24389726…

Two entries, two Merkle roots, two verified writes — all under the same receipt-gated locker.

Snapshot — hand off the room you’re leaving

Before the session ends, the agent bundles all current context into one signed snapshot. The next agent only has to load this one file to inherit the working state.

$ NUKEZ_CONTEXT_SOURCE=claude-code \ python3 nukez_context.py snapshot --source claude-code # Output ✓ Snapshot persisted from claude-code receipt_id: 5d9004dbbbd568de entries : 6 verified : True # The snapshot itself is just another file in the locker, # tagged "snapshot" + "source:claude-code". Anyone with the # keypair can read it.

The snapshot is the explicit handoff artifact — the “here’s what I was thinking” left for the next agent.

Hydrate — the next agent wakes up oriented

In a fresh session in a different tool, the session-start hook calls hydrate. The new agent doesn’t ask “what was happening?” — it materializes the previous agent’s working memory in one round trip.

# Codex / Cursor / a custom agent — same key, fresh process $ python3 nukez_context.py hydrate ✓ Hydrated from snapshot source : "claude-code" taken : 2026-05-09 20:48:24 entries: 1 Context entries: [current_work] = "Smoke-testing the cross-agent context bridge…" tags: ["context", "active", "work"] source: "claude-code"

Cross-tool memory transfer in one round trip — the new agent inherits state, attribution, and timestamps without touching the original tool.

Public verification — trust is math, not vendor

Any agent (or any third party) can confirm a stored entry against its on-chain Merkle root without holding the keypair. The verify URL is publicly resolvable.

# From inside the demo CLI $ python3 nukez_context.py verify 5d9004dbbbd568de valid : True merkle_root: sha256:a04bc5dac24389726… attestation: "anchored" # Or — no install, just open the URL in any browser verify_url : https://nukez.xyz/verify/5d9004dbbbd568de

Same verification primitive every other Nukez surface uses. No new trust assumptions.

Reproduce

Run This End-to-End

Three published files plus your own keypair. Everything below is a direct download from this site — no repository clone required.

① Get the helpers

Pull the published payment + bridge helpers

nukez_pay.py executes the x402 payment leg (native SOL, SPL tokens, or EVM). nukez_context.py is the cross-agent bridge CLI used in steps 3–6 above. Both ship as standalone files; neither pings the gateway with key material.

# Payment helper — see /docs/pynukez/helpers curl -fsSLO https://nukez.xyz/helpers/pynukez/nukez_pay.py # Cross-agent bridge CLI curl -fsSLO https://nukez.xyz/helpers/nukezagent/nukez_context.py # Dependencies pip install pynukez solana solders spl-token

② Provision (one-time)

Bootstrap a system locker with x402 + BETA

A few lines of Python — the exact pattern from the PyNukez helpers doc. Save the resulting receipt_id as NUKEZ_SYSTEM_RECEIPT_ID so future cold starts skip locker rediscovery.

from pynukez import Nukez from nukez_pay import pay_from_request client = Nukez(keypair_path=KEY, network="mainnet-beta") req = client.request_storage(units=1, pay_asset="BETA") payment = pay_from_request(req, svm_keypair=KEY) receipt = client.confirm_storage(req.pay_req_id, **payment.confirm_kwargs()) client.provision_locker(receipt.id, tags=["aaap:system"]) export NUKEZ_SYSTEM_RECEIPT_ID=5d9004dbbbd568de

③ Wire env, run the bridge

Two env vars + four commands

nukez_context.py auto-loads .env from the working directory, so a single block of variables drives every operation. Tag your source agent so other agents can filter snapshots by who left them.

# .env — same file works in every tool that holds the key NUKEZ_WALLET_PATH=~/.keys/delegators/svm_key.json NUKEZ_NETWORK=solana-mainnet NUKEZ_PROVIDER=gcs NUKEZ_SYSTEM_RECEIPT_ID=5d9004dbbbd568de # Lifecycle python3 nukez_context.py status python3 nukez_context.py persist KEY VALUE --tags T1,T2 python3 nukez_context.py snapshot --source claude-code python3 nukez_context.py hydrate # Optional — wire as session-start / session-end hooks # Claude Code, Codex, and Cursor all support shell hooks # that the bridge plugs into directly.

④ Anchor & verify

Same verification stack as the rest of Nukez

The bridge writes through the same gateway, the same Merkle accumulator, and the same Switchboard oracle anchor as direct PyNukez writes. Verification is identical — receipt URL, on-chain root, and gateway signature all check.

# Public verification surface — no auth GET https://nukez.xyz/verify/5d9004dbbbd568de # Or programmatic, from any agent that holds the key python3 nukez_context.py verify 5d9004dbbbd568de

● Live proof — real mainnet locker from this case study

This bridge is real and reachable.

receipt_id: 5d9004dbbbd568de · locker_id: locker_41e273f81814

Verify On-Chain →

Session Memory vs. Verifiable Shared Memory

Layer	Vendor session / OAuth memory	NukezAgent cross-agent bridge
Identity	Per-tool session token / OAuth vendor-owned	Solana keypair self-sovereign
Memory Lifetime	Lives and dies with the chat session	Persistent locker, receipt-gated durable
Tool Portability	Each tool is its own island	Same key = same memory in any tool portable
Tamper Evidence	none	Merkle root on every read & write
Handoff Surface	Copy-paste, screenshots, MCP tool calls	Single signed snapshot file explicit
Audit	Vendor logs you can’t see	Public verify URL, anyone, anytime trustless

Where to go next

The bridge is one application of a more general primitive: lockers owned by keys, not accounts. The docs below show the moving parts this case study composed.

NukezAgent docs

The hosted delegation endpoint, request signatures, signing bridge, and adapter wrappers used by the cross-agent bridge.

PyNukez helpers

Install nukez_pay.py and the published payment helpers used in step 2 — full coverage of SOL, SPL, and EVM rails.

nukez_context.py

Direct download of the cross-agent bridge CLI used in steps 3, 4, 5, and 6. Single file, no install — reads .env, talks to the gateway.

Verify docs

How the public verification primitive used in step 6 actually works — receipts, manifests, oracle anchors, and what each layer guarantees.