SBRC-20: a token standard to ensure backward compatibility for ERC-20

[PaulRBerg]

Context

I hinted at this design in this comment.

Token Standard: SBRC-20

Design

The API will be identical to ERC-20, but the transferFrom functionality won't work (as explained here).

In practice, this is what we will do:

1. Fork OpenZeppelin's ERC-20 implementation.
2. Rewrite the allowance, balance, and transfer logic to conform to the SabVM spec.
3. Add minting and burning logic
4. Offer the newly generated SRBC-20 as a template for developers to use for quickly creating tokens.

Goals

• Ensure backward compatibility with ERC-20 to the maximum extent possible.
• Provide a ready-to-use template.

Notes

• The name is TBD but SBRC works for me.
• SRC-20 has already been taken by Fuel and Bitcoin Stamps.

Related

• EVM Incompatibilities #91
• Actions that trigger a subgraph update #81 (reply in thread)
• https://github.com/FuelLabs/sway-applications/tree/9b124db85722717dd7f597f5c4681c8cf1c7269c/native-asset

[PaulRBerg]

Terminology

Let's settle this once and for all, @IaroslavMazur:

• SabVM only has NTs. Whether they are deployed in a contract that mints a single NT or multiple NTs, they are called the same.
• We shall refer to the contract that deploys a single NT as an SBRC-20 contract.
• We shall also refer to SBRC-20 contracts as NTs.
• We shall NOT refer to SBRC-20 contracts as "application-level tokens".

[IaroslavMazur]

In practice, this is what we will do:

As we've discussed somewhere else on GitHub, the balanceOf() ERC20 function would also need to be rewritten to call our MNABALANCE opcode.

If this isn't done, then, someone transferring the NTs directly (i.e. by specifying the transfer details in the transferred_tokens part of the Tx - and not via the transfer() function of the SBRC-20 contract) would, practically, "break" the accounting inside the smart contract.

*an alternative solution/workaround to this would be for the contract to keep all of the NTs to itself, but this would damage the UX of the token holders (e.g. the NA couldn't be streamed, in this case).

---

Similarly, the transfer() function would need to be rewritten to require the caller to pass the contract the NA to be transferred - and transfer the passed NA amount to the specified recipient. The amount argument would be deleted, being redundant.

This - again - if the total of the minted NTs are not "locked" by the smart contract minter, with just the wrapper tokens being "transferred" between the users.

---

All in all, the ERC-20 implementation would, pretty much, need to be rewritten completely to properly work with the NTs 🙃

[PaulRBerg]

the balanceOf() ERC20 function would also need to be rewritten to call our MNABALANCE opcode.

Yes. I have updated the OP to clarify this.

the transfer() function would need to be rewritten to require the caller to pass the contract the NA to be transferred

This makes me think that maybe this SBRC-20 ideas wasn't so good after all ..

[IaroslavMazur]

This makes me think that maybe this SBRC-20 ideas wasn't so good after all ..

The thing is that, in contrast to the "adaptability" of the Tx types (i.e. introducing a new Tx type, native for our VM, but being able to "represent" it as the other, standard Tx type), here, we can't really "pretend" we accept the old-school ERC-20 transfers, because they're fundamentally different (wrt the push/pull dynamics).

Even if we try to accept the old-style transfers, we simply won't be able to process them correctly, because at the end of the day, someone needs to come up with the NTs that are being transferred, and that "someone" must be the caller of the transfer() function. Otherwise, the SBRC-20 contract will immediately enter the territory of bad accounting...

---

Now, I don't think not being able to fully comply with the standard ERC-20 is necessarily a deal-breaker. It does highlight the fundamental differences between the ERC-20 tokens and our NTs, but this just goes to show that the NTs cannot be viewed as the simple ERC-20 tokens, because they're much more than that.

The lack of the allowance/transferFrom() functionality that you've initially hinted at in the OP was already enough to make the SBRC-20 wrappers of the NTs incompatible with the existing EVM dApps working with the ERC-20 tokens. In other words, those dApps would have to adapt/change their workflows to work with NTs, anyways.

---

The above being said, I believe that it's still a good idea for us to come up with a SabVM-specific interface, similar, in nature, to that of ERC-20. Or, maybe, even 2 such interfaces...

Wdyt about keeping this "new/enhanced/SabVM-specific ERC-20" token standard that we have been discussing here (i.e. SBRC-20), but, then, also introducing the ERC-20-like interface/standard, which would require the smart contract to "lock" the wrapped NTs (losing a part of the SabVM functionality, such as the direct streaming of the underlying tokens), but, in exchange, would allow them to closely mimick the standard ERC-20 behavior, including the allowance-transfer logic?

So, we'd have:

1. one token standard for launching a "full-fledged NA smart contract wrapper" (to decrease the level of confusion, the name of this standard shouldn't contain "20", btw) and
2. another one - to simplify the onboarding of the EVM dApps that would like to come to SabVM, but would only like to support the "ERC-20 token-like workflows" (which would, a propos, also include the old-style ERC-20 tokens deployed to SabVM).

[PaulRBerg]

I suggest we have only one token standard with fully-fledged NA capabilities.

we can't really "pretend" we accept the old-school ERC-20 transfers

Yes.

it's still a good idea for us to come up with a SabVM-specific interface, similar, in nature, to that of ERC-20
Wdyt about keeping this "new/enhanced/SabVM-specific ERC-20" token standard that we have been discussing here

Agree. What I am less convinced about is the naming. SBRC-20 would give the false indication that it's similar to ERC-20, when in fact, it isn't.

also introducing the ERC-20-like interface/standard, which would require the smart contract to "lock" the wrapped NTs

Completely against this.

We don't want fragmentation of token standards. We want just one.

the name of this standard shouldn't contain "20", btw

Agree

[IaroslavMazur]

I suggest we have only one token standard with fully-fledged NA capabilities.

Well, we can only have one "fully-fledged" standard, really. But I think we already agree about this.

---

What I am less convinced about is the naming. SBRC-20 would give the false indication that it's similar to ERC-20, when in fact, it isn't

When I started writing this message, I was gonna suggest that if the "fully-fledged NA wrapper" standard only lacks the allowance-related functions, then, we could still keep the -20 postfix, to resemble the ERC-20.

However, after a closer look at the IERC-20 interface, I realized that w/o the allowance logic, our interface would lack most of the IERC-20 symbols: the allowance(), approve() and transferFrom() functions, as well as the Approval event.

The above, paired with the other differences that our interface will have (e.g. the transfer() workflow now being push- and not pull-based), made me change my mind: I now think the differences are too big and numerous for it to be reasonable to still pursue the resemblance with the IERC-20 standard.

---

We don't want fragmentation of token standards. We want just one.

I do understand your concerns, and agree that, in general, it'd be better to have just 1 standard "to rule 'em all".

However, as we've discussed previously, we can't also make "the one" (standard) directly compatible with the classic ERC-20. The latter means that by refusing to officially "accept"/"approve of" the ERC-20 tokens on SabVM, we're also willingly forfeit the "compatibility" with all of the ERC-20-based EVM dApps currently built.

The big q is whether the potential upside (in the long-term future, when enough "native", NA-compatible dApps are built) is worth the immediate downside of officially "not supporting" the ERC-20 standard on SabVM 🤔

[PaulRBerg]

I now think the differences are too big and numerous for it to be reasonable to still pursue the resemblance with the IERC-20 standard.

Great, so we are on the same page then.

we're also willingly forfeit the "compatibility" with all of the ERC-20-based EVM dApps currently built.

Yes.

The big q is whether the potential upside ... is worth

Yes, totally. We're building a payment streaming chain, not a one-time transfer payments chain.

[PaulRBerg]

I am deprecating SBRC-20 in favor of SRC-20: Single Native Token:

• https://github.com/sablier-labs/SRFs/blob/main/SRFs/srf-20.md
• https://github.com/sablier-labs/stdlib/blob/main/src/standards/srf-20/SRF20.sol