Context

All persistent data in Nexum (wallet metadata, account information, preferences, transaction history) must follow a well-defined schema that supports versioning and migration. The schema must be flexible enough to evolve while maintaining backward compatibility.

Considerations

This specification should address the following considerations:

• Schema structure for identities, wallets, and accounts
• Wallet metadata fields (names, icons, notes, tags)
• Account metadata and categorization
• Transaction history format and indexing
• Preference storage (identity-scoped vs global)
• Schema versioning strategy (semantic versioning)
• Migration procedures between schema versions
• Required vs optional fields
• Default value handling
• Data validation rules and constraints
• Serialization format (JSON, CBOR, MessagePack, or custom)
• Encryption boundaries (which fields are encrypted)
• Size limits and constraints
• Relationship encoding between entities

Dependencies

Depends on (Phase 2):

• docs: design identity model specification #84 (Identity model defines what entities need schemas)

Blocks:

• docs: design tree-based account UX #85 (Tree-based UX needs to know what to display)
• docs: design storage architecture #87 (Storage architecture needs to know what to store)

Out of Scope

• Blockchain data schemas (on-chain state)
• RPC message formats (covered in docs: design system architecture #89)
• Transient UI state
• Cache data structures

References

• Related: docs: design identity model specification #84 (Identity model), docs: design storage architecture #87 (Storage architecture)
• Epic: [EPIC 0.0] Foundation - Identity & Account Architecture pm#3 (Foundation)