Reported elsewhere by @exarkun:

ZKAPAuthorizer exposes a list of unblinded tokens. GridSync fetches the list and stores the information on the grid, reachable from the rootcap so that those tokens can be re-loaded into the client during the client-loss-recovery process.

The schema for ZKAPAuthorizer's persistent state is currently as follows:

CREATE TABLE version(version);
CREATE TABLE [vouchers] (
           [number] text,
           [created] text,                     -- An ISO8601 date+time string.
           [state] text DEFAULT "pending",     -- pending, double-spend, redeemed

           [finished] text DEFAULT NULL,       -- ISO8601 date+time string when
                                               -- the current terminal state was entered.

           [token-count] num DEFAULT NULL, [public-key] text, [counter] integer DEFAULT 0, [expected-tokens] integer NOT NULL DEFAULT 32768,     -- Set in the redeemed state to the number
                                               -- of tokens received on this voucher's
                                               -- redemption.

           PRIMARY KEY([number])
       );
CREATE TABLE [tokens] (
           [text] text, -- The random string that defines the token.
           [voucher] text, [counter] integer NOT NULL DEFAULT 0, -- Reference to the voucher these tokens go with.

           PRIMARY KEY([text])
           FOREIGN KEY([voucher]) REFERENCES [vouchers]([number])
       );
CREATE TABLE [unblinded-tokens] (
           [token] text, -- The base64 encoded unblinded token.

           PRIMARY KEY([token])
       );
CREATE TABLE [lease-maintenance-spending] (
           [id] integer, -- A unique identifier for a group of activity.
           [started] text, -- ISO8601 date+time string when the activity began.
           [finished] text, -- ISO8601 date+time string when the activity completed (or null).

           -- The number of passes that would be required to renew all
           -- shares encountered during this activity.  Note that because
           -- leases on different shares don't necessarily expire at the
           -- same time this is not necessarily the number of passes
           -- **actually** used during this activity.  Some shares may
           -- not have required lease renewal.  Also note that while the
           -- activity is ongoing this value may change.
           [count] integer,

           PRIMARY KEY([id])
       );
CREATE TABLE [invalid-unblinded-tokens] (
           [token] text,  -- The base64 encoded unblinded token.
           [reason] text, -- The reason given for it being considered invalid.

           PRIMARY KEY([token])
       );

(And current development efforts have made further changes still.)

For a complete client-loss-recovery all of this state needs to be backed up and then restored. Otherwise:

• without the vouchers table, it becomes impossible to see spending history or attempt to complete redemption of any not-fully-redeemed voucher
• without the tokens table, it may become impossible to complete redemption of any not-fully-redeemed voucher
• without the lease-maintenance-spending table it becomes impossible to audit past automatic/implicit spending activity
• without the invalid-unblinded-tokens table it becomes impossible to audit spending attempts rejected by storage providers

Beyond this, ZKAPAuthorizer should be free to manage its internal persistent state without risking breaking either GridSync's recovery system or any backed up state created using an older version of ZKAPAuthorizer. This suggests the backup/recovery interface should be:

• explicitly versioned so that a vN backup can be identified as such and used to recover state with a vM client (M >= N)
• somewhat more opaque than it currently is so that when internals change they either automatically or trivially propgate to GridSync's use of those interfaces
• more complete in representing ZKAPAuthorizer's persistent state