Radix - Tempo Whitepaper

Discussion in 'General' started by Fuserleer, Sep 25, 2017.

  1. Fuserleer

    Fuserleer Radix Founder Staff Member

    After 5 long years of hard work, sweat and many many tears, the whitepaper explaining Tempo, our ledger and consensus tech was published today!

    You can get it at our website https://radix.global

    It details how our ledger architecture allows scaling, fast settlement and offers a true micro-payment and IoT solution, along with the consensus algorithm which we developed to secure it.

    This paper is the first of a set that will explain all of the Radix core features such as economics, DEX, payment rails and more.

    I'll keep this short and let the paper do the talking.

    As always, comments, thoughts and feedback welcome.
  2. lou

    lou Beta Testers

    Thanks Dan! An interesting read. :)

    At first glance, my suspicions from an earlier thread seem to be confirmed (but I'll have to read more closely when I find more time).

    > This resolves a large percentage of concurrent events providing that the node is full node and is not storing only information regarding its own events.

    This is kind of cheating - you start out by explaining that Tempo scales through sharding, then require full nodes for verification.
    The Commitments also destroy the advantages of sharding, because effectively every node has to keep track of every other node's commitments.

    I'm missing explanations on how a new node enters the network (obviously it cannot know the state of the shards it supports right from the start, it must be bootstrapped somehow), and how the network ensures that all possible shards are handled by a sufficient number of nodes at all times.
  3. Fuserleer

    Fuserleer Radix Founder Staff Member

    I did wonder when you would show up :p

    Bear in mind that the paper is not meant to provide a full detailed description of an implementation...its the working theory and assumes that the reader will fill in those gaps.

    If its good enough for Satoshi then it's good enough for us.

    Ok, "full" is a bad choice of word maybe...let me define:

    Full = A node that is participating in Temporal Proofs and maintaining one or more shards
    Not-Full = Light client, cares only about its own events

    You're looking at Commitments with the wrong glasses.

    The commitment itself is tiny, its just a Merkle Hash, so the overhead of having them in the Temporal Proofs (TP) is also tiny. Those commitments will only live in the shards for which the Atom was intended, so only nodes maintaining those shards receive them.

    If we have 3 shards in the network, and an Atom destined for Shard(1 & 2), nodes maintaining Shard(3) don't care, nor need to care about that commitment.

    Recall also that the commitments are a delta between what the node has seen since the last time it submitted one in a TP, this is important! Therefore the commitments won't contain many leaves, even if the load of the network is high across all shards because the load will be spread between more nodes.

    Finally commitments are only required when there is a conflict or discrepancy, most of the time the vector clocks themselves should be sufficient for most "natural" occurrences of these due to latency.

    So, those points made, allow me to explain with a simple example:
    • Node(B) receives an Atom(x) and a TP with a commitment from Node(A) containing Atom(x), the Atom is good, Node(B) accepts it
    • Node(B) then receives an Atom(y1) that conflicts with Atom(x)
    • Node(B) looks through the TP of Atom(x) and sees that its connected to Node(A) and asks for the merkle leaves so that it can verify the commitment
    • Node(A) responds accordingly and Atom(y1) is discarded by Node(B)
    ...some time later...
    • Node(B) is then part of a TP for Atom(z), it produces a commitment including Atom(x) and Atom(z)
    • Node(C) receives Atom(z) and the TP from Node(B) validates and accepts it, no conflict
    • Node(C) then receives Atom(y2), which also conflicts with Atom(x)
    • Node(C) looks through the TP of Atom(x) but is not connected to Node(A)
    • Node(C) instead contacts Node(B) asking if it has any information about Atom(x)
    • Node(B) responds with the commitment from Atom(z) and the merkle leaves so that Node(A) can verify
    • Node(C) discards Atom(y2)
    ...some time later still...
    • Node(B) is part of a TP for Atom(n), it produces a commitment including only Atom(n) as Atom(x) and Atom(z) are already in a previous
    Node(B) had no state information whatsoever for Node(A) in the second conflict, nor did it need to have. It only needed to know about its own state information in order to prove to Node(C) that Atom(x) was seen first using commitments.

    That is briefly covered, obviously if a node has no information at all about the shards it is in, then it can not fully participate in TPs until it does. They can then do a "best effort" sync on those shards as mentioned in the paper relying on eventual consistency to resolve an missing information as new Atoms trigger discrepancies in its knowledge.

    Again thats implementation specific, so isn't covered in the paper. However, it should be quite obvious that it is easy to estimate a fairly accurate metric in a number of ways.

    The simplest being, if a node is maintaining 1/10th of all shards, then it is able to see how many unique nodes have participated in all the TPs across that 1/10th of the shard space over a particular period of time. Simply x10 that number and you have an estimation of how many nodes have participated in the entire network over that same time period.

    If a particular set of nodes are very frequent in the TPs for a particular shard, that shard is maybe under served. Remember, you can see this even if you don't have the shard, as transactions will generally have 2 destinations, thus 2 shards, and nodes from both shards will be present in the TP.

    Then it is simply a case of tuning the period depending on the application requirements to derive a suitable parameter.
    Last edited: Sep 25, 2017
    man_44, Collett, jonas452 and 5 others like this.
  4. lou

    lou Beta Testers

    Thanks for the clarifications.

    Ok, so I suppose when you speak about "network wide broadcasts" you mean "network wide" in the sense of "to all nodes interested in the relevant shards".

    Ok, misunderstood that.

    Yup, found it.

    What if Alice wants to send something to Bob, but there are no nodes reachable who handle Bob's shard? Is that detectable at all? Will Bob notice? Will Alice notice? Will 3rd parties (other nodes) notice? Does someone care, and add Bob's shard?

    For example, using figure 3 from the paper, Alice constructs an atom for shards (1,4) and submits it to node N1, which eventually returns a TP from nodes (N1, N2, N6, N11). Does that confirm the transaction, despite the fact that none of the nodes supports shard 4?

    But that's only about completeness and irrelevant for an attacker. Unfortunately I can't find the thread with my earlier attack scenario, but I still think it is applicable to this WP.

    The real problem, IMO, is that when Bob receives a transaction, he can never be sure that no conflicting transaction exists that will later turn out to have occurred earlier than the one he is interested in.

    * Suppose Eve controls 2*3*log(N) nodes (or however many she needs for constructing two independent TPs). All of these have shards 1 (Eve's shard), 2 (Bob's shard), 3 (Carol's shard) and some other random shards as well.
    * Eve constructs a TP1 for the transfer of Atom(x) to her friend Carol using half of her nodes, but she keeps TP1 to herself.
    * The nodes used in TP1 continue to participate in other transactions, creating TPs and Committments as usual. Note that they will never have to disclose TP1, because other nodes don't have a reason to ask. Even if someone asks for TP1, perhaps in the cause of verifying a Committment, they can simulte a network outage and leave the question unanswered.
    * Later, Eve buys a Ferrari from Bob, paying him with Atom(x). She confirms the payment with TP2, which she creates using the other half of her nodes.
    * After Bob has handed over the keys, she publishes TP1 to the network.
    * The network detects the conflict and tries to resolve it by comparing TP1 and TP2.
    * TP1 and TP2 are independent ("concurrent") and cannot be compared directly. So the network resolves to constructing Vector Clocks.
    * Because the nodes used to create TP1 have continued to handle transactions as usual, the network can verify that TP1 is older than TP2.
    * This means that Atom(x) now rightfully belongs to Carol, who immediately returns it to Eve because she values their friendship.

    I may have missed a detail somewhere, but the underlying problem is that due to the lack of global state it is impossible to prove at any given time that a conflict does not exist, and that a given transaction is therefore valid. Even if Bob waits for two weeks before handing over the keys, it doesn't help him, simply because Atom(x) really was transferred to Carol before Bob received it - only Bob didn't know about that.
    Last edited: Sep 26, 2017
    janheski likes this.
  5. Fuserleer

    Fuserleer Radix Founder Staff Member

    Yes exactly

    At the risk of diving into implementation specific stuff again a bit here, which I left out of the paper so that anyone that wants to try and build on has to figure this stuff out for themselves. I guess a few bits won't hurt too much...

    There are 2 questions here really:

    1) How do you ensure that the network is "balanced" and that there are sufficient shards in the network?

    DHT tables can provide that information, the key is the shard and the value is a set of nodes serving it. Nodes broadcast to peers what shards they wish to receive, so the set data in the DHT can be built from that. Nodes can of course lie about what shards they are serving, but it won't become a problem unless all nodes claiming to serve particular shards are lying (even then you can do some verification over a period of time by looking at the TPs).

    2) What happens if NO nodes are serving Bob's shard?

    While unlikely, at first glance this might seem like a total disaster. All nodes containing Bob's shard are gone, thus so are Bob's transactions! Not so...

    Remember, Atoms are routed to the end-point destinations, transactions having at least two. So if Alice was in Shard(1) and Bob Shard(2), the transaction that Alice made will also be in Shard(1). The Atom isn't lost, Bob just can't retrieve it right now, and neither can anyone from Shard(2) access their Atoms.

    Assume this goes on for some time before a node realises that Shard(2) is not being served at all by anyone, that node can reconfigure to also serve Shard(2) (as may some others). Knowing that there are no nodes serving Shard(2), the node can simply contact other nodes, request that they send any Atoms that touch Shard(2) and rebuild it from the Atoms delivered to it that reference Shard(2).

    Hmmm...some parts of your example seem to conflict with the WP content...I'll read between the lines a little...

    * Eve constructs a TP1 for the transfer of Atom(x) to her friend Carol using half of her nodes, but she keeps TP1 to herself.

    A few issues here spring to mind right away. If she keeps TP1 to herself, then the Atom will not validate when it gets to Carol. That problem aside, how can Alice be sure that Carol will not broadcast the Atom, or any nodes that it happens to pass through will not broadcast it either? What if Carol is also taking part in TPs, she will include in her TP Atom(x) and broadcast that? What if Carol attempts to spend it in the meantime?

    It's not as simple as just Alice keeping the TP, if she does that, the Atom is useless and Carol can't receive the funds.

    * The nodes used in TP1 continue to participate in other transactions, creating TPs and Committments as usual. Note that they will never have to disclose TP1, because other nodes don't have a reason to ask. Even if someone asks for TP1, perhaps in the cause of verifying a Committment, they can simulte a network outage and leave the question unanswered.

    Alice's nodes will have to verify their commitment when asked by another node. From the WP:

    It's quite trivial for a node to verify it's commitments, it simply sends the hashes within the commitments to the requesting node, "any time" in our implementation is on connection and at random intervals post connection.

    If Alice' nodes don't complete that test, anything that Alice's nodes send to another node will simply be ignored until verified. Alice's nodes also wont be selected to participate in any main-net TPs either, therefore she cant present new commitments for the later double-spend without leaking about Atom(x).

    I'm gonna stop there as I'm not convinced that Alice would be able to double-spend Atom(x) considering the above points I mention.

    Will wait for additional information.
    Collett likes this.
  6. lou

    lou Beta Testers

    Thanks again.

    Remember that Alice controls all nodes involved in TP1 and can therefore ensure that nobody else notices TP1. Alice is sure that Carol will not try to spend it (because Carol is really just Alice's sock puppet, but don't tell anyone). Carol doesn't actually care about TP1 at this point - all that matters is that TP1 *exists* and is a *valid* Temporal Proof.

    Generally, please assume that an attacker will try to control as much of the process as possible. Controlling an arbitrary number of accounts is trivial, controlling a reasonable amount of nodes is trivial given sufficient resources, as is controlling the network traffic of those.

    AFAICS the commitments only contain *hashes* of events, and therefore no information about an event itself. In your previous response you stated that "commitments are only required when there is a conflict or discrepancy" (which is not the case before both TP1 and TP2 have been published), this seems to contradict that nodes verify the other nodes' commitments upon connection.

    Also note that the nodes involved in TP1 don't *have* to participate in any subsequent transactions concerning shards 1 or 3. It is sufficient to participate in other shards, which will serve to increase their local clocks and have them verified by others. The later double-spend will be confirmed using Alice's other nodes, so even if the nodes involved in TP1 were locked out completely (but on what grounds?) this would not keep Alice from constructing TP2.
  7. Fuserleer

    Fuserleer Radix Founder Staff Member

    Heh I was grossly overtired yesterday when I put that response back, of course Carol could be Alice's sock puppet.

    I'm going to blame that and 5AM for my misunderstanding of your example!

    The paper does state that nodes will be required to verify their commitments at *any* time. Again, I didn't go into the implementation specifics of when WE do it as its not required to for an understanding.

    However, now I think of it, it would be trivial to extend the requirements so that nodes presenting a commitment also have to include a set of hashes relating to the processed Atom and it's Consumables. As Atoms will only contain a few consumables, it will be a minimal overhead and could even be bloomed. Commitments are then specific about the Atom and Consumables which that node was part of the TP process for. Hmmm.....

    Regardless, lets continue :)


    I'm going to call Carol's Atom(x) and Bob's Atom(x') you called them both and it makes my response a bit confusing.

    For Eve to dupe Bob into handing him the keys for the Ferrari, she has got to produce an Atom(x') with TP2 for Bob along with a commitment.

    Eve has to broadcast that Atom, TP2 and commitment to the network because without it, the main-net will not validate it and Bob will not accept it.

    Eve also can't prevent any node in the network from broadcasting that to anyone else while that Atom is on its way to Bob, so assume that Atom(x') and its associated info is stored in many places, and new commitments from nodes not controlled by Eve are being created that contain it.

    In your example, Eve has created two TPs, which to be a viable proof (either now for Bob or later for Carol) must have associated commitment information for them.


    This takes us back to the verification, whereby Eve can not disclose TP1 in case she is requested to verify it.

    I suspect the fact that commitments form a sequence is being overlooked. Eve cant interact at all with her nodes that created TP1 and hide the fact that they have it. If they participate at all, they will have to submit commitments.

    Assume they are participating and the last commitment in the network for Eve before she created Atom(x) was Commitment(n). When she creates Atom(x) she prepares Commitment(n+1) which references Commitment(n).

    Eve participates and submits a commitment. She can not submit Commitment(n+2) as she would have to reference Commitment(n+1). She will be asked to verify Commitment(n+2) at some point and can't risk exposing Commitment(n+1),

    Commitment(n+2) then can only reference Commitment(n).

    Later when Eve attempts to present Atom(x), the commitment that includes it will have to also reference Commitment(n). Eve then has two commitments known that reference Commitment(n), which is illegal, discoverable and the scam is up. Atom(x') for Bob would win.


    The only way for Eve ensure the integrity of her commitments and that none of them expose Commitment(n+1) with Atom(x) is to not participate at all.

    She can not be sure that a node she participates with on Shard(4), does not have a connection to another node which is maintaining Shard(4 & 1).

    For example, Eve participates with a node directly after creating Atom(x) that has Shard(4) and creates Commitment(n+1). She can not be sure that the node with Shard(4) is not connected to another node that has Shard(4 & 1). That node will receive a gossip about the Atom for Shard(4) which just happens to contain a Commitment(n+1) from Eve's nodes.

    Later when she presents TP1 and the Commitment(n+1), the node she didn't know about will receive Atom(x), TP1, and the duplicate Commitment(n+1), inform Shard(1) nodes about the duplication and the game is up.


    Which then leads to the deal breaker.

    If Eve can not participate, then the last known activity of Eve will be Commitment(n), which was submitted before Atom(x) was created.

    Eve's TP1 nodes are not seen at all by the network until after Atom(x') is accepted, and they present a conflicting Atom(x) and Commitment(n+1).

    The lack of presence of Eve's nodes, and the fact that they present a conflict immediately upon rejoining is questionable at best and is actionable in a number of ways.

    We were able to come to that suspicious conclusion without performing any vector clock comparisons, or contacting other nodes at this point.

    The nodes Eve is trying to convince have no real reason whatsoever to accept the fabricated commitment and Atom. As far as they are concerned, Atom(x') was seen first, and all nodes they contact that claim that it was have been active both before and after Atom(x) and Atom(x').
    Last edited: Sep 27, 2017
    Lloyd likes this.
  8. lou

    lou Beta Testers

    I assumed as much. :)

    This is not enforcable. A node can simulate network problems when asked about a specific commitment. Asking nodes about the specifics of each commitment kills performance and destroys the benefits of sharding.

    Yes, exactly.

    No, the fact that commitments form a sequence is crucial for the (later) proof that TP1 existed before TP2. Eve's nodes continue to interact with other nodes, because Eve doesn't care if the *hash* of TP1 or Atom(x) is known to the network. From that hash alone, the network cannot detect the conflict between TP1 and TP2.

    The continuing interaction of Eve's nodes with others will harden that proof, because these other nodes indirectly confirm the existence of Eve's commitments.

    Eve never produces duplicate commitments. All of her nodes act in a perfectly normal way, the only exception being that they refuse to disclose TP1/Atom(x) when asked about the details of Commitment(n+1). Which, as I stated above, is indistinguishable from networking problems and can therefore not be punished.

    (Reading the paper again it seems that verification of a commitment only requires the node to produce atom hashes, not the atoms themselves. That means that Commitment(n+1) can be verified successfully, because Eve can disclose Hash(Atom(x)) without endangering her attack.)
  9. Fuserleer

    Fuserleer Radix Founder Staff Member

    That really makes me suspicious that something in the white paper isn't clear.

    The whole point of commitments is to allow nodes to declare what they have seen in a compact form, relying on the fact that gossip protocols are proven to be reliable and distribute information quickly, allowing a node to prove to anyone that needs to know what it saw.

    Commitments also prevent the kind of attack you describe, as to prove that Atom(x) was first there needs to be a commitment in the network. But there can't be one if it's been withheld to attempt a double spend, there are just too many detectable red flags as I've already explained.

    I'm travelling today so I'll have plenty of time on the flight to read through the paper and make things clearer if needed.
  10. lou

    lou Beta Testers

    Gossip protocols are efficient for transporting information that *wants* to be published. But Eve withholds the crucial piece of information, i. e. Atom(x), and gossip cannot force her to disclose it.

    Eve does not withhold the commitment proving the existence of Atom(x), but the commitment itself and Hash(Atom(x)) cannot be used to deduce the conflict between Atom(x) and Atom(x'). The commitment is only useful in proving that Atom(x) existed before Atom(x'), after Atom(x) has been revealed.
  11. lou

    lou Beta Testers

    Please clarify:

    1. Which of these items are Atoms in the sense of the WP:

    * Temporal Proof
    * Commitment
    * Node configuration broadcast

    2. If any of these are Atoms, then a node receiving such an item will increase its local clock and later publish a commitment for it, right?

    3. If any of these are Atoms, what is their Destination?

    4. A commitment covers *all* events seen by a node, not only those in a specific shard, right? I. e. all of a node's neighbours receive the same commitments, independent from the shards they support?

    5. When a node receives a set of Atom hashes as the result of a commitment verification, these hashes are not included in the set of events seen by that node, right?

    6. When a commitment is embedded in a TP, can the same commitment also be published separately, i. e. without the enclosing TP, as if it was a normal periodic commitment?
  12. Lloyd

    Lloyd Founders Staff Member

    On page 2 of the WP you will see this paragraph.

    "Clients may create and submit Atoms to the network via any node it is connected to. A submitted Atom is then processed by the network and, if valid, a Temporal Proof(TP) is constructed for, and associated with, that Atom from that point forward."

    Each successive Node that verifies and Atom receives the original Atom and the TP from the prior TP node processor. So the original Atom gets propagated through the network via the TP provisioning.

    There are two types of Atoms, Payload and Transfer. Therefore a TP, Commitment, and Node configuration broadcast are not an Atom.

    Also, on page 10 in the Commitment section, you will see that Commitments are also included in the Temporal Proof processing. So if I create and Atom, I must submit it to a Node that I am connected to for verification and if valid that node will generate a Temporal Proof, which also includes a Commitment as part of the (l e o n c) Coordinate.

    The TP process for an Atom includes multiple iterations of the TP process with other nodes that are doing TP processing and have at least one of the shard(s) referenced in the Atom being verified.
    Last edited: Sep 29, 2017
  13. lou

    lou Beta Testers

    Thanks Lloyd. To avoid confusion I'll wait for Dan's update before continuing the discussion.

    Some more questions have come to my mind:

    7. What happens when a TP fails to complete? I. e. node N receives an atom and starts creating a TP by signing an extended space-time coordinate (l,e,o,n,c), then sends this on to node P. Then, one of these happens
    a) node P crashes before it can add its own space-time coordinate
    b) node P detects a conflict and refuses to complete the TP
    Node N is left with a partial TP, what does it do now? What happens to the commitment c embedded in the partial TP?

    8. What happens if two different TPs for the same atom appear in the network?
    a) TP was generated by nodes (A,B,C) and TP' was generated by nodes (D,E,F)?
    b) TP was generated by nodes (A,B,C) and TP' was generated by nodes (A,D,E)?

    9. What happens if a node leaves the network? (It is then no longer possible to verify its commitments, but the TPs it has signed remain valid.)
  14. lou

    lou Beta Testers

    After some more thinking, I'm relatively sure that the resolution algorithms presented in the WP are not even sufficient to guarantee eventual consistency.

    For eventual consistency, the network must be able to unambiguously resolve any conflict that might appear. The whitepaper relies on TPs and commitments to determine a total order of events. In both cases, the general idea is that given some conflicting atoms x and x', we try to find y where we can prove that x existed before y and y existed before x' (or vice versa of course).

    However, there is nothing that guarantees that such an y exists. Furthermore, even if there is an y such that x < y < x', it is possible that at the same time an y' exists with x > y' > x'. This means that some conflicts are not resolvable at all, and some conflicts cannot be resolved unambiguously. What's even worse is that nodes may not be aware of the ambiguity, i. e. some nodes would resolve the conflict in one way while others would resolve it in the opposite way. The result would be a forked network, where one prong will no longer accept transactions that are valid in the other.

    When in a large network x and x' are presented to nodes that are some distance apart, then there is a high likelyhood that the nodes involved in the respective TPs will not detect the conflict before the TP has been completed. In other words, two concurrent TPs are created. Suppose we have TP_x created by nodes (A,B,C) and TP_x' created by nodes (D,E,F).

    Suppose that right after x and x', y and y' enter the network at nodes A and D, and that TP_y is created by nodes (A,G,F) while TP_y' is created by nodes (D,H,C). It is possible that node F completes TP_y before it completes TP_x', and at the same time node C completes TP_y' before it completes TP_x. We now have the situation described above, i. e. TP_y "proves" that x existed before x' and TP_y' "proves" that x' existed before x.

    The same situation can happen with commitments instead of TPs.
  15. Fuserleer

    Fuserleer Radix Founder Staff Member

    Just checking in here with a quick update.

    I discovered a few minor issues within the current paper that could lead to some confusion, especially regarding the contents of a commitment. An oversight on my part when attempting to radically simplify the explanations of the various components and processes to allow a broader audience to understand it.

    Initially I wanted to release a modified version with that language clarified asap, however, I've decided to extend the paper with another section which discusses faulty and dishonest nodes using Lou's examples as the material.

    This will obviously provide answers to Lou how these critical disputes are resolved, but also those that may have similar queries that do not visit this thread. I figured it would be better to put it all in the paper instead.

    Unfortunately as I'm away from home at the moment, I've had little time to sit in front of the laptop and modify the paper. Tonight is the first time I've been able to do so for a significant period of time since Thursday.

    I expect to be able to publish the revised paper with these examples sometime tomorrow.

    Sorry for the delay.
  16. jiayaoqi

    jiayaoqi New Member

    Hi, thanks for your sharing of the whitepaper. I have two basic questions.
    1) Shard availability. Based on some research results, many nodes will be offline in P2P network after a period of time. If all the nodes holding a shard are offline at one time, what's the consequence for that? Will your protocol still work and process the corresponding transactions correctly?
    2) Resilience against byzantine nodes. What's the tolerance fraction against byzantine nodes for your protocol? Is it 50% like bitcoin or 33% like PBFT or else?
    3) Malicious chain of Temporal Proof provisioning. For Temporal Proof provisioning in Fig 5, what will happen when all the nodes on the chain are malicious? Can they collude to provide a fake proof to perform double spending? Actually, if the first node is malicious, it's quite easy for it to choose another malicious successor, and its successor can do the same thing. Gradually, they can build such a malicious chain to affect your protocol.
  17. pastet89

    pastet89 New Member

    I appologize if this question is off-topic here, but wanted to confirm I got the main economical idea behind Radix correctly.

    In brief: the system is made that so it doesn't allow price violation. When the price starts to go up, the supply is increased.
    A rough example:

    There are 1 billion radix in circulation. I have 1,000 in my wallet. Each radix is worth 1 USD. So I have 1,000 USD worth radix coins.
    The demand starts to go up twice, and so should the price. In that moment, the system generates as twice as the current amont of coins in any wallet in the network.
    So at the end:
    1) The price for a single coin remains 1 USD.
    2) I get out of the blue 2,000 instead of 1,000 radix coins in my wallet. So my wealth is estimated now 2,000 USD.

    Is this correct?

  18. lou

    lou Beta Testers

    There are various threads in this forum discussing the economics. Your questions are off-topic in this one.
    Anima likes this.
  19. lou

    lou Beta Testers

    "Tomorrow" was like two weeks ago... what's the status?
  20. Fuserleer

    Fuserleer Radix Founder Staff Member

    Status is "I'm working on it!"

    Since publishing the paper, had a lot of feedback, meetings requests and such.

    Also trying to stay on track with development, hiring team members and a place to put them.

    Simply not enough hours in the day at the moment, and paper writing is time consuming :(
    rafaestefania likes this.

Share This Page