In my writeup, I described it as a balance change triggering the interest payment. That's what I was told. But I can't be 100% sure without reviewing the code.
But it should be easy to test empirically by doing a transfer and checking the results on hiveblocks.com, so I'll leave it as an exercise for the interested reader.
OK, I checked the code (way more accurate than empiric tests), and it is NOT a balance change that triggers the interest but any operation that involves HBD.
Any operation involving assets call function(s) (
database::adjust_balance()which callsdatabase::modify_balance()for liquid, ordatabase::adjust_savings_balance()for savings) which will do the interest payment if required, whether the balances really change or not.Even cancelling a withdrawal from savings can trigger an interest check and potential payment.
So it's better to tell people that any operation involving HBD could trigger interest payment!
Ah, speaks the overly-confident programmer :-) While I agree that code inspection plays an important role in determining in full how code is intended to function, it's my experience that empirical testing is also a vital part of determining actual functionality. And if I have to rely on just one or the other, I'm much more willing to trust empirical tests.
That's overly broad, IMO :-) Consider a hypothetical operation that changes the time period for which funds are staked. Such an operation would have no reason to call adjust_balance(). On the whole, I think that the best description is still that operations that change the balance are the ones that are intended to trigger interest payments. It's really only a current implementation detail that results in calls to this function even when the balance isn't changed (ie. when the delta parameter value passed is 0). And it's easy to imagine a future where the call immediately returns after checking that value, before triggering an interest computation.