Update 09 September, 2021

I was talking “internally” here. As in there could be oh I dunno, say 10E8 of the smallest base units to one SNT… – just a thott…

But we need to know the smallest amount we can transact for micro-payments. What we call them does not really matter, thats for @JimCollinson and others to weave a magic UI cloak around to make it appear simple straightforward and intuitive to the end-user.

I like @neo’s idea of allowing for other tokens within the data structure - thats flexible and far-sighted.


It’s hard even for me to see why we would ever need more than that. We get yoctoSNT at 1E-24 SNT. At 48 to 64 denoms we get a lesser infinite divisibility…

What shall we call 1E-255 SNT? Tribbles😅? Giggles? Overkills😂? Safezies😘? Regardless I’m glad this is possible and don’t mind the infinite possibilities for whatever comes in the future for a single byte.

Can someone add any clarity to what this means for routing? Do we still have 3 hops?


gets my vote :slight_smile:

I won’t say it’s gone 100% (and i think there’s a few different parts to it). But we’ve killed a few loops around an older style sync message as we converted it to AE. So now we know all state/member changes are being validated, which should help to avoid this (and those changes do seem to have had a decent impact).


Are you sending 1 or 5 or 20 of a particular denomination?

So to send 1.23 its

  • 1 x 1.0
  • 2 x 0.1
  • 3 x 0.01
  • each as a value pair count-denomination

If there is to only ever be < 256 denominations then could have denominations starting from 1 billion, then 100 million, then 10 million down to 1, then 0.1 then 0.01 all the way down to 0.000000000000000…01 (240 zeros)

Well just making a point really, that is why I explored it and realised we could have other tokens use the same code/mechanism

But there is an interesting idea of having say 64 bits for denomination and allow for it to represent numerous tokens. If you have 64 or even 128 denominations allowing for exotic denominations then that gives the ability to have 1x10^17 different tokens with 128 denominations each.

The very code for transferring DBCs/SNT could be used for all the other tokens as well. SNT is special because you farm it and pay for resources with it. But the rest of the code for SNT works just as well for all the other tokens.

Thus the Safe Network can then handle any other token with the same security as for SNT


Is this the killer app that will ensure widespread adoption?


But I wonder if with a (negligible) TX fee. Would seem appropriate tbh.


Yes good point. Maybe an amount of SNT to do transaction.

[EDIT: a put charge I guess is the easiest]


I was talking about using powers of two, not ten.
There are two ways of doing this:
1.23 = 123 * 0.01 = (
1 * 2 ^ 6 +
1 * 2 ^ 5 +
1 * 2 ^ 4 +
1 * 2 ^ 3 +
0 * 2 ^ 2 +
1 * 2 ^ 1 +
1 * 2 ^ 0 ) * 0.01
1.23 ≈
1 * 2 ^ 0 +
0 * 2 ^ -1 +
0 * 2 ^ -2 +
1 * 2 ^ -3 +
1 * 2 ^ -4 +
1 * 2 ^ -5 +
0 * 2 ^ -6 +
1 * 2 ^ -7 +
1 * 2 ^ -8 +
… = 1.23046875

Powers of two is not user friendly unfortunately and best to kept it human usable even it wallet does most of the work. And really that is just a number again not denominations as being spoken about.

To mimic coins and notes then using decimal is best which is the plan.


Numbers are already stored in binary form by computer.
So if it is possible to hide mathematics from user, then it is more suitable to use binary form.

The idea is to separate the denominations out so that if I give you 5 x 10 “cents” then tracing the many 10 cent transactions makes it difficult to ever match the transactions from inputs to outputs back to inputs.

But with what your idea seems you still have the transaction as the exact number but are only calling each bit a denomination. Much easier to track as its still a number representing the actual amount.

1 Like

I think it does not matter if network will have lots of 20 token transactions or lots of 16 (2^4) token transaction.
Just binary form is more machine friendly, compact and easier to implement.

The main issue is in your idea it seems you are storing it all in one number, a 32 bit number. This is not different to just storing a fixed point value. And is what they were trying to get away from.

Anyhow they are still developing so it will be interesting to see how they solve the issue.


Chia has been pestering Ledger about getting bls keys on their devices:


This topic has been debated ad nauseum. Simple decimal works best for the man on the street. Binary is more fun for geeks. We had talked about having both binary and decimal denominations, which would be easy to do with the new denomination system for DBC, but that extra complexity is probably not worth it just for the intellectual curiosity and “fun” of using/playing with binary “divs” vs decimal “decs”.


I read only what was posted in this topic.

That’s why I was talking about possibility to hide this complexity.
If not possible, then decimal should be used of course.

I do not see logic in such solution.
Will not dig in older topic to see why it was proposed.

1 Like

Reading the src is good fun… just looking at the basic enum and error classes wondering how to get a foothold understanding it. :smiley:

I expect I might spawn too many questions! :open_mouth: So, ignore the noob…

Does a client make a request to one Node, wait a few minutes and try again?.. or is it a challenge to a couple of Nodes who might respond first? Just wondering how many connections are dropped if an Adult disappears… what occurs when Adult become Elders… do they drop everything and celebrate?

re: state_machine Transition

Might there be transitions from Client or Node back into bootstrapping?

enum State {

state_machine suggesting ~

If not Stay then
// Bootstrapping state transitioning to Client, JoiningNode, or Node. => IntoBootstrapp-ed
// JoiningNode state transitioning back to Bootstrapping. => IntoBootstrapp-ing

but how is loss of connection from Client and Node handled?

1 Like

Just to be clear. My understanding of the idea in part is to

  • have separate amounts for each denominations.
  • give the users the feel of using coins and notes.
  • have the ability to send many of one denomination.
  • idea is to make tracing using exact amounts becomes very difficult since many transactions that are the same count of a denomination for each denominations.

The one bit per denomination would somewhat work as long as they is still one denomination as a value and other denominations are separate values too.

  • inefficient in that if I have 5 of 2^-2 then I’d need to do that as 5 transactions
  • using a bit per denomination rather than enum the denominations.

Using enum allows flexibly in that the denominations can be whatever is desired.

Maybe use the whole, half, quarter, 10cents, 5 cents, penny (+ other needed denominations). Would suit say the American UI and since values are exact the UI can display it as those denominations.

Maybe use the whole, 50 cents, 10 cents, 5 cents, 1 cent which suits the Aussies in the UI.

Maybe use binary which suits the geeks.

Now in fact the single byte enum could have all those denominations.

The reason binary is an issue is purely since there are plenty of times that the UI will not be able to display exact amount desired or the exact amount to be sent since people work in decimal. If you used fixed point of the lowest value then it could work, but then you have to define the lowest value to start with. The enum is extensible since one byte with 256 denominations would cover every conceivable decimal (or binary) because there are not enough sub atomic particles in the known universe to represent 1 SNT split into 10^-240 (as a comparison only, not suggesting the particles are associated with SNT)


In this topic denominations are described as protection measure.
Adding “feel” function to it may be a wrong decision.

This happens only when using binary negative powers (part 2 of my earlier post).
When applying decimal scaling to binary numbers (part 1 of my earlier post), any decimal amount (limited by precision) is represented exactly.

Denominations of any scheme needs to be combined at some point.