# SWAP Assumptions/Issues
## Business logic
- Resolve the problem between a node with accounting enabled and one without.
- [#1548](https://github.com/ethersphere/swarm/issues/1548) The SWAP Smart Contract is deployed every time the node is started.
- A cheque cashing strategy must be implemented.
- The node that receives a cheque request will not check if their own balance is over the payment threshold. Only a _negative_ balance with the node that requests the cheque is necessary.
- As a result, a node with a low payment threshold could eventually spam cheque requests.
- [#1551](https://github.com/ethersphere/swarm/issues/1551) When a balance is reset, it is set to 0. The balance should be adjusted based on the cheque instead.
- The issue of losing cheques must be eventually revisited and discussed, as a security issue.
- [#1549](https://github.com/ethersphere/swarm/issues/1549) Each time a message is accounted for and the balance is over the payment threshold, a cheque will be requested. We need to look into a less spammy implementation for this.
- Peers are straight-up dropped when an error in the accounting function occurs (among other places).
- Pricing logic must be reviewed.
- At some point, custom prices and thresholds should be reviewed.
- While over the disconnect threshold, even messages that would reduce the debt will be dropped, when they would in fact reduce the debt.
- After the disconnect threshold is surpassed, any messages sent from the debitor will be accounted for by the debitor, but unaccounted for and dropped by the creditor.
- The issue of payments interoperability (e.g. different coins) must still be tackled.
- Currently, when a cheque is received, it is submitted but not cashed.
- When a cheque is received, you have to verify the signature so that you know you are able to cash it.
- The cheque cash time out is 0.
- Cheques wei amount is naively treated as msg byte size.
- - Balances after switching config?
## Technical
- [DONE in #1567](https://github.com/ethersphere/swarm/pull/1567) ~~Look into implementing the handshake.~~
- Reimplement the cheque/balance adjustment flow:
- stop resetting the Balance
- move the balance adjustment (or w/e) to the confirm message
- ~~implement a flag to stop cheque spamming~~
- [DONE in #1567](https://github.com/ethersphere/swarm/pull/1567) ~~Remove cheque request message and handler function and update tests accordingly.~~
- Loading states should always use the same kind of peer pointer when loading or saving a balance (or: load by enode).
- The interactions between the `stream` and `swap` protocols must be revised. It's rather confusing and will possibly become difficult to maintain.
- [#1563](https://github.com/ethersphere/swarm/issues/1563) We require additional logs.
- ~~The Proxy object should be deprecated since SWAP implementations are compatible with each other.~~
- ~~Simple SWAP would be a subset of Soft SWAP, and the latter a subset of Swap.~~
- When handling a cheque received message, a general lock is applied on the structure until the message is completely processed.
- A sort of "slowdown attack" is possible through spamming cheque requests as soon as a valid balance is reached.
- The SWAP functions should all have explicit return values, rather than implicit, for better coding style.
- Regarding deployed smart contracts, it seems comparing bytecode is not strictly enough for security purposes.
- Test should be without randomness.
- We must solve the problem of compatibility between different versions of the SWAP smart contracts.
- [#1569](https://github.com/ethersphere/swarm/issues/1569) Old SWAP code must be retired.
- More tests should be added.
- [#1553](https://github.com/ethersphere/swarm/issues/1553) Go code should be renamed to match the SC names.
- SWAP Smart Contract bytecode hard-coding should be documented and preferrably tool-integrated.
- The GetBalances exposed method should be refactored + reorganized.
- We need tests for jsonrpc balances call.