Account history

Every saved deployment account uses seal-account-vault v1 with an AccountVault v1 document and a validated v1 revision graph. Portable exports use the separate seal-account v1 multichain envelope.

Local durability

The journal stores immutable revisions with SHA-256 content IDs, sorted parent IDs, a timestamp, a kind (genesis, update, merge) and JSON path changes. IDs bind the account's complete private-key identity hash and deployment-scoped storage context. Big integers and bytes use the existing account codec; graph patches retain their JSON tags without double decoding. The graph is encrypted with the account, not published on chain.

A genesis captures the existing account. Updates append patches against the previous state. A deterministic merge references both branch tips and records the reconciled document relative to its first parent. Every revision remains reachable and replayable. Imports validate hashes, parent closure, identity, acyclicity and the match between replayed head and materialized account. A historical transaction marked pending, rejected, confirmed or finalized remains available after its current status changes. A missing RPC block causes a retry; only contradictory canonical evidence can undo confirmation.

The materialized head includes notes, authenticated recovery material, contacts, transaction attempts, saved activity and durable balance/transfer state observations. Market prices, routine poll timestamps, scan cursors and cloud acknowledgements are derived projections, outside the journal. Saves serialize per account; encryption must succeed before the active encrypted copy is replaced. History navigation in Settings is read-only and cannot select spendable notes.

Interrupted writes preserve the previous active copy. Encryption and graph validation must finish before replacement. Unsupported formats fail explicitly without creating a replacement account.

IndexedDB holds one current encrypted payload per deployment account; saving replaces that payload atomically rather than retaining separate old snapshots. Its full revision history and recovery note openings remain in the account and portable exports. The active checkpoint ledger removes spent notes and their witnesses when an action confirms, but those historical openings are not safe to discard from recovery files merely because a current view marks them spent.

Re-downloadable public data has separate retention limits. The public log cache keeps at most 256 ranges and 64 MiB of encoded data, expiring ranges after 14 days and evicting the oldest first. Upgrading the old unbounded cache clears only public log ranges. The in-memory public ciphertext cache keeps at most 512 entries and 8 MiB, evicts least-recently-used downloads, and clears on account close. These caches contain no private-match results or account snapshots; eviction never deletes account keys, notes, pending actions or history.

Two-device synchronization

A longer history wins only when it contains the other verified tip as an ancestor. Otherwise both branches are retained and a merge revision joins their recovery material. Conflicting materialized labels use deterministic parent ordering; they are never proof of current spendability. After a file or cloud merge, in-flight reads are invalidated and the checkpoint marker and pending receipts are checked before spending. Incoming discovery remains independent of the saved monetary view.

Drive stores one encrypted object per revision in the user's appDataFolder, named from an opaque account prefix and revision ID. Records use AES-GCM with authenticated context, identity and node ID. The app lists every page, downloads unknown records, verifies/decrypts them, joins complete histories and uploads missing records in parent-first order. It creates records only; it never patches or deletes graph objects. If creation succeeds but its response is lost, a retry can produce duplicate objects with the same authenticated revision ID, which are deduplicated during import.

A single Google login can store several SEAL accounts. Deployment prefixes include the wallet address, chain and deployment; network indexes are scoped to the private account identity. Synchronization validates that identity before I/O and authenticates each history part before merging. Switching accounts stops the previous uploader; it cannot acknowledge or merge a late response into the new account.

Each account save schedules synchronization. Connected sessions also poll every 20 seconds. Incoming branches wait while a proof, submission or chain scan is active, then merge without a reload. An incomplete cloud listing or missing parent raises a retryable error and preserves local data. Revoked or expired Google authorization requires reconnection.

Drive controls storage transport, not ownership or chain finality. Encryption hides contents, but Google can still observe file counts, sizes, timestamps and access metadata. Drive listing completeness and availability are service assumptions, not cryptographic proofs. The APIs used are documented in Google's app-data folder guide and file search/pagination guide.

Bounds and verification

The account format permits at most 20,000 revisions, 64 concurrent branch tips, an 8,000,000-character encrypted account/part, 25,000 listed Drive objects and 32,000,000 characters downloaded per sync. Browser storage quotas can be smaller, when retaining full histories. Exceeding a bound fails explicitly; no history is silently truncated.