curation: signal as an ERC20 token

[abarmat]

Goal:

To have Curation Signal as a transferrable ERC20 token that can be used as a primitive to create more complex use cases on top.

IMPORTANT:

• There is one GST (Graph Signal Token) per Subgraph Deployment.
• The interface is backward compatible to the previous version of the Curation contract.

Implements:

• When signal on a Subgraph Deployment is minted for the first time it deploys an ERC20 token contract for that particular signal.
• Every time new tokens are added to a Curation Pool new ERC20 tokens for that pool are minted.
• When GST is returned to the Curation contract, they are burned and the user get backs GRT tokens in the reserve according to the bonding curve.
• The Curation contract is the only one allowed to mint GST.
• The Curation contract is the only one allowed to burn GST.
• A user holding GST can do anything that an ERC20 can do, except for burning it as it can only be done in the Curation contract.

Remember:

• There is one independent GST token per Subgraph Deployment, for example:

GST-0x4d31d21d389263c98d1e83a031e8fed17cdcef15bd62ee8153f34188a83c7b1c
GST-0x123abcd...
GST-0x321aadd...

[abarmat]

Rebased

[davekay100]

looks good overall

[davekay100]

this and burnFrom could use comments like @dev and @param

[abarmat]

Good catch, will add the natspec.

[davekay100]

also, does burn() ever get used? It looks like just burnFrom() is used. Not sure if we have a future use case for burn() ?

[abarmat]

Yes, I will remove the method. I initially was using ERC20Burnable and overriding the methods like burn and burnFrom to only be called by the Curation contract. Then I decided to just extend the plain ERC20 contract and implement the functions.

[davekay100]

Lets merge 252, then 250, then 254, then 253, then 255. This order will work the best as far as i can tell

[abarmat]

Removed burn() and added many more comments to explain how this works on the natspec.

[abarmat]

I'll merge this one and keep reviewing 250 so we merge in that order: #252, then #250, then #254, then #253

This one #255 could be merged independently as it only changes specific parts of the Staking contract.

[davekay100]

looks good, you can merge