Ralph Pichler

I think it might make sense to store (in swap or the cashout processor) extra information for every peer: * the last cumulativeAmount that was scheduled to be cashed (and...

> The exact mechanics on how/when and if a cheque is cashed out is not relevant for SWAP, unless 1) a cheque bounces or 2) when cashing out is really...

This sounds much more complex than the current plan. Also I don't think that the SWAP codebase would become much simpler. Instead of the transaction logic we would have a...

With the current go bindings this is only possible using `eth_Subscribe` over websockets, but RSK does not implement that yet.

This logic could lead to potential problems if multiple cheques for different beneficiaries are cashed at the same time. A better approach would be to check for the relevant event.

In #1683 we now verify wether the cashing worked. But we don't do anything with error yet.

For this to be complete there 2 things needed: * make sure that we monitor the cashout transactions (depends on #2005) * blacklist the peer if bounced (depends on #2025...

Slightly modified from the discussion [here](https://github.com/ethersphere/swarm/pull/1892#discussion_r336728972) we want to use this formula for determining the available balance for a peer: `s.contract.liquidBalanceFor(peer) - (SUM(forall peers p, p.getLastCheque*().CumulativeAmount) - s.contract.totalPaidOut())`. * The...