Reentrancy

There are sections of code that do not follow the checks-interactions-effects design pattern used to prevent reentrancy attacks. There are limited possibilities for execution control to pass outside of safety. Furthermore, it appears that in most cases other system variables (outside of those accounting for balances before and after fund transfer) are used to prevent reentering the contract. However, there is no reason not to use the nonReentrant modifier to prevent any possibility of reentry.

Revest has applied the nonReentrant modifier on all pertinent functions in Resonate, ResonateSmartWallet, and PoolSmartWallet - commit b81a509b41524c896f8bfa75785b554496e16080.