Central bank digital currency and smart contracts

How are they different from Swift exchanges? Not by much.  As a client, I want to use digital currency in a smart contract, meaning the Smart contract has permission from me in the form of a public key that it can put a hold hold my fiat account. So far, so good, but why not do that within Swift? And I suppose they will.

The smart contract is the proof of stake ledger.  The smart contract must host my account for the duration.

The smart contract must be a public ledger available to counter parties during the contract. The fiat banking holding my account thus issues a public key with which the holds can be verified on the contract ledger. Each of my counter parties must know this key independently.  These keys can be published beforehand.

This should work fine. This should work with the Eth2.0 contract protocol (solidify) . Each counter party has the responsibility to acquire the proper public key from the original issuing fiat.  The real issue is whether Swift has its own contract system, its own programmable contract language and contract ledger.  There is also Viper, a python based contract language.  The digital currency has little to do with it, that is just a standard Swift operation.

Point to point petty cash, bearer assets. To do this, the smart phones needs a copy of Solidify or Viper. The counter party must have independently acquires the cash public key from the issuing fiat bank. The two can simply exchange the current contract ledger, each verifying any part of it needed.

Consider a ledger swap from fiat to SEC, both of them trusted ledgers and they issue public keys for verification.  I send you a copy of the contract with my transfer, and you send me the same contract with the SEC swap. We still have the same issue with race conditions.  You may abscond after verifying my transfer. So we still need the reverse within timeout procedure in both master ledgers. That seems to be a standard with all ledger swaps.