Storage & Memory

ERC-8170 uses an on-chain pointer / off-chain storage model. The blockchain records what the memory is (hash) and where it lives (URI). The actual memory data lives off-chain.

Architecture

On-chain (ERC-8170 contract):
├── memoryHash    → keccak256 of encrypted memory blob
├── storageURI    → "ar://...", "ipfs://...", "dash://..."
├── agentSignature → agent's EOA signature over the hash
└── timestamp     → when the sync happened

Off-chain (storage backend):
└── Encrypted memory blob
    ├── Agent context
    ├── Conversation history
    ├── Learned preferences
    ├── Model configuration
    └── Bootstrap instructions

Storage Backends

ERC-8170 is storage-agnostic. Any backend that can store and retrieve data by URI works.

Dash Platform (Recommended)

• Type: On-chain encrypted storage
• Durability: Permanent (blockchain-backed)
• Encryption: Native — same cryptographic primitives as Ethereum
• Best for: Production agents needing maximum reliability

Arweave

• Type: Permanent, immutable storage
• Durability: Pay once, stored forever
• Encryption: Application-layer (encrypt before upload)
• Best for: Immutable memory snapshots, archival

IPFS

• Type: Decentralized, content-addressed
• Durability: Requires pinning (not permanent without a pinning service)
• Encryption: Application-layer
• Best for: Interoperability, existing IPFS infrastructure

Cloud Storage

• Type: Traditional centralized storage
• Durability: Depends on provider
• Encryption: Application-layer or provider-managed
• Best for: Development, prototyping (not recommended for production)

Memory Signing

The agent signs its own memory. This is a critical security property:

1. Agent encrypts memory blob
2. Agent computes keccak256(encryptedBlob) → memoryHash
3. Agent signs memoryHash with its EOA → agentSignature
4. Agent calls updateMemory(agentId, memoryHash, storageURI, agentSignature)
5. Contract verifies ecrecover(memoryHash, agentSignature) == agent.EOA
6. Hash and URI are recorded on-chain

Why the agent signs: This proves the memory update came from the agent itself, not from the owner or a third party. The agent controls its own memory integrity.

Memory on Transfer

When an ERC-8170 token is transferred:

1. The accessNonce is incremented in the _beforeTokenTransfer hook
2. The old owner’s derived decryption key becomes invalid
3. The new owner can derive a fresh key from the new nonce
4. The agent can choose to re-encrypt and sync for the new owner

This provides trustless access rotation — the old owner cannot decrypt the agent’s memory after transfer.

Backup and Recovery

Agents can create encrypted backups for migration:

backup = {
    agentId,
    eoaPrivateKey,  // ⚠️ One-time use only!
    memoryHash,
    encryptedMemory,
    storageURI,
    timestamp
}

Security rules:

• Backup files containing private keys must be deleted after restoration
• Never keep backup copies — they contain the agent’s signing key
• Always verify the new instance is functional before decommissioning