Sparse documentation and accounting complexity  Acknowledged
Throughout the project, inline documentation is either sparse or missing altogether. Furthermore, few technical documents about the system's design rationale are available. The recent releases' increased complexity makes it significantly harder to trace the flow of funds through the system as components change semantics, are split into separate contracts, etc.\\nIt is essential that documentation not only outlines what is being done but also why and what a function's role in the system's “bigger picture” is. Many comments in the code base fail to fulfill this requirement and are thus redundant, e.g.\\n```\\n// Sanity check that refund balance is zero\\nrequire(nodeRefundBalance == 0, "Refund balance not zero");\\n```\\n\\n```\\n// Remove from vacant set\\nrocketMinipoolManager.removeVacantMinipool();\\n```\\n\\n```\\nif (ownerCalling) {\\n    // Finalise the minipool if the owner is calling\\n    \\_finalise();\\n```\\n\\nThe increased complexity and lack of documentation can increase the likelihood of developer error. Furthermore, the time spent maintaining the code and introducing new developers to the code base will drastically increase. This effect can be especially problematic in the system's accounting of funds as the various stages of a Minipool imply different flows of funds and interactions with external dependencies. Documentation should explain the rationale behind specific hardcoded values, such as the magic `8 ether` boundary for withdrawal detection. An example of a lack of documentation and distribution across components is the calculation and influence of `ethMatched` as it plays a role in:\\nthe minipool bond reducer,\\nthe node deposit contract,\\nthe node manager, and\\nthe node staking contract.
As the Rocketpool system grows in complexity, we highly recommend significantly increasing the number of inline comments and general technical documentation and exploring ways to centralize the system's accounting further to provide a clear picture of which funds move where and at what point in time. Where the flow of funds is obscured because multiple components or multi-step processes are involved, we recommend adding extensive inline documentation to give context.
```\\n// Sanity check that refund balance is zero\\nrequire(nodeRefundBalance == 0, "Refund balance not zero");\\n```\\n