Tracking the token supply of Native Tokens

[PaulRBerg]

Context

As discussed here, we have a dilemma¹ regarding how to keep track of the total supply of Native Tokens:

1. Do it in the VM itself
2. Let the token contracts handle it (see SBRC-20)

Cost/Benefit Analysis

There isn't any huge difference between the two approaches. The trade-offs are subtle.

VM Approach

• Slightly lower gas consumption because the values are stored in native VM state
• More difficult to implement
• More difficult to ZK prove
• Ability to prune "burned down" NTs from the database, which may give us a better grip on state size.

Contract Approach

• Slightly higher gas consumption because the values are stored in contract storage
• Easier to implement because the standard contract storage deals with the token supply.
• Easier to ZK prove (since the VM would have one less property).

RFC

In the spirit of quick iteration, I suggest going with the contract approach because it takes less time to implement. As development progresses, we can revisit this proposal and switch to the VM approach should state size prove problematic.

However, it is worth noting that once we commit to a certain approach in production, we will be married to it for life.

cc @sablier-labs/sabvm

Footnotes

1. There's a third option, which is to treat the total supply as a non-essential metadata meant to be indexed by subgraphs, but this would lead to such a terrible developer experience that I didn't even include it. ↩

[IaroslavMazur]

One thing to take into consideration here is that if we delegate the Token Supply tracking to the smart contracts, we cannot guarantee/assume that they will, actually, do this correctly (nor at all, for that matter).

At this point, the requirements we have for a NT creator is for them to be 1) a contract 2) whitelisted by Sablier. Given that we don't require the contracts to implement any specific interface (containing, among others, the totalSupply() function), we can't expect all of them to contain the logic for Total Supply of their token.

---

Also, as you have correctly suggested in the OP, if we delegate the Total Supply logic to the smart contracts, we also put aside the possibility to stop supporting the NT (i.e. remove it from our database) when it's "burned down".

Even if the smart contracts implements the Total Supply logic correctly, this logic would exist on a different (higher) level of abstraction, and accessing it from the lower abstraction level of the VM, when processing the execution of the BURN opcode, would be an architectural mistake.

---

Having said the above, should we implement the Total Supply of NTs at the VM level?

[PaulRBerg]

Related: #113

[IaroslavMazur]

That problem would still apply only to ETH even on our chain because ETH will be the only token that won't have a smart contract associated with it.

To ETH and any other NT the associated contract of which hasn't (properly) implemented the Total Supply logic.

---

I believe that in order to have the full context for deciding whether we can afford delegating the Total Supply functionality to the smart contracts, we should, first, come up with a list of situations where having the Total Supply information would be useful/important to us.

The benefits of this that come to my mind are the following:

1. simplifying the construction of statistics about our rollup (e.g. services such as Zapper or DefiLlama wouldn't have to manually add up the NT balances of all of the SabVM users to calculate the correct TVL of the chain);
2. the ability to completely remove the NT from the background database if it's being "burned down" (although it's still an open question whether we want to do things this way);
3. What else?

[PaulRBerg]

To ETH and any other NT the associated contract of which hasn't (properly) implemented the Total Supply logic.

1. The vast majority would implement the Total Supply logic properly because they would use SRF-20
2. Again, this is like saying that there can exist tokens that don't implement ERC-20 properly. They do exist, but nobody cares about them. It's the same logic here.

services such as Zapper or DefiLlama wouldn't have to manually add up the NT balances

I don't follow this logic through. If the total supply is provided by the SRF-20 contract, these services wouldn't have to do this anyway.

the ability to completely remove the NT from the background database if it's being "burned down"

Yes, this is the only major benefit of tracking Total Supply at the VM level. I have already countered this point in the OP and in my previous comments in this thread.

[IaroslavMazur]

I don't follow this logic through. If the total supply is provided by the SRF-20 contract, these services wouldn't have to do this anyway.

Right, IF it's provided.

I was referring to the NTs that wouldn't properly implement the total supply/SRF-20 interface.

---

The vast majority would implement the Total Supply logic properly because they would use SRF-20

Yes, all of the NTs we should care about, at least.

---

this is like saying that there can exist tokens that don't implement ERC-20 properly. They do exist, but nobody cares about them. It's the same logic here.

Given the different levels that ERC-20 (application) and NTs (VM) are situated at, I don't think it's the same thing to have a "misbehaving" token of the former and latter kinds.

However, taking into consideration the idea right above this one (that all of the important NTs would, indeed, follow the SRF-20 interface with rigour), I subsede.

[PaulRBerg]

🤝