Discrete amounts: can they work in practice?

[PaulRBerg]

Context

As mentioned here, one of the ideas shared by Eddy Lazarin is to discretize the amounts that can be streamed per cadence.

In this discussion, I will explore this idea more comprehensively.

Open Problems

Decimals

Q: How would this work for assets with different numbers of decimals?

We can enforce 18 decimals in an SRF, but the decimals' value is a higher-level property that the VM cannot read (or take for granted).

We might need to store a dictionary associating NTs and discrete amounts permitted for streaming.

Cadences

Q: to which cadence would the restriction apply?

Per second, per hour, per month? Just per second?

If the former, we might need to have a dictionary within a dictionary - associating NTs to cadences, and then associate each cadence to its own bespoke amounts.

UX

Q: Will the UX be good enough?

Pigeonholing the streaming amounts means that certain users will not be able to achieve their desired payment rate, which is especially problematic for monthly subscriptions.

Suppose we allow only $1, $0.1, $0.01, and $0.001 amounts per second. Scaling up to a day, this means that users can pay only $86.4k, $8.64k, $864, and $86.4 dollars per day. Needless to say this is terrible UX.

Comments

There seem to be so many problems associated with this design that I suggest starting with allowing any streaming amount to begin with (in Genesis), benchmark, and explore this design only if it becomes required.

I am also unsure that these discrete amounts would lead to significant graph optimizations.

RFC @sablier-labs/sabvm

[IaroslavMazur]

Because the negative impact of streaming amount discretization upon the UX would be significant, and in respect of Donald Knuth's idea that "Premature optimization is the root of all evil", I agree that we should get back to this subject in the future, if relevant.