Update 02 September, 2021

We’ve been dangling the prospect of an update on the Safe economy for the last couple of weeks now, and we’re pleased to be able to deliver with an overview of our current thinking on Digital Bearer Certificates (DBCs). There are still a few balls in the air marked “one-time keys” and “denominations” but we’re definitely converging on a workable solution that will be fast, private and secure.

As with many other Safe innovations, the aims of DBCs are simplicity and making the client do the work wherever possible - which usually amounts to the same thing. We want to avoid having to store state (e.g account balances) on the network, or to resort to conditional logic, both of which breed complexity. Instead we are rolling out Anti-Entropy in many communications, where the flow is: try -> success (carry on) | fail (retry), while keeping track of state is the job of the Client.

We know that you’re all itching to get your hands dirty again with a new testnet, but to make it worthwhile we want to make sure the network is stable with multiple sections and that AE is working properly across the board.

General Progress

We’re trying to nail an intermittent issue that is seeing different Elders in a section receiving different messages from the same node (this should not happen) and/or choosing different Adults to store the same chunk. Also Elders sometimes write data, which is the Adults’ job. @Qi_Ma and @lionel.faber have been looking at these messaging anomalies.

We’ve had a push to finish implementing AE on the client, with @bochaco and @yogesh leading the charge. There are still some niggly issues there and @lionel.faber has been helping out with debugging Client AE and has already identified one of the causes of the anomalous behaviour as Elders having different section keys.

@oetyng has finished his refactor of self-encryption (which has now been merged into main), and has also been working on refactoring the way chunks are handled.

And @danda has been looking at the question of denominations of DBCs: in selecting denominations for our currency, what values should we choose and why? What appears to be a simple enough question actually involves some interesting trade-offs between network efficiencies and human usability.

An overview of DBCs

A DBC is a unique ‘digital voucher’ that has value by virtue of the fact it has been provably issued by a trusted mint as part of an economic system. To spend a DBC you need to get it reissued by a mint. The mint can take your DBC and reissue it as two or more new DBCs if you wish (e.g. payment to a shop, the remainder as change to you), and multiple DBCs can be reissued as a single DBC.

The important thing for us is that DBCs provide a quick, safe, flexible way to make payments that is compatible with multisig/threshold signature cryptography and can be used online and offline. They simplify many aspects of the Safe Network economy.

The current state of affairs

Currently our DBC system involves the following:

Sharding: The mint is sharded between sections, such that every section is responsible for reissuing only certain DBCs, determined by the DBC name/id.

Decentralised Mint Nodes: Within a section, individual mint nodes (Elders) operate autonomously, without coordination. A Client performing a reissue operation must obtain a ReissueShare from a supermajority of mint nodes (at least 5 of 7). Each ReissueShare contains a BLS SignatureShare. The client combines these SignatureShare to obtain a full Signature. The Client adds this Signature to the DBC contents to form a complete DBC, ready for spending.

DBC Ownership: Each DBC has an owner, identified by a PublicKey. This enables DBCs to be stored and transferred in cleartext without anyone stealing them. The mint verifies that the owner has properly signed each input DBC when it is spent (reissued).

Amount hiding: DBC amounts are hidden such that only the sender and receiver can know it. Not even the mint nodes can see the amount. Yet the mint can verify that the sum of input DBCs matches the sum of output DBCs through the use of Pedersen commitments and rangeproofs (bulletproofs).

Spentbook: Each Mint node writes to a Spentbook. During each reissue the mint node will first verify that all input DBCs are not already in the Spentbook (have not been spent) and that all signatures and outputs are correct. It then records each input as spent in the Spentbook. Ideally we want to move this to the client, see below.

Future Improvements

We’re still looking at where we can make enhancements to the DBC system, and the following are all under consideration:

One time keys: The mint nodes would enforce that each public key can only be used in a single reissue transaction. This can help with privacy because it prevents keys being used in multiple transactions.

Client writes to Spentbook: With this setup, the client would write Spentbook entries before contacting the mint. The benefit of this is that the reissue call becomes idempotent, meaning that a client could make the same reissue call many times and receive the same response each time.

Blind Signatures: This would bring us a true ownerless “bearer” certificate. A pure form of untraceable digital cash, if you will.

Public Spentbook: Making the Spentbook public is considered desirable/necessary for the public to audit the money supply, i.e. to verify that additional money has not been created either through fraud/theft or bugs/errors.

For anyone interested in diving deeper, our DBC code is in the sn_dbc crate.


First, after months of stalking! Let me read now :happyant:

Privacy. Security. Freedom


Second maybe some day I’ll be fast enough


Moored up and you didn’t wait! Now to read.

I think the work on DBCs and economy is fascinating. There are two areas I’m wondering about:

1. Spentbook

  • does the spentbook grow indefinitely or can it be pruned of certain spent items, and if that is theoretically possible are there any downsides?
  • How is the storage taken up by the spentbook paid for?
  • Are there issues to think about if it just grows and grows?

I’m guessing a spentbook entry is a few bytes, enough to hold a hash or key, and that the number of entries will be >1 per DBC issued (i.e. per transaction) because each new DBC will have at least 1 input, which needs adding to the spentbook.


I think we’ve come to love the idea of almost infinite divisibility that comes with an account balance system, but if we move to denominations I think we lose this because we’ll have to choose the smallest denomination that can exist from the start.

I’m not sure if in practice there’s that much difference between the two approaches, but at first sight it seems there might be. I guess the main concern I see is that as SNT are lost over time, or if the price of things in SNT falls sufficiently there may come a time when the smallest denomination is just too big for small purchases, especially micropayments.

And who knows, maybe nanopayments or picopayments etc will be improtant in time with IOT and other things we’ve not imagined yet.

This is one of the downsides of a hard coded system compared to one which can be rewritten overnight by a central bank.

So at some point I’d be interested in a topic which looks at the pros and cons of the new approach so we can understand this and discuss them.


  • thanks to all who have chipped in and helped me understand how divisibility will work and could in theory be extended, though to be confirmed as things solidify.
  • @MaidSafe any chance of a response on the first questions about the spentbook, or is it best to leave that for now?

Thanks so much for all of your hard work Maidsafe team. There will be a sudden breakthrough, I can feel it coming. :racehorse:


DBC + sharded mints + pedersen commitments + bulletproofs + blind signatures + public spentbook = best currency in the world

Interested to hear more of the pros and cons of clients writing to a register spentbook and also if one time keys have any downsides?

Also are denominations not efficient for the network?
@happybeing brings up great points about micro, nano, pico payments. Part of me thinks, who likes change anyways but again, great points by Mark. How does that one get resolved?


What happens when a section got corrupted someway, and is not working anymore. Are these DBCs then worthless?


My guess is it will just go to the next nearest (in Xor terms) section


Curious what the team says but I would think no not worthless. A compromised section of elders I think can choose not to sign transactions and choose not to store them (maybe a case for the clients going to a public register?) or data but I don’t think they can mutate or delete data.

So maybe the solution would be grow out of that section by growing the network? Maybe that could even be incentivized someday if a compromised section is spotted?


Lot’s happening fast here, big one is data is signed and gets Section signed when required, meaning it is all republishable. So say section goes wonky, spentbook is not there so DBCs look worthless. however an owner can still present a valid spentbook entry with the DBC to make it valid. i.e. you can still write the spentbook, even when section bad.

I favour clients write spentbook before the section signs the outputs, so worst case you are in limbo for a wee while, but not lost your money.

I also really favour the network being irrelevant for data lookup (Still great but not required), so many many backup places to archive provably valid data for republish any time on any medium. It’s close to that now, but a target we like in house.


Makes being a malicious elder boring and not as fun if I can’t take peoples money or keep it from them entirely!

So it’s akin to say a bank went bad but you can take your public (though shielded) pocket book and bearer cert to another bank and have it still be valid, yes?

Is this even less of a problem if DBCs are ownerless with blind signatures?

Brilliant approaches. Always gets better.


Nothing is said about mining/earning/whatever_you_call_it.
Will there be part II of economy overview?


Farming :smiley:

Yeah, we’re having to break down the full economy package because, quite honestly, it’s a lot to communicate.

DBCs make it all happen though.


Does that mean it’s now decided that a section can create SNTs? Having no section wallets and such seemed quite nice. I liked the idea that a compromised or buggy section cannot even in theory create or steal tokens.


As long as you can account for enough denominations, the same level of divisibility can be maintained. For example, 128 bit divisibility = ~40 denominations. That’s not a huge set for a wallet to manage.


Can you democrate how this answers my concern? It’s not obvious to me.

No, not so far, we are looking to ensure sections cannot even write the spentbook either :wink: So much more a validator role, but not a creator role. More to be done, but looking good


David, just to make a rough estimation, how far do you think we are away from the next mindblowing testnet? :crazy_face:


An integral number of days between 10 and 100 is my guess…

I doubt next week, thats when we get the earning side of the economy revealed, maybe the week after…