How we might market a DBC’s (Digital Bearer Certificate) Unique/Cash-like features

From https://opaque.link/post/digitalmoneydbc/

I found this section interesting as Safe utilizes Asynchronous Trustworthy Transfers (AT2).

“ We went from trusted, to verifiable, to possibly trustless. The word I am missing in that enumeration is “trustworthy”. So far, we have failed to build systems that are worthy of our trust. When we have trustless however, do we really need trustworthy anymore? My view is that building trustless systems is very limiting from perspectives on complexity, economics, privacy and adaptability. Trustless systems are necessarily huge, needing many persons to cooperate according to the same protocol. This makes them vulnerable to error of specification and a changing environment. They are also inherently expensive to operate and likely will never be as fast and cheap a DBC systems. Let alone that they are likely never going to achieve the same strength of privacy - anonymity and untraceability - then blind DBC systems can reach.”

In this section I wonder if there could be a network DBC token standard and “swaps” could be done easily by the network with little overhead? I’m just imagining platform tokens, physical assets being tokenized, wrapped coins from outside of Safe and every asset would be universally swappable!

“Multi-currency Mints and advanced ownership

DBC systems are flexible and easily extended to support further use cases. While the ownership feature described above is powerful, it can be adapted for more complex protocols. An example for that is the experimental extension developed for eCache.

Instead of simply recording the public key for transaction signatures, the hash of a “contract” was recorded in the DBC. A contract is a boolean expression describing the conditions under which a DBC will be reissued.

Furthermore the contract can apply to more than a single DBC transaction. eCache supported “combined” transactions in which two or more DBC transactions could be presented to the mint at the same time, the conditions of each of the input DBCs referring to the output DBC templates of the other transaction. This allows creating schemes that allow swapping the ownership of two certificates presented by two different users.

For example, a DBC issued for the denomination “gold” for owner A and another for the denomination “EURO” for owner B can be simultaneously processed if and only if the respective output DBCs would be “gold” for owner B and EURO for owner A. This essentially implements a swap or sales.

To facilitate processes like these eCache in addition implemented an “Issue Book” which cached newly issued DBCs created in combined transactions. It allowed anybody knowing the output DBC template to retrieve the signature for it. That way a user could pre-sign a transaction, give it to another user for combining it with his transaction and sending it to the mint, and then ask the Mint for the signature to be able to recreate the result of the transaction.”

3 Likes