# Offline Payment of Central Bank Digital Currency Based on a Trusted Platform Module
## 3 Methodology
### Offline CBDC Model Protocol  
Prior to the transaction, both the sender (A) and the receiver (B) should install an OffCW on their devices equipped with TPM. During the installation of the OffCW, each entity is required to obtain an ID certificate for its OffCW, following a verification of its identity. To initiate the transaction, each entity executes its OffCW program and establishes a connection with the other party through short-range wireless communication. The execution of the OffCW program necessitates the implementation of a security procedure, such as the entry of an authentication code, to verify the identities of the entities involved. Each OffCW encrypts and stores its valid tokens, which can be utilized for transactions, along with the corresponding ID certificates (Cert_X) for each valid token. Additionally, each TPM securely retains the digital signature generation key (PK\({}_{\text{X}}\)) and the OffCW's ID certificate, which contains the digital signature verification key. Furthermore, the non-volatile memory within the TPM houses a monotonic counter (C\({}_{\text{X}}\)) and the total sum of currently valid tokens (Bal_X). The TPM also stores a decryption key (SRK\({}_{\text{X}}\)) that is capable of decrypting another decryption key (SK\({}_{\text{X}}\)), which, in turn, decrypts the values stored within the OffCW. The protocol delineates two types of communication: internal communication between the OffCW and the TPM, and external communication among OffCWs. Figure 4 illustrates the OffCW and the TPM information pertaining to the entity. Figure 4: Offline CBDC Wallet (OffCW) and TPM information of entity. (9-1) \(SUM=\sum^{N}\)\({}^{\prime}cbAmt_{N}\)\", where \"cbAmt\({}_{N}\)\" is the valid input token's \"cbAmt\". (9-2) \(K=SUM-T\), \(R_{T}=[\{(\sum^{N}cbR_{N})+R_{A}+R_{B}+C_{A}+1+C_{B}]\ mod\ R_{A}\}+R_{A},\) where \"cbR\({}_{N}\)\" is the valid input token's R\({}_{T}\) (9-3) gen_A = Header.Payload[\"cbSta\":\"Tp\",\"cbRt\":Rt,\"cbOwn\":ID\({}_{A}\),\"cbOtcn\": \(C_{A}+1\), \"cbAmt\": K,\"cbEds\":ID\({}_{B}\),\"cbEctn\":C\({}_{B}\)] where, the \"Header\" will be defined by CBDC institution. (9-4) gen_B = Header.Payload[\"cbSta\":\"OX\",\"cbRt\":Rt,\"cbOwn\":ID\({}_{B}\),\"cbOtcn\": C\({}_{B}\), \"cbAmt\":T,\"cbEds\":ID\({}_{A}\),\"cbEctn\":C\({}_{A}+1\)] where, X in \"OX\" is the value by adding 1 to the largest number of N in input valid token's cbSta. (input tokens = valid tokens). Step (10) OffCW_A \(\rightarrow\) TPM_A:  
Step (11) TPM_A \(\rightarrow\) OffCW_A:  
Step (12) OffCW_A:  
Step (13) OffCW_A \(\rightarrow\) OffCW_B:  
Step (14) OffCW_B:  
Step (14-1) new_gen_A = Header.Payload [\"cbSta\":\"OX\",\"cbRt\":Rt,\"cbOwn\":ID\({}_{A}\),\"cbOtcn\": \(C_{A}+1\),\"cbAmt\":K,\"cbEds\":ID\({}_{B}\),\"cbEctn\":C\({}_{B}\)] Step (15) OffCW_B \(\rightarrow\) TPM_B:  
Step (16) OffCW_B \(\rightarrow\) B (receiver)  
Step (17) TPM_B \(\rightarrow\) OffCW_B \(\rightarrow\) OffCW_A:  
Figure 5 is an example of the proposed model. In this scenario, Alice is required to transfer USD 60 to Bob. Alice possesses a total of USD 100, which consists of three valid tokens: Token_A\({}_{O1}\), valued at USD 20 and confirmed by a CBDC institution; Token_A\({}_{O2}\), valued at USD 30 and received from Ann; and Token_A\({}_{O3}\), valued at USD 50 and received from Chan. Furthermore, Alice's current counter value is 15, while Bob's current counter value is 981. For the purposes of this example, for convenience, the IDs have been replaced with the respective names of the entities involved. Token_A\({}_{O1}\) represents the initial token exchanged from an online to an offline context, with the value of 'cbSta' designated as O1 (see Table 2). The transaction number, denoted as 'cbRt', is recorded as 0, indicating that this is the first token exchanged from an online wallet. The first offline token will display a counter value ('cbOtcn') of 0, as the counterparty in this transaction is a central bank, and the token is secured by the signature of the central bank.