Thanks for sharing the code. This probably doesn't matter since a 30s cycle is short, but the top-level chain of if-else-ifs look like they should be independent ifs rather than an else-if chain.

As implemented there's a lol-attack here where a malicious actor could spam post every >30s, set the stabilzer_account as beneficiary and upvote their spam posts. After a week, the pseudocode above then gets into a loop claiming rewards instead of later actions (stabilising the price). The counter-measures are simple too: either make the else-if chain into independent ifs, or identify the spam accounts and downvote their posts to zero just before payout.

Also, with an else-if chain the exchange price fetch is wasted resources if a reward claim occurs first.

The else-if chain does introduce a bit more randomness in the timing of market actions, but if this was going to be exploited by a market bot then the amount of randomness is probably not significant enough to matter. IE.. after each stabilizer_account market action, assume there's 30s to get in whatever the other bot wants to do.

If API node traffic is a concern, then using a finer timer and a step counter with each if clause checked on a different step might be a reasonable solution.

Assuming that API calls are not realtime and are synchronous (at least how the code is written) the cycle isn't going to be 30s. But, I'm aware you know that already and probably it isn't a big enough issue to make the code more complex to fix.