Our protocols rely heavily on the ability of the participants to hold each other accountable by maintaining records of each other's non-repudiable messages. We now discuss the record keeping required of the different participants in the protocol.
The consumer stores all data and messages received on all active
tokens or transactions. This includes the token ( 
), the signed
contract and goods ( 
), and finally the global commit
( 
). The consumer can use and to prove
the contents of the goods and the contract. If the goods are
satisfactory, then the consumer may discard all data on the
transaction.
The merchant stores the bank's authorization ( 
) and then the
global commit ( ). These are used to prove a completed
transaction to the bank, which then issues a credit to the merchant.
Once the bank has issued the credit, the merchant may discard all data
on the transaction.
The transaction log stores the merchant's authorization ( 
)
whenever it produces a global commit ( ). This information
may be discarded after some delay following the transaction expiration
( 
). The delay should be long enough that denial of access
to the log for that duration is extremely improbable. It is also
important that the log not generate 
for any transaction with
an which has been exceeded by more than this delay period.
The bank must maintain a variety of transaction information to correctly manage the protocol. The bank must have a selection of brands of tokens. The brand of a token specifies the method used to create the token as well as the properties (e.g. denomination) associated with the token. Different brands of tokens are used to cover the range of desired token properties, particularly denominations and expiration dates. Since the bank knows the brand of the blinded token withdrawn by a consumer, the denominations and expiration dates should have a coarse granularity so that many tokens of each brand are issued. The bank must maintain a database of processing information for each brand of tokens it issues.
The database for a brand of tokens tracks the status of tokens of that
brand. During the transaction phase, the bank receives an
authorization ( 
) to commit a token to a transaction. This
message is logged in the database, so that attempts at token reuse
can be detected. Once the bank receives the the commit ( ) or
abort ( ) for a transaction, it stores that as well. If the
transaction completes, the bank should keep both and
until some period following the expiration for the brand of
token used. If the transaction aborts, the bank need keep only
. In order to limit the time the bank must store
records, transaction claims by the merchant should have a limited time
of validity, perhaps some fixed period following . This
period should be sufficiently long to allow time for reasonable delays
or for outside party conflict resolution. If the period is based on
, then the bank may decide to not authorize any transactions
with excessively late values.