Update 21 October, 2021

Beauty. 10 chars.


So glad to read soon after that you moved on to SI prefixes. This first naming scheme is something out of Harry Potter… yikes… very hard to grok. The Si functions in the repo look nice. Sticking with SI is very important imo.

It looks great. Nice work. :+1:

Yeah, you nailed it. That’s the equivalent of 425 bits. No more complaining from me. The use of a single i8 for the exponent is nice imo.

Cool. Very cool.


This is an area where different wallets can compete on UX. There won’t ultimately be only one way to interact with the network.


you are welcome to code up an alternative approach and submit a pull request!


acceptable or not would be determined by the market of course. Those could easily be done in two separate reissue if desired. People use USD for large tx regularly and generally do not care about 25 cents when sending 10 million dollars.

Further keep in mind that a reissue is not the same as a payment. A payment is p2p (no mint involvement) and can contain an arbitrary list of DBCs, so those could include DBCs of any size.

Look, everything has tradeoffs. Ideally I would like to have all of: unlinkable transactions, arbitrary hidden amounts, instant settlement, and high efficiency (scalability). This particular solution gives us unlinkability, instant settlement and high efficiency. And the denominations work like cash. I think this is a unique set of attributes that the market might like, but it will have to be proven out of course.

Zero-knowledge proofs (eg PLONK) are another possibility that could provide unlinkability, arbitrary hidden amounts, maybe instant settlement, but the efficiency is (probably) much lower than blind sigs. That might be an avenue to pursue later on.

Also, I should clarify that it has not been at all decided that we use the blind sigs and denominations approach. We are maintaining a hidden-amounts fork and also the blind-sigs fork. We are nearing feature parity in both forks, and then can start some performance testing, which will be informative. Later we might even try some kind of A/B testing with the testnets once DBCs are integrated.

ps, anybody want to start work on a ZK fork of sn_dbc? seriously… it would be awesome to be able to test that out against the other two approaches.


Wallet software could implement that yes. Or one could manually reissue larger “coin” inputs into smaller, or vice-versa. I envision that a wallet would present a list of “bills” or “coins” and one could select one or more of them and then click “reissue” and specify 1 or more output amounts. simple as that.

yes absolutely. If this thing takes off there will doubtless be a ton of documentation available, just as there is with bitcoin and clones today. Anyway, these writeups are a first step at information dissemination, and also anyone is free to look at the code, and the API docs. At the moment we are in an iterative design/code phase and api’s are in flux, so it doesn’t make sense to be writing detailed docs as yet.


These features really stand out even more in the current cryptocurrency environment. Especially denominations which fit the majority of the worlds experience with money and might give a lot of crypto folks a duh moment.

Dealing with the decimals, the valuation of fractions in fiat, the value of Satoshis is such a pain point and an intimidating hurdle for newbies. So far the only avenues that seem reasonably usable to the average joe or jane are the lightning network and coinbase.

It’s always interesting to take a step back and realize that even though there is more adoption, there are still so many people out there that don’t care, are too intimidated by crypto and the terminology (like DeFi, NFTs, Satoshis, etc etc), why they should care about decentralized money because they don’t even understand the current monetary system, or they only want exposure through traditional means like an ETF.

Having a cash like digital currency that is easy to send, receive, and earn is of the utmost importance. I think one simple and relevant message is that, there is a war on cash, cash is king, and SN Token is the king of cash. Not having to worry about fees, complex alphanumeric addresses and multi-factor just to feel secure will also be a huge relief to the layman.

When we get deeper into the fungibility that most won’t understand or relate to, in the future if leverage exchanges or out of jurisdiction exchanges are banned then perhaps so will the bitcoins that come from there to wallets in unsupportive jurisdictions. Virgin bitcoins that are freshly mined may trade at a premium. Chainalysis will grow as an industry to the point where there may end up being just short or worse of the level of control over flagging or blocking accounts as there is today.

I can’t speak to the technical approaches much but when reading it all laid out it is obvious that efficiencies and choices for balancing all of the benefits the world would want out of a currency are being made and that is fantastic for all of us in the end. Proud to be here to even witness this kind of innovation.


This all sounds truly groundbreaking. So much novelties are being implemented in the Safe Network, can’t wait to see it!
Makes me wonder though how this will all be presented to the user without having to understand all the technical details… Is there any info on the UI?


My examples are just variations on Sally example:

The question is: can we send such payments ? If so the OP should be corrected.

1 Like

It very much depends on how you are defining a transaction.

If I go into my bank to deposit £155 in cash, is it a single transaction, or one for each note I hand them?

In reality, services use systems of account, and wallets and apps will have the concept of multiple DBCs grouped as a single payment, in the same way as the bank example above.


I would say that your example is a single transaction that is being completed via multiple operations…

A single transaction that we make day to day often envelopes many object(s) or physical goods/services one is trying to acquire or dispose of. Go to a restaurant and pay for a meal, purchase a car, or a pack of bubble gum, sell your house etc. would each be single transactions imo. But each transaction often requires a lot of tasks or operations to complete.

The use of denominations is intuitive and deeply entrenched in our minds since childhood (going back generations). This is a powerful concept for widespread adoption imo. Passing a bunch of different token/coin denominations around to exactly transfer what total amount is required is no big deal. It offers the same “physical” feel that classic safecoin had when each coin was to be a unique but transferable data object, but now capable of quasi-infinite divisibility.


Fair point. The OP should say:

Sally could reissue 1 billion + 10, but she could not reissue 1 billion + 1 (or 2, 3, 4…).

I don’t think I have perms to edit it myself.

edit: payments are sort of a level “above” DBCs. We have only just started sketching out a design for invoices, payments, and a PaidInvoice (proof-of-payment). We expect a payment to be at least:

pub struct Payment {
    dbc_packets: Vec<DbcPacket>,
    memo: String,    // fixed size?

note: A DbcPacket is a single DBC plus some metadata.

There is not contemplated to be any nearness limit in a Payment, so yes such payments could be sent.


OP edited …


Good. This clarification removes my caveats about the 10^9 nearness limit.


Erm, state of the art in cryptocurrencies is that a transaction shouldn’t disclose the amount to begin with. It also shouldn’t be possible to link a transaction that spends value with the transaction(s) in which that value was received, let alone to link it to any lasting identifier for either the sender or the recipient.

Quantizing transactions doesn’t cut it, especially not when there may be other information available to deanonymize the transaction, possibly from outside the system.

I mean I know you’re not primarily a currency, but if you care about privacy, that’s where you need to go.

Doing better than Bitcoin isn’t enough. Bitcoin is a first-generation system, and if you’re using it as a basis for comparison or a starting point for thinking, you’re looking in the wrong place.

I think your concerns are misplaced because my understanding is:

  • only sender and receiver can see the amount
  • the IDs are one-time and so can’t be used to tie multiple DBCs to a single ID
  • transactions be linked, and not just because it uses denominations

AFAIK, though I confess I’m not an expert on this, the privacy features of this system are as good as any existing privacy currency, while several other features are superior.


Thx 4 the update Maidevs

bitcoin needs fiat so that it’s price can go up, SAFE doesn’t. For example SAFE is the reserve money for gTLD’s. Hope it become the reserve money for storage, enabling exabyte storage for enterprises or clueless uploaders… :joy:

Would be fun to see –exchange enabling every data to be exchanged for every data on SAFE Network, eliminating the time waste of centralized exchanges.

Keep hacking super ants, great read on denom :stuck_out_tongue_closed_eyes:


I do have a question though. What exactly does a reissue mean? Who reissues what precisely and to whom? I mean I get it’s used to reset a coin amount or to consolidate them but what precisely is happening and how is it working?

1 Like

@danda Sounds like denominations is progressing on a good path. And not just because what my view was :slight_smile: its developed past whatever I said LOL

Your explanation was easy enough to follow, except towards the end with how the limits on Denominations in a spend. The max of 1 billion stuff though is simple enough and huge.

Typically one thousand covers most real world situations. Well the person with a 20 litre bottle of pennies might not work with one DBC, but easy with many. How many people have ever transacted actual cash with 1000 of one denomination except the suitcase of 10$ unmarked circulated notes. Now 1 billion covers it I would think.

No I was talking of the very last bit where you couldn’t have something like 10 and 1 pico. The description was not clear to me. But that maybe because my concentration was lax, I will reread. And I am sure this will be developed further and worked out for the best whatever that is.

I am looking forward to seeing denominations implemented


A DBC has an owner, so to spend it you (owner) re-issue it with the payee as owner.

As you note, multiple input DBCs which you own can be consolidated when you re-issue to yourself or a new owner. And DBCs can be split to issue new DBCs with different owners.

I thought that was explained already though so I’m not sure if I’m answering your question.