Enabling multiple cadences (more than just per-second)

[PaulRBerg]

Idea for a future release of Flow - what if we enabled multiple cadences, more than just per-second?

e.g. we could do hourly, daily, and weekly. Monthly would be a little more complicated because of the additional calculations requires to predict the beginning of the next month, but it should be doable in practice (sounds like a good idea for a time utils Solidity library).

WDYT, @sablier-labs/everybody?

Related:

• Cadence for streaming opcodes sabvm#84

[andreivladbrg]

Idea for a future release of Flow - what if we enabled multiple cadences, more than just per-second

Do you have something specific in mind regarding what it would be used for or how it would be useful? My initial reaction is that it would add complexity, and with a rate per second, you can basically achieve any desired period (daily/weekly/monthly) - IMO it’s just a matter of how you present it to the end user in the UI

it should be doable in practice (sounds like a good idea for a time utils Solidity library).

I remember working on something similar couple of months ago: https://gist.github.com/andreivladbrg/43acd687872f55d2e17844093388bfd7

[PaulRBerg]

Subscriptions or users who would prefer less fine-grained payment intervals (for accounting purposes).

It really isn't a matter of frontend. The settlement occurs onchain. From a legal perspective, you may owe taxes on the income earned every second.

[andreivladbrg]

for accounting purposes
From a legal perspective, you may owe taxes on the income

fair, once again, back to the old problem, accounting :))

[smol-ninja]

On the accounting problem, I think it has more to do with withdrawal frequency than rate per second.

We can allow discrete payments by allowing withdrawals only at regular intervals by keeping track of the last withdrawal timestamp. Even though we have this variable called ratePerSecond, it does not stream anything directly between users. It's only an internal variable to track the amount owed between the two parties.

Note: I just realized the amount owed would change too i.e. between two payment intervals, the amount owed should be zero.

[PaulRBerg]

To @smol-ninja:

I think it has more to do with withdrawal frequency than rate per second.

That does appear to be the case, but I would prefer an actual discrete settlement over one that only appears to be discrete on the surface.

Seeing the payment rate per second variable may mislead users into thinking that the settlement is also by the second.

Related: I've argued at length here why it is impossible to know how smart contract balances will be interpreted for tax purposes. If regulators deem claimable balances as taxable, this might incentivize many users to switch to more discrete settlement periods (to lessen the cognitive load on their accountants).

---

To @andreivladbrg:

Regarding the 'added complexity' argument. As I've pointed out elsewhere (can't remember where, but I know I have), we need to balance technical complexity with user engagement. If a feature wins us more users, we should treat the added complexity as a necessary cost.