Solidity - ERC20 Legal Verbiage

Support Contracts
1

Where in the code and what is the proper way to add legal verbiage to my ERC20 Smart Contract?

I’ve seen a few samples where it gets saved on a variable and then that variable value is referenced in the body of a function using memory.

i.e.

contract MyToken is ERC20, Ownable {   
    string public processNumber = "0041518-41.1982.8.26.0053";
    string public legalBinding = "a lot, a lot of verbiage would go here";
    

    constructor() ERC20("MyToken", "MTK") {
        _mint(msg.sender, 9000000 * 10 ** decimals());
    }

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }
    
  function setProcessNumber (string memory v) public onlyOwner() {
    processNumber = v;
  }

  function setLegalBinding (string memory v) public onlyOwner() {
    legalBinding = v;
  }

}

What are those two last functions doing anyway does it ever get executed or just saved in memory?

Is that the correct practice?

Is there a better approach to this?

Where in the code do developers typically add that type of info?

If I’m to save a massive string of text containing all the legal verbiage on a variable, can I save those on a template literal using back-ticks to leverage multiple lines breaks inside the string and so forth?

2

The standard in general is to add legal verbiage to a README or LICENSE file on github.

The standard for smart contracts that will be deployed is to add legal verbiage to the top of your Smart Contract in the form of comments and a license identifier.

You should see many examples with the
// SPDX-License-Identifier: MIT at the top.
Here is a list of licenses.
https://spdx.org/licenses/

I think I may be misunderstanding your question.
Why would you want this to be on the contract somewhere?
You could update it, but why not have it in a README or LICENSE file on github? Direct readers to the github’s readme or license file in your smart contract. That way you can update the README or LICENSE file on github instead of spending the gas on chain.

Usually the standard practice for any coding, not just smart contracts, is to have a reference at the top of your code file to the license or to the README/LICENSE.

Everyone has their own flavor of how they like to do things, but ultimately the goal is to make sure viewers of the code know there is a specific license behind it.

If you absolutely must have this in your Smart Contract, then I think the way you are doing it is “fine”? The two functions at the bottom allow you to change the Legal Statement and the Process number when you need to.

3

@Yoshiko Thank you for the insights - I understand the Readme pattern, but that file won’t get published to the Block chain once you verify the contract. Correct (?)

Is the License File also an .md file, and is it also something to be seeing on Github only?

If so, looks like I’m left with adding a comment section on top of my smart-contract containing the legal verbiage.

4

If you add the verbiage as a comment in the source file, it won’t really end up on the blockchain. Only the compiled bytecode is included in a transaction. If you see the source e.g. on the Etherscan, it was uploaded there separately and is only stored in a centralized way on their servers.

The snippet you cited in the first post would be a way to get the text into the bytecode and then into a storage variable but I don’t think that just putting it in a variable would make it binding in any way. If that was the case then any contract accepting string arguments could be abused by users posting their own licenses into it :slight_smile:

If you really insist on including that info, I think that the right way to go about it would be to get it into the contract metadata. That’s where the SPDX info ends up too. You could use @notice Natspec tag to add it. Whether the user will actually see it or not will depend on the tool he’s using but at least the mechanism is meant as a way to provide an explanation of a specific contract or function to the end users. You could include licensing info there (though if it’s long, it will likely be bothersome to users).

While metadata itself does not go on the blockchain, you can use service like sourcify.dev to easily make it available on IPFS. The compiled contract bytecode contains a hash of its metadata so it’s always possible to prove that a specific piece of metadata matches a deployed contract.

1 Like
5

@cameel Thank you for these insights and suggestions - I’ll dig deeper into these techniques as I get more acquainted to Solidity.