Understanding SRC-3: Mint and Burn

General
1

There appear to be several contradictory statements in SRC-3:

Any contract that implements the SRC-3 standard MUST implement the SRC-20 standard.

And:

Rationale
This standard has been added to enable compatibility between applications and allow minting and burning native assets per use case. This standard has been separated from the SRC-20 standard to allow for the minting and burning for all fungible assets, irrelevant of whether they are Native Assets or not.

If all SRC-3 implementors must implement SRC-20, too, what’s the point of separating the minting and burning logic?

How can a non-native fungible asset implement SRC-3 if they also have to implement SRC-20?

2

Not to speak for the specs team here, but I believe the reason is that minting may come from different places that are non-standard, while still holding an SRC20 compliant ABI.

An example of this is this Constant Product AMM example, where the LP tokens are minted as a by-product of add_liquidity and burn_liquidity and not mint or burn.

This is a good example of where further compartmentalization of the specifications is useful as you can cover more cases with more granular standards.

Constant Product AMM Example:

3

Thanks, @nick!

I don’t understand how this ConstantProductAMM contract is compliant with SRC-3. The standard says that the mint and burn functions must be implemented, but in this case, they aren’t - add_liquidity and remove_liquidity are implemented instead.

If the answer is “the contract isn’t compliant with SRC-3”, what’s the point of the standard, and why bother calling these mint and burn utilities an SRC?

4

Ah, I was only highlighting an example where you could have an SRC20 contract without using SRC3.

The point of separating them is that you can have contracts like the Constant Product AMM where you want to be able to inherit SRC20 but not the burn and mint logic of SRC3.

But I’d let @david expand on this further.

5

Thanks for your answer, @nick.

So the Constant Product AMM is using the SRC-3 burn and mint logic under the hood, but is not inheriting it.

Thus, my question - is it really worth it to standardize these internal functions as an SRC? Sorry if I come across as rude, but that seems overkill to me.

Wouldn’t enshrining them in the standard library have been sufficient? Just like how the ERC-20 mint logic has been implemented and maintained by OpenZeppelin over time.

6

So this contract has minting and burning functionality, but doesn’t inherit SRC3.

I think the idea behind SRC3 is that if a contract can conform to it’s pattern, it’s useful for making minting and burning a standardized interface. Of course, some cases will not be covered by this ABI so it’s not right for everything.

You might be right that it could be considered overkill, but we are trying to get ahead of obvious minting and burning cases where these ABIs may fulfill a vast majority of cases.

I think this standard is useful even just for example purposes for Sway.

Again, curious to hear what @david has to say.

1 Like
7

SRC-3 only defines the contract interface, not the logic. Same pattern as ERC standards, which typically only enforce interfaces, not implementations.

So the AMM nick described only implements SRC-20, not SRC-3.

1 Like
8

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.