Discretion in timing the transition to Stage 2


I’ve just had a chance to do a semi-thorough read of the economics paper. One of the biggest things that stuck out to me was the large amount of discretion that appears to be present in choosing the timing of the transition from Stage 1 to Stage 2.

For reference, page 27 of the paper reads:

Stage 1 will be at least 3 months; with public testing of the Decentralised Exchange and Index Token minting contract to start at least 3 months before Stage 2 can be started. Every three months the team will investigate if the launch process of stage 2 can be started in the next three month window. This is a rolling target, and could take much longer than 3 months after Technical Go Live. We keep a live update on progress on our Roadmap page.

I understand that there is a technological constraint on the transition to Stage 2. However, making this a centralized decision might undermine the network.

I haven’t had the time to think through exact scenarios but here are a few starting points:

  • (Dis)agreement concerning the readiness of the system. Ideally, the transition to stage 2 will occur when all stakeholders agree that the system is technologically ready to make the transition. However, it isn’t clear how easy it will be to form such a consensus. In my experience, deciding that a system is sufficiently tested is an art, not a science. There are always new tests that can be run. If agreement on this front cannot be reached, then stakeholders are going to start to suspect that one of nefarious scenarios discussed below (or others) are taking place. I expect that it will be quite difficult to demonstrate that this is not the case.
  • Insider knowledge. If insiders (i.e. Radix employees) are aware that a certain announcement is going to be made about the transition (e.g. “we will transition in X months”) then they will be able to make adjustments to their holdings of different assets beforehand, which could then be used to earn profits on the secondary market post-announcement. I think that something like this would serve to undermine trust in the system more than anything else.
  • Timing of announcement. Similar to the above, insiders can time the announcement of the transition to benefits themselves.
  • Composition of AMT issuances. The XRI basket will be determined by the amount of reserves of each AMT that are collected in Stage 1. After that, there is some room to readjust the basket under certain TBD conditions but one expects that first-movers will have enjoy some long-lived incumbency advantages due to the fact that - if nothing else - their tokens will be demanded in future periods in order to construct XRI. Dominant AMT issuers could stand to earn a lot of transaction fees (for the fiat-token transaction) in the process. Timing the transition so that a favored AMT issuer has a dominant role in the market could also undermine trust in the system.

Another factor that will likely complicate this transition is that Stage 2 will involve fundamentally different software/rules/protocols. Making a hard fork at that point would be dicey: you can’t just hit the “fork” button and continue on as you were. Decisions would have to be made about what parts of the software to preserve and which parts should be removed. There might also be differences of opinions about how the holdings of any (suspected) offending parties ought to be dealt with. A fragmentation of the network could result.

At the moment, I don’t have a silver-bullet proposal for this issue. Network rules (i.e. "p_{min} \geq 0.45 and # of transactions per week > X") are out of the question because the tech needs to be sorted out. One might consider a form of test-driven development where Stage 2 starts once a certain set of tests are passed (or at the start of the next three month period, say). However, there needs to be some flexibility for adding tests as the need arises. A voting-based system seems attractive initially but I think that this could be undermined by the fact that - in a share-based voting system - insiders would control the voting because they will hold the majority of all initial assets.

To conclude, I reckon that a lot of what is written above will come off as pretty half-baked. However, I thought I’d throw some of these concerns out there in order to try to get a conversation going.


Some excellent comments here. I agree, a more public testing process where there is more community/stakeholder engagement on when the network is “ready” is a very good idea.

Regarding insider knowledge, the team members do not hold tokens, the tokens are held by Radix DLT Ltd rather than individuals, and we would certainly want to avoid anything that came close to insider trading. It isn’t acceptable in the public markets, it should not be acceptable here.

Regarding the composition of AMT - you are absolutely right. That is one of the reasons we want to encourage as many people to become AMTs as possible and it will be a key success factor in the run-up to launch.

I think that as part of the gap between stage 1 and stage 2, there might need to be some community/stakeholder engagement on who stays in as an AMT for the XRI, but it is still very much early thinking - I think that there is still a lot of work to do around the XRI basket and its governance.

Lastly - the “forking” problem is going to be our first major governance hurdle, and you are quite right to flag it. Now that we have laid out the basics of what makes the Economics works, we now need to start constructing how that is implemented as not just a technical process, but a social one as well!


Piers, Thanks for the detailed reply! I don’t have the time to write my own at just this minute (just getting into work). However, I will say right now that I think that the Economics Model will live and die by the governance structure.

I haven’t seen anything in the Roadmap for the development of the governance, though. Should we be expecting another paper or the formation of a governance steering committee or what?


Yea, Governance Paper will be released before Technical Go-Live