From: Michael Birch
A few quick points from me:
- I think having a separate nep-141 contract will be lower risk than having it in the engine when it comes to correctly implementing the standard and interacting with other fungible tokens. This is because we can start with Near’s standard implementation or the implementation used for other bridged tokens, both of which are known to work properly. The engine’s code was written from scratch due to it needing to be no-std and this introduced many problems at the beginning; problems that will be avoided by starting with known template.
- l agree the data migration must be done with extreme care and this represents the greatest risk of going the separate contract route. An alternative proposal (the preferred option by @marcelo.near | think) which avoids this risk is to only separate the nep-141 logic on a software level to avoid the direct engine interaction that caused the previous security vulnerabilities. However, I am skeptical this approach has enough of the benefits that the complete separation offers. I would be interested in hearing arguments from others in either direction.