Nicolas Ochem

@ericlavoie do you want to try implementing it? :wink:

Sounds good. You should probably put `frozenDeposit` and `frozenDepositLimit` in the [reward provider model](https://github.com/tezos-reward-distributor-organization/tezos-reward-distributor/blob/master/src/model/reward_provider_model.py) then in payment_producer.py, implement the logic you described and set a variable `overdelegated = True|False` and...

correct. For tzstats it should be there somewhere (but may have wrong values, I am still working with Alex) and for RPC the hard part is to get access to...

it looks like breadcrums implemented this feature and called it "overdelegation guard": https://github.com/kalouo/breadcrumbs/blob/master/config-template.hjson#L35 Breadcrumbs is shaping up to be a great project :eyes:

Thanks, the suggestion to use a mix of mock and real rpc calls makes sense. Also, I'll make sure to skip the pytest tests instead of commenting them out.

:+1: I never understood the benefits of producer/consumer. It's like we are forcing ourselves to do it async processing in what is fundamentally a synchronous path. Step 1: calculate the...

@habanoz can you please provide historical context on this? Why do we have a producer and a consumer?

> redirects and combines all rewards from a tz contract owner and all its derived Kt contracts into one payment going directly to the tz account will that not break...

Yes, although in some cases it's difficult to input some data with CLI arguments (like the table of delegates and where you want their rewards to go).

> I'm not using dry-run mode because currently it requires an access to the signer and this destroys the whole idea of "dry run" as I'm afraid to provide an...