Currency conversion workstream

PI 22 implementation

Those of you who were present, either in person or virtually, at the last convening in Kigali will recall that I presented on the current state of the currency conversion (FX) workstream. At that convening, I presented a version of currency conversion which is substantively the same as what we are now proposing to implement. Our current proposal may differ in some points of detail, as might be expected as a consequence of the more detailed analysis and discussion in which we have engaged over the course of this PI.

The commitment that we made at the Kigali convening was to implement an initial version of the FX API, as currently proposed at that time, at the end of this PI. This is still my objective. There were, as I recall, no dissenting voices at that time.

Since this is the case, I'm afraid that I will reluctantly have to exclude from future discussions of the implementation any suggestions which do not have to do with the unworkability of the solution currently proposed, and which are not supported by evidence.

It is almost certain that the design currently proposed is not the best that could possibly exist, and completely certain that it could have been improved over the course of its development by greater participation from the community. However, we now have a design which has been agreed by the community at the PI Community Meeting, and I intend to implement it.

It is entirely possible that those of us who have worked long and hard on this design have nevertheless missed some crucial element which would render the implementation useless. Any comments and criticisms relating to issues of that kind will continue to be welcomed with the open arms that I hope we have shown up to now. However, apart from such critical issues, the design is now closed for any improvements which would delay its implementation.

Pedro asked the question in this morning's meeting: is it not possible to improve this design? My answer is: it's always possible to improve a design, and we will start up a forum in which we can discuss such improvements ad lib. This will, I am confident, result in greatly improved versions of the FX API in the future. As I say, we shall also continue to solicit the most abrasive and robust criticism of the design and implementation from the perspectives of security, reliability and efficiency. But for now, and in the absence of such criticisms, we will work with the design we have.

If you have any comments on any matters raised by this post, please feel free to add them as comments to this document or in the Slack channel. I should say, however, that I do not propose to devote any time at Tuesday's meeting to discussion of the issues raised in this document.