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

DBC investigations have been revived!

I have faith in the teams ability and desire to achieve this. So if or when this works out then how might we market this unique feature?

What does it mean to have a DBC?

It means you get a high level of anonymity and can do offline transactions. It could act as a form of physical/digital cash as you have a verifiable amount of the Safe Network token that could be printed on a piece of paper, maybe even cloth/fibrous paper, and you could transact with someone physically and privately. Perhaps there could be the option of scanning a QR on the paper to verify the amount is still held at the printed address or maybe it could be transferred offline from phone to phone via NFC (Near Field Communication).

Some Rough Ideas

  • Bitcoin has been advertised as “Be your own bank” which is powerful. Perhaps we could build off that somehow.
    Also BlockFi, DeFi, etc names have become shorthand as describing something with ‘Fi’ meaning, Finance.
    So I thought MiFi or MyFi might be interesting but it looks like those are being used so maybe some variation of that as a general marketing term could be useful for us describing this feature to the general population and the general space we inhabit.

  • I also considered something along the lines of “Having the power to print your own money” but money printing has become synonymous with devaluation or debasement of a currency and isn’t exactly accurate anyways. You can print what you own though, so maybe build off from that.

With these suggestions, are there any tag lines that pop into your heads hearing these ideas and possibilities made possible by a DBC?

Please share your thoughts.

For your reading pleasure. A bit on DBC’s



  • SelFi (but unfortunately reads like “selfie”

Edit: will update more

1 Like

I have a very basic almost painful question. This seems like an amazing thing to have and would be a welcomed component to the network but also seems 100% unnecessary. Why give even an ounce of time to something like this when it’s not needed for the greater good of a operating network?


@waveman352 Well tbh I’m not sure the level of present anonymity with AT2 as is and DBC is able to give a high level of anonymity that would put other efforts to shame as far as I am aware and I believe because of maybe not enough privacy in AT2 (just my speculation) and given the fundamentals of the network token, this may be why DBC investigations have resurfaced.


DBCs - Crypto with the convenience of cash.


I was not aware of that as an issue or possible issue without DBC. Thank you.


Pure speculation on my part! So please don’t take my word for it.


Why is this being worked on before a test net?


The thing I can’t see how is done is the offline double spend protection. In essence, as far as I’ve seen, spendable crypto balances are conceptually mappable to a ‘right to direct funds from’ account, whether it’s like a 1) custom dedicated account (e.g. btc paper wallet, original cascasius coins, etc.) or 2) like a cashier’s check (pre-allocated balance). Either is trivial to achieve with SAFE, and 1) is trivial with any other crypto. What is hard is to guarantee is that if you accept either variant, what’s to stop the person who sold it to you from simply copying the relevant permissions and emptying before you can make use of it. Depending on the time limit it maps to (t=0 → a regular crypto transaction, to t=mucho → you’re relying completely on a third party).

My thoughts are too limited to square this circle, but if you need internet access to exchange them and SAFE is instant and private, then DBCs add nothing… put another way, if SAFE is private and no history is kept, then SAFE is a DBC without the offline quality.

A semi solution (e.g. not full offline exchangeable) would be something like the phone credit receipt model, where a retailer (or any balance holder) could transfer to a key and print out a token/signature. If you trusted the retailer, e.g. 7-11 or the person who sold you the 7-11 phone credit receipt, then you could get a digital token, and then any SAFE client with access to the information could immediately upload to the network… not unlike bitcoin ATMs that print a paper wallet… you trust it as long as it takes to plug in and sweep.

Would love to hear thoughts on this topic.


I guess, thinking further after @dirvine 's post, that another evolution of it could be as a network-held account with a re-keyable private key…

So, you could have a piece of paper with an address to a server … you could scan it, go to the page on your phone, put in your new password, and have the last owner put in theirs… then the balance would be yours to pass on or to redeem…


  • Don’t need an account to use it/transfer it. Essentially making a wallet out of any password manager.
  • Even if SAFE privacy is breached, not traceable to anything until redemption, e.g. like lightning network on top of SAFE (with however a need to be online to switch keys)
  • Damn close to bearer cash in a world with smartphones


  • Suceptable to key loss ( use a password manager)
  • Phishing attacks, e.g. a website that looked exactly like an official transfer site


  • SAFE cash app? e.g. done with an official app that connects to the safe network, no account and can present the key switch interface…

This could have legs…


It would settle via AT2 I would reckon so one wins and one loses, there is no double spend. I would guess it’s whoever runs is back online first if it’s offline.

Good point. I know the physical bitcoins that came with a balance had a “tamper proof” sticker that hid the private key so maybe a similar solution. Let’s try and think of ideas on how this could be achieved.

This reminds me, I think I remember Jim mentioning having Safe Network gift cards with preloaded balances, maybe a scratch off to a priv key QR or something or url to a preloaded wallet/account etc. like where you find preloaded cards and gift cards in a convenience store. AFAIK this could be done either way but maybe not anonymously without DBC.

This does. We’re just limited by our imaginations. I really like your pro and con list!

I love this. If you or anyone else has others keep them coming!

1 Like


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.”


Imo, its important to keep it simple. The basic DBC should just be viewed as a physical safe coin that has been emitted from the network into the real.

So how do we prevent the double spend off-network? (Imo a sticker hiding the private key isn’t good enough.)


Half-offline capability

The combination of ownership and publicly verifiable mint signatures allows for transactions in which the recipient can do a check against double-spends without having to communicate with the mint. The recipient only has to keep record of the DBCs sent to it that have a specific owner. If a DBC is presented twice a double spend is detected, if the DBC is unique and carries a valid signature by the mint the recipient can be sure that the DBC will be accepted by the mint for reissue at a later point in time. Since DBCs can include two owners that are exclusive to each other and cover two defined time spans, it is also possible to pre-generate DBCs to be used in an offline manner at a later point in time. The user simply generates DBCs for the intended recipient that after a certain time fall back to be reissue-able by the user’s key. This allows transactions between two parties in which both can be offline for a defined, possibly very long, time span without needing to interact with the mint. This makes the system very usable for scenarios of mobile point of sales transactions and simple hardware implementations, such as in the case of payment cards, public transport tickets, etc. Furthermore it makes the system much less vulnerable against denial of service attacks. To clarify: There are only two cases which require one of the transaction parties to talk to the mint during the transaction: The recipient is unknown, or the payment amount is unknown. In all other cases the transaction can be structured so that no communication with the mint is required during the transaction.

To me this kind of reads like you have to know the recipient but I thought that DBC doesn’t require accounts. Also when we speak of double spend, I don’t believe there is any issue with double spending in the system itself but maybe what we are referring to is someone handing off a DBC offline saying it holds value and the recipient possibly being duped before redemption as the details or keys of the DBC were recorded and the value already swept. Is that what we’re talking about here @jlpell? You have any ideas? When I have more time soon I plan on seeing if there are any previously used solutions.



We already have “working” examples in the current banking system that rely on a central authority. The first is coin/cash, the second is a cheque. A model similar to these by analogy that replaces the central authority with a network section might be a winner.

  1. When you go to an ATM (bank-o-mat) you sometimes request that your electronic funds are converted to physical funds (cash) that you use to pay for your morning cup of coffee. This DBC circulates freely in the economy until someone at a later date wants to deposit the physical funds back into “the bank network”. This return to the bank is possible because of the various anti-counterfitting measures built in to the physical coins/cash proves that no double spending has occured. The same physical cash/coin is intended to circulate and be used for many transactions.

  2. Physical cheques can be written at will by buyers of goods/services and are redeemed by sellers at a bank. If a malicious person double spends on their account there are consequences. First the counterparty is harmed because they rendered services to the double spender which now need to be recovered. Often this is where escrow services come in to minimize risk with untrusted parties. A single cheque is only good for a single transaction.

Both of these methods have pros/cons for serving as a model for an analogous SAFE DBC. Personally I do like the idea of physical/trusted objects that are durable and reusable with physical double spend anti-counterfit protection built in (but more than just a sticker). However the cheque issuance model is probably easier to implement since the physical object can be a plain piece of paper. It is also easier to secure since the network is involved for every transaction.

My intuition tells me there is a third approach with the benefits of both and none of their shortcomings. Need to think on it a bit more though…


Safe Network is already totally anonymous. Almost everyone carries around their smartphone with them. If a transfer is done on a smartphone through SAFE Network, it is anonymous and just like cash. There are also paper wallets as well. Why do we need anything else? I’m afraid that fooling around with side projects will delay the Network.


1 Like

Because it isn’t totally anonymous yet, it doesn’t exist. Nor is it secure etc. There’s a design being implemented which we’ll be able to test and try to break during tests.

DBC, if feasible gets us more confidence in the level of secure anonymity the network can achieve, and as a bonus will makes for a more efficient solution (less work for sections, more done by the clients), and the added functionality of offline transactions.

Given this is being explored without distracting any developers from getting the testnets up and running, I don’t understand why some folks are concerned about it. We’ve known MaidSafe wanted to look at DBCs as a potentially better solution for some time, and IMO it’s great that they are so close to the testnets that they have the spare capacity to do this.

More in this topic:


So if SAFE Network is not totally anonymous, how will you create a DBC that is better than the underlying Network that supports it? Why not just put those same resources into making SAFE Network more anonymous instead?