Replies: 1 comment 5 replies
-
I can imagine how this could become problematic, both for the background processess happening in SabVM to maintain the graph network - and the SabVM users who will now have to say good-bye to a lump sum every 1st of a month, not being able to spread the total amount they're streaming to others across the whole month. Maybe, allow monthly value transfers on any dates between the 1st and the 28th, for any month? |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand your contention. By allowing only the 1st date of each month, we simplify the graph. There are fewer assumptions to make. WDYM by "not being able to spread"? Allowing only 1-28 dates is doable but more complicated than just allowing 1 date. The goal here is to to prioritize go-to-market. |
Beta Was this translation helpful? Give feedback.
-
I do agree with the latter, but not the former. The graph will be, pretty much, the same structurally/visually (at the level of relations between accounts), no matter if the monthly Streams/Subs all converge at a single date each month - or not. Additionally, what I was thinking about is that concentrating the dates of the effective monthly value transfer into a single day each month, we would risk creating a room for DoS by introducing a single point of failure via the increased graph re-assessment activity happening en masse right before/during the respective date. With the potential cascading effects throughout the graph, wouldn't we be shooting ourselves in the back with this?
If we force the monthly cadences to be, say, on the 1st of each month, the users will need to make sure they have enough money for all of their outgoing Streams/Subs at that date. For an average person, it'd be easier, imo, to have to pay a part of his subs on the 1st, another part - on the 10th - and so on. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent observation regarding the concentration of dates - it prompted me to open a separate discussion: #90. This point alone settles the matter. We should not allow on the 1st date of the month because a diversity of billing dates lowers UCG and DoS risk.
Yes, but graph traversals could be made more efficient if billing dates are affixed to the 1st of each month.
nitpick: the idiom is "shoot oneself in the foot".
Oh, I see. I get it now. I think this is a reasonable assumption, i.e. most users would prefer it for all subscriptions to start at the same time (for easier accounting), but I agree that not all users may have this preference. |
Beta Was this translation helpful? Give feedback.
-
"could have been made" 😜 Jokes aside, I think I get what you're saying: knowing for a fact that all of the monthly subscriptions end on a certain date, we could simplify the calculations involved in the process of parsing & re-evaluating the graph, by making them specific, instead of generic. Similar to how ASICs are more efficient. At just one thing, but still 😄
There's a saying in Russian that goes smth like this: "everyone talks about what's hurting them (most)". I must've used the "back" in this very spirit 🤣
I can definitely see the benefits for the (more organized) people to have all of their bills due at the same date each month. Personally, I'd prefer to have it like this, as well 🙌 The good piece of news is that if we don't restrict the date of the monthly payments, such users will still be able to organize their finances like this. |
Beta Was this translation helpful? Give feedback.
-
|
OK to everything LOL about the Russian proverb |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
As explained here, we won't support monthly streaming cadences in Genesis. However, the world at large relies on monthly cadences for all sorts of things, so we should strive to implement this feature in Odyssey.
Implementing monthly cadences isn't as easy as by-the-second cadences because months have different lengths and there's a leap year once every 4 years.
I see two possible implementation designs:
I favor the first design due to its simpler implementation and its ability to meet a wide range of user needs.As per the debate with @IaroslavMazur debate below, I now favor the second design.
Related:
Cc @sablier-labs/sabvm and @sablier-labs/frontend because I think we already have an algorithm for pre-computing the dates for the Monthly Unlock shape in the Lockup UI.
Beta Was this translation helpful? Give feedback.
All reactions