Solidity – Using SPDX License When Importing Other People’s Contracts

contract-designcontract-verificationetherscansolidity

Since Solidity 0.6.8, the compiler started throwing warnings if a contract isn't annotated with a SPDX license identifier:

// SPDX-License-Identifier: MIT

contract MyContract {
    ...
}

Suppose that I'm importing third-party contracts, like those from OpenZeppelin or the UnorderedKeySet library built by Rob Hitchens. I will eventually want to verify the source code of my contracts on Etherscan, and it's common to flatten the contracts before doing that. How should I handle the SPDX identifiers in this case?

It it ok for a flattened file to contain multiple SPDX identifiers?

Best Answer

You're right to note that this is an issue when flattening source code for Etherscan verification. There are two solutions to this.

The best solution is to not flatten the source code and instead use Standard Input JSON for verification. Most tooling plugins support that by now (like truffle-plugin-verify and hardhat-etherscan). If you're not using any of these tools, you can also use the Solt tool which generates a Standard Input JSON file for a specific contract, that can then be submitted to Etherscan.

An alternative (but worse) solution is to use a flattening tool that can remove SPDX Identifiers, such as sol-merger. Then you can add the SPDX Identifier of your choice to the top of the flattened file (or not use one if you like).

Related Solutions

Solidity Contract Design – Setting ‘From’ Field When Calling Other Contracts

Any Ethereum contract (an Ethereum account with EVM code and without private key) controls only its private balance. The contract's balance can be increased by sending a message containing some value to the contract's address. What the contract will do with the balance is defined by EVM code of the contract. In particular, the contract can send some value to other addresses using CALL instruction.

In solidity simple CALL that only sends value (no other parameters) is done with .send() method of address type.

address(0x00ea32d8dae74c01ebe293c74921db27a6398d57).send(1 ether);

In case there is a need to both send value to and call a specific method of other contract, there is .value() modifier that can be applied to method execution.

OtherContract c(0x00ea32d8dae74c01ebe293c74921db27a6398d57);
var argument = 2;
c.take_my_money.value(1 ether)(argument);

Solidity Contracts – How to Import Contracts into Each Other

1) The import keyword will import all global symbols from OtherContract.sol into the current scope, allowing you to use whatever contract definitions are defined in there (or in their nested imports).

2) This is called inheritance. This is an OOP (Object Oriented Programming) concept way broader than importing contracts. You can read some of it in here(*1) and from Solidity's official documentation. Long story short, it's a way to create a contract based on another contract, copying its variables and functions.

3) When a contract uses a library, most of the times (*2) it needs for it to be deployed so that the contract can know its library address at deploy time, to call its methods when necessary. The deployer.link function is to link a deployed library to a contract that uses it. See what does deploy.link exactly do in truffle.

(*1) this blogpost uses python to explain it, but it's the same concept in all OOP languages.

(*2) internal library functions can be inlined at compile time, and there is no need to deploy those libraries. Take OpenZeppelin's SafeMath for example.