The atomicity properties of the protocol rest on the atomicity of the
transaction log's non-repudiable 
(or 
). The
transaction log will eventually produce exactly one of or
for any transaction. The other parties can use this, along
with other data gathered during the course of the transaction, to
prove that the transaction did (or did not) complete. Conversely, if
a party claims that the transaction did (or did not) complete, it must
be able to provide this proof to justify its claim to other parties.
The transaction protocol follows the two-phase commit model, however, the
authorization actions of the parties are cascaded. First, the consumer
authorizes the bank to lock the token to the transaction. Next, the
bank authorizes the merchant to transmit the key to the log. Then,
the merchant sends the merchandise key to the log, authorizing the log
to commit the transaction. Finally, the log issues the global commit.
Accountability is similarly cascaded so that a party can be held
accountable exactly when it has made an authorization and the
transaction commits. For example, if the bank authorized the merchant
to deposit the key ( 
) without having received the consumer's
authorization to lock the token ( 
), then the bank could be
held accountable by the merchant (who would have and
), but the consumer could not be held accountable by the bank
(which would have but not ).
The merchant can use and to prove that the bank
should credit the merchant's account with the value of the token.
This provides the bank with . Possession of assures
the bank that it will not be subject to a claim that the transaction
has failed, since such a claim would require .
The bank can use and to justify (to the consumer)
marking the token spent and denying reuse or replacement. The
consumer can demand this proof, requiring the bank to produce
, which contains the merchandise encryption key, thus
giving the consumer access to the goods. Note that in practice,
assuming good faith, the consumer will acquire the key prior to this,
and demand of proof will not be necessary.
The consumer can use and q to demand that the token be
unlocked. This provides the bank with . Possession of
assures the bank that it will not be subject to a claim
that the transaction has completed, since such a claim would require
.
Finally, the consumer can use and 
to prove the
contents of the delivered goods. The goods encryption key, the
encrypted goods, and the description of goods (contained in the
contract) have all been signed by M, and proves that the
transaction completed. Some means for review of goods by an outside
authority should be available to establish claims of incorrect or
fraudulent goods delivery.
From a correctness standpoint, it is important to examine the use of
combinations of signed, non-repudiable messages employed above. Any
given (or ) is valid for only one combination of
n, 
, M, and L; it is considered to be compatible only
with the messages which agree on those values. The one exception is
that the certificate does not mention L or ,
and thus must agree only on n and M to be compatible. At each
step, a party provides a signed message which can be used to prove that
party's accountability with exactly the same range of
messages as it would use in proofs of the preceding party's
accountability. Thus, if a party is held accountable for the
transaction, then it is provided with the non-repudiable messages that
it needs to hold the previous party accountable as well.