No I made a simple mistake. I was talking of the initial allocation. And I was clear on it being the initial allocation to the foundation.
But you make the mistake of assuming I was conflating. No wonder you misunderstood what i said.
EDIT: removed repeating what i already posted as it still stands
And no, i am not trying be harsh, I am trying to save you from causing invalid accounting and risking real problems when audited.
Well it doesn’t work.
Doesn’t the latest revision I posted above address your concerns?
No you did not address the main point I was saying. Jim got it right in showing the MAID exchange amount as the full ~10.5% without any accounting double dipping.
But you still have a 2 stage exchange process with one up front and the other as a accounting double dipping.
Go back and re-read, you seem to not understand the problem.
Putting the 23 million in the initial allocation to the foundation is double dipping since the dev team has already been paid for that work and the initial allocation to the foundation was never to account for already made payments to the dev team before launch apart from the $100K. That 23 million becomes accounting double dipping.
The WHOLE MAID was always to be exchanged as a single action, and the correct way has been done by Jim in the revised (again) RFC0061.
We seem to be talking past each other here. You are claiming that RFC0061A is written in a way that it is not. There is no 2-stage exchange process described, merely a breakdown of where the tokens come from to perform the single exchange. Also, currently there is no double dipping or fuzzy accounting described for anything with regard to the foundation. The accounting is explicit and more accurately conforms to the constraints imposed by the whitepaper. There is no basis for your assertions if one simply reads what is written carefully.
Nothing in current rev RFC0061A says that it would not be done in a single action. Perhaps there is a need for more explanation in some cases to clarify the language, maybe you can help with that, but in general your assertions don’t add up.
Something else you seem to have neglected to point out or consider is that there are other token allocations that RFC0061A maintains from the whitepaper (which is rather important imo) that RFC0061 fails to do. For example, the RFC0061A upholds the promised allocation ratios of ongoing royalties to core development, general development, and the foundation. RFC0061A also upholds the 5% allocation (minus the overmint error correction and genesis ad hoc needs to keep whitepaper promises) to the core development team.
Even Jim pointed it out. Maybe its yourself that is missing the problem with it because of your lack of knowing accounting practices and financial auditing/invalid practices.
Anyhow, its now moot since this has been incorporated in RFC0061 in the correct way.
No, I don’t think so.
Please explain, because that RFC is still rather vague unless it’s been revised again since my last review.