What if we remove the 18 decimal format requirement?

[smol-ninja]

Context

Andrei published this excellent bug report today, noting that one of the invariants fails if the decimal of ERC20 tokens is less than 18. This is due to the precision error in division. So, this raised a question for me:

"What if we remove the 18 decimal format requirement?"

Now

Let's say a user wants to deposit 100 USDC.

• The deposit(streamId, amount) function assumes the input amount to have an 18 decimal format. Since USDC has 6 decimals, the user would have to pass $100 \times 10^{18}$ as value. The deposit execution will then internally calculate the transfer amount as to be $100 \times 10^6$ using ERC20.decimal(). But it gets stored as $100 \times 10^{18}$ in the storage.
• Similarly, during refunds and withdrawals, the user enters the amount in 18 decimal format and the functions internally calculate the transfer amount.

Then

If we remove the 18 decimal requirement and treat 1 token as 1 token, then there is no need to convert deposit amounts into 18 decimal format. Lets take the same example again.

The user wants to deposit 100 USDC.

• deposit(streamId, amount) function takes $100 \times 10^6$ as the input value. The struct object stores it as it is.
• Similarly, during withdrawal and refund, the function transfers the requested amount without any decimal conversions.
• For the contract, decimals don't exist anymore.
• Rate-per-second is also in the absolute format i.e. if ratePerSecond = 1000, that means 1000 tokens are streamed every second.

Tests and Risk

I tested removing all normalizations, and storing the token amounts as they are without converting them to 18 decimal format. All values were treated as absolute, ignoring decimals.

The result is that all tests passed, including the previously failing invariant test for decimal values less than 6. This approach doesn't raise precision errors due to rounding and treats all amounts in their absolute form without us making any conversions between different decimals and 18.

All streams belonging to one asset are mutually exclusive from the streams belonging to another asset. So it does not have any cross-over effects.

---

Let me know if I am missing something. But this approach looks better to me than having an 18-decimal format.

So, I would love to know your thoughts on this.

PS: This does not require a big change in the codebase. I have already done it locally for testing and it works.

cc @sablier-labs/engineers.

[andreivladbrg]

Before giving an answer, I want to mention that the reason for introducing the 18-decimal format for internal amounts is detailed in the README.

[smol-ninja]

Thats the answer. Thank you for reminding me.

[PaulRBerg]

So what did you end up doing about this? Keep 18 decimals for internal representation, or nah?

[andreivladbrg]

Yes sir
Any internal amount has 18-decimal format