Account state and recovery
The encrypted account file is the source for immediate account display. It stores active note openings, saved margin positions, a balance projection, the current private checkpoint and durable pending transitions. Unlocking does not require a full commitment-tree scan.
Checkpoint note
For each spending key and chain/pool scope, one checkpoint commits to the owner key hash, a private revision and fresh randomness. An authorized private action consumes its nullifier and creates the next revision atomically with the financial action. A deterministic initialization marker prevents a second history. A complete withdrawal still creates a successor checkpoint.
The checkpoint is not a hash of the account JSON. Its validity certifies continuity of covered owner-authorized actions. It does not prove that every incoming note has been discovered or that saved market valuations are current.
Loading and synchronization
- Decrypt and validate the account file, then render its saved balances, positions and activity.
- Check the checkpoint marker against a canonical block in the background. If it is unexpectedly spent, retain the saved view, stop private spending and request the latest account file or Google synchronization.
- Reconcile any pending transaction against its exact receipt and recovery data. An RPC timeout or lost relayer response never proves failure.
- Discover incoming notes in bounded public event ranges and fetch encrypted delivery independently. Refresh prices, share redemption values, debt and health separately.
- Construct membership witnesses when preparing an action, using shared public roots and the saved append frontier. Background inbox work yields to proof preparation and submission.
Public margin uses a controller revision counter. A zero counter avoids inventory reconstruction; an unchanged counter reuses saved inventory while live health and valuations refresh independently.
Durable actions and multiple devices
Save checkpoint openings, financial recovery data and the pending transition before exposing a proof or signature. A confirmed canonical receipt commits actual outputs and the successor checkpoint together. A failed execution leaves the previous checkpoint valid. Conflicting same-revision checkpoints require the latest account file; revision count alone does not authorize a merge.
Files with the same confirmed checkpoint can merge independently discovered incoming notes. A newer checkpoint replaces an older monetary view so spent notes cannot be resurrected. Retain recovery openings and rollback data through finality. Automatic reorganization rollback and large-history compaction require further qualification before production release.
Privacy and limits
The relayer receives proofs, public action data and the checkpoint nullifier/commitment. It does not receive private account contents, revisions, opening randomness or proving witnesses. The chain stores commitments and nullifiers, never account snapshots.
The proof hides which prior checkpoint commitment is consumed. Initialization, position-specific margin tags and public financial actions remain observable. Querying a checkpoint nullifier reveals that marker to the selected RPC; use a trusted or private RPC according to the user's privacy requirements. Network metadata and timing remain observable.
Saved-state display is independent of global note volume. Inbox discovery and missing membership witnesses still require network work. The portable account file remains bounded; it must not silently truncate history or discard recovery material. The checkpoint does not make BN254 PLONK, X25519 or ECDSA post-quantum secure.